dnssec-policy questions and suggestions

[Tony Finch]

The new automatic key management stuff looks neat!

On reading through the documentation, some things aren't clear to me.

The description of the `dnssec-policy` inside zone statements takes a
string (name), not a full policy, right? Is the "default" a built-in name?
(It isn't in the default named.conf in config.c)

Do I understand correctly from the code that durations can also be written
in TTL form (e.g. 1w)? It is rather less fussy and shouty than ISO 8601
:-)

For key lengths, this doesn't matter so much for modern algorithms but I
guess for RSA the default is 2048 bits like elsewhere in BIND?

For the publish-safety and retire-safety intervals, I don't understand how
they affect the timing. How are the base values for the publish interval
and retire invterval calculated? Perhaps the safety values will make more
sense if I know that. What kind of unforseen events are they supposed to
cope with? 5 minutes is not long enough to deal with anything unforseen...

In the signature-validity description, my background knowledge tells me
that the inception offset is 1h and that the jitter either spreads
signatures over 1h (in the normal case) or over the whole
validity-minus-refresh interval for newly signed zones. But I didn't get
that from the docs :-)

Would it be possible to calculate the zone-propagation-delay from the SOA
refresh interval by default? Propagation is usually much faster with
NOTIFY but that isn't guaranteed to work so the refresh interval (plus
some safety margin) is more correct.

The default 1h parent-ds-ttl seems a bit low to me: based on a brief
survey I think 24h is more popular.

I don't think it is safe to rely on guesses about how long parent updates
take. One of our parents has a strict rate limit of 10 delegation changes
per day weekdays only, and we have lots of delegations from that parent
so bad thing could happen if there was an unfortunate cluster of changes.
But in the normal case I don't want to have BIND twiddling its thumbs
pessimistically for a week waiting for a change that already happened.

I would be MUCH happier if I could leave the parent intervals unset, and
instead have a safety interlock that prevents a KSK rollover from
proceeding past a DS change until something has verified that the DS
change has actually happened. A script that can run something like `rndc
ds-matches <zone>` would do the trick. In my setup the signing server /
hidden primary is not allowed to talk directly to the outside world, so
the DS checker is a bit awkward. And the checks would not work if they
were built in to `named` even tho that would be super neat.

Is there a way to find out when DS changes are needed? Or do we have to
poll every zone's CDS records?

Is there a way to find out when key files have been modified?  For disaster
recovery I need to be able to encrypt them and back them up promptly.
(Generated keys would be the only unrecoverable data on my signer.)

If we are expected to poll for these things, how does the polling interval
relate to the other timing parameters?

There aren't many ways for `named` to tell other programs when to do
things. One way might be via syslog but that's a bit yuck. Perhaps more
fun would be to use a special NOTIFY message, maybe with QTYPE=DNSKEY with
the full DNSKEY RR of the changed key in the additional section? And
QTYPE=CDS for DS changes. Then I could point it at my `nsnotifyd` program
which can fire off a script.

Tony.
-- 
f.anthony.n.finch  <dot at dotat.at>  http://dotat.at/
Malin, Hebrides, Bailey: North or northeast 4 to 6. Rough or very rough.
Showers. Good.