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

[Nick Jones]

On Tue, Jan 29, 2013 at 9:47 PM, Miloslav Trmač <mitr at volny.cz> wrote:
> Hello,
> just a minor point, not getting into the wider "should getaddrinfo()
> be the primary interface" debate...
>
> On Tue, Jan 29, 2013 at 4:58 AM, Nick Jones <nick.fa.jones at gmail.com> wrote:
>> 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.
>
> That's unnecessarily difficult for the application developers.
> Application should have a single API to call; if they have to call two
> separate APIs, some of them won't.
>     Mirek

Admittedly there is a problem with adding the AI_NODNS flag, in
addition to what you mentioned.  That is, what happens when an
application compiled to use AI_NODNS is run against an older
libc.  The binary interface is the same but not the behavioural
interface, therefore the application will run but will perform two
dns lookups.

One way to get around this is by adding a versioned symbol for
getaddrinfo, which is no different from the current non versioned
symbol.  It will be present for enforcement of runtime and rpm
build time compatability.

Another way is to add a new functional interface like:
getnondnsaddrinfo, except with a better name, which performs
non dns lookups only.

Adding new interfaces to glibc is only done when necessary so
a lot of justification for either would be needed, rightly so.

I agree that splitting name resolution into two parts is an added
complication for application developers, but I feel getaddrinfo
itself is split into two of parts:
- name resolution using databases such as ldap via nss
- name resolution using a dns A or AAAA record lookup

Making getaddrinfo and nss fully asynchronous will not happen
soon, but my suggestion is to split the behaviour to allow an
application to be able to resolve names from non-dns sources
(which is an important function) then make use of a more
modern dns resolver.

The behaviour of existing binaries run against the a libc
will not be changed in any way.  They will continue to use
getaddrinfo as they have always done.

New applications will have the freedom to lookup a name
using getaddrinfo first, then perform the specifically A or
AAAA record lookup using a dedicated dns library that is
fully asynchronous, and also supports richer dns functionality,
thus can be re-used for other purposes.

Nick