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

[Nick Jones]

On Mon, Jan 21, 2013 at 6:25 PM, Daniel P. Berrange <berrange at redhat.com> wrote:
> On Fri, Jan 18, 2013 at 09:37:37AM +0800, Nick Jones wrote:
>> On Wednesday, January 16, 2013 10:11 PM, Jaroslav Reznik wrote:
>> >As the Feature was renamed and the content of Feature has been extended
>> >as requested by FESCo, re-announcing it to the community for re-review.
>> >
>> >See https://fedorahosted.org/fesco/ticket/986
>> >
>> >= Features/Fix Network Name Resolution =
>> >https://fedoraproject.org/wiki/Features/FixNetworkNameResolution
>> >
>> >* Detailed description
>> >Currently the getaddrinfo() function doesn't work as it was desinged.
>> >Many of its features are buggy and cannot be used without extensive
>> >workarounds. Many software packages are using getaddrinfo() with such
>> >workarounds. Many can trigger its failures. And many packages that don't
>> >use getaddrinfo() will be ported in the near future.
>> >
>>
>> One feature I would like to see added to future glibc, is a fully
>> asynchronous version of getaddrinfo, and also getnameinfo.
>>
>> Asynchronous for non filesystem fds at least.
>>
>> The glibc maintainers don't seem to be against this idea and I am
>> willing to put time into design and implementation.
>
> Perhaps I'm misunderstanding what you're after, but doesn't "getaddrinfo_a"
> already provide an async version of getaddrinfo ?
>
>     "Asynchronous Hostname Lookup API"
>    http://www.akkadia.org/drepper/asynchnl.pdf
>
> That said I don't see the reverse - getnameinfo_a
>

In the summary of this Fedora feature for fixing name resolution is
this snippet: "Fedora could be seen as the leader in linux networking"

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.

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.

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)
- No support for DNSSEC
- No TCP fallback for that matter, which is essential for the above
- Probably lot more, I'm no expert on dns

What is needed for networking leadership is:
- a feature rich resolver, supporting the above as well as query
  and response filtering, ala AI_ADDRCONF
- an implementation of an IPv6 migration strategy along the lines
  of Happy Eyeballs
- can be used both asynchronously or synchronously
- ideally pulls in no dependencies outside libc, except perhaps
  libidn
- 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
- provides reverse lookup
- more I can't think of right now but I hope others will add more

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

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

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

This will allow application developers to make use of
getaddrinfo for resolving names using non dns sources (hosts
file is DNS, so this means ldap and others), then perform
internet domain lookups using an alternative DNS library that
is standardised in Fedora.

Given that in most systems, the nss alternatives are local file
based, 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.

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.

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