[bind10-dev] DNS key management

[Stephen Morris]

On 04/03/2012 18:55, Scott Mann wrote:
> Hi Everyone,
> 
> The BIND9 team is beginning to work on a set of key management
> tools which will handle a variety of tasks related to the
> management of all manner of dns-related keys. : :
> 
> I) A zone verification tool: This will likely be written in C
> because there is already a big chunk of this done in C (and we have
> a deadline 1. verifies that the zone is internally consistent and
> complete 2. ensures that the NSEC/NSEC3 chains are complete - make
> sure to cross ref with NSEC3PARAM record

This seems similar to the OpenDNSSEC Auditor,
https://wiki.opendnssec.org/display/OpenDNSSEC/Auditor+Requirements.

The auditor was something we introduced into OpenDNSSEC at an early
stage in the development because we intended OpenDNSSEC for
high-profile zones and wanted to have an added assurance that bugs in
the signing would not reveal themselves as incorrectly signed zones.
It was written using a different language from the signer, in part to
avoid a bug common to both the signer and the auditor allowing an
error through.

> - check DS vs NSEC/NSEC3 record to make sure delegations
> consistent

Bear in mind that a zone may be signed with multiple keys, not all of
which have a DS in the parent. (One could be a newly introduced key)

> II) A key coverage tool (to be written in python): 1. ensures that
> there are no gaps in key coverage - make sure that keys are
> published in your zone at least 1 ttl before that key is to be
> published - use refresh rate from SOA - e.g., ttl+refresh  to
> insure that key is published soon enough

The timing of events during key rollover is covered in
htp://tools.ietf.org/html/draft-ietf-dnsop-dnssec-key-timing (expired,
but I'm hoping to resurrect it) and
http://tools.ietf.org/html/draft-mekking-dnsop-dnssec-key-timing-bis

> III) A dnssec-check tool (to be written in python): 1. Check  the
> parent for the proper KSK - DNS lookup for zones parent and get DS,
> then confirm that it is correct. - Verify that key is published. -
> Pay attention to future use during development. - future use:
> upward check from child - make sure design includes this thinking

I would extend the check so that all parent nameservers are checked
for the presence of the DS record as are all nameservers for the zone
being signed.

Stephen