(In reply to comment #66) > The AI_ADDRCONFIG flag does not preclude link-local addresses. From RFC3493: > > > " If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be > returned only if an IPv4 address is configured on the local system, > and IPv6 addresses shall be returned only if an IPv6 address is > configured on the local system. The loopback address is not > considered for this case as valid as a configured address." > > Note that loopback addresses are, so the designers specifically thought > about exclusion of addresses types. We are not discussing the designers' virtues but the technical issues. The RFC is (1) INFORMATIONAL and (2) wrong. For more detailed information, see: https://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG (any comments of technical value welcome) > For example, I run MDNS at home, > and when I enable it, all of my IPv6 applications automatically work with it. This is not true. Just try mDNS with link-local addresses (which you mentioned) and you will realize that this feature is absent with the current glibc and nss-mdns. > getaddrinfo() can return all the information necessary to use a link-local > address i.e. both the address, and in the interface index, via the > sin6_scope_id field of the sockaddr_in6 structure that is returned via the > ai_addr field. getaddrinfo() can, while the NSS backends cannot. Therefore currently getaddrinfo() would only return scope_id for IPv6 literals, not mDNS nor any similar protocol. > By making AI_ADDRCONFIG ignore link-local addresses, the getaddrinfo() call > becomes broken for NSS backends Currently false. You can't break a feature that is absent. > Perhaps the DNS NSS backend could provide it, You don't need scope_id for global addresses and you don't need this information with DNS responses at all. > Something else outside of DNS could provide the interface information, and > the application combines them. I don't see the need for that. DNS returns global addresses. Global addresses don't need scope_id. > Specifying a hostname (perhaps in /etc/hosts) Not sure whether /etc/hosts can be used to provide scope_id. > and an interface will be much simpler There is currently no standard way to do that. And I don't think it is valuable enough to seek standardization for that. > than specifying literal link-local > addresses because getaddrinfo() won't lookup IPv6 addresses when the host > only has link-local addresses. There's a much easier solution. Just don't apply the same rules to mDNS you apply to DNS. I believe all of this is already described in: https://fedoraproject.org/wiki/Networking/NameResolution/ADDRCONFIG > The "Happy Eyeballs" technique (RFC6555) wasn't just intended to be applied > to web browsers, according to this draft from Fred Baker: > > "Happier Eyeballs" > https://www.ietf.org/id/draft-baker-happier-eyeballs-00.txt > > and could probably be applied to the DNS "application". For example, off the > top of my head: > > 1) issue a standard DNS query including both A and AAAA queries. In the case described by this bug report, there's no need to query AAAA as global routing is not available anyway. That's all. > 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. I think that glibc resolver implementation is too dumb that it's not worth adding a bunch of hacks. And the glibc is, at the same time, too important to be played with on daily basis when another broken name server is discovered. Even important features like split DNS are missing with the glibc resolver. Therefore my current recommendation is that *all distributions* start deploying a local recursive DNS server like unbound or dnsmasq and perform all DNS tweaking in the specialized software. This is much more useful and much more maintainable. Any libc and any DNS-enabled software can make use of the features then. > That way you're not stopping getaddrinfo() from being used on IPv6 hosts > with just link-local addresses, and it won't penalise people who have > resolvers in their CPE that does the right thing. If you consider a CPE with DNS resolver a good solution, then I think a local full-fledge DNS resolver is an even better one (it would still use the CPE one as its upstream source). (In reply to comment #67) > I thought the obvious problem with this was addressed way up near the top in > comment 20 when someone pointed out that using the same port for the IPv4 > and IPv6 queries gave firewalls fits. > Ulrich Drepper had one of his standard > "purity over practicality" tantrums and refused to change it to use two > different ports to accommodate dumb firewalls, but since Ulrich is gone now, > perhaps saner heads could revisit that? Revisit? We certainly can. But I think this exact bug report is about saving AAAA query when it is apparently not needed. Unfortunately the patch had a side effect on non-DNS cases and therewore was removed. The glibc getaddrinfo() is rather broken for many cases (corner cases for some, day-to-day cases for others), see: https://fedoraproject.org/wiki/Features/FixNetworkNameResolution > (And perhaps revisit all other bug fixes rejected over the years by Ulrich? :-). I already did some bugkeeping upstream: http://sourceware.org/bugzilla/buglist.cgi?quicksearch=getaddrinfo But none of the bug reports are actually specific to DNS protocol processing. I personally believe that the DNS processing in the GNU C Library should be as simple as possible and hack-free. Distributions should use local resolving DNS servers that work correctly from the glibc side and perform any necessary hacks on the external side. Such software is much more easily testable, replacable (e.g. with an instance with more debugging enabled) and maintainable.