How not to set up your DNS (part 12)

September 27, 2006

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.


Comments on this page:

By Dan.Astoorian at 2006-09-28 11:05:07:

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).

"With the same answers" is slightly stricter than necessary. Some leeway is tolerable, just as it's acceptable for slave servers not to report the same answers as the master during the refresh+retry period between the update of a zone and the zone transfers. "With valid answers" would be a more apt rule.

From a technical perspective, the ideal behaviour, I think, would be for the Symantec servers to be configured as slave servers off of the UltraDNS servers until all of the NS records in the rest of the delegation tree expired, but this is administratively too much to expect of providers; an adequate second best would have been for the Symantec servers to be left alone (i.e., continue to serve obsolete records as though it were still authoritative) for a sufficient time to allow the obsolete records in the parent domains to go away.

Then there's the problem of name services that don't honour the TTL on DNS records correctly, but that's another rant entirely.

--Dan Astoorian

Written on 27 September 2006.
« Why people still like TCL/TK
Why I hate $LANG and locales on Unix »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Sep 27 21:44:32 2006
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.