Opt into strict DNSSEC checking - does DNSSEC provide a way for a zone to request strict signature validation?

Question

Is there a way for a domain good.com to promise that it will sign all of its DNS records, and that any unsigned records for any host *.good.com should be rejected? In other words, is there a way for a zone to provide a signed statement indicating that it is DNSSEC protected, and to suggest that DNSSEC clients can use strict signature checking for DNS records in that zone?

This would be analogous to a HSTS record (where a site opts into only HTTPS, and suggests that browsers should reject any attempts to connect through insecure HTTP), or a SPF policy that opts into strict checking (stating that emails that don't comply with the SPF policy should be rejected).

Background (as I understand it). In principle, DNSSEC provides protection against man-in-the-middle attacks: the client can check whether the DNS response has a valid signature, and ignore all unsigned responses and responses with invalid signatures. Unfortunately, in practice, this has an unacceptable compatibility cost. If you treat all unsigned responses as invalid, then you "break the Internet": some sites stop working, either because the domain isn't consistently signing all records, or (I'm told) because signatures occasionally get stripped by middleboxes.

As a result, for practical deployment reasons, many DNSSEC-capable clients are actually non-validating: they look at the signature, but if the signature is missing, they still accept the DNSSEC response. (Even Google's public DNS resolver will do this in some cases.)

This opens up a nasty man-in-the-middle attack: the man-in-the-middle simply strips all of the DNSSEC signatures, and then modifies the records however he likes. If the client accepts unsigned DNS responses, this man-in-the-middle attack negates the value of DNSSEC. Of course the other side of this unhappy situation is that if the client rejects all unsigned DNS responses, then it might be secure against man-in-the-middle attacks, but many legacy sites will stop working, causing an unacceptable compatibility cost. At least, this is my understanding.

You could imagine a better solution might be possible if DNSSEC-aware clients had a way to tell which zones should use strict signature validation. In particular, if google.com or good.com had a way to declare "I guarantee all of my DNS records will be signed, and I want you to treat any unsigned records as invalid", then a cooperating client could apply strict validation to DNS records for *.good.com, while being non-validating for other zones. This might allow good compatibility with legacy domains while allowing strict checking for zones that want to opt into it, in other words, providing partial protection against man-in-the-middle attacks without "breaking the Internet".

Does such a mechanism exist?

Answer 1

There are three flags in a DNSSec packet that are responsible for communicating the validation requirements of a domain.

The DO bit

The DO bit is set by the resolver to indicate that it requires authentication Resource Records to be included in the response.

If a resolver is security aware, it MUST set the DO bit. If a Name Server gets a message without the DO bit, it MUST strip out any authentication Resource Records. Unless there is a specific request for an authentication record.

The CD bit

This bit allows the intermediate name servers to disable signature validation. This basically says 'don't bother validating things, I'll do it myself, just send me the raw records'

The AD bit

This is the part that actually answers your question.

The name server side SHOULD set the AD bit if and only if the resolver side considers all RRsets in the Answer section and any relevant negative response RRs in the Authority section to be authentic.

The AD bit says, these records are authentic they are signed.

Performing Secure Queries

If www.example.com has the correct keys and resource records configured. It must still respond to clients that don't understand DNSSec. DNSSec is designed to be backwardly compatible, it must respond to requests that don't understand DNSSec. This does create the vulnerability that you highlight.

However the process exists, using the above flags to ensure that only authentic records are received, but this requires that the resolver is configured to do so. Bind does provide this mechanism in the DNSSec-validation flag (which is enabled by default)

Enable DNSSec validation in named. Note DNSSec-enable also needs to be set to yes to be effective. The default is yes.

So if you create your own DNS Resolver, and configure it to only accept validated responses, you will not be able to resolve domains that don't have a complete chain of trust associated with them. Though domains that have no DNSSec records will work as before.

The reason that Google's name servers behave as they do, is that they have configured them to ignore the AD Bit if the domain is popular. So if stackexchange had a problem with their certificate, Google would still resolve with their name servers. This seems like a decision to prevent stackexchange dropping off the internet for a large proportion of people using Google DNS.

edited to answer the actual question!

If you have configured your secure resolver, and somebody upstream can hijack its queries they could strip out the DO bit, which would force the upstream servers to strip out all authentication records. When your secure resolver receives that record it would simply presume that the domain you were looking for didn't have any authentication configured.

To perform this attack you don't even explicitly need to be completely inserted in the middle, the ability to adjust the outgoing DNS packet would be enough.

This was considered as part of DNSSec's original design. According to RFC3833 - Threat Analysis of the Domain Name System

While it certainly would be possible to sign DNS messages using a channel security mechanism such as TSIG or IPsec, or even to encrypt them using IPsec, this would not be a very good solution for interception attacks
[...]
For heavily used name servers (such as the servers for the root zone), this cost would almost certainly be prohibitively high. Even more important, however, is that the underlying trust model in such a design would be wrong, since at best it would only provide a hop-by-hop integrity check on DNS messages and would not provide any sort of end-to-end integrity check

DNSSec is designed to protect against a number of specific attacks, such as cache poisoning, Man in the middle attacks were simply discounted for the above reason.

Answer 2

The short answer is: when you use DNSSEC in a zone, all records should be signed. So there is no need for a mechanism to explicitly convey this statement as it is the default and only policy of DNSSEC signed zones.

There are no exceptions with that. There is an NSEC3 Opt-Out mechanism but this is more targeted to delegation only zones like TLDs, in order to reduce the size by signing just for child zones that are themselves DNSSEC enabled.

So if the zone is DNSSEC enabled and the resolver is validating, it should treat all non signed records as a validation failure and returning SERVFAIL.

For details, please refer to "4.3. Determining Security Status of Data" in RFC4035 and note this last paragraph in section 5:

A resolver SHOULD expect authentication information from signed zones. A resolver SHOULD believe that a zone is signed if the resolver has been configured with public key information for the zone, or if the zone's parent is signed and the delegation from the parent contains a DS RRset.

In summary the presence of a key in the zone and the validation to all the chain of trust from the root up to this key in the zone should have as a consequence that all records in the zone have accompanying RRSIG records to validate their authenticity.

In that case, getting a reply without the RRSIG records may as well show an ongoing attack so this should be treated as a validation error, hence SERVFAIL.

Now, as you quoted yourself, various resolvers choose to override the default standard behavior and let pass through some invalid or missing DNSSEC records. It is a local policy decision, up to each resolver, but it is clearly outside of the standard.

As you linked, Google does it for cases like "very popular domain", many ISPs do it from time to time, for example Comcast, as they get the blame when domain names are not properly configured (see this example: https://www.darkreading.com/risk/dnssec-error-caused-nasa-website-to-be-blocked/d/d-id/1136990 and you can find a curated list of related problems at https://ianix.com/pub/dnssec-outages.html ). And there is now even a RFC specifically on this problem: RFC7646: Definition and Use of DNSSEC Negative Trust Anchors

This document defines Negative Trust Anchors (NTAs), which can be used to mitigate DNSSEC validation failures by disabling DNSSEC validation at specified domains.

and:

In the case of a validation failure due to misconfiguration of a Top- Level Domain (TLD) or popular domain name (such as a top 100 website), content or services in the affected TLD or domain could be inaccessible for a large number of users. In such cases, it may be appropriate to use an NTA as soon as the misconfiguration is confirmed. An example of a list of "top N" websites is the Alexa "Top 500 Sites on the Web" [Alexa] or a list of the of the most- accessed names in the resolver's cache.

You may also be interested by this draft: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dnssec-roadblock-avoidance-05 that deals with difficulties validating resolvers need to take into account, both due to misconfigurations and also to hostile environments.