mailing list of musl libc
 help / color / mirror / Atom feed
* [musl] getaddrinfo() fails for domains with no AAAA records (regression?)
@ 2021-07-19 12:58 Yuri Kanivetsky
  2021-07-19 13:22 ` Florian Weimer
  2021-07-19 21:07 ` Olivier A.
  0 siblings, 2 replies; 13+ messages in thread
From: Yuri Kanivetsky @ 2021-07-19 12:58 UTC (permalink / raw)
  To: musl

[-- Attachment #1: Type: text/plain, Size: 1878 bytes --]

Hi,

a.c:

    #include <netdb.h>
    #include <stdio.h>
    #include <stdlib.h>
    #include <string.h>
    #include <arpa/inet.h>

    int
    main(int argc, char *argv[])
    {
        struct addrinfo hints;
        struct addrinfo *result, *rp;
        int r;
        char s[INET6_ADDRSTRLEN];

        memset(&hints, 0, sizeof(hints));
        if (argc > 2)
            hints.ai_family = AF_INET;
        hints.ai_socktype = SOCK_DGRAM;

        r = getaddrinfo(argv[1], NULL, &hints, &result);
        if (r != 0) {
            fprintf(stderr, "getaddrinfo: %s\n", gai_strerror(r));
            exit(EXIT_FAILURE);
        }

        for (rp = result; rp != NULL; rp = rp->ai_next) {
            switch (rp->ai_family) {
            case AF_INET:
                inet_ntop(AF_INET, &((struct sockaddr_in
*)rp->ai_addr)->sin_addr, s, INET6_ADDRSTRLEN);
                printf("AF_INET: %s\n", s);
                break;
            case AF_INET6:
                inet_ntop(AF_INET6, &((struct sockaddr_in6
*)rp->ai_addr)->sin6_addr, s, INET6_ADDRSTRLEN);
                printf("AF_INET6: %s\n", s);
                break;
            }
        }

        freeaddrinfo(result);
    }

a.sh:

    #!/bin/sh -eux
    apk add build-base
    cd app
    gcc a.c
    ./a.out p2.x-yuri.site set_ai_family
    ./a.out p2.x-yuri.site

$ docker run --rm -itv $PWD:/app alpine:3.12 ./app/a.sh
...
+ ./a.out p2.x-yuri.site set_ai_family
AF_INET: 3.67.126.242
+ ./a.out p2.x-yuri.site
AF_INET: 3.67.126.242

$ docker run --rm -itv $PWD:/app alpine:3.13 ./app/a.sh
...
+ ./a.out p2.x-yuri.site set_ai_family
AF_INET: 3.67.126.242
+ ./a.out p2.x-yuri.site
getaddrinfo: Name does not resolve

$ docker run --rm -itv $PWD:/app alpine:3.14 ./app/a.sh
...
+ ./a.out p2.x-yuri.site set_ai_family
AF_INET: 3.67.126.242
+ ./a.out p2.x-yuri.site
getaddrinfo: Name does not resolve

Regards,
Yuri

[-- Attachment #2: p1.png --]
[-- Type: image/png, Size: 79835 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] getaddrinfo() fails for domains with no AAAA records (regression?)
  2021-07-19 12:58 [musl] getaddrinfo() fails for domains with no AAAA records (regression?) Yuri Kanivetsky
@ 2021-07-19 13:22 ` Florian Weimer
  2021-07-19 18:51   ` Yuri Kanivetsky
  2021-07-19 21:08   ` Rich Felker
  2021-07-19 21:07 ` Olivier A.
  1 sibling, 2 replies; 13+ messages in thread
From: Florian Weimer @ 2021-07-19 13:22 UTC (permalink / raw)
  To: Yuri Kanivetsky; +Cc: musl

* Yuri Kanivetsky:

> $ docker run --rm -itv $PWD:/app alpine:3.14 ./app/a.sh
> ...
> + ./a.out p2.x-yuri.site set_ai_family
> AF_INET: 3.67.126.242
> + ./a.out p2.x-yuri.site
> getaddrinfo: Name does not resolve

p2.x-yuri.site/IN/AAAA queries result in Name Error/NXDOMAIN, so the
domain is misconfigured.  This error is independent of the record type.

Thanks,
Florian


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] getaddrinfo() fails for domains with no AAAA records (regression?)
  2021-07-19 13:22 ` Florian Weimer
@ 2021-07-19 18:51   ` Yuri Kanivetsky
  2021-07-19 19:29     ` Shiz
  2021-07-19 19:47     ` Érico Nogueira
  2021-07-19 21:08   ` Rich Felker
  1 sibling, 2 replies; 13+ messages in thread
From: Yuri Kanivetsky @ 2021-07-19 18:51 UTC (permalink / raw)
  To: Florian Weimer; +Cc: musl

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

So you're saying that that is the registrar's fault (which also
provides the name servers)? Can you possibly tell how this can be
fixed? Other than by giving up on wildcard dns records?

A couple more points. First, apparently there was some change between
musl-1.2.2-r0 and musl-1.1.24-r10, getaddrinfo() stops working since
Alpine Linux 3.13. Which comes down to the fact that ping and ssh
can't resolve such hostnames. Although host, getent and dig can.
Second, it works on Arch Linux, Debians 8, 9, 10, and CentOS 7. The
way it looks, it works on libc, and doesn't work on musl.

Additionally I've attached the relevant part of the registrars' web interface.

Regards,
Yuri

On Mon, Jul 19, 2021 at 4:22 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Yuri Kanivetsky:
>
> > $ docker run --rm -itv $PWD:/app alpine:3.14 ./app/a.sh
> > ...
> > + ./a.out p2.x-yuri.site set_ai_family
> > AF_INET: 3.67.126.242
> > + ./a.out p2.x-yuri.site
> > getaddrinfo: Name does not resolve
>
> p2.x-yuri.site/IN/AAAA queries result in Name Error/NXDOMAIN, so the
> domain is misconfigured.  This error is independent of the record type.
>
> Thanks,
> Florian
>

[-- Attachment #2: p2.png --]
[-- Type: image/png, Size: 15925 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] getaddrinfo() fails for domains with no AAAA records (regression?)
  2021-07-19 18:51   ` Yuri Kanivetsky
@ 2021-07-19 19:29     ` Shiz
  2021-07-19 19:47     ` Érico Nogueira
  1 sibling, 0 replies; 13+ messages in thread
From: Shiz @ 2021-07-19 19:29 UTC (permalink / raw)
  To: musl; +Cc: yuri.kanivetsky



> On 19 Jul 3 Reiwa, at 20:51, Yuri Kanivetsky <yuri.kanivetsky@gmail.com> wrote:
> 
> So you're saying that that is the registrar's fault (which also
> provides the name servers)? Can you possibly tell how this can be
> fixed? Other than by giving up on wildcard dns records?

Your registrar should return empty data responses if the domain exists,
but no records of the requested type are available for it. This is a
distinct response from the NXDOMAIN error response, which indicates
the domain doesn’t exist at all. This is specified by RFC1035[0] and
clarified further by RFC8020[1].

Appropriately, musl aborts the query if it gets such a response from the server[2].
The fact that it returns NXDOMAIN for AAAA-type queries if A-type record do in fact
exist would point to a bug in your registrar’s DNS implementation to me.

- Shiz

[0]: https://datatracker.ietf.org/doc/html/rfc1035 §4.1.1
[1]: https://datatracker.ietf.org/doc/html/rfc8020
[2]: https://git.musl-libc.org/cgit/musl/tree/src/network/res_msend.c?id=6a209f14ff7273d9429e5153c5b6b1990cb508e3#n149 (3 means NXDOMAIN)

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] getaddrinfo() fails for domains with no AAAA records (regression?)
  2021-07-19 18:51   ` Yuri Kanivetsky
  2021-07-19 19:29     ` Shiz
@ 2021-07-19 19:47     ` Érico Nogueira
  1 sibling, 0 replies; 13+ messages in thread
From: Érico Nogueira @ 2021-07-19 19:47 UTC (permalink / raw)
  To: musl, Florian Weimer

On Mon Jul 19, 2021 at 3:51 PM -03, Yuri Kanivetsky wrote:
> So you're saying that that is the registrar's fault (which also
> provides the name servers)? Can you possibly tell how this can be
> fixed? Other than by giving up on wildcard dns records?
>
> A couple more points. First, apparently there was some change between
> musl-1.2.2-r0 and musl-1.1.24-r10, getaddrinfo() stops working since

fd7ec068efd590c0393a612599a4fab9bb0a8633 and
5cf1ac2443ad0dba263559a3fe043d929e0e5c4c have happened between those.
It's possible 5cf1ac applies to your case, since it changes the error
handling to take NXDOMAIN into account from any of the queries.

> Alpine Linux 3.13. Which comes down to the fact that ping and ssh
> can't resolve such hostnames. Although host, getent and dig can.

AFAIK dig/drill will look at /etc/resolv.conf for nameservers, but use
their own resolver, not libc's. getent, on the other hand, uses the libc
resolver, so comparing how ssh/ping and getent perform the query might
be worthwhile, since they are all using the same resolvers.

> Second, it works on Arch Linux, Debians 8, 9, 10, and CentOS 7. The
> way it looks, it works on libc, and doesn't work on musl.

*glibc

>
> Additionally I've attached the relevant part of the registrars' web
> interface.
>
> Regards,
> Yuri
>
> On Mon, Jul 19, 2021 at 4:22 PM Florian Weimer <fweimer@redhat.com>
> wrote:
> >
> > * Yuri Kanivetsky:
> >
> > > $ docker run --rm -itv $PWD:/app alpine:3.14 ./app/a.sh
> > > ...
> > > + ./a.out p2.x-yuri.site set_ai_family
> > > AF_INET: 3.67.126.242
> > > + ./a.out p2.x-yuri.site
> > > getaddrinfo: Name does not resolve
> >
> > p2.x-yuri.site/IN/AAAA queries result in Name Error/NXDOMAIN, so the
> > domain is misconfigured.  This error is independent of the record type.
> >
> > Thanks,
> > Florian
> >


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] getaddrinfo() fails for domains with no AAAA records (regression?)
  2021-07-19 12:58 [musl] getaddrinfo() fails for domains with no AAAA records (regression?) Yuri Kanivetsky
  2021-07-19 13:22 ` Florian Weimer
@ 2021-07-19 21:07 ` Olivier A.
  2021-07-19 21:12   ` Rich Felker
  1 sibling, 1 reply; 13+ messages in thread
From: Olivier A. @ 2021-07-19 21:07 UTC (permalink / raw)
  To: musl

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.

Yours,

-- 

Olivier Antoine


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] getaddrinfo() fails for domains with no AAAA records (regression?)
  2021-07-19 13:22 ` Florian Weimer
  2021-07-19 18:51   ` Yuri Kanivetsky
@ 2021-07-19 21:08   ` Rich Felker
  1 sibling, 0 replies; 13+ messages in thread
From: Rich Felker @ 2021-07-19 21:08 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Yuri Kanivetsky, musl

On Mon, Jul 19, 2021 at 03:22:47PM +0200, Florian Weimer wrote:
> * Yuri Kanivetsky:
> 
> > $ docker run --rm -itv $PWD:/app alpine:3.14 ./app/a.sh
> > ...
> > + ./a.out p2.x-yuri.site set_ai_family
> > AF_INET: 3.67.126.242
> > + ./a.out p2.x-yuri.site
> > getaddrinfo: Name does not resolve
> 
> p2.x-yuri.site/IN/AAAA queries result in Name Error/NXDOMAIN, so the
> domain is misconfigured.  This error is independent of the record type.

To clarify, NXDOMAIN from DNS means "this name does not exist" in the
sense that "no records at all exist for it". The nameserver should be
returning NODATA (RCODE 0 = Success, with 0 records in the answer)
meaning "this name exists but has 0 records of the requested type".

Rich

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] getaddrinfo() fails for domains with no AAAA records (regression?)
  2021-07-19 21:07 ` Olivier A.
@ 2021-07-19 21:12   ` Rich Felker
  2021-07-23 20:25     ` Yuri Kanivetsky
  0 siblings, 1 reply; 13+ messages in thread
From: Rich Felker @ 2021-07-19 21:12 UTC (permalink / raw)
  To: Olivier A.; +Cc: musl

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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] getaddrinfo() fails for domains with no AAAA records (regression?)
  2021-07-19 21:12   ` Rich Felker
@ 2021-07-23 20:25     ` Yuri Kanivetsky
  2021-07-23 20:33       ` Yuri Kanivetsky
  2021-07-23 20:45       ` Laurent Bercot
  0 siblings, 2 replies; 13+ messages in thread
From: Yuri Kanivetsky @ 2021-07-23 20:25 UTC (permalink / raw)
  To: musl; +Cc: Olivier A.

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@libc.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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] getaddrinfo() fails for domains with no AAAA records (regression?)
  2021-07-23 20:25     ` Yuri Kanivetsky
@ 2021-07-23 20:33       ` Yuri Kanivetsky
  2021-07-23 20:45       ` Laurent Bercot
  1 sibling, 0 replies; 13+ messages in thread
From: Yuri Kanivetsky @ 2021-07-23 20:33 UTC (permalink / raw)
  To: musl; +Cc: Olivier A.

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@gmail.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@libc.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

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] getaddrinfo() fails for domains with no AAAA records (regression?)
  2021-07-23 20:25     ` Yuri Kanivetsky
  2021-07-23 20:33       ` Yuri Kanivetsky
@ 2021-07-23 20:45       ` Laurent Bercot
  2021-07-27 14:21         ` Yuri Kanivetsky
  1 sibling, 1 reply; 13+ messages in thread
From: Laurent Bercot @ 2021-07-23 20:45 UTC (permalink / raw)
  To: musl


  I wrote a tool some time ago that was precisely designed to work
around buggy DNS servers incorrectly returning NXDOMAIN, precisely
because such a need was expressed in Alpine.

  This tool is called dnsfunnel, and is available here:
https://skarnet.org/software/dnsfunnel/

  It is also available in Alpine, in testing/ - it has been rotting there
for months because I asked Alpine people to test it in situations
involving actual buggy servers (my own infrastructure is not exposed
to this problem), but my request apparently got lost in the void.

  If there is motivation to actually work around incorrect NXDOMAINs,
it may be a good idea to bring this back to life and actually test
dnsfunnel in real situations where it could be useful, so it can
properly be packaged in Alpine and set up for users who need it.

--
  Laurent


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] getaddrinfo() fails for domains with no AAAA records (regression?)
  2021-07-23 20:45       ` Laurent Bercot
@ 2021-07-27 14:21         ` Yuri Kanivetsky
  2021-07-27 14:41           ` Rich Felker
  0 siblings, 1 reply; 13+ messages in thread
From: Yuri Kanivetsky @ 2021-07-27 14:21 UTC (permalink / raw)
  To: musl

Well, the way it looks... they (registrar) aren't gonna fix this. But
the problem is only with wildcard RRs, so bearable.

By the way, do you know which dns servers are buggy, and which are not?

On Fri, Jul 23, 2021 at 11:45 PM Laurent Bercot
<ska-dietlibc@skarnet.org> wrote:
>
>
>   I wrote a tool some time ago that was precisely designed to work
> around buggy DNS servers incorrectly returning NXDOMAIN, precisely
> because such a need was expressed in Alpine.
>
>   This tool is called dnsfunnel, and is available here:
> https://skarnet.org/software/dnsfunnel/
>
>   It is also available in Alpine, in testing/ - it has been rotting there
> for months because I asked Alpine people to test it in situations
> involving actual buggy servers (my own infrastructure is not exposed
> to this problem), but my request apparently got lost in the void.
>
>   If there is motivation to actually work around incorrect NXDOMAINs,
> it may be a good idea to bring this back to life and actually test
> dnsfunnel in real situations where it could be useful, so it can
> properly be packaged in Alpine and set up for users who need it.
>
> --
>   Laurent
>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [musl] getaddrinfo() fails for domains with no AAAA records (regression?)
  2021-07-27 14:21         ` Yuri Kanivetsky
@ 2021-07-27 14:41           ` Rich Felker
  0 siblings, 0 replies; 13+ messages in thread
From: Rich Felker @ 2021-07-27 14:41 UTC (permalink / raw)
  To: Yuri Kanivetsky; +Cc: musl

On Tue, Jul 27, 2021 at 05:21:14PM +0300, Yuri Kanivetsky wrote:
> Well, the way it looks... they (registrar) aren't gonna fix this. But
> the problem is only with wildcard RRs, so bearable.
> 
> By the way, do you know which dns servers are buggy, and which are not?

As far as I know, there's no actual DNS software that's open source or
commercially offered that has this kind of severe problem. It only
happens when the hosting provider has rolled their own broken software
or made in-house hacks to existing software to break it.

If your registrar is really this bad, you should probably move or at
least use them only as a registrar (not a DNS host) and delegate the
DNS hosting to someone who doesn't botch it so bad.

Rich



> On Fri, Jul 23, 2021 at 11:45 PM Laurent Bercot
> <ska-dietlibc@skarnet.org> wrote:
> >
> >
> >   I wrote a tool some time ago that was precisely designed to work
> > around buggy DNS servers incorrectly returning NXDOMAIN, precisely
> > because such a need was expressed in Alpine.
> >
> >   This tool is called dnsfunnel, and is available here:
> > https://skarnet.org/software/dnsfunnel/
> >
> >   It is also available in Alpine, in testing/ - it has been rotting there
> > for months because I asked Alpine people to test it in situations
> > involving actual buggy servers (my own infrastructure is not exposed
> > to this problem), but my request apparently got lost in the void.
> >
> >   If there is motivation to actually work around incorrect NXDOMAINs,
> > it may be a good idea to bring this back to life and actually test
> > dnsfunnel in real situations where it could be useful, so it can
> > properly be packaged in Alpine and set up for users who need it.
> >
> > --
> >   Laurent
> >

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2021-07-27 14:41 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-19 12:58 [musl] getaddrinfo() fails for domains with no AAAA records (regression?) Yuri Kanivetsky
2021-07-19 13:22 ` Florian Weimer
2021-07-19 18:51   ` Yuri Kanivetsky
2021-07-19 19:29     ` Shiz
2021-07-19 19:47     ` Érico Nogueira
2021-07-19 21:08   ` Rich Felker
2021-07-19 21:07 ` Olivier A.
2021-07-19 21:12   ` Rich Felker
2021-07-23 20:25     ` Yuri Kanivetsky
2021-07-23 20:33       ` Yuri Kanivetsky
2021-07-23 20:45       ` Laurent Bercot
2021-07-27 14:21         ` Yuri Kanivetsky
2021-07-27 14:41           ` Rich Felker

mailing list of musl libc

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/musl

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 musl musl/ https://inbox.vuxu.org/musl \
		musl@inbox.vuxu.org
	public-inbox-index musl

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.musl


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/musl/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git