DNSSEC, views & trusted keys...

[Timothe Litt]

I have 9.7.1-P2 running and since it's supposed to be 'for humans', I guess
I'm trying to determing if I am one.  It's not going as well as hoped... :-)

I have a domain - example.net, with two views, the usual 'internal' and
'external'; a third is planned.  The master maintaining all the sub-domains
with auto-dnssec maintain.  Master and slaves have dnssec-validation on and
lookaside auto.

My internal systems use these servers as their resolvers.  The external view
doesn't allow recursion.

example.net's internal view is signed by ksk-internal. (Yes, the ZSK sigs
are there too.)
example.net's external view is signed by ksk-external, which is distinct
from ksk-internal.

The external keys are registered in the ISC DLV, and dnsviz seems quite
happy to validate a host that is in a delegated sub-domain signed by a yet
another key.

I'm unclear about how to configure this for the validation side of
example.net.

The ARM has a sentence where it says that BIND 'won't do crypto validation
on zones for which it is authoritative'.

And sure enough, dig +adflag to either view never has AD set on the
response.  (It will on ., isc.org, .gov, so validation is working.)

This doesn't seem right.  How is an ordinary internal client supposed to
know that it has authoritative (signed) data?  Yes, someday there may be
client resolver libraries that provide end-to-end validation.  But until
then, if trusting AD from my configured server is good enough for .gov, why
isn't it good enough for example.net?  

I've heard the argument that 'it doesn't make sense to verify the zone on
your own disk', but I don't buy it.

I'd like, for example, for my internal servers to show green with
http://www.dnssec-validator.cz/'s firefrox plugin...

If a server is authoritative for a zone that it maintains, it knows that the
signatures are all valid (or not).  It also should be able to check with its
parent (dlv, trusted-key list...) that its delegation is still valid.  So
it's surprising that it won't set AD.

The idea that the client should trust AA without AD in this case also seems
a step backwards.

There is other advice in the ARM that says to put 'your organization's
public keys in the trusted-keys list'.  That doesn't help - and in fact,
confuses me even more since example.net has TWO different public keys - one
for each view.  And trusted-keys is a global server option...

I must be missing something.

Bottom line question:
	Short of configuring some other systems as caching-only validating
nameservers and having clients point to them, how does one configure BIND to
get AD for authoritative zones - preferably iff it can validate that the
chain of delegations to it is valid?

And no, it's not practical to run nested copies of BIND - most of my systems
are small embedded systems with very limited memory.  Nor is it practical to
double the number of name servers in my network.

Semi-related question:
	Does anyone know of a public validating resolver that uses the isc
dlv?  That doesn't solve the internal problem, of course, but it would be
handy for testing from 'outside'.

---------------------------------------------------------
This communication may not represent my employer's views,
if any, on the matters discussed.