Re: Malformed DNS requests for single-label hostnames with `search .`

[Rich Felker <dalias@libc.org>]

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