Florian Weimer wrote: > * 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 case it should read server de.pool.ntp.org iburst server de.pool.ntp.org iburst server de.pool.ntp.org iburst but that can result in your getting the same IP address for each of them which is a problem particularly if you have remembered the last query. Use of the new config option pool de.pool.ntp.org iburst would avoid that since it uses up to 10 IP addresses for NTP servers to use from the list of IP addresses returned by the one getaddrinfo() query. Here too you want to avoid any kind of preferred order. The use of more than one returned address completely obviates the need for RFC3484 which somehow assumes that you are only going to use one address. Section 6 assumes prior knowledge of the addresses returned, either by the O/S or the application. For example, Rule 1 talks about unreachable addresses, but we won't know if they are unreachable unless we try that address or have some OOB means of knowing and in any case are they temporarily unreachable or permanently unreachable? Rule 3 talks about deprecated addresses. What's that and how would anyone know if an address is deprecated? Also if it is deprecated why is the DNS returning it? Danny -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf