BIND-9.16.1 & KASP

[Mark Elkins]

Thanks for the reply....

On 2020/04/14 08:42, Matthijs Mekking wrote:
> 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).


Got that. So if one has a rarely changing zone and gives it a (default) 
$TTL of four days - then the defaults in the "dnssec-policy" will be
too short! Something for people to think about. I think the 
dnssec-policy system should probably look into the Zone as the default 
method
of finding the "maximum zone TTL".

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

Thumbs Up!


>
> - Matthijs
>
-- 

Mark James ELKINS  -  Posix Systems - (South) Africa
mje at posix.co.za       Tel: +27.826010496 <tel:+27826010496>
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za

Posix SystemsVCARD for MJ Elkins

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200414/eaca183f/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abessive_logo.jpg
Type: image/jpeg
Size: 6410 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200414/eaca183f/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QR-MJElkins.png
Type: image/png
Size: 2163 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20200414/eaca183f/attachment-0001.png>