Re: [dnsext] Re: RFC 3484 section 6 rule 9 causing more operational problems

[Ask Bjørn Hansen <[e-mail]>]

On Mar 8, 2009, at 21:24, Danny Mayer wrote:

>> i'm not sure we're in the same discussion.  pool.ntp.org is using  
>> short
>> ttl and silent truncation and round robin.  there's no geo-ip  
>> stability
>> that could be hurt by client-side reordering or rerandomizing.  and  
>> the
>> nameserver examples you gave are all subject to rdns RTT sorting.   
>> the
>> "large RRset" approach works just fine, and is not related to Rule 9.
>>
>
> pool.ntp.org divides itself up into subdomains (okay they are really
> hostnames) for each country-code so that you get addresses in that
> country code. NTP in the future will take advantage of the fact that  
> it
> gets back multiple addresses and will use more than just one of them  
> to
> find NTP servers. The order does not really matter and it's better  
> that
> there be no particular order so that we do not overload any one  
> server.


Hi everyone,

Funny the NTP Pool was brought up as an example.  I'm looking after  
pool.ntp.org and I actually subscribed earlier in the week to comment  
on the round robin issue.  :-)

It's a little more complicated than what Paul described above  
(although it worked like that until ~2005 when I took over maintaining  
the system).

When you query pool.ntp.org (or 1.pool.ntp.org etc), the DNS server  
does the "IP to geo-location" thing to automatically select the "sub- 
zone".  You can also explicitly ask for the sub-zone with  
0.us.pool.ntp.org, 0.north-america.pool.ntp.org, etc.

Paul is right that there's no problems with geo-stability because the  
DNS server will generally just give you servers from one area anyway;  
but we can get hurt by dumb re-ordering.

For distributing the load[1] we depend on clients making mostly random  
picks when receiving multiple A records.

Within each "zone" we have anywhere from a dozen to 1000+  
servers[2].   The DNS server will return a list of A records weighted  
by the bandwidth the server administrator have told us they have.   
This is absolutely crucial.  Before I implemented the current system,  
we just used a frequently updated zone with rotating A records and  
once or twice a day server operators with a small pipe (say a T1) or a  
small scale "router" would get overloaded enough that they'd leave the  
pool.

It's critical to the longevity and the geographic diversity of the  
pool that "small operators" are able to contribute; even if they  
handle much less traffic than others.

If "RFC 3484 section 6 rule 9" really is implemented with "matching"  
prefixes all the way up to /2, I'd worry that could mess up the  
weighting we do and cause operators on "unlucky" IP addresses to have  
to stop offering their service.

Since the DNS server does most of the weighting by giving just a few  
records from a usually much larger set, I could just return fewer A  
records to force "my choice".   But returning ~5 A records is valuable  
- some NTP servers knows how to use multiple A records from one lookup  
(ntpd in the future being one of them, as Danny pointed out).

Having the client be "smart" would be absolutely unhelpful.  Someone  
was arguing that the client might have useful network knowledge to  
apply.  I don't know of any actual implementations of that whereas  
there are lots of deployed implementations with the DNS server being  
smart and/or deliberate about the records returned.


   - ask

[1] The NTP Pool is used a lot.  You'd have an unlikely network to not  
have some local users.  It's the default in for example most Linux  
distributions and many consumer devices.  Practically none of the  
manufacturers contribute anything back; but the whole point of the NTP  
Pool is to preserve NTP as a useful public resource, so better us than  
some poor overloaded NIST server!

I don't know how many clients we have; but the name servers do about  
20m requests a day; and that's basically only counting "dumb" ntp  
clients because the long running daemons generally just do one set of  
lookups on startup.  It also, obviously, doesn't count the effects of  
local caches.  In any case: It's a lot of users.

[2] There are ~1743 active server in the pool right now distributed  
around the world: http://www.pool.ntp.org/zone - about 1000 in Europe  
and just under 600 in North America, http://www.pool.ntp.org/zone/ 
europe and http://www.pool.ntp.org/zone/north-america

-- 
http://develooper.com/ - http://askask.com/