Re: DNSSEC questions
On Thu 28/Oct/2021 09:34:42 +0200 Matthijs Mekking wrote: On 27-10-2021 18:48, Alessandro Vesely wrote: 3. The server produces new .signed and .signed.jnl files every day, which is inconvenient as the zone files directory is checked by tripwire. Is that timing determined by the dnskey-ttl? Would it be okay to set it to one month? The zone is signed if a signature is about to expire. It is not determined by dnskey-ttl. I would exclude these files from tripwire because they need to written out anyway. Then, why does it have to rewrite it every day, if the zone didn't change? dnskey-ttl is the only one-day timing thing, except parent-ds-ttl. It shouldn't. It should only rewrite if there are changes, for example due to zone updates or due to resigning. Nope. It logs these lines: 28-Oct-2021 04:50:23.230 notify: info: zone ext.tana.it/IN/external: sending notifies (serial 2009110701) 28-Oct-2021 04:50:23.318 general: info: zone tana.it/IN/external (signed): receive_secure_serial: unchanged 28-Oct-2021 04:50:23.374 notify: info: zone tana.it/IN/external (signed): sending notifies (serial 2021102409) 28-Oct-2021 04:50:23.390 general: info: zone tana.it/IN/internal (signed): receive_secure_serial: unchanged (Note that the serial for both views is 2021101902. I don't know where th logged numbers come from.) And then Access/Modify/Change dates of .signed and .signed.jnl are 2021-10-28 04:50:47.0 +0200. Furthermore, all the files in the keys directory, .key, .private, .state, are marked 12:50 today, which is a few minutes ago. All, except the ones for a zone still in "auto-dnssec maintain" mode, and has no .state. The log says nothing about this. How can I investigate why? I run BIND 9.16.15-Debian (Stable Release) . BTW, DS RR has a ttl of 10800 at the parent; should I copy that to parent-ds-ttl in my policy definition? Yes. Done. However, I don't think I'll notice if they change it. What for? To make sure the key rollovers are timed correctly. In addition, I took a closer look at your policy. publish-safety P3W; retire-safety P3W; The publish-safety and retire-safety are intended to be small margins added to rollover timings to give some extra time to cover unforeseen events. The defaults are 1 hour. Maybe you have good reasons to set them to 3 weeks, but it is remarkably long. I thought if "unforeseen events" require manual intervention, I might be in a hospital for a liver transplant, say, and need 3 weeks to be dismissed. Best Ale -- ___ 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: DNSSEC questions
On 27-10-2021 18:48, Alessandro Vesely wrote: 3. The server produces new .signed and .signed.jnl files every day, which is inconvenient as the zone files directory is checked by tripwire. Is that timing determined by the dnskey-ttl? Would it be okay to set it to one month? The zone is signed if a signature is about to expire. It is not determined by dnskey-ttl. I would exclude these files from tripwire because they need to written out anyway. Then, why does it have to rewrite it every day, if the zone didn't change? dnskey-ttl is the only one-day timing thing, except parent-ds-ttl. It shouldn't. It should only rewrite if there are changes, for example due to zone updates or due to resigning. BTW, DS RR has a ttl of 10800 at the parent; should I copy that to parent-ds-ttl in my policy definition? Yes. > What for? To make sure the key rollovers are timed correctly. In addition, I took a closer look at your policy. publish-safety P3W; retire-safety P3W; The publish-safety and retire-safety are intended to be small margins added to rollover timings to give some extra time to cover unforeseen events. The defaults are 1 hour. Maybe you have good reasons to set them to 3 weeks, but it is remarkably long. Best regards, Matthijs ___ 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: DNSSEC questions
Hi Matthijs, thanks for clarifications. On Wed 27/Oct/2021 17:53:46 +0200 Matthijs Mekking wrote: On 27-10-2021 12:54, Alessandro Vesely wrote: I also switched to dnssec-policy. Somewhere I read that I should have defined a policy with keys matching the existing keys. I also defined a "combined" key. Now I have two DS, two CDS, and two CDNSKEY RRs. I attach a picture of a zone and paste the policy below. Adding the combined key to the policy means you did not create a policy that matched the existing keys. BIND notices that you want three keys, you only have two, so it creates the CSK. Yup, the intention was (and still is) to migrate to CSK, as it's simpler, without breaking existing status. So now I need to get rid of the old keys. 1. Now, how do I get rid of the extra ksk and zsk? Is it enough to remove them from the policy? You can remove them from the policy yes, but make sure the migration is complete. You can check with "rndc dnssec -status " and make sure that your key states are in "omnipresent". Thanks, that's what I was looking for. I have to check all zones (and two views each). I'll write a script for that. 2. I have double CDS/CDNSKEY records, but they're not in the zone files. Do I have to run rndc dnssec -checkds to remove them? That's because you added the additional CSK to the policy. It is probably best to remove it again from the policy and only change the policy if the migration is complete. Right. So the script must also check that the new keys have a parental DS. 3. The server produces new .signed and .signed.jnl files every day, which is inconvenient as the zone files directory is checked by tripwire. Is that timing determined by the dnskey-ttl? Would it be okay to set it to one month? The zone is signed if a signature is about to expire. It is not determined by dnskey-ttl. I would exclude these files from tripwire because they need to written out anyway. Then, why does it have to rewrite it every day, if the zone didn't change? dnskey-ttl is the only one-day timing thing, except parent-ds-ttl. BTW, DS RR has a ttl of 10800 at the parent; should I copy that to parent-ds-ttl in my policy definition? What for? 4. Is rndc managed-keys status supposed to display anything meaningful, given my setup? It talks about a non-existing key id. The sync option produces no output at all. How do I know the overall dnssec status? "rndc managed-keys status" is for trust anchors, use "rndc dnssec -status " instead. OK. Thanks again, Ale -- ___ 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: DNSSEC questions
Hi Allesandro,
Your policy has three keys:
keys {
ksk key-directory lifetime unlimited algorithm rsasha256 2048;
zsk key-directory lifetime unlimited algorithm rsasha256 2048;
csk key-directory lifetime unlimited algorithm rsasha256 2048;
};
Two of them require DS records (ksk and csk), so that is why you have
double CDS/CDNSKEY records.
On 27-10-2021 12:54, Alessandro Vesely wrote:
Hi all,
I recently installed version 9.16, and have a number of doubts. During
the upgrade, named didn't want to load signed zones because of
CDS/CDNSKEY inconsistency. There were CDS records in the zone files,
which I removed.
I also switched to dnssec-policy. Somewhere I read that I should have
defined a policy with keys matching the existing keys. I also defined a
"combined" key. Now I have two DS, two CDS, and two CDNSKEY RRs. I
attach a picture of a zone and paste the policy below.
Adding the combined key to the policy means you did not create a policy
that matched the existing keys. BIND notices that you want three keys,
you only have two, so it creates the CSK.
The questions:
1. Now, how do I get rid of the extra ksk and zsk? Is it enough to
remove them from the policy?
You can remove them from the policy yes, but make sure the migration is
complete. You can check with "rndc dnssec -status " and make sure
that your key states are in "omnipresent".
2. I have double CDS/CDNSKEY records, but they're not in the zone
files. Do I have to run rndc dnssec -checkds to remove them?
That's because you added the additional CSK to the policy. It is
probably best to remove it again from the policy and only change the
policy if the migration is complete.
3. The server produces new .signed and .signed.jnl files every day,
which is inconvenient as the zone files directory is checked by
tripwire. Is that timing determined by the dnskey-ttl? Would it be
okay to set it to one month?
The zone is signed if a signature is about to expire. It is not
determined by dnskey-ttl. I would exclude these files from tripwire
because they need to written out anyway.
4. Is rndc managed-keys status supposed to display anything meaningful,
given my setup? It talks about a non-existing key id. The sync option
produces no output at all. How do I know the overall dnssec status?
"rndc managed-keys status" is for trust anchors, use "rndc dnssec
-status " instead.
Best regards,
Matthijs
Here's my policy setting:
dnssec-policy "explicit" {
// Keys
keys {
ksk key-directory lifetime unlimited algorithm rsasha256 2048;
zsk key-directory lifetime unlimited algorithm rsasha256 2048;
csk key-directory lifetime unlimited algorithm rsasha256 2048;
};
nsec3param iterations 1 optout false salt-length 16;
// Key timings
dnskey-ttl 86400;
publish-safety P3W;
retire-safety P3W;
purge-keys P1Y;
// Signature timings
signatures-refresh P2M;
signatures-validity P6M;
signatures-validity-dnskey P6M;
// Zone parameters
max-zone-ttl 86400;
zone-propagation-delay PT1H;
// Parent parameters
parent-ds-ttl 86400;
parent-propagation-delay PT1H;
};
___
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
DNSSEC questions
Hi all,
I recently installed version 9.16, and have a number of doubts. During the
upgrade, named didn't want to load signed zones because of CDS/CDNSKEY
inconsistency. There were CDS records in the zone files, which I removed.
I also switched to dnssec-policy. Somewhere I read that I should have defined
a policy with keys matching the existing keys. I also defined a "combined"
key. Now I have two DS, two CDS, and two CDNSKEY RRs. I attach a picture of a
zone and paste the policy below.
The questions:
1. Now, how do I get rid of the extra ksk and zsk? Is it enough to remove them
from the policy?
2. I have double CDS/CDNSKEY records, but they're not in the zone files. Do I
have to run rndc dnssec -checkds to remove them?
3. The server produces new .signed and .signed.jnl files every day, which is
inconvenient as the zone files directory is checked by tripwire. Is that
timing determined by the dnskey-ttl? Would it be okay to set it to one month?
4. Is rndc managed-keys status supposed to display anything meaningful, given
my setup? It talks about a non-existing key id. The sync option produces no
output at all. How do I know the overall dnssec status?
Here's my policy setting:
dnssec-policy "explicit" {
// Keys
keys {
ksk key-directory lifetime unlimited algorithm rsasha256 2048;
zsk key-directory lifetime unlimited algorithm rsasha256 2048;
csk key-directory lifetime unlimited algorithm rsasha256 2048;
};
nsec3param iterations 1 optout false salt-length 16;
// Key timings
dnskey-ttl 86400;
publish-safety P3W;
retire-safety P3W;
purge-keys P1Y;
// Signature timings
signatures-refresh P2M;
signatures-validity P6M;
signatures-validity-dnskey P6M;
// Zone parameters
max-zone-ttl 86400;
zone-propagation-delay PT1H;
// Parent parameters
parent-ds-ttl 86400;
parent-propagation-delay PT1H;
};
___
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: DNSSEC questions
Hi Matthijs, On Mon, Aug 09, 2021 at 11:11:48AM +0200, Matthijs Mekking wrote: > Hi raf, > > On 09-08-2021 10:08, raf via bind-users wrote: > > Hi, > > > > I've got a bunch of DNSSEC questions. > > Any advice would be appreciated. > > > > The context is a little VM with six little zones, > > soon to be upgraded to debian-11 and bind-9.16.15. > > I haven't signed my zones before but now is the time. > > I'm going to rotate KSKs annually because it's > > finally so easy to on debian stable. Thanks for that. > > I know it won't be totally automatic, and that's OK, > > but I'd like to check that I have the right idea of > > what to monitor for and what to do each time. > > > > Q: Is it OK to use exact multiples for ksk/zsk lifetimes (e.g. 366d/61d)? > >I assume it's OK if there aren't too many keys to generate at once. > > Yes. > > > Q: Regarding "parent-propagation-delay" and CDS/CDNSKEY RRs: > > Assuming the registrar doesn't process them, does this equate to > > how long it takes me to notice there's a new DS to upload, > > plus how long it takes me to upload it via the registrar's website, > > plus how long it takes the registrar to publish the uploaded DS? > > Or is it, having instructed the registrar to add/remove a DS, > > how long after I've seen it published/withdrawn in the DNS and have > > run "rndc dnssec -checkds -key ID published/withdrawn ZONE" that > > the parent can be expected to propagate the DS addition/removal > > to all their servers? Or does "rndc dnssec -checkds" make > > "parent-propagation-delay" irrelevant except when the parent > > processes CDS/CDNSKEY RRs? I assume the last. > > No, with the latest version of BIND 9.16 you will have either tell named > that the DS is published with the "rndc dnssec -checkds published" command, > or you will have to configure parental-agents: > > parental-agents lists allow for a common set of parental agents to > be easily used by multiple primary and secondary zones in their > parental-agents lists. A parental agent is the entity that the zone > has a relationship with to change its delegation information > (defined in RFC 7344). > > > BIND will query the parental agents to see if the new DS is actually > published before withdrawing the old DNSSEC key. I won't be able to use parental-agents yet. Debian-11 only has bind-9.16.15 (to start with), and parental-agents was added in 9.16.19. Also, my new registrar doesn't implement RFC 7344 yet, but I suggested it, and they're considering it. In the meantime, I'll just use rndc. > > Q: Are CDS/CDNSKEY RRs always in the zone, or just temporarily > > there for a short time before and after KSK rollovers? > > I don't see them in the wild, so I assume the latter. > > I ask for monitoring purposes. What to monitor for withdrawal? > > I'm thinking I might want to monitor for DNSKEY additions and > > removals instead. More on that below. > > While not necessary, CDS and CDNSKEY RRs are always in the zone as long as > the corresponding DS record is expected to be published. That makes sense. > > Q: When would you want a DS RR for a ZSK (i.e. dnssec-dsfromkey -A)? > > Never, DS is meant to refer to the key that signs the DNSKEY RRset, thus > only applicable for KSK. > > > > Q: Any idea why example.com has two KSK DNSKEY RRs? > > Might they be mid-rollover at the moment? There's only a DS for one of > > them. > > Perhaps it's just an example. > > Most likely a mid-rollover, I will need more details on example.com to know > for sure. It's not important. I'm sure they have their reasons. > > Q: What software could a registrar use to process CDS/CDNSKEY automatically? > > Just curious. > > ... > > > > Q: Do any/many registrars support CDS/CDNSKEY/RFC7344 yet? It seems not. > > No, but I have heard about some registrars looking into it. > > > > > Q: Is a "key-directory" option value that doesn't start with "/" relative > > to the "directory" option (i.e. a subdirectory)? I assume it is. > > The "key-directory" is an optional option that signals that the configured > "key-directory" should be used. Currently it is the only key storage > supported, but in the future it may be possible to have per-key storage. I'll use an absolute path, just to be on the safe side. > > Q: Does the signed zone always have a serial that is the serial in the > > unsigned zone file plus
Re: DNSSEC questions
Hi raf, On 09-08-2021 10:08, raf via bind-users wrote: Hi, I've got a bunch of DNSSEC questions. Any advice would be appreciated. The context is a little VM with six little zones, soon to be upgraded to debian-11 and bind-9.16.15. I haven't signed my zones before but now is the time. I'm going to rotate KSKs annually because it's finally so easy to on debian stable. Thanks for that. I know it won't be totally automatic, and that's OK, but I'd like to check that I have the right idea of what to monitor for and what to do each time. Q: Is it OK to use exact multiples for ksk/zsk lifetimes (e.g. 366d/61d)? > I assume it's OK if there aren't too many keys to generate at once. Yes. Q: Regarding "parent-propagation-delay" and CDS/CDNSKEY RRs: Assuming the registrar doesn't process them, does this equate to how long it takes me to notice there's a new DS to upload, plus how long it takes me to upload it via the registrar's website, plus how long it takes the registrar to publish the uploaded DS? Or is it, having instructed the registrar to add/remove a DS, how long after I've seen it published/withdrawn in the DNS and have run "rndc dnssec -checkds -key ID published/withdrawn ZONE" that the parent can be expected to propagate the DS addition/removal to all their servers? Or does "rndc dnssec -checkds" make "parent-propagation-delay" irrelevant except when the parent processes CDS/CDNSKEY RRs? I assume the last. No, with the latest version of BIND 9.16 you will have either tell named that the DS is published with the "rndc dnssec -checkds published" command, or you will have to configure parental-agents: parental-agents lists allow for a common set of parental agents to be easily used by multiple primary and secondary zones in their parental-agents lists. A parental agent is the entity that the zone has a relationship with to change its delegation information (defined in RFC 7344). BIND will query the parental agents to see if the new DS is actually published before withdrawing the old DNSSEC key. Q: Are CDS/CDNSKEY RRs always in the zone, or just temporarily there for a short time before and after KSK rollovers? I don't see them in the wild, so I assume the latter. I ask for monitoring purposes. What to monitor for withdrawal? I'm thinking I might want to monitor for DNSKEY additions and removals instead. More on that below. While not necessary, CDS and CDNSKEY RRs are always in the zone as long as the corresponding DS record is expected to be published. Q: When would you want a DS RR for a ZSK (i.e. dnssec-dsfromkey -A)? Never, DS is meant to refer to the key that signs the DNSKEY RRset, thus only applicable for KSK. Q: Any idea why example.com has two KSK DNSKEY RRs? Might they be mid-rollover at the moment? There's only a DS for one of them. Perhaps it's just an example. Most likely a mid-rollover, I will need more details on example.com to know for sure. Q: What software could a registrar use to process CDS/CDNSKEY automatically? Just curious. ... Q: Do any/many registrars support CDS/CDNSKEY/RFC7344 yet? It seems not. No, but I have heard about some registrars looking into it. Q: Is a "key-directory" option value that doesn't start with "/" relative to the "directory" option (i.e. a subdirectory)? I assume it is. The "key-directory" is an optional option that signals that the configured "key-directory" should be used. Currently it is the only key storage supported, but in the future it may be possible to have per-key storage. Q: Does the signed zone always have a serial that is the serial in the unsigned zone file plus one? If so, can I continue to use the following scheme for serials: a 10-digit number consisting of the date followed by a 2-digit sequence number, where I increment the serial in the zone file by one whenever I change the zone multiple times on the same day? e.g. serial in 1st zone file = 2021091000 signed and published as 202109101 serial in 2nd zone file = 2021091001 signed and published as 202109102 i.e. Is it OK that the never-published serial in a new unsigned zone file is the same as the previously/currently published serial in the signed zone? Or is it better to increment the serial in the file by 2 instead of 1? The serial used depends on the setting of "serial-update-method". Q: Does the following sound right as a process for managing KSK rollovers? - Monitor for the appearance of new KSK DNSKEY RRs that bind creates (or monitor for the appearance of new CDS RRs) - Manually upload the DS RRs for the new KSKs via the registrar's website - Wait for the new DS RRs to appear in the DNS - Run "rndc dnssec -checkds -key ID publ
DNSSEC questions
Hi, I've got a bunch of DNSSEC questions. Any advice would be appreciated. The context is a little VM with six little zones, soon to be upgraded to debian-11 and bind-9.16.15. I haven't signed my zones before but now is the time. I'm going to rotate KSKs annually because it's finally so easy to on debian stable. Thanks for that. I know it won't be totally automatic, and that's OK, but I'd like to check that I have the right idea of what to monitor for and what to do each time. Q: Is it OK to use exact multiples for ksk/zsk lifetimes (e.g. 366d/61d)? I assume it's OK if there aren't too many keys to generate at once. Q: Regarding "parent-propagation-delay" and CDS/CDNSKEY RRs: Assuming the registrar doesn't process them, does this equate to how long it takes me to notice there's a new DS to upload, plus how long it takes me to upload it via the registrar's website, plus how long it takes the registrar to publish the uploaded DS? Or is it, having instructed the registrar to add/remove a DS, how long after I've seen it published/withdrawn in the DNS and have run "rndc dnssec -checkds -key ID published/withdrawn ZONE" that the parent can be expected to propagate the DS addition/removal to all their servers? Or does "rndc dnssec -checkds" make "parent-propagation-delay" irrelevant except when the parent processes CDS/CDNSKEY RRs? I assume the last. Q: Are CDS/CDNSKEY RRs always in the zone, or just temporarily there for a short time before and after KSK rollovers? I don't see them in the wild, so I assume the latter. I ask for monitoring purposes. What to monitor for withdrawal? I'm thinking I might want to monitor for DNSKEY additions and removals instead. More on that below. Q: When would you want a DS RR for a ZSK (i.e. dnssec-dsfromkey -A)? Q: Any idea why example.com has two KSK DNSKEY RRs? Might they be mid-rollover at the moment? There's only a DS for one of them. Perhaps it's just an example. Q: What software could a registrar use to process CDS/CDNSKEY automatically? Just curious. Q: Do any/many registrars support CDS/CDNSKEY/RFC7344 yet? It seems not. Q: Is a "key-directory" option value that doesn't start with "/" relative to the "directory" option (i.e. a subdirectory)? I assume it is. Q: Does the signed zone always have a serial that is the serial in the unsigned zone file plus one? If so, can I continue to use the following scheme for serials: a 10-digit number consisting of the date followed by a 2-digit sequence number, where I increment the serial in the zone file by one whenever I change the zone multiple times on the same day? e.g. serial in 1st zone file = 2021091000 signed and published as 202109101 serial in 2nd zone file = 2021091001 signed and published as 202109102 i.e. Is it OK that the never-published serial in a new unsigned zone file is the same as the previously/currently published serial in the signed zone? Or is it better to increment the serial in the file by 2 instead of 1? Q: Does the following sound right as a process for managing KSK rollovers? - Monitor for the appearance of new KSK DNSKEY RRs that bind creates (or monitor for the appearance of new CDS RRs) - Manually upload the DS RRs for the new KSKs via the registrar's website - Wait for the new DS RRs to appear in the DNS - Run "rndc dnssec -checkds -key ID published ZONE" to inform bind - Wait for bind to sign the ZSKs with the new KSKs - Wait a few TTLs - Manually delete the DS RRs for the old KSKs via the registrar's website - Wait for the old DS RRs to disappear from the DNS - Run "rndc dnssec -checkds -key ID withdrawn ZONE" to inform bind 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: dnssec questions
On 8/27/2010 11:42 AM, CT wrote: Per my isc class and the book I received by Jeremy C. Reid .. you still need to include your keys in the zone file either via $include dir/KSK $include dir/ZSK1 $include dir/ZSK2 or (cat *.key allkeys) which is what I have done.. $include dir/allkeys I thought the use of -S (smart signing) that this was no longer necessary ..? If you use -S, dnssec-signzone pulls the keys into the zone file based on the timing metadata. You don't need to $INCLUDE the keys any longer. AlanC signature.asc Description: OpenPGP digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
dnssec questions
I just migrated my dns server to bind 9.7.1-P2 KSK dnssec-keygen -r /dev/urandom -a RSASHA256 -b 2048 -f KSK $zone ZSK dnssec-keygen -r /dev/urandom -a RSASHA256 -b 1024 $zone SIGN dnssec-signzone -S -C -g -a -H 10 -3 salt -K dir $zone Per my isc class and the book I received by Jeremy C. Reid .. you still need to include your keys in the zone file either via $include dir/KSK $include dir/ZSK1 $include dir/ZSK2 or (cat *.key allkeys) which is what I have done.. $include dir/allkeys I thought the use of -S (smart signing) that this was no longer necessary ..? Thx Charles ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dnssec questions
On 08/27/2010 11:32 AM, Alan Clegg wrote: On 8/27/2010 11:42 AM, CT wrote: Per my isc class and the book I received by Jeremy C. Reid .. you still need to include your keys in the zone file either via $includedir/KSK $includedir/ZSK1 $includedir/ZSK2 or (cat *.key allkeys) which is what I have done.. $includedir/allkeys I thought the use of -S (smart signing) that this was no longer necessary ..? If you use -S, dnssec-signzone pulls the keys into the zone file based on the timing metadata. You don't need to $INCLUDE the keys any longer. AlanC Alan.. Much thanks for the info.. I had to include the keys for my keyset upload to our registrar.. and it did require the keys either in the file or with an include statement.. so a one time deal then.. Also discovered (was using 9.6.1-16.P3 before) the keyset does not change after re-signing the zone... One less file to keep up with .. V/R Charles ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
