在配置EDNS Client Subnet 后部分域名无法获取DNS解析 about unbound

[wcawijngaards]

Can you write the issue in English? If this is about resolution of a particular name, the logs when verbosity: 5 is enabled could be useful to look at to see what is going on.

[duckxx]

this is log.
unbound.txt

[wcawijngaards]

This is useful: error: SERVFAIL <itp.hncsmtr.com. HTTPS IN>: all servers for this domain failed, at zone itp.hncsmtr.com. upstream server timeout

So all the servers for the zone give no response. This makes the lookup fail. In addition, all of the IPv6 addresses fail with network unreachable errors, it is probably a good idea to set do-ip6: no because that would then not bother with the effort. But the lookup failure for the query is caused by the servers for the zone, on ip4, having timeouts.

Another interesting bit is this one, when sending to sending to target: <itp.hncsmtr.com.> 218.76.13.58#53 it receives the error error: recvfrom 82 failed: Connection refused. So the upstream server has connection refused. Perhaps the upstream server is not running or the firewall disallows access from the outside.

And then this error, error: SERVFAIL <itp.hncsmtr.com. AAAA IN>: all servers for this domain failed, at zone itp.hncsmtr.com. from 111.22.160.50 could not parse upstream response. And also for other types. The upstream server includes an EDNS record that says it contains 11 bytes of rdata, but those bytes are not in the packet. The packet length is too short. Possibly that is the reply for the edns client subnet rdata element. The upstream server malformed response is then not picked up by unbound and unbound continues to attempt other servers, that timeout.

Since the upstream servers respond with malformed EDNS record contents, it is probably best to not send them edns client subnet queries. It is possible to configure what upstream hosts get subnet info, with send-client-subnet and client-subnet-zone options, and then do not include this zone and its servers in that list.

[duckxx]

This is useful: error: SERVFAIL <itp.hncsmtr.com. HTTPS IN>: all servers for this domain failed, at zone itp.hncsmtr.com. upstream server timeout

So all the servers for the zone give no response. This makes the lookup fail. In addition, all of the IPv6 addresses fail with network unreachable errors, it is probably a good idea to set do-ip6: no because that would then not bother with the effort. But the lookup failure for the query is caused by the servers for the zone, on ip4, having timeouts.

Another interesting bit is this one, when sending to sending to target: <itp.hncsmtr.com.> 218.76.13.58#53 it receives the error error: recvfrom 82 failed: Connection refused. So the upstream server has connection refused. Perhaps the upstream server is not running or the firewall disallows access from the outside.

And then this error, error: SERVFAIL <itp.hncsmtr.com. AAAA IN>: all servers for this domain failed, at zone itp.hncsmtr.com. from 111.22.160.50 could not parse upstream response. And also for other types. The upstream server includes an EDNS record that says it contains 11 bytes of rdata, but those bytes are not in the packet. The packet length is too short. Possibly that is the reply for the edns client subnet rdata element. The upstream server malformed response is then not picked up by unbound and unbound continues to attempt other servers, that timeout.

Since the upstream servers respond with malformed EDNS record contents, it is probably best to not send them edns client subnet queries. It is possible to configure what upstream hosts get subnet info, with send-client-subnet and client-subnet-zone options, and then do not include this zone and its servers in that list.

So, how should these domain names be configured to exclude from the edns client subnet? If this also happens on the root domain name and all subdomains of the domain name, how to configure and exclude it?

[wcawijngaards]

I think something like client-subnet-always-forward: no, and then client-subnet-zone: "example.com" to send to example.com and other zones for which subnet is desired. But then hncsmtr.com is not configured in that way and also its nameservers are not configured. With send-client-subnet: 192.0.2.1 specific nameservers can be configured to send subnet to.

[duckxx]

I think something like client-subnet-always-forward: no, and then client-subnet-zone: "example.com" to send to example.com and other zones for which subnet is desired. But then hncsmtr.com is not configured in that way and also its nameservers are not configured. With send-client-subnet: 192.0.2.1 specific nameservers can be configured to send subnet to.

But I need every request to go through the edns client subnet. Except hncsmtr.com and the subdomain of the domain name.

[wcawijngaards]

The edns subnet configuration is set up to have an allowlist, and it does not have rejectlist configuration.

[duckxx]

The edns subnet configuration is set up to have an allowlist, and it does not have rejectlist configuration.

Can it be developed? Because this kind of unresolved domain name is a small number of domain names. Most domain names are resolved.

[wcawijngaards]

We do not want to support this. This is caused by edns-client-subnet. The feature is not meant to be deployed at large. It should be deployed only to a whitelisted range. The reasons for that are because of privacy reasons, and the standards issues that arise from probing complexity and dns architecture decisions wanting to have the query name as determinant of outcome. The other server is buggy, in that it sends a bad reply. Unbound should not deploy fixups for it, this has been a topic of discussion, eg. dns flag day 2019. Unbound does not implement the probing strategy from RFC 7871 section 12.1, but uses the whitelist approach from section 12.2.