Determine DNS resolver features independent from actual queries

[ott]

systemd-resolved determines features that are supported by an upstream DNS resolver and adjusts its query behaviour accordingly. So, for example, if an upstream resolver supports TCP, systemd-resolved sends queries over TCP. At the moment it adjusts the supported features under one of the following conditions:

• A query timeout occurs.
• A response with its RCODE set to FormErr, ServFail or NotImp is received.
• A TCP connection could not be established.
• A TLS connection could not be established.
• A response with an invalid OPT RR is received.
• A response with a missing RRSIG RR is received, although the DO bit is set.
• A truncated response is received.

Some of these conditions are incorrect. For example, a query timeout can occur under many conditions and ServFail can be returned under many circumstances that do not imply that the resolver does not support a certain feature. It was reported multiple times, for example, that systemd-resolved unnecessarily degrades the feature level and becomes unusable, if DNSSEC validation is enabled and the upstream resolver returns ServFail because a query timeout occurred.

Therefore it seems best to determine the supported features independent from the actual queries that systemd-resolved forwards to upstream resolvers. One possibility would be to send probe queries with an empty question section or queries for the SOA RR of the root zone. However, it might be possible that some broken resolvers don't understand an empty question section or SOA RRs. So one open question is what a probe query should contain.

And of course it would still make sense to use feedback from actual queries, for example, if a TCP connection failed.

Moreover, the current feature level state diagram seems questionable to me. If I'm not mistaken, there are multiple orthogonal and independent features:

• TCP support
• DNS over TLS support
• EDNS0 support and supported options

It seems best to first determine whether queries over TCP are supported. This makes it easier to determine whether the upstream resolver did not reply because it can't be lost. Then support for EDNS0 and the various EDNS0 options can be determined. Last should be DNS over TLS to be able validate the resolvers certificate. If TCP is not supported there should be some timeout and retransmission algorithm. Perhaps it easiest to use some variant of RFC 6298.

[ott]

This issue details a comment that I made in #8849.