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=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 11093 invoked from network); 1 Sep 2022 01:32:33 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 1 Sep 2022 01:32:33 -0000 Received: (qmail 17420 invoked by uid 550); 1 Sep 2022 01:32:30 -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 16349 invoked from network); 1 Sep 2022 01:32:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:from:to:cc; bh=FfI6oSJGo2ctfrR/mSbFd/MrhSimdrJsD/VImrHP9Is=; b=hlQ9ESVPzmUisVHgWsvEqNGlxYThg2R0l69mH/uGNz3T5cIrXyK8biHaEYUX8R560a vZE3HS2M35+4Anci+W7nX1pW+zUI5I3wdg7Xl8tz8fOxciYpPNLYlz1GfSymHiRksU4M ojMizES7r8VWnz8NbguP+pf5a8y2DcunAy6yUfahA+qIL6vZXXszAZawrIwINIvvCXO4 pwIbYfHLFmaP1HP+96YuadBx64zEwfSrrwN5/sH8hzrt1uPXsyEQmj9ToIuoGWE9Zqu5 APgq5NI/LDLHQs9WBiWmAN5+8GMWXojDGWmb6182Eg6gOcvuKQSFQqHzWpdq6uniFiMq A/IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:reply-to:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=FfI6oSJGo2ctfrR/mSbFd/MrhSimdrJsD/VImrHP9Is=; b=ND2WsLp3uN2ChnjZRNfb1Hf5G632wzeZ3ut4RkK3umk5cnvapoy4UtJDvGJTWpyAtF 9QtYqdCY5PwtqnRKJw0oANch03GhQetX2bxKbKDUjhoukHHZUcw9RPF93HTtEwP0/Uj2 hmxyB3F0tDJvZWuN/djNQKqjov+T7C18HGku1a5WZG7yR+AgWK8VGqusZGflD4yFEksI ZVkTkvcgaMSoXjLlPBW1Pa44M+w11EeiGQao3qATzi5/JU1IzhNlYUPahfYKbrCMZJCo Vvx9D6abZhFCRNYMxKZJeJB1nXAmoRuAyrZ4jrxO2C3NFRbWoQOSiT6rPO/dWDrhPj/r y1Kg== X-Gm-Message-State: ACgBeo0YghThFuYx6l+qTWrwPd5gdf+LKOI5uD6N8YNDOPBCmYMhIhnK Zc5S5KUZt3A1Dd2hl7f917O3ijkDG92XzSvzDpSihaZCTNA= X-Google-Smtp-Source: AA6agR4bgf+ZMOPuuDzEeS3in2ztBA84E3/VYOU33sjZ/fyMR/UDMxuEkGmoRzrliIrxEQwbCsAMD4umrb4gvye/C4w= X-Received: by 2002:a17:90b:3142:b0:1fa:f533:3191 with SMTP id ip2-20020a17090b314200b001faf5333191mr5983706pjb.193.1661995936571; Wed, 31 Aug 2022 18:32:16 -0700 (PDT) MIME-Version: 1.0 References: <20220831235914.GA19125@brightrain.aerifal.cx> In-Reply-To: <20220831235914.GA19125@brightrain.aerifal.cx> From: Jeffrey Walton Date: Wed, 31 Aug 2022 21:32:02 -0400 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] musl resolver handling of "search ." in /etc/resolv.conf On Wed, Aug 31, 2022 at 7:59 PM Rich Felker wrote: > > On Wed, Aug 31, 2022 at 10:33:05AM -0700, Dalton Hubble wrote: > > Hey folks, > > > > I wanted to flag a possible issue with musl handling of DNS "search ." in > > /etc/resolv.conf.The easiest way I have to repro and consume musl is > > starting an alpine or busybox musl container image. > > > > podman run -it docker.io/alpine:3.16.2 /bin/ash > > > > Edit /etc/resolv.conf to the following (not the "." at the end of search): > > > > ``` > > search default.svc.cluster.local . > > nameserver 8.8.8.8 > > options ndots:5 > > ``` > > > > ``` > > wget www.google.com > > wget: bad address 'www.google.com' > > ``` > > > > Remove the "." from search and wget will work fine again. > > > > https://github.com/coreos/fedora-coreos-tracker/issues/1287 has some great > > details showing DNS packet capture and a malformed packet. > > > > Broader context is that systemd and recently Kubernetes start adding > > "search ." to resolv.conf in certain scenarios, which seems to break > > musl-based resolvers. > > - https://github.com/systemd/systemd/pull/17201 > > - https://github.com/kubernetes/kubernetes/pull/109441 > > - https://github.com/kubernetes/kubernetes/issues/112135 > > Uhg. It was not forseen that . would be put in the search domains > list, and putting it there, especially anywhere but the final position > in the list, recreates a bad behavior that we explicitly tried to > avoid having in musl. > > The mechanism of the failure is that malformed DNS queries are sent > with a literal . at the end of the name. This probably also happens if > the domains in the search list end in dot. Since the queries are > malformed, they don't get responses (or ServFail) and then the search > cannot continue. > > This can be fixed by properly stripping the final dot in search > entries, and skipping ones that are otherwise malformed. Then we need > to decide what to do with the empty (root) search suffix. There are 3 > options I see: > > - Actually support it as a search. This is *bad* behavior, but at > least unlike the version of this behavior musl explicitly does not > implement, it was explicitly requested by the user. Except that it > wasn't, because systemd is just putting it in everyone's > resolv.conf.. > > - Skip it completely. Never search root; wait for the end of the > search list and query root as always. > > - End search on encountering it and go directly to the post-search > query at root. > > If it weren't for systemd and other things creating searches for . > without the user's intent, I think the first option would clearly be > the most reasonable. It provides a way to explicitly "get back" the > functionality musl omits, on an opt-in basis. And maybe systemd is > only emitting it as "search .", not putting . in the middle of other > search domains? > > One of the other options might be a more conservative choice to make > now, to avoid creating a new "feature" without thinking through what > consequences it might have. We could always allow searching root > later after there's been time to think through the consequences, > rather than rushing is as part of a bugfix. > > Anyone care strongly about this one way or another? Forgive my ignorance Rich. What, exactly, does 'search .' mean? Does that mean lookup a single-label hostname in the TLD context? If so, that's not supposed to happen: https://www.iab.org/documents/correspondence-reports-documents/2013-2/iab-statement-dotless-domains-considered-harmful/ . I would reject a 'search .' as malformed. And be careful of systemd and its networking implementation. The systemd folks do some shady things, like stripping a trailing dot from a fqdn when setting a hostname. Stripping that dot means it is no longer fully qualified. Jeff