DNSSEC and forward zones
tmorizot at sd.is.irs.gov
Tue Nov 1 18:34:05 UTC 2011
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.
More information about the bind-users