Re: djb and multiple IPs
On Tue, Nov 26, 2002 at 08:04:05PM +0100, Kinszler Balazs wrote:
> > > cache and a server running on the same machine, which can only
> > > have one public IP address?
> >
> > Yes. I mean, I can assign more addresses but queries must come to
> > the same address (and answers must go back from the same address).
>
> Set up external dnscache on the public IP, and set up tinydns on IP
> 127.0.0.1
>
> Then, if you host a domain eg. test.com, you simple create a file:
>
> echo "127.0.0.1" > /service/dnscachex/root/servers/test.com
>
> So when a client is asking for the domain on the public IP, dnscache
> will ask tinydns on local IP about the domain. This way queries can
> go to one IP, and come from the same.
yep, that's the obvious way to do it. it does leave a few questions,
though:
1. can this kind of setup return authoritative answers?
2. can it handle incoming zone-transfer requests for your secondaries?
getting other ISPs to change their secondary configuration can be a
pain, but getting a customer (who happens to secondary their own domain
from your server - not an uncommon situation) is almost impossible.
3. can tinydns send a zone xfer request from the real IP address even
when it's configured to run only on 127.0.0.1?
i eventually intend to switch from bind to nsd (an authoritative-only
nameserver with a real open-source license that uses bind zonefiles
natively and operates like a normal unix daemon without any bernstein
weirdness), but there are a few things i need resolved before that can
happen.
the main issue is legacy configurations. it's all very well to give the
djb standard answer of "throw it all away and start from scratch" but
the real world doesn't work like that - i can't just change the IP
address of either our authoritative or recursive nameserver (currently
the same server).
if i tried doing it, there'd be a week of two of complete chaos, with
almost all customers getting the impression that our service was broken
(to their eyes, it would be)...and i'd still be dealing with customer
problems months later because some customers are just incapable of
following clear and simple instructions, sometimes it's difficult enough
getting help desk staff to understand what needs to be done - i know all
you ISPs out there will find this hard to believe, but it's true :)
what would be useful here is an application layer DNS proxy sitting on
port 53 (both tcp and udp), with both authoritative and recursive
servers on other IP addresses. that way neither customers, secondary
servers, nor help desk staff would need to do anything - as far as
they're concerned, nothing has changed.
the proxy should have access to the config for the authoritative
nameserver (or, at least, a list of authoritative domains plus a list of
who is allowed to zone-xfer them) and transparently forward requests for
those domains to that server. all other requests get transparently
forwarded to the recursive nameserver.
actually, that's something that could be built into nsd - if it is
authoritative for a given request then answer it, otherwise proxy it to
a recursive server.
craig
--
craig sanders <cas@taz.net.au>
Fabricati Diem, PVNC.
-- motto of the Ankh-Morpork City Watch
Reply to: