© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
(In reply to comment #72)
> You continue to miss the point. *Your* proposal on how to *fix* the problem
> was to change the behaviour of AI_ADDRCONFIG, regardless of the backend,
> because you didn't *specify* what backend your solution applied to.
My very first response to you in this thread, in comment #65, began like this:
«That's not what this bug report is about. It's about suppressing DNS "IN AAAA" queries [...]»
So how you can claim that I am not clear about talking specifically about DNS is beyond me, to be honest. It should in any case be clear by now, I hope.
> Even then, the title is not actually saying what the problem is. The actual
> problem is CPE or DNS servers that did not handle IPv6 AAAA queries
> correctly.
Such CPEs and DNS servers are buggy, true. However, it is in our users' best interest to help them avoid tickling these bugs, because it leads to crappy user experiences and bug reports with a huge number of subscribers:
https:/
https:/
It's sucks extra, because this is perceived to be a Linux-specific problem. MS Windows and Apple Max OS X does interpret the AI_ADDRCONFIG flag in the proposed way (i.e., it will suppress IN AAAA queries if the host only has link-local addresses configured. (I haven't verified that this behaviour still is in place in the latest versions of those operating systems though.)
> > glibc speaks to a caching resolver (e.g. dnsmasq) on 127.0.0.1 or ::1, using
> > the regular DNS protocol.
>
> It can also speak to a caching resolver directly, as it does with nscd. That
> is the cache that I though you were talking about, because it is part of
> glibc.
NSCD is *not* a resolver. NSCD knows nothing of AAAA queries or the DNS protocol at all. The only thing NSCD can do is to cache results that came from NSS backends, such as - you guessed it - DNS.
> Well, as you saw, I pointed out a valid and reasonable use for storing
> link-locals in DNS, so it isn't completely pointless.
This is still a red herring. If you use DNS as a documentation tool like you've outlined, there's no reason why you'd use AI_ADDRCONFIG when extracting the records. Otherwise the "documentation" would look different when read on a computer with no IPv6 addresses (not even link-locals), or on a Mac/Windows computer with IPv6 link-locals, than it would when read on a machine with global IPv6 (or a Linux machine with IPv6 link-locals). I find it far-fetched that anyone would use getaddrinfo() for "reading" such "DNS documentation" to begin with, as you cannot retrieve your TXT records with it, for example.
> > as it cannot possibly work, because there is no way the DNS
> > protocol can communicate a scope ID to the querier.
>
> It doesn't need to, that information can be gleaned from some other source,
> such as a command line option, or a configuration file.
FWIW, it simply doesn't work in a fully updated Fedora 18:
tore@wrath:~$ host ll.fud.no
ll.fud.no has IPv6 address fe80::230:
tore@wrath:~$ ssh ll.fud.no%eth0
ssh: Could not resolve hostname ll.fud.no%eth0: Name or service not known
tore@wrath:~$ ssh fe80::230:
The authenticity of host 'fe80::
[...]
> > Red herring. Making getaddrinfo() with AI_ADDRCONFIG suppress IN AAAA
> > queries have nothing to do with this use of DNS as essentially a
> > documentation tool, and would not "prohibit" this in any way.
>
> Yes it would. You'd stop me being able to use any of the standard command
> line tools that use getaddrinfo() to resolve a name to an address.
The standard CLI frontend for getaddrinfo(), "getent ahosts", *doesn't* use AI_ADDRCONFIG, for a very good reason.
AI_ADDRCONFIG is counter-productive if your ultimate goal is to learn what address records are in DNS, because it would arbitrarily hide records from you depending on the machine you're running it on - IN AAAA records would be hidden on IPv4-only machines, and IN A records would be hidden on IPv6-only machines.
AI_ADDRCONFIG is only useful if the main goal isn't to dump the addresses, but to actually get an address that in turn will be used as a destination for communication with. As in, when getaddrinfo() is just a mandatory step towards the ultimate goal making a connect() somewhere. This is when you'd use AI_ADDRCONFIG, and this is when the link-locals in DNS are have no use.
> You assume I actually want to ssh to the host. All I might want to do is see
> the link-local address behind the name. Once ssh starts connecting, I'll
> abort it via Control C, because I've got the information I wanted.
So I take it this is the information you wanted?
host tore@wrath:~$ host ll.fud.no
ll.fud.no has IPv6 address fe80::230:
tore@wrath:~$ ssh ll.fud.no
ssh: connect to host ll.fud.no port 22: Invalid argument
tore@wrath:~$ ssh ll.fud.no%wlan0
ssh: Could not resolve hostname ll.fud.no%wlan0: Name or service not known
> > Well, you can say that this behaviour is already present within
> > getaddrinfo(). If called without AI_ADDRCONFIG (or with on a host that has
> > the required global addresses configured), it will fire off to queries in
> > parallel, wait for replies to come back for both (or either to time out),
> > sort the result set according to /etc/gai.conf, and then return the results
> > to the caller.
>
> Why can't this behaviour occur all the time, regardless of whether
> AI_ADDRCONFIG is set or not?
It *does* occur all the time! This is how getaddrinfo() fundamentally works.
> You seem to believe your solution is both the only one and the best one. Yet
> it changes the external behaviour of the AI_ADDRCONFIG flag. As you don't
> consider the drawbacks I've pointed out to be valid based on your point of
> view and experience, you think it is fine to burden everybody else with them
> because they apparently won't effect you, even though you most likely
> can't accurately predict the future.
To be completely honest with you, I don't think that you (like me) have seen an actual real-world use case where you 1) put link-locals in DNS IN AAAA records, and 2) need to resolve those using getaddrinfo(
Your example use case of putting link-locals unique within an organisation and stuffing in DNS for documentation purposes seems to me to be made up on the spot, solely to support your position (not to mention ludicrous - I'd *really* like to see you post it to a mailing list like NANOG, ipv6-ops, or IETF v6ops and see what kind of feedback you'd get). This goes especially when you're describing how you'd use SSH to look up the addresses, which simply doesn't seem to work.
I would personally prefer to discuss real issues. Do you have any of those, by any chance? If so, I'd like to echo Pavel's suggestion that you contribute in the feature page at https:/
> If there is a solution which doesn't change the external behaviour of
> AI_ADDRCONFIG *at all*, significantly improves the situation for those who
> are effected by the actual problem - broken resolvers in CPE -, and doesn't
> have any effect to anybody who has working resolvers, that is a better
> solution than yours. In my opinion, the Happy Eyeballs approach, applied to
> the DNS backend, is the better solution. The Happy Eyeballs model has worked
> extremely effectively in Firefox, Chrome and Safari. There is no reason it
> can't be applied to DNS.
Happy Eyeballs are orthogonal to this particular issue, you can implement it fine without AI_ADDRCONFIG, and as I've pointed out earlier, getaddrinfo() already implements "HE" by issuing queries in parallel and timing them out independently.
BTW: You could also say that MS Windows and Mac OS X's interpretation of AI_ADDRCONFIG has "worked extremely effectively", as they avoid ruining the experience of the users' that happen to have a broken CPE. Linux users aren't so lucky, cf. the two bugs I linked to above.
Tore