What does 'rndc nta' do and when should I use it?

Question:

I've heard that there's a new rndc command in BIND 9.11.0 - 'rndc nta'.  What does it do?

Answer:

'rndc nta' is used to temporarily disable DNSSEC validation for a domain, allowing unsigned and/or non-validating signed data to be returned by an otherwise-validating resolver. This is called a 'negative trust anchor', or 'nta' for short.

Question:

Great!  So when should I use it?

Answer:

You probably shouldn't.

Question:

Okay... so why did you implement it?

Answer:

DNSSEC exists so that resolvers can choose to verify that the results they received have been properly signed by a a key that can be proven to be the 'correct' key by a chain of signed keys traceable all the way up to the known key for the root zone. The purpose of doing this validation is so that no one unauthorized can tamper with the zone data without DNSSEC detecting it, so that the modified and/or spoofed data can be discarded. In theory that's the only time that DNSSEC validation will fail.

In practice, sometimes things don't work smoothly. For example, a key might not get replaced before it expires, or signatures get published for the wrong key, or the parent zone publishes corrupted DS records, or any of a number of other issues (some human, some technical) can cause a zone to fail validation by breaking the chain of signatures up to the known root zone key.

The 'rndc nta' command exists to allow the operator of a resolver to specify that they want to disable DNSSEC validation for a particular domain for a limited period of time. During this time unvalidated answers will be used and returned to queries, and (it is hoped) the issues causing the validation failure will be fixed.

It is important to note that while validation is turned off the domain in question will be no more secure than any unsigned zone. If the zone is failing to validate due to human error or accident then this generally won't pose a significant threat. If, on the other hand, the zone is failing to validate due to an attack, on either the owner of the zone or the operator of the resolver on which 'rndc nta' will be run, then it is possible that disabling validation will be of more help to the attacker than it will be to anyone else.

It is therefore the responsibility of the server operator to verify the cause of the validation failures and ensure that those failures are due to acknowledged issues, all based on information obtained from trustworthy sources, before issuing the 'rndc nta' command.

To put it another way, a validation failure is DNSSEC successfully detecting data with unverifiable provenance and preventing it from being used. That is what DNSSEC was created and designed to do. All of the other details for managing keys, signature records, provable non-existence, chains of trust, etc. exist only to support the goal of preventing suspect data from being sent to innocent DNS clients.

If an operator chooses to blindly disable validation for a zone 'in trouble' without ensuring that there are confirmed legitimate reasons for the failures then they are preventing DNSSEC from fulfilling the purpose for which it was created.