Re: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
Hi Mark! Very thankful again for your time. Sorry for answering so late, but I was not at the office yesterday. I answer below in blue for instance... El 2022-01-27 02:56, Mark Andrews escribió: > DNSSEC involves lots of timing / co-ordination points and if any of them get > delayed for any reason the > following ones also need to be delayed. While dnssec-keygen will allow you > to set all of the timers for > all of a keys life, it is bad practice to do that. > > But as I have read in Michael Lucas book, it's recommended to refresh at > least ZSK keys from time to time. For that purpose... it's required to set > the needed date and times... isn't it?. > > If you are going to set the timers like this there needs to be much more time > between the inactivation time > and the deletion time. > > I see, so first and required value of sig-validity-interval <= deletion time > - inactivation time then ?. > > As I said earlier about 30 days with default values for > sig-validity-interval. > > This is the reason by which I have deduced the formula written above... > > Thanks again Mark > Cheers > > Mark > > On 25 Jan 2022, at 18:46, ego...@ramattack.net wrote: > > Hi!! > > Don't really know if it could help, but I generate the ZSK keys this way : > > /usr/local/sbin/dnssec-keygen -3 -a 8 -b 1024 -P now -A now -I +45d -D +47d > _ > > Cheers!! > > El 2022-01-25 02:48, Mark Andrews escribió: > > 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 > 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 wrote: > These are the contents of a cat of the private file I have renamed to > samename.private-OLD : > > Created: 20211031230338 > Publish: 2020220241 > Activate: 2020220341 > 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 thei
Re: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
Hi!! Don't really know if it could help, but I generate the ZSK keys this way : /usr/local/sbin/dnssec-keygen -3 -a 8 -b 1024 -P now -A now -I +45d -D +47d _ Cheers!! El 2022-01-25 02:48, Mark Andrews escribió: > 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 > 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 wrote: > These are the contents of a cat of the private file I have renamed to > samename.private-OLD : > > Created: 20211031230338 > Publish: 2020220241 > Activate: 2020220341 > 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 `, 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___ 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
Re: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
Hi Mark!!! Thanks again!!!. Very very thankful really. Please allow me to answer you something more as we found a guru here :) :) But then Mark, what does a key deletion time of a key mean?. I understood that when the deletion time was overtaken in a ZSK, the key dissapeared from the DNSKEY and so... it should not exist RRSIGs with that ZSK (because that RRSIG could not become validated with a valid/in effect ZSK) key because all should have been renewed between the key inactive time and the delete time. I assume I am wrong then. I read the ARM and understood that. What I'm missing or what I have misunderstood if you are so kind as to clarify me?. By the way, when you say "sig-validity-interval and re-signing is independent of inactive and delete dates" I understand but I assume, then I don't have clear the concept of "key delete time", because I thought that sig-validity-interval and the fact of re-signing, was just applied to in effect keys. I would be very thankful if you could help me clarifying the delete time of a key then... I'm going to try to do it by my own, reading the ARM relevant parts again too... As said before, extremely thankful Mark :) Regards, El 2022-01-25 02:48, Mark Andrews escribió: > 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 > 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 wrote: > These are the contents of a cat of the private file I have renamed to > samename.private-OLD : > > Created: 20211031230338 > Publish: 2020220241 > Activate: 2020220341 > 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 `, 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 th
Re: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
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?. > > 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?. > > Mark > > BEST REGARDS > > On 25 Jan 2022, at 05:21, egoitz--- via bind-users > 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 wrote: > These are the contents of a cat of the private file I have renamed to > samename.private-OLD : > > Created: 20211031230338 > Publish: 2020220241 > Activate: 2020220341 > 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 `, 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___ 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
Re: AW: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
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 wrote: > >> These are the contents of a cat of the private file I have renamed to >> samename.private-OLD : >> >> Created: 20211031230338 >> Publish: 2020220241 >> Activate: 2020220341 >> 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 `, 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
Re: AW: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
Hi! In the "Bump in wire" dns machine, have finally ended up by fixing the errors. For that purpose I have done a : In the directory of the zone file : - rename the own zonefile to zonefile-NO - rename the zonefile.jbk to zonefile.jbk-NO - rename the zonefile.jnl to zonefile.jnl-NO - rename the zonefile.signed to zonefile.signed-NO - rename the zonefile.signed.jnl to zonefile.signed.jnl-NO After that : - rndc retransfer thedomain.thetld - rndc sign thedomain.thetld - rndc signing -nsec3param 1 0 10 5F0F0D thedomain.thetld It seems now I have the zone signed (with the same keys) and without errors. I suppose this is not valid for production really, because you could have some records signed with an inactive (but in effect ZSK) and I suppose that ZSK won't be entered in the DNSKEY?. Apart from that, obviously I would needed to manage to increase SOA in order the zone to be updated in our Internet facing nameservers, that it's another thing to do. What could be the proper way of fixing this?. Is this normal?. Why could it happened?. Best regards, El 2022-01-24 16:13, ego...@ramattack.net escribió: > If you return the -OLD files to it's before name (without -OLD) and you make > changes to the zone or perform rndc loadkeys of the zone, error dissapear but > still the DNSKEY become outdated > > Any ideas mates? > > El 2022-01-24 16:12, ego...@ramattack.net escribió: > > I think the problem is that if you do a : > > dig +multi @dnssecserver thedomain.thetld dnskey +dnssec | grep 44526 > > You then see still that key id exists in DNSKEY records (and an RRSIG of that > ZSK, the 44526, but outdated). > > But I don't really understand why because you see the delete date of 44526 is > very old > > Anyway that could explain the error : "dns_dnssec_keylistfromrdataset: error > reading .private: File not found", because it seems Bind source code, > checks the DNSKEY and later tries to load that keys. As the files for keyid > 44526 don't exist, that could (are renamed) that could explain the error. > > But why has this happened??. Sometime ago, it happened to me that in this > machine (it's more than nothing a learning machine), the ZSK got outdated > because the script in charge of renewing the zsk was stopped. So the only > supposed valid key could have been in that moment the KSK (which does not get > expired). Could perhaps, those ZSK become everlasting or similar, although in > the file the date sais it's totally outdated > > I can't understand what's happening there... > > Regards, > > El 2022-01-24 15:04, ego...@ramattack.net escribió: > > In fact... in a domain for whom I have seen these errors, it's arguing about > key id 44526 (it's private file) saying "File not found". But if I perform an > axfr request of the signed zone with pipe grep the key id, no matches > appear... so should not exist rrsigs for that key > > These are the contents of a cat of the private file I have renamed to > samename.private-OLD : > > Created: 20211031230338 > Publish: 20211110220241 > Activate: 2020220341 > Inactive: 20211215230338 > Delete: 20211217230338 > > Not understandable > > Cheers, > > El 2022-01-24 14:58, egoitz--- via bind-users escribió: Hi Klaus, > > Thank you so much for your answer but when Bind deletes a key from a zone, if > I remember correctly, there should not be any rrsig still active, signed > previously by the deleted key. Isn't it?. So I assume in that case, I should > be doing it properly but still see these messages. > > Am I wrong Klaus in some statement?. If a ZSK is deleted (I'm not renewing > KSK at the moment) no RRSIG with that key should exist... > > Cheers! > > El 2022-01-24 13:08, Klaus Darilion escribió: > > IIRC, Bind needs the key as long as there are signatures in the zone > generated by this key. After key deactivation I waited the RRSIG lifetime > before deleting them. > > regards > > Klaus > > VON: bind-users IM AUFTRAG VON egoitz--- > via bind-users > GESENDET: Montag, 24. Jänner 2022 13:00 > AN: bind-users@lists.isc.org > BETREFF: Bind 9, dnssec, and .key .private files physical deletion after the > key id becomes deleted from zone (the key becomes outdated) > > Good morning, > > I have a DNSSEC "bump in wire" server, which uses "inline-signing yes;" and > "auto-dnssec maintain;" for that reason. > > I do the task of ensuring always are valid keys in the zone with an script > that generates them whenever is needed. All fine until here and all working. > > I have seen, that Bind logs in messages log file sometim
Re: AW: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
If you return the -OLD files to it's before name (without -OLD) and you make changes to the zone or perform rndc loadkeys of the zone, error dissapear but still the DNSKEY become outdated Any ideas mates? El 2022-01-24 16:12, ego...@ramattack.net escribió: > I think the problem is that if you do a : > > dig +multi @dnssecserver thedomain.thetld dnskey +dnssec | grep 44526 > > You then see still that key id exists in DNSKEY records (and an RRSIG of that > ZSK, the 44526, but outdated). > > But I don't really understand why because you see the delete date of 44526 is > very old > > Anyway that could explain the error : "dns_dnssec_keylistfromrdataset: error > reading .private: File not found", because it seems Bind source code, > checks the DNSKEY and later tries to load that keys. As the files for keyid > 44526 don't exist, that could (are renamed) that could explain the error. > > But why has this happened??. Sometime ago, it happened to me that in this > machine (it's more than nothing a learning machine), the ZSK got outdated > because the script in charge of renewing the zsk was stopped. So the only > supposed valid key could have been in that moment the KSK (which does not get > expired). Could perhaps, those ZSK become everlasting or similar, although in > the file the date sais it's totally outdated > > I can't understand what's happening there... > > Regards, > > El 2022-01-24 15:04, ego...@ramattack.net escribió: > > In fact... in a domain for whom I have seen these errors, it's arguing about > key id 44526 (it's private file) saying "File not found". But if I perform an > axfr request of the signed zone with pipe grep the key id, no matches > appear... so should not exist rrsigs for that key > > These are the contents of a cat of the private file I have renamed to > samename.private-OLD : > > Created: 20211031230338 > Publish: 2020220241 > Activate: 20211110220341 > Inactive: 20211215230338 > Delete: 20211217230338 > > Not understandable > > Cheers, > > El 2022-01-24 14:58, egoitz--- via bind-users escribió: Hi Klaus, > > Thank you so much for your answer but when Bind deletes a key from a zone, if > I remember correctly, there should not be any rrsig still active, signed > previously by the deleted key. Isn't it?. So I assume in that case, I should > be doing it properly but still see these messages. > > Am I wrong Klaus in some statement?. If a ZSK is deleted (I'm not renewing > KSK at the moment) no RRSIG with that key should exist... > > Cheers! > > El 2022-01-24 13:08, Klaus Darilion escribió: > > IIRC, Bind needs the key as long as there are signatures in the zone > generated by this key. After key deactivation I waited the RRSIG lifetime > before deleting them. > > regards > > Klaus > > VON: bind-users IM AUFTRAG VON egoitz--- > via bind-users > GESENDET: Montag, 24. Jänner 2022 13:00 > AN: bind-users@lists.isc.org > BETREFF: Bind 9, dnssec, and .key .private files physical deletion after the > key id becomes deleted from zone (the key becomes outdated) > > Good morning, > > I have a DNSSEC "bump in wire" server, which uses "inline-signing yes;" and > "auto-dnssec maintain;" for that reason. > > I do the task of ensuring always are valid keys in the zone with an script > that generates them whenever is needed. All fine until here and all working. > > I have seen, that Bind logs in messages log file sometimes the following > error logs : > > _dns_dnssec_keylistfromrdataset: error reading > /xxx/xxx/xxx/xx-domain/named.aaa/aaa.xx.+008+41919.private: file not found_ > > That "file not found" is due to a rename of ".key" and ".private" files to > ".key-OLD" and ".private-OLD". > > I did the rename, because I have seen that the ZSK key 41919 was set to be > deleted (and obviously always renamed after that deletion date) from the > zone, so I renamed the ".key" and ".private" files to ".key-OLD" and > ".private-OLD". > > I do this rename, because this way my key checking script differentiates, any > needed (in effect) key with the "supposedly" (I say supposedly because I > would have said that Bind should not be using nowadays that non finding files > for nothing!) non needed keys, in order to check that each zone, has always > the needed keys for keeping properly signed by Bind (else it would generate > them). > > As I previously commented, I check with a script the existence of all needed > keys for
Re: AW: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
I think the problem is that if you do a : dig +multi @dnssecserver thedomain.thetld dnskey +dnssec | grep 44526 You then see still that key id exists in DNSKEY records (and an RRSIG of that ZSK, the 44526, but outdated). But I don't really understand why because you see the delete date of 44526 is very old Anyway that could explain the error : "dns_dnssec_keylistfromrdataset: error reading .private: File not found", because it seems Bind source code, checks the DNSKEY and later tries to load that keys. As the files for keyid 44526 don't exist, that could (are renamed) that could explain the error. But why has this happened??. Sometime ago, it happened to me that in this machine (it's more than nothing a learning machine), the ZSK got outdated because the script in charge of renewing the zsk was stopped. So the only supposed valid key could have been in that moment the KSK (which does not get expired). Could perhaps, those ZSK become everlasting or similar, although in the file the date sais it's totally outdated I can't understand what's happening there... Regards, El 2022-01-24 15:04, ego...@ramattack.net escribió: > In fact... in a domain for whom I have seen these errors, it's arguing about > key id 44526 (it's private file) saying "File not found". But if I perform an > axfr request of the signed zone with pipe grep the key id, no matches > appear... so should not exist rrsigs for that key > > These are the contents of a cat of the private file I have renamed to > samename.private-OLD : > > Created: 20211031230338 > Publish: 2020220241 > Activate: 2020220341 > Inactive: 20211215230338 > Delete: 20211217230338 > > Not understandable > > Cheers, > > El 2022-01-24 14:58, egoitz--- via bind-users escribió: Hi Klaus, > > Thank you so much for your answer but when Bind deletes a key from a zone, if > I remember correctly, there should not be any rrsig still active, signed > previously by the deleted key. Isn't it?. So I assume in that case, I should > be doing it properly but still see these messages. > > Am I wrong Klaus in some statement?. If a ZSK is deleted (I'm not renewing > KSK at the moment) no RRSIG with that key should exist... > > Cheers! > > El 2022-01-24 13:08, Klaus Darilion escribió: > > IIRC, Bind needs the key as long as there are signatures in the zone > generated by this key. After key deactivation I waited the RRSIG lifetime > before deleting them. > > regards > > Klaus > > VON: bind-users IM AUFTRAG VON egoitz--- > via bind-users > GESENDET: Montag, 24. Jänner 2022 13:00 > AN: bind-users@lists.isc.org > BETREFF: Bind 9, dnssec, and .key .private files physical deletion after the > key id becomes deleted from zone (the key becomes outdated) > > Good morning, > > I have a DNSSEC "bump in wire" server, which uses "inline-signing yes;" and > "auto-dnssec maintain;" for that reason. > > I do the task of ensuring always are valid keys in the zone with an script > that generates them whenever is needed. All fine until here and all working. > > I have seen, that Bind logs in messages log file sometimes the following > error logs : > > _dns_dnssec_keylistfromrdataset: error reading > /xxx/xxx/xxx/xx-domain/named.aaa/aaa.xx.+008+41919.private: file not found_ > > That "file not found" is due to a rename of ".key" and ".private" files to > ".key-OLD" and ".private-OLD". > > I did the rename, because I have seen that the ZSK key 41919 was set to be > deleted (and obviously always renamed after that deletion date) from the > zone, so I renamed the ".key" and ".private" files to ".key-OLD" and > ".private-OLD". > > I do this rename, because this way my key checking script differentiates, any > needed (in effect) key with the "supposedly" (I say supposedly because I > would have said that Bind should not be using nowadays that non finding files > for nothing!) non needed keys, in order to check that each zone, has always > the needed keys for keeping properly signed by Bind (else it would generate > them). > > As I previously commented, I check with a script the existence of all needed > keys for each domain. Obviuosly, it's not the same checking a couple of ZSK > or just one ZSK and a KSK (per domain), than them plus all outdated keys that > each month become outdated. > > So, how many time should I wait in order to rename that files?. Should I > handle them with another dnssec-__ command instead of renaming?. All > seems to be working well but I see these errors and was won
Re: AW: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
In fact... in a domain for whom I have seen these errors, it's arguing about key id 44526 (it's private file) saying "File not found". But if I perform an axfr request of the signed zone with pipe grep the key id, no matches appear... so should not exist rrsigs for that key These are the contents of a cat of the private file I have renamed to samename.private-OLD : Created: 20211031230338 Publish: 2020220241 Activate: 2020220341 Inactive: 20211215230338 Delete: 20211217230338 Not understandable Cheers, El 2022-01-24 14:58, egoitz--- via bind-users escribió: > Hi Klaus, > > Thank you so much for your answer but when Bind deletes a key from a zone, if > I remember correctly, there should not be any rrsig still active, signed > previously by the deleted key. Isn't it?. So I assume in that case, I should > be doing it properly but still see these messages. > > Am I wrong Klaus in some statement?. If a ZSK is deleted (I'm not renewing > KSK at the moment) no RRSIG with that key should exist... > > Cheers! > > El 2022-01-24 13:08, Klaus Darilion escribió: > >> IIRC, Bind needs the key as long as there are signatures in the zone >> generated by this key. After key deactivation I waited the RRSIG lifetime >> before deleting them. >> >> regards >> >> Klaus >> >> VON: bind-users IM AUFTRAG VON egoitz--- >> via bind-users >> GESENDET: Montag, 24. Jänner 2022 13:00 >> AN: bind-users@lists.isc.org >> BETREFF: Bind 9, dnssec, and .key .private files physical deletion after the >> key id becomes deleted from zone (the key becomes outdated) >> >> Good morning, >> >> I have a DNSSEC "bump in wire" server, which uses "inline-signing yes;" and >> "auto-dnssec maintain;" for that reason. >> >> I do the task of ensuring always are valid keys in the zone with an script >> that generates them whenever is needed. All fine until here and all working. >> >> I have seen, that Bind logs in messages log file sometimes the following >> error logs : >> >> _dns_dnssec_keylistfromrdataset: error reading >> /xxx/xxx/xxx/xx-domain/named.aaa/aaa.xx.+008+41919.private: file not found_ >> >> That "file not found" is due to a rename of ".key" and ".private" files to >> ".key-OLD" and ".private-OLD". >> >> I did the rename, because I have seen that the ZSK key 41919 was set to be >> deleted (and obviously always renamed after that deletion date) from the >> zone, so I renamed the ".key" and ".private" files to ".key-OLD" and >> ".private-OLD". >> >> I do this rename, because this way my key checking script differentiates, >> any needed (in effect) key with the "supposedly" (I say supposedly because I >> would have said that Bind should not be using nowadays that non finding >> files for nothing!) non needed keys, in order to check that each zone, has >> always the needed keys for keeping properly signed by Bind (else it would >> generate them). >> >> As I previously commented, I check with a script the existence of all needed >> keys for each domain. Obviuosly, it's not the same checking a couple of ZSK >> or just one ZSK and a KSK (per domain), than them plus all outdated keys >> that each month become outdated. >> >> So, how many time should I wait in order to rename that files?. Should I >> handle them with another dnssec-__ command instead of renaming?. All >> seems to be working well but I see these errors and was wondering if I could >> improve the way of handling outdated keys. >> >> I have been taking a look at the source code of Bind (the tag of version I'm >> using), and I have seen that Bind seems not remove any of that key files >> when they become outdated. Or does it with some param?. I have not been able >> to find it. I have been taking a look too the ARM, but still no luck on >> finding the answers I was trying to. >> >> Any help very appreciated, >> >> Best regards, > > 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. > > ___ > 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://w
Re: AW: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
Hi Klaus, Thank you so much for your answer but when Bind deletes a key from a zone, if I remember correctly, there should not be any rrsig still active, signed previously by the deleted key. Isn't it?. So I assume in that case, I should be doing it properly but still see these messages. Am I wrong Klaus in some statement?. If a ZSK is deleted (I'm not renewing KSK at the moment) no RRSIG with that key should exist... Cheers! El 2022-01-24 13:08, Klaus Darilion escribió: > IIRC, Bind needs the key as long as there are signatures in the zone > generated by this key. After key deactivation I waited the RRSIG lifetime > before deleting them. > > regards > > Klaus > > VON: bind-users IM AUFTRAG VON egoitz--- > via bind-users > GESENDET: Montag, 24. Jänner 2022 13:00 > AN: bind-users@lists.isc.org > BETREFF: Bind 9, dnssec, and .key .private files physical deletion after the > key id becomes deleted from zone (the key becomes outdated) > > Good morning, > > I have a DNSSEC "bump in wire" server, which uses "inline-signing yes;" and > "auto-dnssec maintain;" for that reason. > > I do the task of ensuring always are valid keys in the zone with an script > that generates them whenever is needed. All fine until here and all working. > > I have seen, that Bind logs in messages log file sometimes the following > error logs : > > _dns_dnssec_keylistfromrdataset: error reading > /xxx/xxx/xxx/xx-domain/named.aaa/aaa.xx.+008+41919.private: file not found_ > > That "file not found" is due to a rename of ".key" and ".private" files to > ".key-OLD" and ".private-OLD". > > I did the rename, because I have seen that the ZSK key 41919 was set to be > deleted (and obviously always renamed after that deletion date) from the > zone, so I renamed the ".key" and ".private" files to ".key-OLD" and > ".private-OLD". > > I do this rename, because this way my key checking script differentiates, any > needed (in effect) key with the "supposedly" (I say supposedly because I > would have said that Bind should not be using nowadays that non finding files > for nothing!) non needed keys, in order to check that each zone, has always > the needed keys for keeping properly signed by Bind (else it would generate > them). > > As I previously commented, I check with a script the existence of all needed > keys for each domain. Obviuosly, it's not the same checking a couple of ZSK > or just one ZSK and a KSK (per domain), than them plus all outdated keys that > each month become outdated. > > So, how many time should I wait in order to rename that files?. Should I > handle them with another dnssec-__ command instead of renaming?. All > seems to be working well but I see these errors and was wondering if I could > improve the way of handling outdated keys. > > I have been taking a look at the source code of Bind (the tag of version I'm > using), and I have seen that Bind seems not remove any of that key files when > they become outdated. Or does it with some param?. I have not been able to > find it. I have been taking a look too the ARM, but still no luck on finding > the answers I was trying to. > > Any help very appreciated, > > Best regards,___ 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
Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
Good morning, I have a DNSSEC "bump in wire" server, which uses "inline-signing yes;" and "auto-dnssec maintain;" for that reason. I do the task of ensuring always are valid keys in the zone with an script that generates them whenever is needed. All fine until here and all working. I have seen, that Bind logs in messages log file sometimes the following error logs : _dns_dnssec_keylistfromrdataset: error reading /xxx/xxx/xxx/xx-domain/named.aaa/aaa.xx.+008+41919.private: file not found_ That "file not found" is due to a rename of ".key" and ".private" files to ".key-OLD" and ".private-OLD". I did the rename, because I have seen that the ZSK key 41919 was set to be deleted (and obviously always renamed after that deletion date) from the zone, so I renamed the ".key" and ".private" files to ".key-OLD" and ".private-OLD". I do this rename, because this way my key checking script differentiates, any needed (in effect) key with the "supposedly" (I say supposedly because I would have said that Bind should not be using nowadays that non finding files for nothing!) non needed keys, in order to check that each zone, has always the needed keys for keeping properly signed by Bind (else it would generate them). As I previously commented, I check with a script the existence of all needed keys for each domain. Obviuosly, it's not the same checking a couple of ZSK or just one ZSK and a KSK (per domain), than them plus all outdated keys that each month become outdated. So, how many time should I wait in order to rename that files?. Should I handle them with another dnssec-__ command instead of renaming?. All seems to be working well but I see these errors and was wondering if I could improve the way of handling outdated keys. I have been taking a look at the source code of Bind (the tag of version I'm using), and I have seen that Bind seems not remove any of that key files when they become outdated. Or does it with some param?. I have not been able to find it. I have been taking a look too the ARM, but still no luck on finding the answers I was trying to. Any help very appreciated, Best regards,___ 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
