[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 20 Sep 2022 15:29:35 -0400
From: Rich Felker <dalias@...c.org>
To: libc-coord@...ts.openwall.com
Subject: Re: EAI_NOADDR ?
On Tue, Sep 20, 2022 at 11:39:55AM +0300, Konstantin Belousov wrote:
> 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.
Ah, that makes sense. I don't think it's a really important
distinction, but it's one that can be expressed clearly. In musl we're
returning EAI_NONAME here, which doesn't seem to hurt either, but my
leaning would be to add and switch to EAI_ADDRFAMILY just so that
EAI_NONAME is not overloaded for any cases where the "name" does
exist.
> 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
I can't find any text explicitly deprecating it, just no mention of it
at all in the new RFC. And if there was an intent to deprecate it,
this was clearly a mistake, as the distinction is important to convey
to applications. Do you know anything else about the history here?
Unfortunately this sounds like it might make it harder to get
EAI_NODATA codified in POSIX, but we might just have to be happy with
the majority of implementations doing the right thing outside the
scope of the standard.
Rich
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.
