Wes Hardaker wrote:
>>>>>> On Sat, 21 Mar 2009 22:44:42 -0700, Doug Barton <do...@dougbarton.us> 
>>>>>> said:
> DB> I've read the draft at the URL above and am generally supportive of
> DB> its moving forward.
> 
> Doug,
> 
> Thanks for responding with a review about the Management Requirements
> document.  I've applied all your very useful changes to the draft.

I'm glad to be of service. :)

> I only had a question/comment about one of them:
> 
> DB> 3.1.1 Needed Control Operations
> DB> The ability to do a reload on an individual zone should probably be
> DB> mentioned here.
> 
> That's probably a good point but I think it's worth checking to make
> sure anyone else reading this has a problem with this.  Supporting
> partial reloads (be that split line along a zone data set or something
> more granular) is potentially more intensive than a complete reload.
> 
> You're right the original text didn't really specify anything (though it
> implied a complete reload).  How does this bullet replacement sound:
> 
>   OLD:     Reloading zone data
>   NEW:     Reloading some or all of the zone data sets
> 
> I'm not sure "sets" should be in there or not...  I think it conveys the
> boundary line better though.

That wording may imply granularity at less than the zone level, which
I'm not suggesting but would not be opposed to.

In regards to the necessity of supporting reloading of less than the
whole server, when I was at Yahoo! I had well over 500,000 zones
configured on the name servers we used for our registrar-reseller
operation. A cold start/full reload of those name servers took a very
long time, IIRC somewhere in the neighborhood of 20 minutes. While we
had redundant systems that handled the load for the occasional cold
start, knocking the whole server off line for 20 minutes every time a
user made a change to their zone (or the system did it for them) would
have resulted in effectively no name service at all. Individual zone
reloads are essential in this environment, and I believe they are a
requirement for any kind of DNS management system.


hope this helps,

Doug
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to