From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14106 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Malformed DNS requests for single-label hostnames with `search .` Date: Tue, 7 May 2019 14:04:15 -0400 Message-ID: <20190507180415.GE23599@brightrain.aerifal.cx> References: Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="36652"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-14122-gllmg-musl=m.gmane.org@lists.openwall.com Tue May 07 20:04:32 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hO4S8-0009QH-0r for gllmg-musl@m.gmane.org; Tue, 07 May 2019 20:04:32 +0200 Original-Received: (qmail 13691 invoked by uid 550); 7 May 2019 18:04:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 13673 invoked from network); 7 May 2019 18:04:28 -0000 Content-Disposition: inline In-Reply-To: Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14106 Archived-At: On Tue, May 07, 2019 at 12:29:43PM -0400, Luke Shumaker wrote: > In some scenarios, musl libc generates invalid DNS queries that are > discarded by the DNS server. Particularly when `resolv.conf` says > `search .` and we attempt to resolv a single-label hostname. > > / # cat /etc/resolv.conf > search . > nameserver 1.1.1.1 > > For context of "what it should do", if I have a trailing `.` to tell > it to ignore the `search`-path, it makes the request correctly: Note that this is not a good idea, even if it weren't buggy, as it will just perform all your queries twice. If you don't want to search, omit the search option or leave it blank. > / # time strace -f -e trace=sendto,sendmsg,sendmmsg getent hosts label. > sendto(3, "\214\302\1\0\0\1\0\0\0\0\0\0\5label\0\0\34\0\1", 23, > MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), > sin_addr=inet_addr("1.1.1.1")}, 16) = 23 > sendto(3, "\355b\1\0\0\1\0\0\0\0\0\0\5label\0\0\1\0\1", 23, > MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), > sin_addr=inet_addr("1.1.1.1")}, 16) = 23 > +++ exited with 2 +++ > Command exited with non-zero status 2 > real 0m 0.03s > user 0m 0.00s > sys 0m 0.00s > > But if I allow it to use the `search`-path, the query is invalid: > > / # time strace -f -e trace=sendto,sendmsg,sendmmsg getent hosts label > sendto(3, "\16s\1\0\0\1\0\0\0\0\0\0\5label.\0\34\0\1\0", 24, > MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), > sin_addr=inet_addr("1.1.1.1")}, 16) = 24 > sendto(3, "\16s\1\0\0\1\0\0\0\0\0\0\5label.\0\34\0\1\0", 24, > MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), > sin_addr=inet_addr("1.1.1.1")}, 16) = 24 > sendto(3, "\363\365\1\0\0\1\0\0\0\0\0\0\5label.\0\1\0\1\0", 24, > MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), > sin_addr=inet_addr("1.1.1.1")}, 16) = 24 > sendto(3, "\363\365\1\0\0\1\0\0\0\0\0\0\5label.\0\1\0\1\0", 24, > MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), > sin_addr=inet_addr("1.1.1.1")}, 16) = 24 > +++ exited with 2 +++ > Command exited with non-zero status 2 > real 0m 10.01s > user 0m 0.00s > sys 0m 0.00s > > We see it take 10s to time-out waiting for a reply from the DNS server > that will never come (because the server ignored the query as > malformed). To annotate the queries a bit: > > Good request: > > sendto(3, "\214\302\1\0\0\1\0\0\0\0\0\0\5label\0\0\34\0\1", > 23, MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), > sin_addr=inet_addr("1.1.1.1")}, 16) = 23 > [ header-section [question-section] > [-----][][---][--] > ^ ^ ^ ^ > QNAME[0] = octet[5]{"label"} --' | | | > QNAME[1] = end -----------------------' | | > QTYPE = AAAA ------------------------' | > QCLASS = IN -------------------------------' > > Bad request (as seen by a parser) > > sendto(3, "\16s\1\0\0\1\0\0\0\0\0\0\5label.\0\34\0\1\0", 24, > MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), > sin_addr=inet_addr("1.1.1.1")}, 16) = 24 > [ header-section [question-section ] > [-----][----------- - - - > ^ ^ > QNAME[0] = octet[5]{"label"} -----' | > QNAME[1] = octet[46]{"\0\34\0\1\0"...} --' > QNAME[n] = end --------------------------------------- - - - > QTYPE = ??? --------------------------------------- - - - > QCLASS = ??? --------------------------------------- - - - > > Bad request (as seen by a human): > > sendto(3, "\16s\1\0\0\1\0\0\0\0\0\0\5label.\0\34\0\1\0", 24, > MSG_NOSIGNAL, {sa_family=AF_INET, sin_port=htons(53), > sin_addr=inet_addr("1.1.1.1")}, 16) = 24 > [ header-section [question-section ] > [-----]|[---][--][] > ^ ^^ ^ ^ > QNAME[0] = octet[5]{"label"} -----' || | | > QNAME[1] = should-be-end -----------------' | | | > QTYPE = AAAA --------------------------' | | > QCLASS = IN ---------------------------------' | > garbage = garbage --------------------------------' > > So there are 2 pieces of corruption going on here: > > 1. Instead of getting the \0 terminator indicating that there are no > more lables in the QNAME, it gets an ASCII '.', indicating another > label of length 46. > 2. An extra byte is allocated, which appears at the end of the > message. > > I have verified that the error happens with: > > - Alpine 3.9's musl 1.1.20-r3 on x86_64 > - Alpine 3.9's musl 1.1.20-r4 on x86_64 > - Alpine edge's musl 1.1.21-r2 on x86_64 > - Alpine edge's musl 1.1.22-r0 on x86_64 Yes, this is probably a bug, if search is expected to accept trailing dots, which seems like reasonable-ish functionality. Around line 203 of lookup_name.c, we'd need to detect this case and replace the search component with a zero-length one. I don't recall right off if we'd also need to strip the . separating the query from the search component; that depends on whether name_from_dns accepts a trailing dot, which I think it does, so such stripping probably isn't needed. Again, I think it's a really bad idea to configure your resolv.conf like this. As you've done, it will repeat the same query twice in the case of NxDomain, for no benefit. This will only happen for queries with fewer than ndots dots in them, which, unless you've increaded ndots (which has a lot of other problems), will always be NxDomain. And in the case where you have other nontrivial search components *after* ".", it will produce a situation where appearance of new domains in the global namespace will mask local names you might be using. I wonder if it would make more sense to just skip/ignore "." in the search path... Rich