> On 27-sep-2007, at 3:33, Mark Andrews wrote: > > >> So your issue that the results are inconsistent is certainly real. > > >> I'd say that the best way to avoid this is not having a search domain > >> at all, or at the very least not several. > > > Which is a totally unreasonable suggestion. > > It's not. Even without IPv6, having search domains means you can get > unexpected results. If that's not acceptable, don't complain, but put > a period behind your FQDNs. Please state were in RFC 952 a final period is legal in a hostname. Remember applications take HOSTNAMES not DOMAIN NAMES. There are HOSTNAMES that you cannot store in the DNS. There are DOMAIN NAMES that are not legal HOSTNAMES. > > The problem here is not the search but different stoping > > critera depending apon the address families supported by > > the host or requested by the application. > > > We wrote a API that failed to account for the usual use > > senario. In fact the guidance in there is the direct > > opposite of what should be done with the usual use senario. > > I thought the solution would be hard or would be suboptimal in the > common case, but I think that doesn't have to be so. > In my example, MacOS would go through the search domains and keep > going until it found AAAA records for IPv6 or IPv4+IPv6 applications > (and presumably look for A records if there were no AAAA records and > IPv4 was present/requested also). > > So basically, both the "answers = 0, noerror" and "nxdomain" > responses trigger trying the next search domain. If we change this to > "answers = 0, noerror" means try the same FQDN again for an A record, > and "nxdomain" means move on to the next search domain, the results > for different permutations of IP version availability would all > result in connecting to the same FQDN = the first one with an address > that's compatible with current connectivity, rather than the first > one with an AAAA record if there is IPv6 connectivity. > > > I'm saying we should go back and fix the specification for > > getaddrinfo() so that it accounts for searching. > > Volunteers...? If need be, yes. > > We should also add a AI_NOSEARCH flag so that searching is > > controlled directly rather than indirectly. > > That's what the period terminating a domain name is for. Again you confuse domain names and hostname. > > I've set Reply-To to ipv6@xxxxxxxx as this is more approriate > > for 6man. > > No, it's a DNS issue, so it should go to dnsop. dnsop people: see > discussion between Mark, Keith and me that started under the subject > "renumbering" on the ietf discussion list. I chose ipv6@xxxxxxxx (or it predecessor) because ipv6@xxxxxxxx was where getaddrinfo()s behaviour was spec'd out. We need to at least give the 6man a chance to address it. Mark > Everyone: feel free to prune some lists when you respond. :-) > > _______________________________________________ > DNSOP mailing list > DNSOP@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf