[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMhVC3YQMHNyuQJv1HMeV71mZKeF+NgMr_udvSpEwuA9Hajjfg@mail.gmail.com>
Date: Fri, 23 Jul 2021 23:33:17 +0300
From: Yuri Kanivetsky <yuri.kanivetsky@...il.com>
To: musl@...ts.openwall.com
Cc: "Olivier A." <olivier.antoine@...il.com>
Subject: Re: getaddrinfo() fails for domains with no AAAA records (regression?)
I mean, I can see they address ENTs, but I don't see anything
concerning the cases where there's an A RR, but no AAAA RR.
Especially, if wildcard records are considered.
On Fri, Jul 23, 2021 at 11:25 PM Yuri Kanivetsky
<yuri.kanivetsky@...il.com> wrote:
>
> Can you possibly provide some quotes from the RFCs? The closest I could find is:
>
> > QNAME=host3.example. QTYPE=A, QCLASS=IN
> > the answer will reflect "no error, but no data"
> > because there is no A RR set at '*.example.'
>
> https://datatracker.ietf.org/doc/html/rfc4592
>
> And it's from an example.
>
> Also, all other software I could get my hands on (basically, glibc, I
> guess) ignores NXDOMAIN for AAAA RRs.
>
> On Tue, Jul 20, 2021 at 12:12 AM Rich Felker <dalias@...c.org> wrote:
> >
> > On Mon, Jul 19, 2021 at 11:07:21PM +0200, Olivier A. wrote:
> > > On 19/07/2021 14:58, Yuri Kanivetsky wrote:
> > > > [..]
> > >
> > > Hi,
> > >
> > > I notice that too. If both A and AAAA are sent and there is a
> > > response for A and NXDomain for AAAA
> > >
> > > musl-libc discard both results. It's the expected behaviour
> > > according to this commit:
> > >
> > > https://git.musl-libc.org/cgit/musl/commit/src/network/lookup_name.c?id=5cf1ac2443ad0dba263559a3fe043d929e0e5c4c
> > >
> > > And it conform to https://datatracker.ietf.org/doc/html/rfc8020
> > >
> > > It's was not the case before Alpine-Linux 3.13
> > >
> > > But I also notice that if the DNS reply ServFailed instead of
> > > NXDomain for AAAA request, musl-libc retry 10 times, return 'bad
> > > address' and do not fallback to return a A record.
> > >
> > > According to
> > > https://datatracker.ietf.org/doc/html/rfc4074#section-4.3 it's not
> > > expected.
> >
> > This behavior is necessary/mandatory to provide secure behavior under
> > DNSSEC. Otherwise a forged response (causing ServFail) would result in
> > a false answer returned to the application, indicating that only one
> > or the other exists, rather than the correct inconclusive answer.
> >
> > This is https://sourceware.org/bugzilla/show_bug.cgi?id=27929
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.
