Deprecation notice force BIND 9.20+: dnssec-must-be-secure option
Hello, in line with out deprecation policy, I am notifying the mailing list about our preliminary intent to deprecate the 'dnssec-must-be-secure' option. The option will be marked as deprecated (causing warning from named-checkconf) in BIND 9.18 and 9.20 and it will be removed in BIND 9.21+ when the next development cycle starts next year. The 'dnssec-must-be-secured' description from the ARM: >This specifies hierarchies which must be or may not be secure (signed and >validated). If ``yes``, then :iscman:`named` only accepts answers if >they are secure. If ``no``, then normal DNSSEC validation applies, >allowing insecure answers to be accepted. The specified domain >must be defined as a trust anchor, for instance in a :any:`trust-anchors` >statement, or ``dnssec-validation auto`` must be active. > In BIND 9.21: 1. Using dnssec-must-be-secure option in named.conf will be now a fatal error In BIND 9.18 and BIND 9.20: 1. Using dnssec-must-be-secure option in named.conf will issue a deprecation warning This is tracked under https://gitlab.isc.org/isc-projects/bind9/-/issues/4263 Thanks. -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. -- 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! 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 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
Re: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
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. 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. As I said earlier about 30 days with default values for sig-validity-interval. 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 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
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 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
Re: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
> 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 -- 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
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: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
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. 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. Mark > 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 -- 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
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)
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. -- f.anthony.n.finchhttps://dotat.at/ St Davids Head to Great Orme Head, including St Georges Channel: Variable 2 to 4. Smooth or slight. Fair. Good. ___ 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: 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 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: 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
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
AW: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)
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
Re: debian11 + bind-9.16.15 + dnssec-policy = lost zonefiles + crashes
On 16-08-2021 11:22, raf via bind-users wrote: On Mon, Aug 16, 2021 at 10:32:35AM +0200, Matthijs Mekking wrote: Hi, On 16-08-2021 04:28, raf via bind-users wrote: On Sun, Aug 15, 2021 at 10:35:27PM +1000, raf wrote: ... So it's looking good and I'm happy now. But how long after the zone has been signed can I expect to see CDS/CDNSKEY RRs appear? Why aren't they created at the same time as the DNSKEY RRs? I assume there's a good reason but I can't think what it is. First the RRsets with signatures need to be in the zone long enough that any cached unsigned RRsets in resolver's caches have expired. If you call 'rndc dnssec -status ' you might see that the "zone rrsigs" are still in the "rumoured" state. Once they are omnipresent, the DS may be submitted and that is the time when the corresponding CDS/CDNSKEY records will be published. Thanks! That makes much sense. I was thinking that it would be OK to publish the DS sooner when the zone is signed for the first time. But I get it. I'll trust bind's sense of timing and be patient. :-) It is 99% of the time, but there will be corner cases (and dragons). ___ 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: debian11 + bind-9.16.15 + dnssec-policy = lost zonefiles + crashes
On Mon, Aug 16, 2021 at 10:32:35AM +0200, Matthijs Mekking wrote: > Hi, > > On 16-08-2021 04:28, raf via bind-users wrote: > > On Sun, Aug 15, 2021 at 10:35:27PM +1000, raf wrote: > ... > > > > So it's looking good and I'm happy now. But how long > > after the zone has been signed can I expect to see > > CDS/CDNSKEY RRs appear? Why aren't they created at > > the same time as the DNSKEY RRs? I assume there's > > a good reason but I can't think what it is. > > First the RRsets with signatures need to be in the zone long enough that any > cached unsigned RRsets in resolver's caches have expired. > > If you call 'rndc dnssec -status ' you might see that the "zone > rrsigs" are still in the "rumoured" state. Once they are omnipresent, the DS > may be submitted and that is the time when the corresponding CDS/CDNSKEY > records will be published. Thanks! That makes much sense. I was thinking that it would be OK to publish the DS sooner when the zone is signed for the first time. But I get it. I'll trust bind's sense of timing and be patient. :-) cheers, raf ___ 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: debian11 + bind-9.16.15 + dnssec-policy = lost zonefiles + crashes
Hi,
On 16-08-2021 04:28, raf via bind-users wrote:
On Sun, Aug 15, 2021 at 10:35:27PM +1000, raf wrote:
...
So it's looking good and I'm happy now. But how long
after the zone has been signed can I expect to see
CDS/CDNSKEY RRs appear? Why aren't they created at
the same time as the DNSKEY RRs? I assume there's
a good reason but I can't think what it is.
First the RRsets with signatures need to be in the zone long enough that
any cached unsigned RRsets in resolver's caches have expired.
If you call 'rndc dnssec -status ' you might see that the "zone
rrsigs" are still in the "rumoured" state. Once they are omnipresent,
the DS may be submitted and that is the time when the corresponding
CDS/CDNSKEY records will be published.
Also, please document the dangers of putting a
dnssec-policy usage directive in the options {} stanza
(unless something signficant has changed since version
9.16.15, and bind now knows not to sign zones that
really shouldn't be signed locally - but even if that's
the case, you could document what version that changed in).
That's a good addition. There are a bunch of other suggestions to
improve the documentation that I am planning to make and I'll add this
suggestion to the list. Thanks.
Thanks again for making DNSSEC so easy to implement
(as long as you avoid classic rookie errors). :-)
Thanks for trying it out and reporting back, this way we can improve it
even more.
Best regards,
Matthijs
cheers,
raf
___
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: debian11 + bind-9.16.15 + dnssec-policy = lost zonefiles + crashes
On Sun, Aug 15, 2021 at 10:35:27PM +1000, raf wrote:
> But the real problem is that bind crashed, and dumped
> core, and couldn't start at all. There were a hectic
> few minutes there. :-) I deleted the coredump and the
> key files, and the .jnl files, restored backup
> zonefiles, updated the serials to be greater than that
> of the new DNSSEC signed zones, and then bind was able
> to start again.
>
> Does anyone have any idea why bind-6.19.15 would have
> crashed repeatedly?
I've had a sleep, looked in the logs, and found this:
general: notice: all zones loaded
general: notice: running
general: critical: rbtdb.c:6780: REQUIRE(((rbtnode->nsec ==
DNS_RBT_NSEC_NSEC3 && (rdataset->type ==
((dns_rdatatype_t)dns_rdatatype_nsec3) || rdataset->covers ==
((dns_rdatatype_t)dns_rdatatype_nsec3)))
|| (rbtnode->nsec != DNS_RBT_NSEC_NSEC3 && rdataset->type !=
((dns_rdatatype_t)dns_rdatatype_nsec3) &&
rdataset->covers != ((dns_rdatatype_t)dns_rdatatype_nsec3 failed, back
trace
general: critical: #0 0x558ce49ffeed in ??
general: critical: #1 0x7fd079be6d9a in ??
general: critical: #2 0x7fd079d7f73c in ??
general: critical: #3 0x7fd079e45680 in ??
general: critical: #4 0x7fd079c1b720 in ??
general: critical: #5 0x7fd079c20f52 in ??
general: critical: #6 0x7fd07995cea7 in ??
general: critical: #7 0x7fd079590def in ??
general: critical: exiting (due to assertion failure)
That assertion failed 13 times before I cleaned up.
Perhaps this is an old bug that's been fixed by now.
The only problems logged in the lead up to these
assertion failures were permission errors trying to
create jnl files in /etc/bind for the zones that
shouldn't have been signed anyway, e.g.:
general: error: /etc/bind/db.empty.jnl: create: permission denied
general: error: /etc/bind/db.255.jnl: create: permission denied
AppArmor prevented it, but the directory permissions
would have also prevented it (drwxr-sr-x root bind).
I'm convinced that the dnssec-policy usage directive
doesn't belong in the options {} stanza, and should
only appear in zone {} stanzas.
As for testing that approach on a separate VM, the
behaviour is very different, and completely wonderful.
Instead of overwriting my source zone files and then
crashing, it has created ZONE.jbk, ZONE.signed, and
ZONE.signed.jnl files, all of which are binary. But
last night, I definitely saw the overwritten ZONE files
as a text version of the signed zone. Wierd. Never
mind.
So it's looking good and I'm happy now. But how long
after the zone has been signed can I expect to see
CDS/CDNSKEY RRs appear? Why aren't they created at
the same time as the DNSKEY RRs? I assume there's
a good reason but I can't think what it is.
Also, please document the dangers of putting a
dnssec-policy usage directive in the options {} stanza
(unless something signficant has changed since version
9.16.15, and bind now knows not to sign zones that
really shouldn't be signed locally - but even if that's
the case, you could document what version that changed in).
Thanks again for making DNSSEC so easy to implement
(as long as you avoid classic rookie errors). :-)
cheers,
raf
___
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: debian11 + bind-9.16.15 + dnssec-policy = lost zonefiles + crashes
raf via bind-users wrote:
>
> But that means that it applies to all of the zones in
> /etc/bind/named.conf.default-zones which is not helpful. It also applies
> to the zones in /etc/bind/zones.rfc1918 if that is included in
> /etc/bind/named.conf.local (which a comment there suggested). That's not
> helpful either.
A tangential point, but I think this kind of setup (with lots of empty
zones) isn't necessary, if you are doing DNSSEC validation and you turn on
synth-from-dnssec - much less configuration clutter.
> Can you sign 127.in-addr.arpa and 168.192.in-addr.arpa?
You can: it's harmless but pointless and wasteful.
> I've come to the conclusion that putting dnssec-policy in the options {}
> stanza, so that it applies to all zones, is a terrible idea. It only
> makes sense (to me) to add dnssec-policy to each individual (real)
> authoritative zone {} stanza.
It makes sense to configure dnssec-policy in one place if you have an
authoritative-only primary server, which is configured with just the zones
that it is signing. (The extra zones in the Debian config are only
suitable for a recursive server.)
> What I found more upsetting, was that my carefully crafted, well
> documented zonefiles in /var/cache/bind had been overwritten by bind so
> as to include the DNSSEC records. It might seem obvious to anyone who
> uses DNS updates that that was going to happen, but I wasn't expecting
> it. It would be great if the DNSSEC guide could be updated to mention
> that this happens, and include advice to keep your zonefile sources
> somewhere other than where bind looks for them.
Yes, this is a relatively common gotcha. You can avoid overwritten zone
files by turning on inline-signing mode, so that your source zone files
are separate from the signed zone files maintained by named. If your
configuration uses dynamic updates or DNSSEC then the zone files are
normally owned by named and will be rewritten, and you are right that
there isn't much warning of this in the documentation.
> But the real problem is that bind crashed, and dumped core, and couldn't
> start at all.
There should be something in the logs to indicate why this might have
happened; failing that a stack trace from the core dump would have been
helpful.
> I have a new question about the process of updating zonefiles when
> dnssec-policy is in use. From now on, I'll have my zonefile sources
> somewhere other than /var/cache/bind (e.g. /etc/bind/zone). When I make
> changes, I'll install them to /var/cache/bind and reload bind9. Bind9
> will replace them with the signed versions. Is it OK for me to modify my
> unsigned sources, install them over the top of bind's signed versions,
> and will bind happily recreate all of the DNSSEC records each time?
No, I'm afraid it's more complicated than that.
You can do what you suggest if the server uses inline-signing mode. If
not, your process will go wrong horribly: you need to use `rndc freeze`
and `rndc thaw` if you are manually editing a zone file that is owned by
named, BUT if you do that with a signed zone, you will lose all the
signatures and it will have to be re-signed from scratch. Not good.
Another alternative is to enable `update-policy local`, and use nsdiff and
nsupdate to make the live zone match your source files.
http://dotat.at/prog/nsdiff/
Tony.
--
f.anthony.n.finchhttps://dotat.at/
North Fitzroy, Sole: Westerly or northwesterly 4 to 6 veering
northerly or northwesterly 3 to 5. Rough becoming moderate. Showers
then fair. Good, occasionally moderate.
___
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
debian11 + bind-9.16.15 + dnssec-policy = lost zonefiles + crashes
Hi,
I've just upgraded my bind9 server to debian-11 which
has bind-9.16.15. I've been looking forward to this. I
had my local dnssec-policy ("annual") all ready to go.
But it didn't go well at all.
For the first few seconds, I thought it was great. I
uncommented my new config to enable DNSSEC signing, and
the keys directory was full of new files, but there
were too many. There were key files for all of the
RFC1918 zones. I thought that can't be right.
I had put dnssec-policy "annual" in the options {}
stanza, so that it would apply to all zones. This is
suggested as a possibility in the DNSSEC guide and/or
the configuration reference.
But that means that it applies to all of the zones in
/etc/bind/named.conf.default-zones which is not
helpful. It also applies to the zones in
/etc/bind/zones.rfc1918 if that is included in
/etc/bind/named.conf.local (which a comment there
suggested). That's not helpful either. At least, I
can't see how. Can you sign 127.in-addr.arpa and
168.192.in-addr.arpa? Maybe this is a Debian package
issue. Maybe named.conf.default-zones isn't an
upstream thing. But it's good to be aware of when
writing the documentation.
I've come to the conclusion that putting dnssec-policy
in the options {} stanza, so that it applies to all
zones, is a terrible idea. It only makes sense (to me)
to add dnssec-policy to each individual (real)
authoritative zone {} stanza.
It would be great if the DNSSEC guide and the
configuration reference were updated to include a
warning about this.
But that was just a surprise, maybe wasteful, but
possibly harmless (although possibly not).
What I found more upsetting, was that my carefully
crafted, well documented zonefiles in /var/cache/bind
had been overwritten by bind so as to include the
DNSSEC records. It might seem obvious to anyone who
uses DNS updates that that was going to happen, but I
wasn't expecting it. It would be great if the DNSSEC
guide could be updated to mention that this happens,
and include advice to keep your zonefile sources
somewhere other than where bind looks for them.
I never received any indication when reading the
documentation about DNSSEC that this would happen. I
knew that bind would read in my zonefiles and construct
a signed version of it, but the documentation never
mentioned that that signed version would be written to
disk over my original source zonefiles. At least, I
never got that impression. Thank goodness for backups. :-)
I'll know for next time, and I'll restructure things,
but it would have been nice to be warned in advance
by the documentation.
But the real problem is that bind crashed, and dumped
core, and couldn't start at all. There were a hectic
few minutes there. :-) I deleted the coredump and the
key files, and the .jnl files, restored backup
zonefiles, updated the serials to be greater than that
of the new DNSSEC signed zones, and then bind was able
to start again.
Does anyone have any idea why bind-6.19.15 would have
crashed repeatedly? Here's the subset of the
config that I think could be relevant:
options
{
allow-recursion { localhost; };
dnssec-validation auto;
directory "/var/cache/bind";
key-directory "/var/cache/bind/keys";
dnssec-policy "annual"; # I'm moving this away!
};
dnssec-policy "annual"
{
keys
{
ksk key-directory lifetime 366d algorithm ecdsap256sha256;
zsk key-directory lifetime 61d algorithm ecdsap256sha256;
};
nsec3param iterations 5 optout no salt-length 16;
publish-safety 7d;
retire-safety 7d;
purge-keys 90d;
signatures-validity-dnskey 14d;
signatures-validity 14d;
signatures-refresh 7d;
dnskey-ttl 1d;
max-zone-ttl 1d;
parent-ds-ttl 1d;
zone-propagation-delay 300;
parent-propagation-delay 1d;
};
Might it just be because the RFC1918 zones were signed
and therefore invalid?
I'll try a more gradual approach on a separate test VM
and see how things go. But any advice would be greatly
appreciated. I want to be able to keep using whatever
version of bind9 is on debian stable. So workarounds
that don't involve an upgrade would be appreciated.
Hmm, on a separate VM just adding dnssec-policy "annual"
to one zone {} statement, and reloading, nothing happens.
I should come back to this tomorrow.
I have a new question about the process of updating
zonefiles when dnssec-policy is in use. From now on,
I'll have my zonefile sources somewhere other than
/var/cache/bind (e.g. /etc/bind/zone). When I make
changes, I'll install them to /var/cache/bind and
reload bind9. Bind9 will replace them with the signed
versions. Is it OK for me to modify my unsigned
sources, install them over the top of bind's signed
versions, and will bind happily recreate all of the
DNSSEC records each time? Is that what's expected? That
bind and I keep overwriting each other's zone files?
Th
Re: DHCPD - BIND DDNS: dnssec-keygen hmac-md5 removed
I would suggest: tsig-keygen your-key-name It does not need any options, the defaults are fine. -- Bob Harold On Fri, Apr 10, 2020 at 7:52 PM moo can via bind-users < bind-users@lists.isc.org> wrote: > Hello, > > For educational purpose I need to setup an DDNS between DCHPD and BIND. > > Everywhere, debian, zytrax, freeipa, veritas ... use dnssec-keygen. > > Zytrax: > dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST keyname > > Veritas: > dnssec-keygen -a HMAC-MD5 -b 128 -n HOST example.com. > > Debian: > dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom -n USER DDNS_UPDATE > > HMAC-* support seems to have been removed from dnssec-keygen > https://gitlab.isc.org/fanf/bind9/commit/80788e72d0698f93e92a0e8f1aa60ff982623997 > > It seems we need to use tsig-keygen but it is not clear. > > I try to follow this guide from debian > https://wiki.debian.org/DDNS#How_to_set_up_DDNS as example but there is no -n > USER or -n HOST option with tsig-keygen. > > I do not find any clear example. > > Thanks you in advance for your help. > > Kind Regards > Fabien > > > > > > > > ___ > 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 > ___ 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: DHCPD - BIND DDNS: dnssec-keygen hmac-md5 removed
Use tsig-keygen. -- Mark Andrews > On 11 Apr 2020, at 09:52, moo can via bind-users > wrote: > > > Hello, > > For educational purpose I need to setup an DDNS between DCHPD and BIND. > > Everywhere, debian, zytrax, freeipa, veritas ... use dnssec-keygen. > Zytrax: > dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST keyname > > Veritas: > dnssec-keygen -a HMAC-MD5 -b 128 -n HOST example.com. > > Debian: > dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom -n USER DDNS_UPDATE > > HMAC-* support seems to have been removed from dnssec-keygen > https://gitlab.isc.org/fanf/bind9/commit/80788e72d0698f93e92a0e8f1aa60ff982623997 > > It seems we need to use tsig-keygen but it is not clear. > > I try to follow this guide from debian > https://wiki.debian.org/DDNS#How_to_set_up_DDNS as example but there is no -n > USER or -n HOST option with tsig-keygen. > > I do not find any clear example. > > Thanks you in advance for your help. > > Kind Regards > Fabien > > > > > > > ___ > 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 ___ 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
DHCPD - BIND DDNS: dnssec-keygen hmac-md5 removed
Hello, For educational purpose I need to setup an DDNS between DCHPD and BIND. Everywhere, debian, zytrax, freeipa, veritas ... use dnssec-keygen.Zytrax: dnssec-keygen -a HMAC-SHA512 -b 512 -n HOST keyname Veritas: dnssec-keygen -a HMAC-MD5 -b 128 -n HOST example.com. Debian: dnssec-keygen -a HMAC-MD5 -b 128 -r /dev/urandom -n USER DDNS_UPDATE HMAC-* support seems to have been removed from dnssec-keygen https://gitlab.isc.org/fanf/bind9/commit/80788e72d0698f93e92a0e8f1aa60ff982623997 It seems we need to use tsig-keygen but it is not clear. I try to follow this guide from debian https://wiki.debian.org/DDNS#How_to_set_up_DDNS as example but there is no -n USER or -n HOST option with tsig-keygen. I do not find any clear example. Thanks you in advance for your help. Kind Regards Fabien ___ 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 and DNSSEC
On Nov 1, 2012, at 3:02 AM, Kobus Bensch kben...@fullnet.co.uk wrote: Thank you for this. Had a look and it seems fairly easy. Not sure if that is a flippant remark. As the author of this document, I must say thanks. Deploying DNSSEC is not hard. It's the care and feeding after-the-fact (key rollover) that you must be extremely careful with. A question: is implementing dnssec a good enough reason to abandon split horizon DNS? I'd find any excuse to abandon views/split-horizon. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com ___ 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 and DNSSEC
Hi Is that because split horizon doubles admin or because its bad all together? I have been using split horizon for many years now and found it very useful. Any thoughts from any on the list would be most welcomed. Kobus - Original Message - From: Alan Clegg a...@clegg.com To: Kobus Bensch kben...@fullnet.co.uk Cc: Feng He fen...@nsbeta.info, bind-users@lists.isc.org Sent: Thursday, 1 November, 2012 11:08:10 AM Subject: Re: BIND and DNSSEC On Nov 1, 2012, at 3:02 AM, Kobus Bensch kben...@fullnet.co.uk wrote: Thank you for this. Had a look and it seems fairly easy. Not sure if that is a flippant remark. As the author of this document, I must say thanks. Deploying DNSSEC is not hard. It's the care and feeding after-the-fact (key rollover) that you must be extremely careful with. A question: is implementing dnssec a good enough reason to abandon split horizon DNS? I'd find any excuse to abandon views/split-horizon. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com -- Fullnet Solutions Limited 7 Marlborough Close Maidenhead Berkshire SL6 4LP United Kingdom Telephone: +44 (07703) 503 733 Kobus Bensch: kben...@fullnet.co.uk Information: i...@fullnet.co.uk WWW: http://www.fullnet.co.uk Registered in England Wales. Company Number: 3568937 VAT registration number: UK 714 7309 42 E O.E. All prices exclude VAT Carriage unless otherwise specified. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system administrator by emailing ad...@fullnet.co.uk with the subject eMail Confidentiality Query! . The content of this email does not necessarily reflect the views or opinions of Fullnet Solutions Limited. If you have any queries or complaints please email i...@fullnet.co.uk with the subject eMail Comment/Complaint Query!. This footnote also confirms that this email message has been scanned for the presence of computer viruses. Fullnet Solutions Limited can however not be held responsible for any virus infections on the recipients or any other systems. For more information regarding the solutions Fullnet has to offer please email i...@fullnet.co.uk with the subject Sales Query!. ___ 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 and DNSSEC
On Nov 1, 2012, at 7:14 AM, Kobus Bensch kben...@fullnet.co.uk wrote: Is that because split horizon doubles admin or because its bad all together? I have been using split horizon for many years now and found it very useful. Any thoughts from any on the list would be most welcomed. Crafted for a private reply, but being re-used here: There are places that views/split-horizon fit the model that has been put into place. It does, however, break the one-question, one-answer concept that was foundational for DNS. My recommendation is that for internal addressing, a separate zone be created that serves that address space. You gain a number of things from this, including easier debugging and better data security (no-longer are you concerned about exactly what clients are seeing at www.internal.example.com since you know that the only people able to resolve/route internal.example.com are the ones that should be able to). The problem lies in that over the years, people (usually the higher-ups) have been trained (by us, the in-the-trench guys) that www.example.com can be one thing internally and something else externally, or that their printer really _should_ be named myprinter.example.com and not myprinter.internal.example.com. All the best, AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com ___ 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 and DNSSEC
Feng He fen...@nsbeta.info wrote: Take a look at: http://www.dnssec.lk/docs/DNSSEC_in_6_minutes.pdf I recommend using auto-dnssec maintain so named keeps the zone signed, instead of dnssec-signzone. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ 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 and DNSSEC
Thanks. All makes sense and definitely something to think about in the new network design. Also wanted to say, I did like the doc and will be using that, but as you say, will make particular note about the maintenance side of things. Thanks Kobus - Original Message - From: Alan Clegg a...@clegg.com To: Kobus Bensch kben...@fullnet.co.uk Cc: bind-users@lists.isc.org Sent: Thursday, 1 November, 2012 11:26:31 AM Subject: Re: BIND and DNSSEC On Nov 1, 2012, at 7:14 AM, Kobus Bensch kben...@fullnet.co.uk wrote: Is that because split horizon doubles admin or because its bad all together? I have been using split horizon for many years now and found it very useful. Any thoughts from any on the list would be most welcomed. Crafted for a private reply, but being re-used here: There are places that views/split-horizon fit the model that has been put into place. It does, however, break the one-question, one-answer concept that was foundational for DNS. My recommendation is that for internal addressing, a separate zone be created that serves that address space. You gain a number of things from this, including easier debugging and better data security (no-longer are you concerned about exactly what clients are seeing at www.internal.example.com since you know that the only people able to resolve/route internal.example.com are the ones that should be able to). The problem lies in that over the years, people (usually the higher-ups) have been trained (by us, the in-the-trench guys) that www.example.com can be one thing internally and something else externally, or that their printer really _should_ be named myprinter.example.com and not myprinter.internal.example.com. All the best, AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com -- Fullnet Solutions Limited 7 Marlborough Close Maidenhead Berkshire SL6 4LP United Kingdom Telephone: +44 (07703) 503 733 Kobus Bensch: kben...@fullnet.co.uk Information: i...@fullnet.co.uk WWW: http://www.fullnet.co.uk Registered in England Wales. Company Number: 3568937 VAT registration number: UK 714 7309 42 E O.E. All prices exclude VAT Carriage unless otherwise specified. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system administrator by emailing ad...@fullnet.co.uk with the subject eMail Confidentiality Query! . The content of this email does not necessarily reflect the views or opinions of Fullnet Solutions Limited. If you have any queries or complaints please email i...@fullnet.co.uk with the subject eMail Comment/Complaint Query!. This footnote also confirms that this email message has been scanned for the presence of computer viruses. Fullnet Solutions Limited can however not be held responsible for any virus infections on the recipients or any other systems. For more information regarding the solutions Fullnet has to offer please email i...@fullnet.co.uk with the subject Sales Query!. ___ 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 and DNSSEC
On Nov 1, 2012, at 7:34 AM, Tony Finch d...@dotat.at wrote: I recommend using auto-dnssec maintain so named keeps the zone signed, instead of dnssec-signzone. I do as well, and this will be documented in the next version of this document. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com ___ 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 and DNSSEC
On Nov 1, 2012, at 7:34 AM, Tony Finch d...@dotat.at wrote: I recommend using auto-dnssec maintain so named keeps the zone signed, instead of dnssec-signzone. I do as well, and this will be documented in the next version of this document. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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 and DNSSEC
On Nov 1, 2012, at 7:34 AM, Tony Finch d...@dotat.at wrote: I recommend using auto-dnssec maintain so named keeps the zone signed, instead of dnssec-signzone. I do as well, and this will be documented in the next version of this document. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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 and DNSSEC
On Nov 1 2012, Jan-Piet Mens wrote: I do as well, and this will be documented in the next version of this document. I believe you've mentioned that here before. Several times. Today. ;-) What I tell you three times is true.” The Bellman, pp Lewis Carroll -- Chris Thompson Email: c...@cam.ac.uk ___ 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 and DNSSEC
On 01/11/12 12:26, Alan Clegg wrote: On Nov 1, 2012, at 7:14 AM, Kobus Bensch kben...@fullnet.co.uk wrote: Is that because split horizon doubles admin or because its bad all together? I have been using split horizon for many years now and found it very useful. Any thoughts from any on the list would be most welcomed. Crafted for a private reply, but being re-used here: There are places that views/split-horizon fit the model that has been put into place. It does, however, break the one-question, one-answer concept that was foundational for DNS. My recommendation is that for internal addressing, a separate zone be created that serves that address space. You gain a number of things from this, including easier debugging and better data security (no-longer are you concerned about exactly what clients are seeing at www.internal.example.com since you know that the only people able to resolve/route internal.example.com are the ones that should be able to). I believe that thinking is no longer valid with laptops moving around. I assume you don't have enough public addresses to give everything its own address, I don't, my servers work through a NAT. They are behind NAT partly for lack of IPs and partly because I want to keep their other ports away from accidental exposure to script kiddies, I know more concerted efforts will do more harm. The typical server setup (for own servers) is that one name is used for setting up e.g. the mail server, the ideal situation for everybody is that whether I am in house or visiting you, if I have any internet access, I can read and send mail. Now if there is an internal zone with a different name, how will you set up the mail client? internal name is not accessible from outside and external name is not present in internal name space. - two mail clients? changing setups when moving between networks? My solution is to have the exactly same names internally and externally, any client SW will just ask for the same server but the IP will differ with the network segment. IPv6 will change all that of course. The problem lies in that over the years, people (usually the higher-ups) have been trained (by us, the in-the-trench guys) that www.example.com can be one thing internally and something else externally, or that their printer really _should_ be named myprinter.example.com and not myprinter.internal.example.com. All the best, AlanC -- Best regards Sten Carlsen No improvements come from shouting: MALE BOVINE MANURE!!! ___ 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 and DNSSEC
On Nov 1, 2012, at 7:45 AM, Alan Clegg a...@clegg.com wrote: On Nov 1, 2012, at 7:34 AM, Tony Finch d...@dotat.at wrote: I recommend using auto-dnssec maintain so named keeps the zone signed, instead of dnssec-signzone. I do as well, and this will be documented in the next version of this document. Sorry for the spammage. Bad failure mode of mail.app under OSX, it seems. :( AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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 and DNSSEC
On 11/1/2012 3:31 PM, Sten Carlsen st...@s-carlsen.dk wrote: The typical server setup (for own servers) is that one name is used for setting up e.g. the mail server, the ideal situation for everybody is that whether I am in house or visiting you, if I have any internet access, I can read and send mail. Now if there is an internal zone with a different name, how will you set up the mail client? internal name is not accessible from outside and external name is not present in internal name space. - two mail clients? changing setups when moving between networks? In this case, either 1) you have one mail server at the external border and one mail server internal, or 2) the same MX record in the external and internal view. You can have a common records file that you $INCLUDE in both views. --Barry Finkel ___ 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 and DNSSEC
On 02/11/12 2:08, Barry S. Finkel wrote: On 11/1/2012 3:31 PM, Sten Carlsen st...@s-carlsen.dk wrote: The typical server setup (for own servers) is that one name is used for setting up e.g. the mail server, the ideal situation for everybody is that whether I am in house or visiting you, if I have any internet access, I can read and send mail. Now if there is an internal zone with a different name, how will you set up the mail client? internal name is not accessible from outside and external name is not present in internal name space. - two mail clients? changing setups when moving between networks? In this case, either 1) you have one mail server at the external border and one mail server internal, or 2) the same MX record in the external and internal view. You can have a common records file that you $INCLUDE in both views. --Barry Finkel This will work for smtp service, I see a host of interesting issues with IMAP service. Two mail servers that must be synchronized within a minute, I don't think that is standard. The simple solution (small scale) is to have one server, sitting internally or in DMZ, the internal address record points to the 192.168.x.x address and the external address record points to the public address of the router, which then has a virtual server set up for it. This works flawless, I never consider if I am in or out of the house. -- Best regards Sten Carlsen No improvements come from shouting: MALE BOVINE MANURE!!! ___ 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
BIND and DNSSEC
Hi Can anybody point me in the direction of a good guide on setting up BIND split horizon DNS and DNSSEC? Thanks in advance Kobus -- ___ 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.7, dnssec and multiple key directories and resalt NSEC3
On 04/06/10 11:11, Tim Verhoeven wrote: Hi, I'm currently testing the automatic signing for DNSSEC present in Bind 9.7. I'm currently using Bind 9.7.0 and I have 2 questions. The first one, can I configure multiple key directories? The reasoning for this is that I would like to seperate the KSK's from the ZSK's. And this to be able to not have the KSK's present all the time by putting them on a removable media. For the ZSK's I have no choice since I will be doing dynamic updates. Or are there other means to do this except from adding and removing the KSK's when needed ? Symlinks to the KSK in another directory? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7, dnssec and multiple key directories and resalt NSEC3
On Fri, Jun 4, 2010 at 1:18 PM, Phil Mayers p.may...@imperial.ac.uk wrote: On 04/06/10 11:11, Tim Verhoeven wrote: I'm currently testing the automatic signing for DNSSEC present in Bind 9.7. I'm currently using Bind 9.7.0 and I have 2 questions. The first one, can I configure multiple key directories? The reasoning for this is that I would like to seperate the KSK's from the ZSK's. And this to be able to not have the KSK's present all the time by putting them on a removable media. For the ZSK's I have no choice since I will be doing dynamic updates. Or are there other means to do this except from adding and removing the KSK's when needed ? Symlinks to the KSK in another directory? A good one, why haven't I thought of that myself ;-) Thanks, Tim -- Tim Verhoeven - tim.verhoeven...@gmail.com - 0479 / 88 11 83 Hoping the problem magically goes away by ignoring it is the microsoft approach to programming and should never be allowed. (Linus Torvalds) ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7, dnssec and multiple key directories and resalt NSEC3
On Fri, Jun 4, 2010 at 3:11 AM, Tim Verhoeven tim.verhoeven...@gmail.comwrote: The second question. I've tried doing a resalt using dynamic updates but I can't get it to work. Just adding a new NSEC3PARAM RR crashes Bind and doing a delete and then a add (to replace the present RR) gives me a servfail but I see the updats in the log. What is the correct way to do a resalt when using automatic signing ? This should work: rndc freeze dnssec-signzone ... # using same keys but with new NSEC3 salt rndc reload rndc thaw Although, at least in earlier versions of BIND, if not all RRsets in the zone are resigned with the resign (i.e., within interval specified with -i), then the NSEC3 chain with the new salt is added to any existing NSEC3 chains. There shouldn't be any ill effects from this, but it does increase the size of the zone some. Regards, Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7, dnssec and multiple key directories and resalt NSEC3
The first one, can I configure multiple key directories? The reasoning for this is that I would like to seperate the KSK's from the ZSK's. No, you can't... but that's an interesting idea. Right now it's a single key directory per zone. The second question. I've tried doing a resalt using dynamic updates but I can't get it to work. Just adding a new NSEC3PARAM RR crashes Bind and doing a delete and then a add (to replace the present RR) gives me a servfail but I see the updats in the log. What is the correct way to do a resalt when using automatic signing ? The way it's supposed to work is: you add the new NSEC3PARAM record, then wait for the new NSEC3 chain to be built. The newly inserted record will, at first, have its flags field set to a nonzero value; this indicates that the chain isn't complete yet. When the server is finished building the chain, it updates the newly-added NSEC3PARAM record, and zeroes the flags field. At that point, it's safe to remove the old NSEC3PARAM record, which will cause the server to remove the old NSEC3 chain. If inserting a new NSEC3PARAM RR is crashing named, please file a bug report. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.7, dnssec and multiple key directories and resalt NSEC3
On Fri, Jun 4, 2010 at 9:10 AM, Evan Hunt e...@isc.org wrote: The way it's supposed to work is: you add the new NSEC3PARAM record, then wait for the new NSEC3 chain to be built. The newly inserted record will, at first, have its flags field set to a nonzero value; this indicates that the chain isn't complete yet. When the server is finished building the chain, it updates the newly-added NSEC3PARAM record, and zeroes the flags field. At that point, it's safe to remove the old NSEC3PARAM record, which will cause the server to remove the old NSEC3 chain. This is a much more elegant solution... :) Casey ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
