[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Sep 2022 11:39:55 +0300
From: Konstantin Belousov <kostikbel@...il.com>
To: libc-coord@...ts.openwall.com
Cc: Rich Felker <dalias@...c.org>
Subject: Re: EAI_NOADDR ?
On Tue, Sep 20, 2022 at 10:28:16AM +0200, Florian Weimer wrote:
> * 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.
I became curious after the mention of FreeBSD not having EAI_NODATA.
There, the following fragment pops up immediately in the code:
37b3e941672a7 (Hajimu UMEMOTO 2003-10-23 564) if (hostname == NULL)
37b3e941672a7 (Hajimu UMEMOTO 2003-10-23 565) ERR(EAI_NONAME); /* used to be EAI_NODATA */
And indeed, the change came from the following commit:
commit 37b3e941672a71200ddbfabe3e19aff7b5ed73f8
Author: Hajimu UMEMOTO <ume@...eBSD.org>
Date: Thu Oct 23 13:55:36 2003 +0000
EAI_ADDRFAMILY and EAI_NODATA was deprecated in RFC3493
(aka RFC2553bis). Now, getaddrinfo(3) returns EAI_NONAME
instead of EAI_NODATA. Our getaddrinfo(3) nor getnameinfo(3)
didn't use EAI_ADDRFAMILY.
Obtained from: KAME
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.
