dnssec-policy questions and suggestions

Tue Dec 3 08:23:57 UTC 2019

Hi Tony,

Thanks for your questions and suggestions.

Now that I am back from vacation, let me reply to your e-mail.

On 11/13/19 9:39 PM, Tony Finch wrote:
> The new automatic key management stuff looks neat!

Thanks!

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

I'll reply here, and take note to update the documentation too.

> 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)

Correct: dnssec-policy inside zone statements take a string that refers
to a dnssec-policy statement elsewhere in the configuration.

The default is "none", no DNSSEC maintenance.  I just checked and it is
in config.c:

    bin/named/config.c:     dnssec-policy \"none\";\n\

The "default" and "none" are built-in names. "default" uses a default
dnssec policy that you don't need to configure explicitly. "none"
explicitly turns DNSSEC maintenance of for a zone.

> 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
> :-)

Strictly speaking: The ttlval option type now also understands ISO 8601
durations :).  If a ttlval starts with a 'P' we will assume it's a duration.

> 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?

KSK is 2048, non-KSK is 1024, I believe that is the same 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...

The publish-safety interval will be added to the publication interval.
In other words, if the publish-safety is set to 5 minutes, the keymgr
will wait 5 additional minutes before moving the DNSKEY into OMNIPRESENT
state.

Similarly, the retire-safety interval will be added to the retire
interval, and it will take that much additional time before a DNSKEY is
withdrawn from the zone.

5 minutes may not be the best default, I agree.  Maybe 1 hour is better
or perhaps set it to zero and leave it up to the operator if it is needed?

> 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 :-)

You are right, that is missing.

> 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.

It may be possible, I consider this a feature request ;-)

Also note that the zone propagation delay should also take into account
a small constant value, because it may take some time to actually load
and serve the zone at the primary server.

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

Okay, I am happy to change it.

> 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.

Parent update times can usually be retrieved from their SLAs. But what
we really want is to incorporate the check-ds logic: Did we see the DS
at the given server?  We plan to add this at a later stage.

> 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.

Yes that is on the road map, but time.

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

We will need to add some rndc commands that can give you these timings.

But it sounds like you are asking as a parent zone operator?  It is hard
to tell when changes are needed without having the corresponding DNSSEC
policy in use.

> 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.)

I guess 'stat' is not good enough? :)

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

Not sure if I understand this question, can you elaborate?

> 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.

What is it that you want to trigger? And after what event?

> Tony.

Best regards, Matthijs

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-workers/attachments/20191203/7da94743/attachment.bin>