[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