[dns-operations] SE and the value of having NS in more than one TLD

Phil Regnauld regnauld at nsrc.org
Wed Oct 14 13:37:25 UTC 2009


Calvin Browne (calvin) writes:
> 
> Perhaps saying something like "If you're running a large TLD, and
> it is trivially possible to remove a dependency on one single zone file,

	By definition, if you're running *a* large TLD, you've got a dependency
	on a single zone file -- that of your TLD :)

	When you're running a production chain of this sort (in this case, a
	TLD receiving updates to a zone, updating the zone, provisioning the
	nameservers that will serve this zone -- but this applies to *any*
	other data processing system), you can mitigate the risk of publishing a
	flawed output by instrumenting the different points in the process so
	that you may abort and catch errors as early as possible.

	For instance, .CL's verification of the zone size, or using a "marker"
	record in the zone that can only be present if the entire zone has been
	exported correctly.  But if the problem happens early enough and hasn't
	been foreseen, it can bite you, no matter how many redundant checks
	are implemented.  Also, proper change procedures are required when you
	modify the production chain so as to catch new possible error scenarios.

	Some organizations still haven't understood that Development, Testing and
	Production are three separate systems :)

> some might even suggest using more than one registry ;-)

	That's a more interesting idea -- multiple ways of creating the zone,
	with different data paths.  But ultimately the nameservers out there
	still need a copy of a zone, and if you can't automatically detect
	that the zone from registry A is flawed before you push it, it won't
	help that registry B has produced a correct copy.  Caching is a bitch.

	Monitor, detect, alert, abort.

	P.



More information about the dns-operations mailing list