<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hey all,</p>
<p><br>
</p>
<p>having this configurable makes sense particularly thinking about
the multitude of IoT devices often receiving not all that much
attention from their manufacturers. A particular example is the
camera Tapo C-310 which seems to be widely used and has often been
reported in the Pi-hole forums to cause a huge amount of queries
due to exactly this truncation method we are talking about here
(when dnsmasq is used with DNSSEC, the query A time.nist.gov
results in truncation).</p>
<p><br>
</p>
<p>Said Tapo camera is not behaving nicely and does not retry over
TCP. Instead, it retries the same query roughly one second later,
resulting in a whooping 86,400 identical queries, all being
truncated. A workaround is querying this domain periodically
manually over TCP but it is a rather ugly workaround.</p>
<p><br>
</p>
<p>If there would be an option to allow truncated content to remain,
I would indeed find it very useful for situations like the one
mentioned above. I confirmed that the camera could successfully
reads the returned CNAME/A record. This is what I got when simply
applying the submitted patch (but keeping the logging):</p>
<p><br>
</p>
<p>Oct 2 17:46:53 dnsmasq[1861633]: 25 127.0.0.1/45027 query[A]
time.nist.gov from 127.0.0.1<br>
Oct 2 17:46:53 dnsmasq[1861633]: 25 127.0.0.1/45027 forwarded
time.nist.gov to 127.0.0.1#5335<br>
Oct 2 17:46:53 dnsmasq[1861633]: 26 dnssec-query[DS] gov to
127.0.0.1#5335<br>
Oct 2 17:46:53 dnsmasq[1861633]: 26 reply gov is DS for keytag
2536, algo 13, digest 2<br>
Oct 2 17:46:53 dnsmasq[1861633]: 27 dnssec-query[DS] nist.gov to
127.0.0.1#5335<br>
Oct 2 17:46:53 dnsmasq[1861633]: 28 dnssec-query[DNSKEY] gov to
127.0.0.1#5335<br>
Oct 2 17:46:53 dnsmasq[1861633]: 28 reply gov is DNSKEY keytag
2536, algo 13<br>
Oct 2 17:46:53 dnsmasq[1861633]: 28 reply gov is DNSKEY keytag
35496, algo 13<br>
Oct 2 17:46:53 dnsmasq[1861633]: 27 reply nist.gov is DS for
keytag 33751, algo 8, digest 2<br>
Oct 2 17:46:53 dnsmasq[1861633]: 29 dnssec-query[DNSKEY] nist.gov
to 127.0.0.1#5335<br>
Oct 2 17:46:53 dnsmasq[1861633]: 29 reply nist.gov is DNSKEY
keytag 18303, algo 8<br>
Oct 2 17:46:53 dnsmasq[1861633]: 29 reply nist.gov is DNSKEY
keytag 33751, algo 8<br>
Oct 2 17:46:53 dnsmasq[1861633]: 30 dnssec-query[DS] glb.nist.gov
to 127.0.0.1#5335<br>
Oct 2 17:46:53 dnsmasq[1861633]: 30 reply glb.nist.gov is DS for
keytag 56235, algo 7, digest 1<br>
Oct 2 17:46:53 dnsmasq[1861633]: 30 reply glb.nist.gov is DS for
keytag 4395, algo 7, digest 1<br>
Oct 2 17:46:53 dnsmasq[1861633]: 31 dnssec-query[DNSKEY]
glb.nist.gov to 127.0.0.1#5335<br>
Oct 2 17:46:53 dnsmasq[1861633]: 31 reply glb.nist.gov is
truncated[DNSKEY]<br>
Oct 2 17:46:53 dnsmasq[1861633]: 25 127.0.0.1/45027 validation
result is TRUNCATED<br>
Oct 2 17:46:53 dnsmasq[1861633]: 25 127.0.0.1/45027 reply is
truncated<br>
</p>
<p><br>
</p>
<p>For testing, "dig +ignore + notcp time.nist.gov" is handy as it
is guaranteed to be truncated with dnsmasq and DNSSEC enabled if
the domain isn't already in your local cache through a preceding
TCP query.<br>
</p>
<p><br>
</p>
<p>Best,</p>
<p>Dominik<br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">Am 10/2/24 um 12:30 AM schrieb Petr
Menšík:<br>
</div>
<blockquote type="cite"
cite="mid:dc7bdf0b-bab1-4f3c-b4c4-e2d7db64b5b2@redhat.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<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"
moz-do-not-send="true"><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"
moz-do-not-send="true"><simon@thekelleys.org.uk></a>;
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:dnsmasq-discuss@lists.thekelleys.org.uk"
moz-do-not-send="true">dnsmasq-discuss@lists.thekelleys.org.uk</a>
<a class="moz-txt-link-rfc2396E"
href="mailto:dnsmasq-discuss@lists.thekelleys.org.uk"
moz-do-not-send="true"><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"
moz-do-not-send="true"><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"
moz-do-not-send="true"><simon@thekelleys.org.uk></a><br>
<b>Sent:</b> 25 September 2024 13:39<br>
<b>To:</b> <a
class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:dnsmasq-discuss@lists.thekelleys.org.uk"
moz-do-not-send="true">dnsmasq-discuss@lists.thekelleys.org.uk</a>
<a class="moz-txt-link-rfc2396E"
href="mailto:dnsmasq-discuss@lists.thekelleys.org.uk"
moz-do-not-send="true"><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"
moz-do-not-send="true"><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/"
moz-do-not-send="true">https://www.redhat.com/</a>
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB</pre>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre wrap="" class="moz-quote-pre">_______________________________________________
Dnsmasq-discuss mailing list
<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-freetext" href="https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss">https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss</a>
</pre>
</blockquote>
</body>
</html>