[Dnsmasq-discuss] [PATCH] forward.c: fix handling of truncated response

[Simon Kelley]

The release of 2.91 is (really) imminent. I'm awaiting one set of 
information to confirm that a reported problem comes from elsewhere and 
not dnsmasq and then it will be ready to go.

2.91 no longer unconditionally empties a truncated response from an 
upstream server. There are still circumstances where it does remove 
answers, for instance when the answer from upstream is NOT truncated, 
but it is too large to fit into the packet size advertised by the 
client. In that case dnsmasq sets the TC flag, and, because it can't 
know which answers to keep, removes all the answers.

My opinion is that any program making DNS request that can't or doesn't 
fall back to TCP is a disaster waiting to happen. Even if the new 
release of dnsmasq "fixes" the problem, the recursive servers which 
dnsmasq is forwarding to can unfix it at any time. I just tested 
Google's recursive server at 8.8.8.8 and it returns empty truncated replies.

Cheers,

Simon.


On 2/5/25 13:40, Niels Hendriks wrote:
> Hi all,
> 
> I believe we are affected by this bug and had to downgrade to 2.89 on 
> our Debian installation.
> 
> I see it has been a few months since the last message regarding this 
> issue. I'm just a normal user and a little bit confused on how to proceed.
> Is this something that is still being worked on, and is there an 
> expectation of when the new version will be released that fixes this 
> issue? Or is there something wrong with the program performing the DNS 
> requests and should I ask them to fix something on their side to handle 
> what is happening here?
> 
> Thanks in advance!
> Niels Hendriks
> 
> 
> *From: * Rahul Thakur via Dnsmasq-discuss <dnsmasq- 
> discuss at lists.thekelleys.org.uk>
> *To: * <dnsmasq-discuss at lists.thekelleys.org.uk>
> *Sent: * 04/10/2024 1:33 PM
> *Subject: * [Dnsmasq-discuss] [PATCH] forward.c: fix handling of 
> truncated response
> 
>     From: Rahul Thakur <rahul.thakur at iopsys.eu>
> 
>     The handling of truncated reponse is broken in 2.90. The answers
>     are removed before forwarding in case TC bit is set, which
>     seems incorrect as per rfc 5625.
>     A combined reading of section 4.4.1 of rfc 5625 section 6.1.3.2
>     of rfc 1123 suggests when dnsmasq explicitly deletes the answers
>     in a truncated response, then it deprives clients that do not fallback
>     to TCP and are happy with the truncated UDP response to be able
>     to resolve the queries. In light of this, it sounds like a better
>     strategy is to forward the truncated UDP response as is to the client,
>     and let the client decide what action it wants to take.
> 
>     Signed-off-by: Rahul Thakur <rahul.thakur at iopsys.eu>
>     ---
>     src/forward.c | 3 ---
>     1 file changed, 3 deletions(-)
> 
>     diff --git a/src/forward.c b/src/forward.c
>     index 10e7496..1ede913 100644
>     --- a/src/forward.c
>     +++ b/src/forward.c
>     @@ -785,9 +785,6 @@ static size_t process_reply(struct dns_header
>     *header, time_t now, struct server
>        if (header->hb3 & HB3_TC)
>          {
>            log_query(F_UPSTREAM, NULL, NULL, "truncated", 0);
>     -      header->ancount = htons(0);
>     -      header->nscount = htons(0);
>     -      header->arcount = htons(0);
>          }
> 
>        if  (!(header->hb3 & HB3_TC) && (!bogusanswer || (header->hb4 &
>     HB4_CD)))
>     -- 
>     2.25.1
> 
> 
>     _______________________________________________
>     Dnsmasq-discuss mailing list
>     Dnsmasq-discuss at lists.thekelleys.org.uk
>     https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-
>     discuss
> 
> 
> _______________________________________________
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss at lists.thekelleys.org.uk
> https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss