BIND-9.16.1 & KASP

[Matthijs Mekking]

Mark,

On 4/13/20 8:54 PM, Evan Hunt wrote:
> On Mon, Apr 13, 2020 at 02:22:53PM +0200, Mark Elkins wrote:
>> Question - What are the "TYPE65534" records? What are they saying? I am 
>> using "DiG 9.16.1" so surprised it doesn't know.
> 
> This is a mechanism named uses to keep track of the status of zone
> signing operations, so that if there's a crash or power outage before
> signing is complete, it'll know which step it needs to resume on. To
> see the status in a human-readable form, use "rndc signing -list <zone>".
> If it says signing is complete, you're free to remove the records
> with "rndc signing -clear all <zone>".
> 
>> My zones '$TTL' is 1200... so I would have thought the CDS record would 
>> have appeared by now.
>> I "signed" the zone at Apr 12 21:27 +02:00 and its now 16 hours later. I 
>> thought the biggest delay factor is the zones $TTL, often set to one day.
> 
> I'm... not sure CDS is published automaitcally yet. I'd have to check to be
> sure, but I think that's coming in a future release.

If you sign your zone for the first time, named needs to make sure the
DNSKEY and RRSIG records are long enough in the zone such that if a
resolver is able to fetch the DS, it must also be able to fetch the
corresponding DNSKEY and RRSIG records. Only then the CDS is published
indicating it is safe to submit the DS record.

This time is the the maximum zone TTL, zone propagation delay, and
publish safety time. The dnssec-policy does not yet look into the zone
for the maximum TTL but derives it from configuration. The default
policy sets the maximum zone TTL to 1 day. Together with  the zone
propagation delay and publish safety delay from the default policy this
is a 25 hour and 5 minute wait before the CDS is published.

Obviously you can change your policy to lower the maximum-zone-ttl to
1200 in your case (and if you don't care about a publish safety period,
you can set it to 0 seconds).

>> Looks like the SOA Serial Number still needs to be maintained manually. 
>> Was expecting a more OpenDNSSEC approach. Would love an automated 
>> YYYYMMDDxx number - date it was last 'modified'. Would be perfect for 
>> small zones that are rarely updated.

> I think the zone option "serial-update-method date;" does this. (I haven't
> tested it with dnssec-policy though.)

Despite the documentation says this is for dynamic DNS zones, this also
works for inline-signing and dnssec-policy zones.

- 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-users/attachments/20200414/eadf61a6/attachment.bin>