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

[Luke Shumaker <lukeshu@datawire.io>]

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:

    / # 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

-- 
Happy hacking,
~ Luke Shumaker