Reproposed F19 Feature: Fix Network Name Resolution [Was: DualstackNetworking]

[Pavel Simerda]

----- Original Message -----
> From: "Nick Jones" <nick.fa.jones at gmail.com>
> In the summary of this Fedora feature for fixing name resolution is
> this snippet: "Fedora could be seen as the leader in linux networking"

Yep. My intention to improve the overall networking features is not limited to what is described in FixNetworkNameResolution.

> getaddrinfo is important for Linux systems, and the existing issues
> with it's implementation are well worth fixing, but when it comes to
> DNS, getaddrinfo is holding Fedora and Linux back.

When it comes to DNS, it's absolutely necessary to run a local resolver like dnsmasq or unbound (the latter supporting DNSSEC) to achieve some of the advanced features like split lists of DNS name servers (e.g. for VPNs). But at least dnsmasq is already supported by NetworkManager.

> Even though DNS is not the only source of 'names' that getaddrinfo
> can return, it is the most important, and in the context of DNS,
> getaddrinfo will not let Fedora reach the above stated goal.

I'd be happy to discuss the details, probably in a separate discussion from this feature. Maybe IRC some time?

> It's not just the lack of support for asynchronous usage, getaddrinfo
> is a very feature poor resolver:
> - No support for alternative DNS record types: mx, txt ((ab)used for
>   a lot of things)

True enough. I was thinking about implementing at least SRV records.

> - No support for DNSSEC

True enough. And also no support for DNS lifetimes. There probably should be a more coprehensive API for that while getaddrinfo would work on top of it.

> - No TCP fallback for that matter, which is essential for the above

This should be handled in the DNS daemon (or supplementary tools) anyway.

> - Probably lot more, I'm no expert on dns

Possibly.

> What is needed for networking leadership is:
> - a feature rich resolver, supporting the above as well as query
>   and response filtering, ala AI_ADDRCONF

Agreed.

> - an implementation of an IPv6 migration strategy along the lines
>   of Happy Eyeballs

I'm afraid this is not limited to DNS.

> - can be used both asynchronously or synchronously

That would be nice. Communication with a daemon over sockets works asynchronously for free.

> - ideally pulls in no dependencies outside libc, except perhaps
>   libidn

That would require a custom communication protocol for the async part.

> - ideally the DNS packet parsing routines use only ANSI C
> - can be used by both C and C++ applications, and is easily
>   bound to other scripting languages, even in the async case

That again suggests a daemon with IPC.

> - provides reverse lookup

Sure.

> - more I can't think of right now but I hope others will add more

It would be better to maintain such information on a wiki page or something. Nobody will come back to the e-mails now and then.

> The question is does this all get added into glibc?
> 1) Yes:
> - glibc getaddrinfo gets updated to support this through
>   the addition of new hints flags and return values, or a new
>   function interface is created instead of shoehorning into the
>   old interface, in any case the old getaddrinfo interface will
>   always be callable using traditional, existing semantics and
>   run time linking to existing apps will not be broken
> - the nss layer gets rewritten to support asynchronous usage
>   (and decent error reporting and additional lookup domains
>   maybe samba?)
> - perhaps the resulting work gets packaged into a proposed
>   extension to POSIX

Even if this could be done, it looks like a very-long-term project and needs more than just dropping suggestions to a mailing list.

> 2) No:
> - simply say: forget it, lets do proper DNS outside of libc

We already can do proper DNS outside libc. There's no problem with that. The more complicated part is getting all sorts of resolution methods together.

> I say 1) could be possible over the course of a few years but
> for now, 2) is more realistic.
> 
> As a quick summary: I would suggest, in addition to addressing
> the outstanding bugs and issues covered by the Fedora feature,
> a flag be added to the set of getaddrinfo parameters that
> instructs it NOT to do DNS lookups, only perform alternative
> resource lookups supported by nss.  This flag would be something
> like: AI_NODNS

I'm not in favor of adding this flag, as DNS is not IMO as specific.

> This will allow application developers to make use of
> getaddrinfo for resolving names using non dns sources

What for?

> (hosts file is DNS,

This is a huge mistake. Many of the bugs are results of treating the /etc/hosts the same way as DNS resolution. While the /etc/hosts file often overrides the information that would otherwise be recieved through DNS, it is no DNS at all, just a way to specify static mapping between names and addresses.

> so this means ldap and others), then perform
> internet domain lookups using an alternative DNS library that
> is standardised in Fedora.

I don't think this is a good solution.

> Given that in most systems, the nss alternatives are local file
> based,

Not at all. And even less in the future.

> and given the option of using nsscache, these lookups
> could be considered reasonably constrained therefore NOT in
> need of asynchronous implementations.
> 
> Over time, the alternative DNS library could be considered for
> inclusion in the core c library, and could replace the DNS
> lookup aspect of getaddrinfo, at least for A and AAAA lookups,
> and more if additional query flags are defined for getaddrinfo
> or if an alternative function interface is defined.

Spliting out DNS from other host name resolution more than it is now, would IMO be a huge mistake. There's not just DNS out there.

> In addition, work can be done to make the nss layer
> asynchronous, or at least constrain it to local file resources and
> standardise on the use of nsscache.

This is something that could be discussed after fixing up the current synchronous API.

> Or use this effort to re implement a switched name service
> lookup library, including DNS aspect, outside of glibc.

Also worth discussing later.

Cheers,

Pavel