[question] bind mishandles some cases when bad dns response is received
Summary
When the DNS forwarder iteratively queries the malicious domain name server, it returns some malformed dns packets, and bind returns the packet to the client without proper verification, which will give the user a distrust or malicious data. Other authoritative dns servers have done correct verification. you can start a fake domain name server locally and return specific data.
BIND version used
BIND 9.17.21 (Development Release) id:ffdb856, BIND 9.19.6
Steps to reproduce
1、Turn on a fake name server and return a specific payload.
- download dns_server.py
- run
python3 dns_server.py "response file path"
to listen 53 port.
2、start bind. The configuration options are as follows:
options {
directory "/etc/named";
pid-file "named.pid";
allow-query { any; };
forward only;
forwarders {
127.0.0.1;
};
listen-on port 5353 { 127.0.0.1; };
listen-on-v6 port 5353 { ::1; };
allow-recursion { 127.0.0.1; };
dnssec-validation no;
recursion yes;
max-cache-size 0;
max-ncache-ttl 0;
};
3、Send the corresponding dns request.
- download dns_request.py
- run
python3 dns_request.py "request file path" 5353
to send the quey packet. Run multiple times and watch the return message.
What is the current bug behavior?
When the first query is made, the dns packet has passed the verification. When the second query is made, the rcode is 2, and the rcode is 2 after that. The first behavior is inconsistent with the latter. In the latest version bind9.19.6, when you repeat the query several times, it will return rcode as 0, which is very strange.
What is the expected correct behavior?
unbound,knot-resolver,pdns all always return the response packets with rcode 2.
Reproduce data
The first four bytes are the length