From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 20221 invoked from network); 24 Jun 2022 15:16:03 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 24 Jun 2022 15:16:03 -0000 Received: (qmail 27910 invoked by uid 550); 24 Jun 2022 15:16:01 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 27875 invoked from network); 24 Jun 2022 15:16:00 -0000 Date: Fri, 24 Jun 2022 11:15:48 -0400 From: Rich Felker To: Jeffrey Walton Cc: musl@lists.openwall.com, Markus Geiger Message-ID: <20220624151548.GQ7074@brightrain.aerifal.cx> References: <20220624145936.GP7074@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] [BUG] Non-FQDN domain resolving failure on musl-1.2.x On Fri, Jun 24, 2022 at 11:10:37AM -0400, Jeffrey Walton wrote: > On Fri, Jun 24, 2022 at 10:59 AM Rich Felker 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