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 <[EMAIL PROTECTED]> Fabricati Diem, PVNC. -- motto of the Ankh-Morpork City Watch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]