> 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] (or it predecessor) because [EMAIL PROTECTED]
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
> [EMAIL PROTECTED]
> https://www1.ietf.org/mailman/listinfo/dnsop
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
Ietf mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ietf
