On Sat, Nov 26, 2022 at 10:26:46PM +0000, Simon Kelley wrote:
> On 24/11/2022 02:40, zhangjiangyu via Dnsmasq-discuss wrote:
> > On 24/11/2022, zhangjiangyu via Dnsmasq-discuss wrote:
> > >
> > > After I read rfc5625, I understand what you mean. you are right.
> > > |Section 4.3 writes:
> > > |
> > > |Similarly, all responses MUST be proxied regardless of the values of
> > > | the TYPE and CLASS fields of any Resource Record therein.
> > >
> > > In fact, there are corresponding security considerations in rfc5625,
> > > and the requirements for packet filtering are proposed. These points
> > > are consistent with my previous description of dnsmasq returning
> > > SERVFAIL. The explicitly cited example, "incorrect counts for the
> > > Question, Answer, Authority, and Additional Sections", has the
> > > same cause as our finding "request3-response3-combination"(Thanks
> > > to Geert Stappers for the correction). The expected behavior for
> > > this test case should return rcode as SERVFAIL.
> > >
> > > |Section 4.3 writes:
> > > |
> > > |Examples of malformed packets that MAY be dropped include:
> > > |
> > > | o invalid compression pointers (i.e., those that point outside of
> > > | the current packet or that might cause a parsing loop)
> > > |
> > > | o incorrect counts for the Question, Answer, Authority, and
> > > | Additional Sections (although care should be taken where
> > > | truncation is a possibility)
> > > |
> > > |In these circumstances, proxies SHOULD synthesise a suitable DNS
> > > |error response to the client (i.e., SERVFAIL) instead of dropping the
> > > |packet completely. This will allow the client to detect the error
> > > |immediately.
> > >
> > > Here is another bug for the same reason:
> > > https://www.mail-archive.com/dnsmasq-discuss@lists.thekelleys.org.uk/msg16552.html
> > >
> > > Thank you very much for your reply.
> > >
> > > Thanks,
> > > P1n9
> >
> > I'm so sorry that I need to make a correction.
> > https://datatracker.ietf.org/doc/html/rfc5625#section-6.3
> >
> > |Section 6.3 writes:
> > |
> > |Examples of malformed packets that MAY be dropped include:
> > |
> > | o invalid compression pointers (i.e., those that point outside of
> > | the current packet or that might cause a parsing loop)
> > |
> > | o incorrect counts for the Question, Answer, Authority, and
> > | Additional Sections (although care should be taken where
> > | truncation is a possibility)
> > |
> > |In these circumstances, proxies SHOULD synthesise a suitable DNS
> > |error response to the client (i.e., SERVFAIL) instead of dropping the
> > |packet completely. This will allow the client to detect the error
> > |immediately.
>
>
> I've just pushed
>
> https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=e939b45c9facb1b2dad688de1ce14457247615e9
>
> which turns a malformed reply detected by the existing code parsing data for
> the DNS cache into a SERVFAIL.
--- a/CHANGELOG
+++ b/CHANGELOG
@@ -60,7 +60,9 @@ version 2.88
Thanks to Ye Zhou for spotting the problem and an initial patch.
If we detect that a DNS reply from upstream is malformed don't
- return it to the requestor; send a SEVFAIL rcode instead.
+ return it to the requestor; send a SERVFAIL rcode instead.
+ Described at https://datatracker.ietf.org/doc/html/rfc5625#section-6.3
+ Thanks to Zhang Jiangyu for raising awareness of it.
version 2.87
>
> That should cover both the examples above.
>
I haven't yet played with it.
Groeten
Geert Stappers
--
Silence is hard to parse
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
