== How not to set up your DNS (part 6) 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|http://www.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.)