How not to set up your DNS (part 12)

Last week Securityfocus, home of a number of reasonably active mailing lists that our users like getting, changed their nameservers from the Symantec corporate nameservers to UltraDNS. And then the Symantec corporate nameservers promptly stopped giving useful answers to queries about the securityfocus.com domain (instead returning the standard 'I have nothing to do with them' results of a referral to the root zone).

Since the mailing lists are reasonably active and we do check to make sure that the MAIL FROM domain actually exists (much like most of the rest of the Internet), our nameserver had the old NS records cached. The ones that now disclaimed authority, thereby creating temporary DNS failures when we tried to verify the MAIL FROM of new email from Securityfocus mailing lists.

(We eventually 'solved' the problem by restarting our caching nameserver, thereby purging its cache of the old NS records.)

All of this points out the golden rule of DNS server transitions: you need both the new and the old NS servers answering queries (and with the same answers). In a sense it is a form of garbage collection; you shouldn't turn off the old DNS servers while anyone can legally still have a cached reference to them.