<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<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>
<div id="appendonsend"></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 <rahul.thakur@genexis.eu><br>
<b>Sent:</b> 25 September 2024 15:29<br>
<b>To:</b> Simon Kelley <simon@thekelleys.org.uk>; dnsmasq-discuss@lists.thekelleys.org.uk <dnsmasq-discuss@lists.thekelleys.org.uk><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">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">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">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 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>
<div id="x_appendonsend"></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 <dnsmasq-discuss-bounces@lists.thekelleys.org.uk> on behalf of Simon Kelley <simon@thekelleys.org.uk><br>
<b>Sent:</b> 25 September 2024 13:39<br>
<b>To:</b> dnsmasq-discuss@lists.thekelleys.org.uk <dnsmasq-discuss@lists.thekelleys.org.uk><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 <rahul.thakur@iopsys.eu><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>
<br>
_______________________________________________<br>
Dnsmasq-discuss mailing list<br>
Dnsmasq-discuss@lists.thekelleys.org.uk<br>
<a href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a><br>
</div>
</span></font></div>
</div>
</body>
</html>