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
m...@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
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
