Kurt Roeckx writes ("Re: glibc's getaddrinfo() sort order"): > It's atleast in the spirit of the rfc to prefer one that's on the local > network. It might be the intention of rule 9, but then rule 9 isn't > very well written.
I agree that applying RFC3484 section 6 rule 9 to IPv4 addresses is a mistake and that therefore we should change the default in Debian accordingly. I would encourage Kurt to take this matter up with the relevant IETF working group. Others have already written about problems involving NAT. I agree with this argument (although I don't approve of NAT and it galls me to use some braindamage involving NAT as an argument for anything). However there is another argument I would like to make: A host using getaddrinfo configured to apply rule 9 to IPv4 addresses will behave quite differently to a host using gethostbyname. I think that this change in behaviour is unwarranted. Whether an application uses gethostbyname or getaddrinfo is an implementation detail (related closely to whether that particular application's source code has been modified to try to support IPv6) and this should not change the behaviour. Presently when connecting to a service offering only IPv4 addresses, most hosts will use gethostbyname and use the addresses offered in round-robin DNS order. That is to say, the meaning (pre-RFC3484, and current de-facto) of a DNS RRset containing several IP addresses is that the addresses should be tried `uniformly at random' by callers, as done by the nameserver round-robin RRset rotation algorithm. RFC3484 section 6 rule 9 applied to IPv4 appears to be an attempt to change that meaning. This interpretation of rule 9 for IPv4 as an attempt to change the meaning of existing deployed DNS RRsets is supported by the fact that proponents of rule 9 for IPv4 claim that it will fix existing problems, as in http://udrepper.livejournal.com/16116.html. However, it is obviously wrongheaded to attempt to change the defined meaning of all existing multi-record A RRsets. On the existing Internet, zone administrators use multi-record A RRsets in the knowledge that those RRsets will be used by callers in an evenly-distributed round-robin fashion as currently implemented by bind and gethostbyname. This meaning for multiple A records had been established for well over a decade by the time 3848 was written and in the intervening years it has continued to be dominant. New systems, and systems newly modified to support IPv6, should continue to interpret existing A RRsets in the same way as before. A few cursory web searches show that this new behaviour of getaddrinfo is indeed causing trouble as applications are converted to IPv6 and the change in behaviour with IPv4 is found to be undesirable. Finally, I would like to preemptively address the line "but this is an RFC and we must do what it says". There are two responses: The most obvious one is that RFC3484 is merely Proposed Standard. At this stage of the standardisation process one can expect to find errors, mistaken deviations from existing practice, and so on. (The IETF standardisation process has been broken so that documents often get stuck in this state; but that doesn't mean that we should treat draft documents as if they were gospel, let alone documents that aren't even drafts.) The second is a more general point: if a standards document tells us to do something which is wrong, then we should not do it. Obviously we should think fairly hard before making the decision to go against a standard, but our job is to do the right thing and standards documents are there to help us not to constrain us. I think my argument above about the existing meaning of multiple A records is irrefutable. > I already suggested that maybe rule 9 should be limited to the common > prefix length of the netmask you're using. An other option is that you > extend rule 2 to have the same behaviour with ipv4, and that 10/8, > 172.16/12 and 192.168/16 should be considered organization-local. Replacing rule 9 with something more limited based on local network interfaces (ie, prefer what appear to be locally-attached addresses) would be fine. Or a default based on routing metrics would be fine too. (Although I think these may be too much work to do in getaddrinfo.) The problem occurs when we start ranking IPv4 addresses of foreign systems about we have no special knowledge of the topology. Ranking RFC1918 addresses ahead of others is not entirely a safe thing to do because people sometimes foolishly publish RFC1918 addresses for public services and expect callers to skip those addresses somehow. But at least it wouldn't break people who weren't already doing wrong things. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]