Comment 406 for bug 417757

(In reply to comment #71)
> (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.
>

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.

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.

> > 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.

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.

> 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,

Well, as you saw, I pointed out a valid and reasonable use for storing link-locals in DNS, so it isn't completely pointless.

> 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. In this instance, DNS is still useful, because it is providing a much simpler and easier to type name for an IPv6 link-local address, even though in itself it isn't enough information to use the returned link-local address by itself.

> > 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.example.com. IN AAAA fe80::15
> > eth0.rtr10.example.com. IN TXT "Ethernet 0 on Router 10, MAC addr
> > 02:00:00:00:00:01"
> >
> > 5.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa.
> > IN PTR eth0.rtr10.example.com.
>
> 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.

> What you can't do, though, is e.g. "ssh eth0.rtr10.example.com" - regardless
> of presence of IPv4 addresses on the host, IPv6 addresses on the host, and
> whether or not the ssh application uses AI_ADDRCONFIG.
>

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. I'd more likely use ping or telnet for this purpose, but ssh and anything else that calls getaddrinfo() would do - I have plenty of choices.

> > The happy eyeball behaviour would be within the DNS backend, hidden from the
> > application behind the getaddrinfo(,AI_ADDRCONFIG) call.
>
> 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?

> 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.
>

As demonstrated, sometimes you don't need the interface scope, for the DNS information still to be useful.

> 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.
>

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.

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.

Mark.