2005-12-08
How not to set up your DNS (part 5)
This one is partly my fault, due to me inheriting responsibility for managing DNS for this organization. (Needless to say it's fixed now, but it gives me a useful cautionary example.)
This won't be presented in illustrated form, because it's simpler
to just explain the problem. All of this is for the domain
transportationtomorrow.on.ca.
- according to the .ca nameservers, the nameservers for the domain are ns1.jpint.utoronto.ca and mto.jpint.utoronto.ca.
- mto.jpint isn't responding with useful information (for complex reasons).
- ns1.jpint claimed that the nameserver for the domain was 'ns1.transportationtomorrow.on.ca'.
- ns1.jpint had no A record for ns1.transportationtomorrow.on.ca.
Odd things start happening when you and the level above you disagree on what a domain's NS records are. Worse things happen when your set of NS records don't work; usually what happens is that the first query works but subsequent queries fail.
(This happens because answers to DNS queries also usually contain NS records as well. So the first query is made to the real nameservers, but comes back with broken NS records as well as the answer. Your local nameserver then caches the broken NS records, and until they time out will try to send subsequent queries off to them.)
Actually the situation is not quite fixed yet, because I've been unable
to figure out how to make the Solaris 2.4 machine's nameserver manage a
successful zone transfer from the Bind 9 machine; named-xfer becomes
unhappy with life, dying with the helpful error message 'getzone:
print_update failed (46, 60)'.
(Why is the machine still running Solaris 2.4? Well, it's a Sparcstation 2, so the upgrade options are somewhat limited. We will probably try to install Debian on it at some point, just to have relatively recent versions of various daemons.)