<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>I think Simon has pointed out this is intentional. Partial reply
is incomplete and for well behaving clients carries not useful
information. It would use TCP anyway instead, therefore it adds
just additional data.</p>
<p><br>
</p>
<p>I would consider clients not falling back to TCP as broken. TCP
is not considered optional nowadays. Attempts to fix such clients
by relying on incomplete responses instead are wrong.</p>
<p><br>
</p>
<p>It might make sense to allow enabling such behaviour by
configuration, if you have broken software not able to workaround.
But I would insist that software is broken and therefore sending
incomplete responses should be only workaround for them, not
something behaved by default.</p>
<p><br>
</p>
<p>Is that something using Alpine C library?</p>
<p><br>
</p>
<p>Cheers,<br>
Petr</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 30/09/2024 06:39, Rahul Thakur via
Dnsmasq-discuss wrote:<br>
</div>
<blockquote type="cite"
cite="mid:AM9PR08MB72766DCBDD24F988D8B2DF1DF2762@AM9PR08MB7276.eurprd08.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Simon,</div>
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
So what do you think of my reasoning for this patch? Do you
agree?</div>
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Best regards,</div>
<div class="elementToProof"
style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Rahul Thakur</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif"
style="font-size:11pt" color="#000000"><b>From:</b> Rahul
Thakur <a class="moz-txt-link-rfc2396E" href="mailto:rahul.thakur@genexis.eu"><rahul.thakur@genexis.eu></a><br>
<b>Sent:</b> 25 September 2024 15:29<br>
<b>To:</b> Simon Kelley <a class="moz-txt-link-rfc2396E" href="mailto:simon@thekelleys.org.uk"><simon@thekelleys.org.uk></a>;
<a class="moz-txt-link-abbreviated" href="mailto:dnsmasq-discuss@lists.thekelleys.org.uk">dnsmasq-discuss@lists.thekelleys.org.uk</a>
<a class="moz-txt-link-rfc2396E" href="mailto:dnsmasq-discuss@lists.thekelleys.org.uk"><dnsmasq-discuss@lists.thekelleys.org.uk></a><br>
<b>Subject:</b> Re: [Dnsmasq-discuss] [PATCH 1/1] forward.c:
fix handling of truncated response</font>
<div> </div>
</div>
<style type="text/css" style="display:none">p
{margin-top:0;
margin-bottom:0}</style>
<div dir="ltr">
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Hi Simon,</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Thanks for responding to this patch, please find my
justification for this patch as follows:</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
I think rfc 2181 is defining the behaviour for DNS server and
not DNS proxy.</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
I am relying on and referring to rfc 5625 while making this
change.</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
In section 4.4 (<a
href="https://datatracker.ietf.org/doc/html/rfc5625#section-4.4"
id="LPlnk793323" class="x_OWAAutoLink moz-txt-link-freetext"
moz-do-not-send="true">https://datatracker.ietf.org/doc/html/rfc5625#section-4.4</a>),
the rfc 5625 states,</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
If a proxy must unilaterally truncate a response, then the
proxy MUST</div>
<div
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
set the TC bit. Similarly, proxies MUST NOT remove the TC
bit from</div>
<div
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
responses.</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Dnsmasq is ofcourse complying to this behaviour and not
meddling with the TC bit while setting the answers to 0. But,
if I read further section 4.4.1 (<a
href="https://datatracker.ietf.org/doc/html/rfc5625#section-4.4.1"
id="LPlnk270035" class="x_OWAAutoLink moz-txt-link-freetext"
moz-do-not-send="true">https://datatracker.ietf.org/doc/html/rfc5625#section-4.4.1</a>),</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Whilst TCP transport is not strictly mandatory, it is
supported by<br>
the vast majority of stub resolvers and recursive servers.</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
So, this indicates that it is not mandatory that the client
ignores this truncated response. This is further supported by
section 6.1.3.2 of rfc 1123 (<a
href="https://datatracker.ietf.org/doc/html/rfc1123#section-6.1.3.2"
id="LPlnk122739" moz-do-not-send="true"
class="moz-txt-link-freetext">https://datatracker.ietf.org/doc/html/rfc1123#section-6.1.3.2</a>).
In paragraph 3 of the DISCUSSION in section 6.1.3.2, it
states,</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Whether it is possible to use a truncated
answer<br>
depends on the application.</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Hence, when dnsmasq explicitly deletes the answers, then it
deprives clients that do not fallback to TCP and are happy
with the truncated response to be able to resolve their
queries.</div>
</div>
</blockquote>
Fix such client to fall back to TCP instead of making dnsmasq to
provide it. Or ensure it uses EDNS0 with buffer big enough to
receive whole message.<br>
<blockquote type="cite"
cite="mid:AM9PR08MB72766DCBDD24F988D8B2DF1DF2762@AM9PR08MB7276.eurprd08.prod.outlook.com">
<div dir="ltr">
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
To me, it sounds like a better strategy to forward the
truncated response as is to the client and let the client
decide what it wants to do rather than forcefully dropping the
answers.</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Best regards,</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
Rahul Thakur</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div class="x_elementToProof"
style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font
face="Calibri, sans-serif" color="#000000"
style="font-size:11pt"><b>From:</b> Dnsmasq-discuss
<a class="moz-txt-link-rfc2396E" href="mailto:dnsmasq-discuss-bounces@lists.thekelleys.org.uk"><dnsmasq-discuss-bounces@lists.thekelleys.org.uk></a> on
behalf of Simon Kelley <a class="moz-txt-link-rfc2396E" href="mailto:simon@thekelleys.org.uk"><simon@thekelleys.org.uk></a><br>
<b>Sent:</b> 25 September 2024 13:39<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:dnsmasq-discuss@lists.thekelleys.org.uk">dnsmasq-discuss@lists.thekelleys.org.uk</a>
<a class="moz-txt-link-rfc2396E" href="mailto:dnsmasq-discuss@lists.thekelleys.org.uk"><dnsmasq-discuss@lists.thekelleys.org.uk></a><br>
<b>Subject:</b> Re: [Dnsmasq-discuss] [PATCH 1/1] forward.c:
fix handling of truncated response</font>
<div> </div>
</div>
<div class="x_BodyFragment"><font size="2"><span
style="font-size:11pt">
<div class="x_PlainText">I think that this is legitimate
behaviour. RFC 2181 para 9 says<br>
<br>
Where TC is set, the partial RRSet that would not
completely fit may<br>
be left in the response. When a DNS client receives
a reply with TC<br>
set, it should ignore that response, and query
again, using a<br>
mechanism, such as a TCP connection, that will
permit larger replies.<br>
<br>
Which means the contents (or lack of them) of the
answer, auth and <br>
additional sections has to be ignored by the client
anyway.<br>
<br>
Do you have a standards reference which says otherwise?
Test suites can <br>
tell you either that behaviour has changed over releases
or that <br>
behaviour differs from other implementations. They cant
tell you that <br>
behaviour is correct.<br>
<br>
There is a subtle reason for the code being as it is.
Dnsmasq<br>
has various functions which change the contents of a
packet being <br>
returned, and these can't reliably be applied to a
truncated packet, so <br>
data in a truncated packet may (for instance) disclose
DNS data which <br>
should be blocked.<br>
<br>
The patch is, in any case, broken because it
gratuitously removes the <br>
call to the logging code.<br>
<br>
<br>
Cheers,<br>
<br>
Simon.<br>
<br>
On 24/09/2024 11:01, Rahul Thakur via Dnsmasq-discuss
wrote:<br>
> From: Rahul Thakur <a class="moz-txt-link-rfc2396E" href="mailto:rahul.thakur@iopsys.eu"><rahul.thakur@iopsys.eu></a><br>
> <br>
> the handling of truncated reponse is broken in
2.90. The answers<br>
> are removed before forwarding in case TC bit is
set, which<br>
> seems incorrect.<br>
> <br>
> test details-<br>
> the regression was caught by a CDrouter run and
this change fixes<br>
> the regression.<br>
> ---<br>
> src/forward.c | 7 -------<br>
> 1 file changed, 7 deletions(-)<br>
> <br>
> diff --git a/src/forward.c b/src/forward.c<br>
> index 10e7496..c893d84 100644<br>
> --- a/src/forward.c<br>
> +++ b/src/forward.c<br>
> @@ -782,13 +782,6 @@ static size_t
process_reply(struct dns_header *header, time_t now,
struct server<br>
> server->flags |= SERV_WARNED_RECURSIVE;<br>
> }<br>
> <br>
> - if (header->hb3 & HB3_TC)<br>
> - {<br>
> - log_query(F_UPSTREAM, NULL, NULL,
"truncated", 0);<br>
> - header->ancount = htons(0);<br>
> - header->nscount = htons(0);<br>
> - header->arcount = htons(0);<br>
> - }<br>
> <br>
> if (!(header->hb3 & HB3_TC) &&
(!bogusanswer || (header->hb4 & HB4_CD)))<br>
> {<br>
<br>
<span style="white-space: pre-wrap">
</span></div>
</span></font></div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Petr Menšík
Software Engineer, RHEL
Red Hat, <a class="moz-txt-link-freetext" href="https://www.redhat.com/">https://www.redhat.com/</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
</body>
</html>