I think that this is legitimate behaviour. RFC 2181 para 9 says
Where TC is set, the partial RRSet that would not completely fit may
be left in the response. When a DNS client receives a reply with TC
set, it should ignore that response, and query again, using a
mechanism, such as a TCP connection, that will permit larger replies.
Which means the contents (or lack of them) of the answer, auth and
additional sections has to be ignored by the client anyway.
Do you have a standards reference which says otherwise? Test suites can
tell you either that behaviour has changed over releases or that
behaviour differs from other implementations. They cant tell you that
behaviour is correct.
There is a subtle reason for the code being as it is. Dnsmasq
has various functions which change the contents of a packet being
returned, and these can't reliably be applied to a truncated packet, so
data in a truncated packet may (for instance) disclose DNS data which
should be blocked.
The patch is, in any case, broken because it gratuitously removes the
call to the logging code.
Cheers,
Simon.
On 24/09/2024 11:01, Rahul Thakur via Dnsmasq-discuss wrote:
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.
test details-
the regression was caught by a CDrouter run and this change fixes
the regression.
---
src/forward.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/src/forward.c b/src/forward.c
index 10e7496..c893d84 100644
--- a/src/forward.c
+++ b/src/forward.c
@@ -782,13 +782,6 @@ static size_t process_reply(struct dns_header *header,
time_t now, struct server
server->flags |= SERV_WARNED_RECURSIVE;
}
- 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)))
{
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
