Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Sep 2022 10:28:16 +0200
From: Florian Weimer <fweimer@...hat.com>
To: Rich Felker <dalias@...c.org>
Cc: libc-coord@...ts.openwall.com
Subject: Re: EAI_NOADDR ?

* Rich Felker:

> On Mon, Sep 19, 2022 at 10:57:55PM +0200, Florian Weimer wrote:
>> * Rich Felker:
>> 
>> > One problem I've seen come up again and again with libc stub resolver
>> > API is that there's no way to distinguish between NxDomain and NODATA
>> > responses from DNS. These have very different meanings ("name doesn't
>> > exist" vs "name exists but has no address (or whatever record type you
>> > were looking for") and being able to distinguish them is important for
>> > implementing containerized-type DNS service on top of the host's
>> > resolver API rather than direct proxying to outside DNS (when the
>> > latter isn't desirable).
>> >
>> > POSIX defines EAI_NONAME as:
>> >
>> > [EAI_NONAME]
>> >     The name does not resolve for the supplied parameters. 
>> >
>> > which, under generous interpretation of "parameters", seems to cover
>> > both cases, although arguably it does "resolve" to just an empty list
>> > of addresses in the NODATA case.
>> >
>> > To address this, I'm considering proposing a new error code EAI_NOADDR
>> > that would be defined something like:
>> >
>> > [EAI_NOADDR]
>> >     The name does not have any addresses for the supplied parameters.
>> >
>> > Would other implementators be on-board with such a proposal?
>> 
>> I think several libcs implemented this as EAI_NODATA already.  I see it
>> documented for AIX, glibc, NetBSD, OpenBSD, QNX, Solaris.  Apparently,
>> it's absent from FreeBSD (and Windows).
>
> Oh, perfect! In that case, can we push this for standardization?

I think a separate error code makes sense.

> And, it looks like glibc also defines EAI_ADDRFAMILY with somewhat
> overlapping meaning. Is there good documentation for how they're
> distinguished? I don't think you can meaningfully choose which to
> return unless you query both A and AAAA even when only one was
> requested..?

EAI_ADDRFAMILY is only used when the host name is a numeric address that
implies an address family, and a different address family is requested.
EAI_NODATA implies that the host name exists, which doesn't really apply
to a numeric address, so I guess that's why a different error code was
introduced.

Thanks,
Florian

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.