From: Rich Felker <dalias@libc.org>
To: Jeffrey Walton <noloader@gmail.com>
Cc: musl@lists.openwall.com, Markus Geiger <markus.geiger@nielsen.com>
Subject: Re: [musl] [BUG] Non-FQDN domain resolving failure on musl-1.2.x
Date: Fri, 24 Jun 2022 11:15:48 -0400 [thread overview]
Message-ID: <20220624151548.GQ7074@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAH8yC8=2EOvb7OJ7RL1A-oxEV1Ac-eK5QV8kZ-QLYJqdom=J1A@mail.gmail.com>
On Fri, Jun 24, 2022 at 11:10:37AM -0400, Jeffrey Walton wrote:
> On Fri, Jun 24, 2022 at 10:59 AM Rich Felker <dalias@libc.org> wrote:
> >
> > On Fri, Jun 24, 2022 at 12:28:24PM +0200, Markus Geiger wrote:
> > > Hej!
> > >
> > > First, I love MUSL (and alpine linux). Great project!
> > >
> > > We encountered a bug in our CI pipeline using alpine images in conjunction
> > > with AWS DNS servers - and it seems to be related to MUSL:
> > >
> > > $ curl -fsSL https://slack.com
> > > curl: (6) Could not resolve host: slack.com
> > >
> > > Usually that should return some HTML. It seems to affect only non-FQDN
> > > domains. As a workaround we use now full FQDN api.slack.com. But there is a
> > > bug in resolvement! It seems if an AAAA domain is queried over an IPV4
> > > IP/DNS and doesn’t not return a record the overall resolvement of the
> > > domain fails.
> >
> > That's not non-FQDN. Non-FQDN would be "api" as short for
> > api.slack.com. slack.com is just the apex of a zone, but there's
> > nothing special about that for resolving; it's likely just a
> > difference in the records for it vs api, or something fishy the
> > recursive nameserver you're using is doing...
>
> +1.
>
> A FQDN ends in '.' (dot). The dot specifies the root of the DNS tree.
> 'slack.com.' is fully qualified, but 'slack.com' is not. If you are
> configured to search with domain suffixes, 'slack.com' could resolve
> to 'slack.com.home.pvt' because it is not fully qualified.
While this is pedantically correct in some usage, it's not really the
issue at hand here. In ordinary usage, most folks call a domain you
just *intend* to be interpreted from the DNS root a FQDN, regardless
of whether it has a dot to express that. But in any case, the point
was that the issue is not a matter of FQDNs but of something wrong
Amazon's nameservers are apparently doing (again?? *headdesk*). Let's
see if we can figure out what and how to get them to fix it...
Rich
next prev parent reply other threads:[~2022-06-24 15:16 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-24 10:28 Markus Geiger
2022-06-24 14:59 ` Rich Felker
2022-06-24 15:10 ` Jeffrey Walton
2022-06-24 15:15 ` Rich Felker [this message]
2022-06-24 17:14 ` Markus Geiger
2022-06-25 1:56 ` Rich Felker
2022-06-27 11:35 ` Markus Geiger
2022-06-27 14:06 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220624151548.GQ7074@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=markus.geiger@nielsen.com \
--cc=musl@lists.openwall.com \
--cc=noloader@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).