Comment 408 for bug 417757
Revision history for this message
|
|
#408 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
(In reply to comment #73)
> 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.
I think it is crystal clear and if anyone wants to have a good summary, there's still:
https:/
> > 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:
+1
> 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.
Please keep being specific whether you're talking about DNS or generally. I don't think the Apple folks would break their link-local name resolution deliberately.
> NSCD is *not* a resolver.
+1
Using NSCD with network name resolution and AI_ADDRCONFIG sounds dangerous to me.
> > 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 irrelevant to the problem in this bug report, as NSS backends currently don't convey scope_id at all.
With that in mind, I think we should stop polluting this bug report with link-local in DNS as it's irrelevant in the current situation. Start a new bug report and link it from here, if you're still interested, and describe your use case there.
> The standard CLI frontend for getaddrinfo(), "getent ahosts", *doesn't* use
> AI_ADDRCONFIG, for a very good reason.
+1
According to my own micro-research, AI_ADDRCONFIG only good for one specific purpose which is a loop over getaddrinfo results with connect() in each step.
https:/
> 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.
+1
> 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.
Exactly. Any other discussions than those related to getaddrinfo(
> 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
AFAIK this is not even the standard notation. The percent sign is IMO only used with literal addresses.
> I would personally prefer to discuss real issues.
+1
Real issues and in their actual context.
> 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.
+1
I kindly ask to move any further discussions about link-local in DNS to a separate resource (bug report, wiki page, mailing list, whatever). It doesn't belong here and it isn't affected by the solution of this problem, as the current getaddrinfo NSS backends don't work with that anyway.
Of course if you have anything for the discussion of *global* addresses in *DNS*, feel free to contribute here. The *link-local* case in *Multicast DNS* was only discussed because of a flawed patch. We know about the non-DNS issues, we are thinking about them, talking about them and we have already documented them publicly:
https:/
https:/
If you have anything to add regarding AI_ADDRCONFIG, that is not yet described at the above wiki page, please let me know off bugzilla. I will be happy to summarize your information and/or use cases there. Or you can add a new section yourself, if you wish so.