Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZuRLy8albBM87SBF@voyager>
Date: Fri, 13 Sep 2024 16:27:23 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: Question about tcp failure in udp truncated scenarios

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

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.