DNSSEC and forward zones

[Scott Morizot]

On 1 Nov 2011 at 18:12, Vinny_Abello at Dell.com wrote:
> Thanks, however I can't control the domain in question
> unfortunately. It is what it is. We have to work with it. I totally
> understand why this doesn't work and actually agree with the design,
> however I just don't have a workaround or way to force forwarders
> for this domain with dnssec validation enabled on the resolver. 

Short answer. You can't simply forward queries for an undelegated zone 
from a tree that's signed from a DNSSEC validating nameserver. The 
validation correctly determines that the parent is signed and that no 
delegation exists, rendering any response bogus. (In your example 
'internal' would have had to have been delegated from root, which is 
signed. It's not, so validates as bogus.) There's no way to make that 
work with your architecture as described. There are, however, two 
alternate approaches that should work.

First, you can have a layer of non-validating recursive, caching DNS 
servers used directly by clients. Those would be configured to forward 
only queries for policydomain.internal to its nameservers and forward 
only everything else to the DNSSEC validating nameservers. (Actually, to 
work properly, the recursive nameservers you don't want to validate need 
to have DNSSEC enabled and validation enabled, but no trust anchors 
configured. Otherwise, they will forward queries to the validating 
nameservers with the CD bit set, I believe.)

Alternatively, you can sign 'policydomain.internal' and configure its key 
as one of the trust anchors on the validating name servers. The order of 
validation is, if I recall correctly, locally configured trust anchors, 
then chain of trust from root, and finally DLVs. So doing that should 
provide a successful validation for the domain.

Those are the only two approaches that come to my mind to make the 
environment you describe work. Others may have other thoughts.

HTH,

Scott