> On 25 Jan 2022, at 11:55, ego...@ramattack.net wrote: > > Hi Mark!! > > > > Thank you so much for your answer!! and your time!!. > > > > I have a couple of questions. I ask them between your lines and in blue for > instance... for emphasizing and being easier to see what I'm referring to. > I'm talking about ZSK keys in the questions I am asking in blue. > > > > > El 2022-01-25 00:36, Mark Andrews escribió: > >> >> How 'named' manages DNSSEC is very different to how 'dnssec-signzone' >> manages DNSSEC. When you tell named to >> inactivate a DNSKEY it stops re-signing the zone with it and it stops >> signing new records added to the zone >> with it. >> >> >> The fact is, I don't tell named nothing really. It maintains the zone >> signatures (I'm using inline-signing yes; auto-dnssec maintain; per zone). I >> just provide it keys and then I wait, until the ZSK key's delete time >> arrives, then I remove it's files (.key and .private). I don't wait until >> the inactive time. I wait until the delete time (not the inactive time). >> After the delete time of the key, can still records (rrsigs) exist signed >> with that key then?.
Yes. >> It DOES NOT immediately replace all RRSIGs generated using that key. Those >> records will be replaced >> over the sig-validity-interval as they fall due for re-signing. Once all >> those RRSIG records have been >> replaced and they have expired from caches, you can then delete the DNSKEY >> record. >> >> With the default sig-validity-interval (30) that takes up to 22.5 days to >> which you have to add the record TTL. >> >> Ok, but does sig-validity-interval affect too, after the key deletion date?. >> Or does it affect only from the inactivation date to the deletion date of a >> key?. sig-validity-interval and re-signing is independent of inactive and delete dates. >> Mark >> >> >> Best regards >> >>> On 25 Jan 2022, at 05:21, egoitz--- via bind-users >>> <bind-users@lists.isc.org> wrote: >>> >>> Hi!! >>> >>> >>> >>> Thanks a lot for your answer!! >>> >>> >>> >>> I tried before the fact of renaming back and rndc sign... but does not >>> work.... just has removed the error from the log.... >>> >>> >>> >>> I have changed my key managing code, for not renaming to "-OLD" the ZSK >>> (.key and .private) until have passed at least 2 days from the deletion >>> time... Let's see if this way works better.... >>> >>> >>> >>> >>> Any more ideas mates?. >>> >>> >>> >>> Thank you so much for your time :) >>> >>> >>> >>> Best regards, >>> >>> El 2022-01-24 17:51, Tony Finch escribió: >>> >>>> ATENCION >>>> ATENCION >>>> ATENCION!!! Este correo se ha enviado desde fuera de la organizacion. No >>>> pinche en los enlaces ni abra los adjuntos a no ser que reconozca el >>>> remitente y sepa que el contenido es seguro. >>>> >>>> egoitz--- via bind-users <bind-users@lists.isc.org> wrote: >>>>> >>>>> These are the contents of a cat of the private file I have renamed to >>>>> samename.private-OLD : >>>>> >>>>> Created: 20211031230338 >>>>> Publish: 20211110220241 >>>>> Activate: 20211110220341 >>>>> Inactive: 20211215230338 >>>>> Delete: 20211217230338 >>>> >>>> Yes, it can be confusing when the state of the key files doesn't match the >>>> state of the zone. >>>> >>>> I think you said you have renamed all your key files back to their usual >>>> non-OLD names. Good; that is necessary if named is still looking for a key >>>> file even if it shouldn't need it any more. >>>> >>>> Then, try running `rndc sign <zone>`, to make named reload the keys. I >>>> think that should also get it to make whatever updates might be necessary. >>>> >>>> Then look at the logs to see if there are errors, and look at the DNSKEY >>>> RRset (with its RRSIGs) to make sure it matches what you expect. >>>> >>>> If that doesn't get things straightened out then, um, dunno :-) >>>> >>>> I guess it is possible to get into a muddle if you try to move a key out >>>> of the way very soon after its delete time. By default, named does key >>>> maintenance infrequently, so I guess if you move the key after its >>>> deletion time but before the next key maintenance cycle, things will get >>>> out of sync. But I have not checked whether my guess is right or not. >>>> >>>> Tony. >>> _______________________________________________ >>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to >>> unsubscribe from this list >>> >>> ISC funds the development of this software with paid support subscriptions. >>> Contact us at https://www.isc.org/contact/ for more information. >>> >>> >>> bind-users mailing list >>> bind-users@lists.isc.org >>> https://lists.isc.org/mailman/listinfo/bind-users -- 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 ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
