© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
73416ba
(Get the code!)
(In reply to comment #70)
> There were no qualifiers on your described behaviour. You may have been
> talking about DNS, but the description of the change of behaviour to
> AI_ADDRCONFIG did not specify that it was limited to the DNS backend.
The title of this bug is:
«getaddrinfo() with AI_ADDRCONFIG doesn't suppress ****AAAA DNS queries**** on IPv4-only networks»
(emphasis mine)
If that's not a crystal clear qualifier, I don't know what is.
> Then the cache is broken. It should be caching all the information that
> would be returned in the sockaddr structure returned to getaddrinfo(), not
> just the returned IP addresses.
glibc speaks to a caching resolver (e.g. dnsmasq) on 127.0.0.1 or ::1, using the regular DNS protocol. The DNS protocol has no means of communicating an interface scope ID. So how exactly would this work?
> You're asserting that link-locals aren't being stored in DNS. How do you
> know that? Have you queried all the DNS space in the world?
No, but I am asserting that storing link-locals in DNS is completely pointless, as it cannot possibly work, because there is no way the DNS protocol can communicate a scope ID to the querier.
> There has been no prohibitions on link-local addresses being put in DNS, and
> now you are creating one, and are asserting that as you've never seen reason
> to do so, nobody else has either.
>
> Here is a realistic scenario where link-local addresses would usefully be
> stored in DNS.
>
> An organisation may want to create organisation wide unique static
> link-local addresses, assigning them to their routers' interfaces. This
> would make the link-local addresses independent of the MAC addresses of the
> routers interfaces, and would also make the use of link-local addresses as
> e.g., static route next hops, simpler and less error prone because there are
> no intentional duplicates. e.g., their first router's first configured
> interface would have fe80::1, their e.g. 10th router's first configured
> interface might be fe80::15, depending on how many interfaces the other
> routers have.
>
> To document the static link local addresses the following sorts of DNS
> records are created (using router10, interface eth0 as an example)
>
> eth0.rtr10.
> eth0.rtr10.
> 02:00:00:00:00:01"
>
> 5.1.0.0.
> IN PTR eth0.rtr10.
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.
What you can't do, though, is e.g. "ssh eth0.rtr10.
> The happy eyeball behaviour would be within the DNS backend, hidden from the
> application behind the getaddrinfo(
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.
The only thing not "Happy" about this is that the timeout is multi-second. But it has to be, due to the way that DNS work. I think you can say "options timeout:1" in /etc/resolv.conf, but that will make queries that trigger deep recursion to randomly fail.
> > So again, this is not about stopping getaddrinfo() from being used on such
> > hosts, it's just to stop it from emitting useless and potentially harmful IN
> > AAAA DNS queries. Nothing else.
>
> How do you know they're useless? How are they harmful?
They're useless because DNS cannot communicate the interface scope, and without the interface scope you cannot communicate with the link-local address.
AI_ADDRCONFIG is a heuristic an application can use to request only addresses that it is likely useful for communication. Link-local addresses found in DNS will simply never be useful in this manner.
Tore