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

[Florian Weimer <[e-mail]>]

* Paul Vixie:

>> > some number of vendors have depended on revenue from selling this
>> > feature but i'd say that only a small number of sites ever saw any
>> > benefit from it.
>> 
>> pool.ntp.org, security.debian.org, rsync.gentoo.org,
>> [a-o].ns.spamhaus.org, [a-n].surbl.org.  In general the "large RRset"
>> approach is used by those who do not buy special DNS appliance to serve
>> their zones, I think.
>
> 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.

The NTP issue is rather specific and affected ntpd when you had

server pool.ntp.org
server pool.ntp.org
server pool.ntp.org

in your configuration.

And some those mirrors I mentioned are affected by *deterministic*
reordering.  They don't care if traffic hits the closest instance,
they want to spread the load (security.debian.org, for instance, is
difficult to serve from a single node from time to time).

> and the nameserver examples you gave are all subject to rdns RTT
> sorting.

If you follow Rule 9, you haven't got that many RTTs to sort by: Rule
10 ensures that there is a single IP address you should use as long as
the service on it is reachable.  Unless you cheat, deviate from Rule
9, contact additional servers, and gather additional RTTs--but you
have to cheat to get that data.

> and they have to use drastically low TTL's to prevent mobility from
> breaking their assumptions.  and they have no way to cope with opendns or
> any other global or semi-coherent caching layer.  and even when they use
> TTL=0 and happen to be talking to an rdns who shares topology with the
> stub, they're making an educated guess without knowing what kinds of
> wormholes the stub may have access to, whether VPN, private interconnects
> that don't show up in global BGP, or whatever.

Well, if it's not a good idea, why are most large web sites served
this way?

I suspect there is currently no better way to distribute initial
client requests than to play DNS tricks.

-- 
Florian Weimer                <[e-mail]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: [phone]
D-76133 Karlsruhe             fax: [phone]