[Enhancement] Implement RFC 8914 to deal with failed DNS queries

[jean-christophe-manciot]

This proposal tries to fix the way the stub resolver dnscrypt-proxy (DCP) deals with situations where one DNS resolver cannot answer positively to a DCP query.

So far, the algorithm DCP uses to deal with failed DNS queries is based on:

1. an ancient RFC 1035:
   The DNS resolver may return a RCODE=2 to a query called SERVFAIL and meaning Server failure - The name server was unable to process this query due to a problem with the name server. This answer is too broad to help DCP determine with certainty what is the cause of the failed DNS query, in order to take the appropriate action.
2. a random reaction:
   The same failed resolver can be tried by DCP several times in a row as shown by this post, or all reachable resolvers can be tried as shown by this post. This inconsistent, unpredictable and sub-optimal strategy may have some undesirable effects, including the inability to resolve an address which was resolvable by one of the resolvers but not all of them.

My proposal is to implement the RFC 8914: Extended DNS Errors published 2 years ago with the designed goal of precisely deal with this type of situation.

• This document defines an extensible method to return additional information about the cause of DNS errors. Though created primarily to extend SERVFAIL to provide additional information about the cause of DNS and DNSSEC failures, the Extended DNS Errors option defined in this document allows all response types to contain extended error information.
• There are many reasons that a DNS query may fail -- some of them transient, some permanent; some can be resolved by querying another server, some are likely best handled by stopping resolution....the stub resolver's only option [with RFC 1035] is to ask the next configured DNS resolver.
• This document specifies a mechanism to extend DNS errors to provide additional information about the cause of an error. The Extended DNS Error [EDE] codes described in this document can be used by any system that sends DNS queries and receives a response containing an EDE option. Different codes are useful in different circumstances, and thus different systems (stub resolvers, recursive resolvers, and authoritative resolvers) might receive and use them.

This will allow DCP to implement a predictable, consistent and optimal algorithm to deal with failed DNS queries.

If DCP does not implement RFC 8914, it will become irrelevant eventually.

@lifenjoiner
@livingentity
@maage
@alisonatwork
@ianbashford

[jedisct1]

Do actual resolvers send extended error codes yet?

My impression is that like the vast majority of DNS-related RFCs, it just exists as a document.

[lifenjoiner]

In my knowledge:

1. RFC 8914 is just proposed, but not approved to become the standard. Of course it is a good proposal.
2. A communication protocol is like a language, it needs the one you communicate with understand and speak it too.
3. We may implement it, once it became a final standard, and there are upstream servers and end user clients adopted it.

[jean-christophe-manciot]

@lifenjoiner @jedisct1

In my knowledge:

1. RFC 8914 is just proposed, but not approved to become the standard. Of course it is a good proposal.
2. A communication protocol is like a language, it needs the one you communicate with understand and speak it too.
3. We may implement it, once it became a final standard, and there are upstream servers and end user clients adopted it.

Proposed standards are considered stable. From this, "Many Proposed Standards are actually deployed on the Internet and used extensively, as stable protocols. Actual practice has been that full progression through the sequence of standards levels is typically quite rare, and most popular IETF protocols remain at Proposed Standard." It means that becoming an Internet standard is quite rare for a RFC.

For instance, many other RFCs are a proposed standard but used extensively nevertheless:

• RFC 1886: DNS Extensions to support IP version 6
• RFC 2535: Domain Name System Security Extensions
• RFC 4034: Resource Records for the DNS Security Extensions
• ...

If you wait for RFC 8914 to become an Internet Standard:

• it will most probably never happen
• if it happens, it will be too late

EDE is already supported by some major players such as:

• cloudflare
• cisco

dig dnssec-failed.org @208.67.220.220

; <<>> DiG 9.19.2 <<>> dnssec-failed.org @208.67.220.220
...
; EDE: 6 (DNSSEC Bogus)

• Cisco umbrella
• unbound
• bind9/dig since 9.16.4; current stable release is 9.19.2!
• nsd
• ...

Furthermore, you know it takes time to implement and test some major evolution like this one.

[jedisct1]

dig dnssec-failed.org @208.67.220.220

For the same query, that server returns a different code than everybody else. Yay.
That's why a standard would be a good thing.

[jedisct1]

Quad9 and Cloudflare seem to support it -- A query for dnssec-failed.org returns EDE: 9 (DNSKEY Missing).

But Unbound doesn't support it. Not sure what open source software does.