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-
disc...@lists.thekelleys.org.uk>
*To: * <dnsmasq-discuss@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.tha...@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.tha...@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@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-
discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
