Hi, On 22/11/2022 07:00:26; Simon Kelley via Dnsmasq-discuss wrote: > This behaviour arises from the way dnsmasq works. It doesn't attempt to > completely parse the reply packet, it just sends it bit-for-bit to the > original requestor. This has the advantage dnsmasq as a DNS forwarder is > transparent: new packet formats or data types that it doesn't understand > are still returned to the original requestor. > > As far as security is concerned, I think it's a fundamental mistake to > rely on dnsmasq or any upstream DNS infrastructure to protect the > resolver code in the original requestor. DNS happens most often over > UDP, and if the resolver is vulnerable to malformed packets it's quite > easy to get those malformed packet to the resolver without the use of > dnsmasq.
Yes, I admit that the original requestor will have some checks, but if dnsmasq relies on the checks of the client and the upstream DNS server, is it inappropriate? Should dnsmasq also check accordingly? In my opinion, dnsmasq should not return to the client a packet that does not conform to the rfc definition, such as the first bug. I also know that DNS is mostly UDP protocol, but it seems that the same problem exists under TCP protocol. > > If you'd found a malformed packet which causes dnsmasq to misbehave, I'd > be very interested, I'd be especially interested in any malformed > packets that can get ad flag set when DNSSEC validation is enabled. \As > I understand, you've found neither of those. > > Forwarding untrusted DNS packets to a client which is (or should be) > expecting untrusted DNS packets is simply not a bug, in my opinion. > I don't quite understand why clients expect untrusted packets. > Of course dnsmasq does attempt to understand the contents of replies in > order to extract the records which it caches, and it handles any > malformed packets it detects as part of that process. It does that by > abandoning the caching of the records, but still returns the broken > answer. It would be fairly simple to modify extract_addresses() to > produce a different return value when it terminates due to a known > malformed packet, and then turn that return code into a SERVFAIL reply. > There would be no guarantee that the packet didn't have some of the > malformations you list, but it would catch some nonsense packets. Yes, I think it is necessary to return rcode as SERVFAIL when encountering malformed packets. Bind, maradns, pdns and knot all return packets with rcode SERVFAIL. This behavior is compliant with the DNS RFC specification. If dnsmasq returns the message whose rcode is SERVFAIL to the client, the client can mark the packets as untrusted and request again without parsing all records of the packets. I think this is also why the RFC defines the rcode field. Thank you very much for your reply. > > > Cheers, > > Simon. > > _______________________________________________ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss Thanks, P1n9 _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
