Comment 404 for bug 417757

(In reply to comment #69)
> Pavel already responded to most of your points, so I'll try to avoid just
> repeating his points.)
>
> (In reply to comment #66)
>
> > getaddrinfo() is not a DNS protocol specific API call, and is used in front
> > of all those NSS backends, so that applications don't have to be exposed to
> > how the address information was determined. For example, I run MDNS at home,
> > and when I enable it, all of my IPv6 applications automatically work with it.
>
> Well, again, this isn't about MDNS. Nobody is suggesting to make the MDNS
> backend ignore link-locals if called from getaddrinfo() w/AI_ADDRCONFIG.
> This bug is specifically about the DNS backend's behaviour; MDNS is out of
> scope.
>

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.

> > By making AI_ADDRCONFIG ignore link-local addresses, the getaddrinfo() call
> > becomes broken for NSS backends that can provide both the link-local address
> > and the corresponding interface index, such as MDNS or any other future ones.
>
> See above, this is about the DNS backend *only*.
>

Again, you had no qualifiers.

> > Perhaps the DNS NSS backend could provide it, by returning the interface
> > index of the interface it received the response on if a link-local address
> > is returned. On the common single-homed host, this is likely to be the
> > correct interface index for the link-local address.
>
> This is a flawed assumption, even in the single-homed host case. One obvious
> example: If you run a local caching resolver (which I believe NetworkManager
> has native support for doing these days), you'll end up with all the
> returned link-local addresses being scoped to the "lo" interface, which is
> probably not what you want.
>

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.

> > Something else outside of DNS could provide the interface information, and
> > the application combines them. Specifying a hostname (perhaps in /etc/hosts)
> > and an interface will be much simpler than specifying literal link-local
> > addresses because getaddrinfo() won't lookup IPv6 addresses when the host
> > only has link-local addresses.
>
> It would appear to me that the proper thing for such an application to do is
> to simply not use AI_ADDRCONFIG. However, does such an application actually
> exist, or are you inventing it just to support your position?
>

I don't know if an application like this exists, but I doubt you know absolutely that it doesn't exist. Where are the restrictions that say such an application can't exist? The definition of AI_ADDRCONFIG didn't prohibit them, or even make recommendations against them.

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?

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.

> > 1) issue a standard DNS query including both A and AAAA queries.
>
> Not possible. There is no single DNS query that requests both A and AAAA
> responses. (If, by any chance, you want to say "ANY" right now - don't, it
> doesn't do what you think it does.)
>

This was a basic example to demonstrate the concept of the happy eyeballs approach ("off the top of my head"), not a detailed proposal.

> > 2) if no response is received after 400ms (roughly half way around the
> > world), issue two individual queries, one for an A and one for an AAAA.
>
> Two individual queries is what's being done today, and that's the only thing
> you can do. Also, 400ms, even multiple seconds, is too short a timeout - the
> major part a DNS lookup isn't the single RTT to the resolver listed in
> /etc/resolv.conf - it's waiting for that resolver to actually find the
> record in question. This is the sum of all RTTs to all the authoritative
> name servers in the delegation chain, potentially including timeouts and
> retransmits at some of the steps.
>
> The only way to get Happy Eyeballs-ish behaviour using getaddrinfo() is if
> you run an IPv4-only thread with getaddrinfo(AF_INET)->connect(AF_INET), and
> a similar one for AF_INET6. You can't do it within getaddrinfo(), as it must
> wait for all responses (or timeouts) before it can return anything. In any
> case, in the dual thread case it doesn't make sense to use AI_ADDRCONFIG
> since you're requesting an explicit address family.
>

The happy eyeball behaviour would be within the DNS backend, hidden from the application behind the getaddrinfo(,AI_ADDRCONFIG) call.

> > That way you're not stopping getaddrinfo() from being used on IPv6 hosts
> > with just link-local addresses,
>
> 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?

The things that are useless and harmful here are the broken CPE, not link-locals in DNS, or IPv4/IPv6 hosts that only have link-local IPv6 addresses.

Mark.