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

[Miloslav Trmač]

On Wed, Feb 6, 2013 at 4:57 AM, Nick Jones <nick.fa.jones at gmail.com> wrote:
> On Tue, Jan 29, 2013 at 9:47 PM, Miloslav Trmač <mitr at volny.cz> wrote:
>> 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.
>
> 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.

Precisely what should happen:
>   if (hints->ai_flags
>       & ~(AI_PASSIVE|AI_CANONNAME|AI_NUMERICHOST|AI_ADDRCONFIG|AI_V4MAPPED
> #ifdef HAVE_LIBIDN
>           |AI_IDN|AI_CANONIDN|AI_IDN_ALLOW_UNASSIGNED
>           |AI_IDN_USE_STD3_ASCII_RULES
> #endif
>           |AI_NUMERICSERV|AI_ALL))
>     return EAI_BADFLAGS;


> 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.
If I understand you correctly, you want to split the queries that
return "immediately" vs. those that may take a long time.  In that
case the split should not be DNS/non-DNS - in particular NIS/LDAP
belong to the asynchronous ("DNS") case.
   Mirek