ietf
[Top] [All Lists]

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

2009-03-09 13:14:59
* 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                <fweimer(_at_)bfk(_dot_)de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>