Re: BIND-9.16.1 & KASP
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 ". If it says signing is complete, you're free to remove the records with "rndc signing -clear all ". 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 MMDDxx 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 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
Re: BIND-9.16.1 & KASP
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 ". > If it says signing is complete, you're free to remove the records > with "rndc signing -clear all ". > >> 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 >> MMDDxx 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 signature.asc Description: OpenPGP digital signature ___ 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
Re: BIND-9.16.1 & KASP
> On 14 Apr 2020, at 04:54, 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 ". > If it says signing is complete, you're free to remove the records > with "rndc signing -clear all ”. And the gory details from the ARM. 5.9.4. Private-type records The state of the signing process is signaled by private-type records (with a default type value of 65534). When signing is complete, these records will have a nonzero value for the final octet (for those records which have a nonzero initial octet). The private type record format: If the first octet is non-zero then the record indicates that the zone needs to be signed with the key matching the record, or that all signatures that match the record should be removed. algorithm (octet 1) key id in network order (octet 2 and 3) removal flag (octet 4) complete flag (octet 5) Only records flagged as “complete” can be removed via dynamic update. Attempts to remove other private type records will be silently ignored. If the first octet is zero (this is a reserved algorithm number that should never appear in a DNSKEY record) then the record indicates changes to the NSEC3 chains are in progress. The rest of the record contains an NSEC3PARAM record. The flag field tells what operation to perform based on the flag bits. 0x01 OPTOUT 0x80 CREATE 0x40 REMOVE 0x20 NONSEC -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
Re: BIND-9.16.1 & KASP
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 ". If it says signing is complete, you're free to remove the records with "rndc signing -clear all ". > 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. > Looks like the SOA Serial Number still needs to be maintained manually. > Was expecting a more OpenDNSSEC approach. Would love an automated > MMDDxx 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.) -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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
