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