[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ygeczbfs92f.wl-ume@FreeBSD.org>
Date: Thu, 29 Sep 2022 02:27:52 +0900
From: Hajimu UMEMOTO <ume@...eBSD.org>
To: Konstantin Belousov <kostikbel@...il.com>
Cc: libc-coord@...ts.openwall.com,
Hajimu UMEMOTO <ume@...ebsd.org>
Subject: Re: EAI_NOADDR ?
Hi,
>>>>> On Tue, 27 Sep 2022 23:36:20 +0300
>>>>> Konstantin Belousov <kostikbel@...il.com> said:
kostikbel> On Tue, Sep 20, 2022 at 03:29:35PM -0400, Rich Felker wrote:
> 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?
kostikbel> No, I do not.
RFC 3493 obsoleted RFC 2553.
> 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.
kostikbel> Perhaps we should ask ume@...eBSD.org about the original reference
kostikbel> and the modern outcome there? I added Hajimu UMEMOTO to Cc:.
At that time, the KAME project actively followed IETF discussions and
the latest RFCs. I ported the codes from the KAME project.
The KAME repository is lost, but luckily I found a copy on github.
The change was from the following commits:
https://github.com/kame/kame/commit/89c1292ccb74090df121c83d7ab435829ff1f1c5
https://github.com/kame/kame/commit/319434b4252e801fb8dff30e608da6f50960b968
https://github.com/kame/kame/commit/405e1ecedd0436705662fab7989a7ca66bceb364
Sincerely,
--
Hajimu UMEMOTO
ume@...oroba.org ume@...eBSD.org
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.
