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. _______________________________________________ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
