Today's illustrative example is about the odd things that can happen if you rename a nameserver without making sure that you tell the people delegating zones to you.

There are four nameservers for utoronto.ca : ns1, ns2, bay.cs, and ns1.tpc.int (following local practice, I'm dropping the .utoronto.ca bit a lot). Three of those four (everything except ns1) are also secondaries for all campus subdomains, including the domain jpint.utoronto.ca .

; sdig ns jpint.utoronto.ca.
ns1.jpint.utoronto.ca.
bay.cs.utoronto.ca.
ns2.utoronto.ca.
ns1.tpc.int.
; sdig a ns1.jpint.utoronto.ca.
128.100.16.12

There is also another machine, mto.jpint . Most of the time, if I asked for its IP address I got 128.100.16.27. Except once or twice, I didn't; I got 128.100.16.12, ns1.jpint's IP address.

Unfortunately, this nice proper set of NS records was a lie. The lie was exposed by asking ns1.utoronto.ca for NS information for jpint ; it was of the opinion that the right nameserver was mto.jpint , to be found at the IP address 128.100.16.12.

What had happened is that jpint had renamed their primary nameserver; what had been 'mto.jpint' became 'ns1.jpint', and the 'mto.jpint' name was given a new IP address. But no one told the campus nameserver people about this, so the utoronto.ca zone carried the old NS data, with the old glue record for mto.jpint with its old IP address.

As secondaries, three out of four of the utoronto.ca nameservers then fetched the jpint zone from 128.100.16.12, and replaced their own idea of the jpint NS records and mto.jpint 's IP address with the zone's information. Because it is not a campus secondary, ns1.utoronto.ca did not, preserving the original info to be handed out when queried.

As you can see, this is really quite hard to notice; the only real sign was the 'blue moon' wrong IP address for mto.jpint . I only really chased this down when I ran the domain through the dnsreport.com DNS consistency checker and it picked ns1.utoronto.ca to pull DNS information from, leading me to wonder just why ns1.jpint was being reported as a 'stealth NS record'.

This isn't a new problem; similar issues (but worse) used to happen in the old InterNIC days. (An explanation of those problems does not fit in the margin of this entry.)

(The jpint situation is in the process of being fixed, so hopefully soon you won't be able to see this for yourself.)