[nsd-users] reloading NSD zone configuration

[Greg A. Woods]

At Wed, 20 May 2009 22:22:22 -0700 (PDT), Aaron Hopkins <lists at die.net> wrote:
Subject: Re: [nsd-users] reloading NSD zone configuration
> 
> On Thu, 21 May 2009, Greg A. Woods wrote:
> 
> > May I humbly suggest that if you are making promises you cannot possibly
> > keep because of protocol design and real-world limitations then perhaps
> > you should more urgently be attempting to change your customer's
> > expectations
> 
> You are confusing the worst-case with the average case here.

Well, personally from an SLA point of view I firmly believe user
expectations should be set for the _worst_ case if you wish to avoid
issues.  It also offers you the chance to impress users when you can
consistently exceed their expectations in the normal average case.

If you tell your new users that it will take on the order of at 30
minutes (plus the TTL of any RRs if the zone was previously served by
any other NS, plus the time for the parent zone servers to consistently
(re)delegate the domain) under ideal circumstances before everything is
in sync and their new domain is fully functional, and you tell them that
you will send them an e-mail notification(s) when all of this has
happened, eg. showing confirmation that all NS hosts are actively
serving the new zone, and then again when all NS hosts are properly and
consistently delegated in all the NS hosts for the parent zone, then
they will have proper and appropriate expectations.  I.e. tell them what
to expect, and give job completion confirmation automatically.  That's
what expectation management is all about.  Without knowing what to
expect then users will make up their own ideas, and they will ignore
critical issues such as TTLs for any existing NS records, parent zone
update cycles and timing, etc., etc., etc.  If you fail to set
reasonable user expectations then you will end up in the uncomfortable
place of being unable to (easily) meet their unreasonable demands.

I believe one of the most important things to do in implementing your
infrastructure is to ensure that configuration changes are batched.
Don't try to trigger reloads on customer demand -- do regular rolling
reloads every 20 minutes or so (thus the suggested 30-minute SLA).  This
design was best when using BIND, and it is still best for NSD of course.

I think the primary concept of using periodic batched config updates on
a rolling schedule to each auth server should answer all the practical
problems for most small DNS providers.  Of course those hosting very
large numbers of domains should also consider some of the other more
expensive suggestions given in this thread, such as using load balancing
to a cluster, or a hot standby with CARP, etc. -- not to improve new
customer setup time, but rather to improve reliability and availability.
Also there may be some pending optimizations on this front as per the
TODO file, especially if someone steps up to code them.

-- 
						Greg A. Woods

+1 416 218-0098                VE3TCP          RoboHack <woods at robohack.ca>
Planix, Inc. <woods at planix.com>      Secrets of the Weird <woods at weird.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://lists.nlnetlabs.nl/pipermail/nsd-users/attachments/20090527/a412f9b9/attachment.bin>