Interesting tests.
But dnsmasq is somehow naive in parsing replied queries. It tries to
deliver the response exactly as it were delivered to it. I think the
main reason for it is it expects trusted resolvers to be used as a
forwarding servers, not something bogus. Sure, I admit that might not be
correct expectation. dnsmasq is minimalistic and tries to minimize the
size of code and used resources. Therefore it does not do full parsing
of the message and verification of every aspect in the response.
I would recommend using Unbound for less trusted forwarders. I think all
other implementations do not rely on recursive server doing the hard
work, so they may encounter also less trusted responses. But dnsmasq
should send queries to trusted forwarders only. It can therefore trust
them to do more strict checking.
But I admit we should add at least the most obvious checks. Would you
please make the responses in ldns-testns [1] server format, so it would
be easier to test it? It allows also encoding the body in hex format, so
invalid responses are broken as well. It would be easier to test the bad
behaviour and prepare fixes for them. Are those links leading to DNS in
wire format? It would be simpler to read if pcap with them were used,
wireshark would visualise those responses well.
But as I said already, unlike other mentioned implementations, dnsmasq
will accept responses ONLY from configured addresses. It will never use
any other for iterative queries from root. Because it does not know how
to do that. So if the forwarder ensures those packets have valid format,
dnsmasq just relies on it. It is not possible to send query for
attacker's name and get around the forwarder's checking. I think at
least the 1st bug should be fixed, others can rely on forwarder's checks.
Regards,
Petr
[1] https://linux.die.net/man/1/ldns-testns
On 11/12/22 03:30, ZhangJiangyu 张江瑜 via Dnsmasq-discuss wrote:
The rcode of the dnsmasq returned
--
Petr Menšík
Software Engineer, RHEL
Red Hat, https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
