Re: djb and multiple IPs
Craig Sanders writes:
> yep, that's the obvious way to do it. it does leave a few questions,
> 1. can this kind of setup return authoritative answers?
I don't think so, you would only be talking to dnscache. If you want a public
dns server, you need to run tinydns on a public IP address.
> 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.
You need to setup axfrdns to handle zone-transfers. tinydns & axfrdns can run
on the same IP address, because they use different protocols (udp and tcp,
> 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?
[snip potential flammable material ;-]
> 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 :)
If you don't provide dns cache (recursive) services to your clients, there's
no problem. If you do, you can install new caches at different IPs and give
your clients time until you migrate your bind dns servers.
> 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.
Then you'd be (almost) back to bind.