Hi， On Mon, Nov 15, 2022 at 8:15:00PM +0800, Petr Menšík wrote: > 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.
Unfortunately the unbound also has the same problem, I also submitted an issue. Although the forwarders configured by dnsmasq are trusted, there are also some situations that need to be considered, such as, the dnsmasq configuration file has been maliciously changed, your trusted forwarder has the same error handling problem or the host computer where the forwarder is located is attacked, so dnsmasq needs to do some obvious wrong checks, and it is also necessary.it can't rely entirely on other parsers. > > 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. Yes, The message I provided is a wire format, but it is a bit different from the wire format, because the first four bytes are a length field. I removed the length field, it should be all dns request and reply messages, it is wire format. Below is the download link: origin request: https://643684107.oss-cn-beijing.aliyuncs.com/packet/request0 origin response: https://643684107.oss-cn-beijing.aliyuncs.com/packet/response0 request1: https://643684107.oss-cn-beijing.aliyuncs.com/packet/request1 response1: https://643684107.oss-cn-beijing.aliyuncs.com/packet/response1 request2: https://643684107.oss-cn-beijing.aliyuncs.com/packet/request2 response2: https://643684107.oss-cn-beijing.aliyuncs.com/packet/response2 request3: https://643684107.oss-cn-beijing.aliyuncs.com/packet/request3 response3: https://643684107.oss-cn-beijing.aliyuncs.com/packet/response3 Of course, in previous comminicate, Geert Stappers has already made a reproduced git repository, here: https://git.sr.ht/~stappers/cert_check_by_dnsmasq, you can use this to reproduce it. For ldns-testns, I don't know how to construct the corresponding data format, so I can only provide complete dns request and response messages. But I think the structure of these packets is relatively simple, and it is very easy to analyze where the problem is. > > 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. > I think the second bug is also an obvious one, since the domain name of the query is not the same as the answer, it deserves to be fixed. Thank you very much for your reply. Regards, P1n9 _______________________________________________ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss
