Anthony Towns writes ("Re: glibc's getaddrinfo() sort order"):
> Stability is useful for any case where the servers hosting a particular
> might be out of sync with each other; eg, if stability could be assumed
> we'd have less errors where an invocation of "apt-get update" chooses one
> mirror, and a subsequent "apt-get upgrade" chooses a different server
> that hasn't finished syncing. Hopefully "apt-get" isn't considered
> "too pathological to live"...If an application needs to get (or prefer) the same address each time, it is trivial to have it save the answer from the DNS lookup (preferably, honouring the timeout). Note that _when apt started doing rule 9 it broke our own ftp site_ ! > > One of the existing use cases that breaks is round-robin DNS. > > Round-robin DNS isn't broken; the expectation of (approximately) equal > load-distribution across all servers in a round-robin is broken. DNS administrators currently configure multiple addresses in order to achieve equal load distribution. > Better routing has less direct benefits to the client, probably limited > to slightly better ping times, with a small chance of somewhat cheaper > bandwidth costs. For the people providing the service, it lets you make > better assumptions as to load balancing -- you can expect the servers > based in a particular area to be serving a load proportional to the > number of users in that area, rather than having the load fairly evenly > distributed globally. Of course, there are other ways of doing this > that don't rely on how the client's resolver is implemented. Of course, > if the routing is worse, those turn into drawbacks instead of benefits. This "number of users in that area" idea is _not_ what DNS administrators currently mean when they configure multiple IPv4 addresses. And of course that's not what rule 9 does, as Steve has explained. > Even without the possibility of applications like apt-get benefiting > from stability of results, I don't think we've done anywhere enough of > a review to be declaring that there aren't any benefits to rule 9. You're asking us to prove a negative. And, this is the wrong analysis in any case. Regardless of whether rule 9 for IPv4 would have some theoretical (or even practical benefits) it is _not the current standard_. The current standard, as expected by DNS administrators who actually configure multiple addresses, is the behaviour of gethostbyname. AJ: You keep dodging this point. Can you please explain why if getaddrinfo should do rule 9, gethostbyname shouldn't ? Or to look at it another way, why whether an application applies rule 9 for IPv4 should depend on whether that application has been updated to allow it to support IPv6 ? > As far as I can see, for rule 9 to be fundamentally misguided and > broken, the concept of providing a stable answer, or a better than random > ordering, would need to be harmful. If they're beneficial, even in some > cases, then we've got a problem in the details of the specification, > not a fundamental issue. Yes, providing a stable answer _is_ harmful precisely because the whole point of round robin DNS is to _not_ provide a stable answer, because that allows a server operator to spread load effectively (and various fringe benefits). > Uh, round-robin DNS isn't a guarantee that any individual client will > get different or randomised results -- and the argument that round-robin > won't break anything that relies on rule 9 goes the other way too. There aren't Internet protocols where server operators have deployed multiple IPv4 addresses relying on rule 9. You can see that quite easily, because any application that happens to use gethostbyname rather than getaddrinfo won't work. > Further, having getaddrinfo() behave differently for IPv4 and IPv6 > isn't completely helpful in making Debian support IPv6 -- if we change > a program from gethostbyname() to getaddrinfo() under the assumption > they behave the same way and that's fine (for IPv4), but getaddrinfo() > for the particular app for IPv6 requires extra randomisation or the > addition of fail-over code to work sensibly, we're not done. The difference is that it is alleged (by rule 9 proponents) that DNS operators who configure multiple IPv6 addresses ought to do that only when they want rule 9. As Steve and I have explained, we don't think rule 9 makes sense for IPv6 either. However, there is only a very small base of IPv6 use at the moment, and of course clients which can do IPv6 have necessarily already been converted to use getaddrinfo, many implementations of which have done rule 9 for some time. Ie, using rule 9 is more common for IPv6 and DNS administrators therefore already can't publish multiple AAAA RRs and expect to get the benefits of the DNS round robin. Or to put it another way: the IMO irrefutable argument I'm laying out against rule 9 for IPv4 is that _existing DNS configurations_ where multiple IPv4 addresses are published expect that those addresses will be treated by client systems the same way they have been for decades: according to round robin DNS. This argument doesn't apply to IPv6. So that's why I think it is impossible to argue coherently that rule 9 is correct for IPv4, but at least conceivable for IPv6. > It's sound to a point, but we haven't established an understanding of > what common behaviour on today's internet actually is, we haven't done any > review of how getaddrinfo() is being used outside of our own experiences, > and we haven't made any examination of how we can achieve the apparent > goals underlying the proposed standard without the drawbacks that are > concerning us. COMMON BEHAVIOUR ON TODAY'S INTERNET IS THAT IMPLEMENTED BY GETHOSTBYNAME. How many times do I have to explain this ? getaddrinfo is the REPLACEMENT FOR GETHOSTBYNAME. It is not an interface which applications choose because they want different address sorting behaviour. It is the interface applications MUST USE TO SUPPORT IPV6. Changing applications to use getaddrinfo instead of gethostbyname is done BECAUSE THOSE APPLICATIONS ARE BEING UPDATED TO SUPPORT IPV6. Updating an application to support IPv6 should not change the way it treats DNS RRsets containing multiple IPv4 addresses. Obviously. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
