[musl] Question about tcp failure in udp truncated scenarios

[musl] Question about tcp failure in udp truncated scenarios

[JinCheng Li]

[-- Attachment #1: Type: text/plain, Size: 1015 bytes --]

Hi

    I have a question for __res_msend_rc in dns query. In the case of multiple nameservers, if the first vaild udp query result is truncated,  musl will discard the udp query result and turn to tcp query. But I found many dns nameservers do not response to the tcp connection or do not respond to tcp query request which will finally trigger timeout. As a result, the success rate of DNS queries is greatly reduced when udp is truncated, for example, in the case of only IPV4.
    In bionic, the dns query in multiple nameservers is one by one. The first udp is truncated, if the tcp also fail, it will turn to the second udp and do it again. This may be slower than musl in terms of speed, but is more stable in truncation cases.
    In musl, if the udp truncated case has happened, we will convert to tcp which is more likely not supported by the nameserver and discard all other udp response which may be also valid from other nameserver . Do you have any good suggestions to optimize this?

Best
Li

[-- Attachment #2: Type: text/html, Size: 2701 bytes --]

Re: [musl] Question about tcp failure in udp truncated scenarios

[Markus Wichmann]

Am Fri, Sep 13, 2024 at 01:56:49PM +0000 schrieb JinCheng Li:
> Hi
>
>     I have a question for __res_msend_rc in dns query. In the case of multiple nameservers, if the first vaild udp query result is truncated,  musl will discard the udp query result and turn to tcp query. But I found many dns nameservers do not response to the tcp connection or do not respond to tcp query request which will finally trigger timeout. As a result, the success rate of DNS queries is greatly reduced when udp is truncated, for example, in the case of only IPV4.
>     In bionic, the dns query in multiple nameservers is one by one. The first udp is truncated, if the tcp also fail, it will turn to the second udp and do it again. This may be slower than musl in terms of speed, but is more stable in truncation cases.
>     In musl, if the udp truncated case has happened, we will convert to tcp which is more likely not supported by the nameserver and discard all other udp response which may be also valid from other nameserver . Do you have any good suggestions to optimize this?
>

Basically, when that happens, the server is broken. musl supports
multiple DNS servers for redundancy only. So if a UDP query gets a TC
response, we assume that that is the only possible response to the
query. Any other server must send the same response. If that is not the
case, your DNS is misconfigured.

The server not responding on TCP is a violation of RFC 7766. TCP is
simply not optional for DNS servers anymore.

Ciao,
Markus

Re: [musl] Question about tcp failure in udp truncated scenarios

[Rich Felker]

On Fri, Sep 13, 2024 at 04:27:23PM +0200, Markus Wichmann wrote:
> Am Fri, Sep 13, 2024 at 01:56:49PM +0000 schrieb JinCheng Li:
> > Hi
> >
> >     I have a question for __res_msend_rc in dns query. In the case of multiple nameservers, if the first vaild udp query result is truncated,  musl will discard the udp query result and turn to tcp query. But I found many dns nameservers do not response to the tcp connection or do not respond to tcp query request which will finally trigger timeout. As a result, the success rate of DNS queries is greatly reduced when udp is truncated, for example, in the case of only IPV4.
> >     In bionic, the dns query in multiple nameservers is one by one. The first udp is truncated, if the tcp also fail, it will turn to the second udp and do it again. This may be slower than musl in terms of speed, but is more stable in truncation cases.
> >     In musl, if the udp truncated case has happened, we will convert to tcp which is more likely not supported by the nameserver and discard all other udp response which may be also valid from other nameserver . Do you have any good suggestions to optimize this?
> >
> 
> Basically, when that happens, the server is broken. musl supports
> multiple DNS servers for redundancy only. So if a UDP query gets a TC
> response, we assume that that is the only possible response to the
> query. Any other server must send the same response. If that is not the
> case, your DNS is misconfigured.
> 
> The server not responding on TCP is a violation of RFC 7766. TCP is
> simply not optional for DNS servers anymore.

Exactly. Assuming we need a response larger than the UDP max to
satisfy the query, inability to obtain that is a hard error that needs
to be reported to the caller.

When TCP support was added, however, there was the question of whether
we should (either always, or optionally) make it so the high-level
resolver functions (getaddrinfo and the legacy gethostbyname family)
avoid doing TCP fallback if the truncated UDP response contains a
sufficient answer (nonzero number of records of the requested type).
This could still be considered if it would improve things in some
environments...

Rich