Re: Quick dynamic DNS?
On 12/23/20 6:53 PM, @lbutlr wrote: Give that I have a authoritative bind9 server for example.com and given that I have a home connection that is (technically) dynamic home.example.com what is the easiest way for me to automatically update the DNS on the rare occasions that it changes? I assume: 1) That example.com is a stand in for the real domain name(s) 2) Your bind9 server is somewhere on the Internet 3) You are asking how to dynamically update it to change where home.example.com resolves to. The example.com domain is setup with DNSSEC and the home connection has a rPI already acting as an unbound/piHole server, if that helps. Are you wanting to do some sort of zone transfer from the rPI to BIND? Is home.example.com public or private? Can the world query it? I used to use a dynamic DNS service, but I figure I have the tools available to do this all myself. What am I doing right now is just manually changing the IP. ACK I'm going to further assume: 4) That you have home.example.com delegated to the rPI at your house. 5) That you want to dynamically update this delegation. You can use BIND's support for Dynamic DNS across the Internet. (I can't speak to the security of such.) I assume that you will be using something like TSIG keys or Kerberos to authenticate your Dynamic DNS updates. (Possibly even a VPN or the likes.) Or you can use nsupdate on the system hosting your public BIND DNS server. Please clarify where the Dynamic DNS client will be in comparison to the BIND DNS server. Then we can get into the minutia of how to go about things. -- Grant. . . . unix || die smime.p7s Description: S/MIME Cryptographic Signature ___ 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
Quick dynamic DNS?
Give that I have a authoritative bind9 server for example.com and given that I have a home connection that is (technically) dynamic home.example.com what is the easiest way for me to automatically update the DNS on the rare occasions that it changes? The example.com domain is setup with DNSSEC and the home connection has a rPI already acting as an unbound/piHole server, if that helps. I used to use a dynamic DNS service, but I figure I have the tools available to do this all myself. What am I doing right now is just manually changing the IP. -- "There will always be women in rubber flirting with me." ___ 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: Forwarded lookup failing on no valid RRSIG
On Sun, Dec 20 2020, Mark Andrews wrote: >> On 21 Dec 2020, at 06:04, Matthew Pounsett wrote: >> >> >> >> On Fri, 18 Dec 2020 at 18:08, Nicolas Bock >> wrote: >> Thanks Mark. Am I correct then that I need to either convince the >> administrator of that DNS to enable DNSSEC or configure my DNS with >> `dnssec-validation = no`? >> >> The upstream administrator isn't required to be validating DNSSEC for this >> to work, but in order for your DNS server to do DNSSEC validation, their DNS >> server must be DNSSEC aware enough to be requesting DNSSEC data when it >> queries the authoritative DNS servers. Of course, the resilience of the >> whole thing would also be improved by that server also validating. > > Matthew, there is a difference between sometimes getting answers out of a > forwarder that isn’t validating that validate and a system that is working. > If the forwarder is not validating then the system cannot recover from > situations that a iterative validating resolver can recover from. Thanks Matthew and Mark for the details. I will have a chat with the upstream administrator and see whether I can convince them to enable full DNSSEC on their end. At least at this point I have a better grasp of what and why I am seeing those messages. Thanks! Nick > It is bad advice to deploy validating clients behind forwarders that are not > validating. > >> If they can't or won't update their server, then yes, you'll either have to >> disable validation yourself, or select a better upstream. Personally I'd go >> looking for a better upstream (or just stop using a forwarder entirely, and >> do your own direct recursion, if that's possible in your environment). ___ 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: How does query denial actually work?
On 17.12.20 14:35, Andrew P. wrote: I was curious about one of the features in BIND. Per the Best Practices, my on-site primary nameserver for my public domains (the secondaries being with a large public DNS provider) is configured to only allow queries from within my LAN and transfers in the LAN and to the designated servers at the DNS provider, and the zones don't actually list the primary in NS records (only in the SOA record). So I'm seeing large numbers of bursts of denied errors like this: client @0x6e702710 73.61.186.10#21509 (.): query (cache) './ANY/IN' denied I'll get maybe 20 in a row in under 2 seconds from one IP address, then a time gap, then a similar burst supposedly from a different IP address. So, my questions are: 1. Are these attacks? yes, and they are very common on the internet. 2. Does BIND actually send a reject message back, or is it silent in such denial cases (as in, not still attacking with smaller packets the victim of a DNS amplication attack)? usually, yes. Those responses are small (I measured 74B now) and you can limit there using responses-per-second or errors-per-second. if you don't provide any servce (domain) to a public, you can filter DNS requests from the internet. I can't figure it out from reading the source code; I haven't so far been able to trace back from where the messages are logged to where (if any) a response packet would be transmitted. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. M$ Win's are shit, do not use it ! ___ 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: ISC DNSSEC Guide - Working with the Parent Zone
Hi Matthijs,
The zone was not signed before. I enabled DNSSEC by adding the
'dnssec-policy'. I will send you the requested files off list.
Thank you,
Daniel
On 23.12.20 11:39, Matthijs Mekking wrote:
> Hi Daniel,
>
> This zone was signed before, prior to switching to 'dnssec-policy'? Or
> did you enable DNSSEC by adding 'dnssec-policy'?
>
> If you have them, would you be able to share with me (off list) the logs
> and the key (state) files?
>
> - Matthijs
>
>
> On 23-12-2020 10:47, Daniel Stirnimann wrote:
>> Hello Matthijs,
>>
>> I'm testing with version 9.16.9.
>>
>> Ok, I'm more confused now.
>>
>> For the current key rollover the DNSKEY RRset is not signed with both
>> the old key 6207 and the new key 15769 but only with the new key 15769.
>> The domain is now bogus:
>>
>> https://dnsviz.net/d/badware.ch/X-MRAg/dnssec/
>>
>>
>> rndc dnssec -status badware.ch
>> dnssec-policy: test
>> current time: Wed Dec 23 10:42:00 2020
>>
>> key: 39414 (ECDSAP256SHA256), CSK
>>published: no
>>key signing:no
>>zone signing: no
>>
>>Key has been removed from the zone
>>- goal: hidden
>>- dnskey: unretentive
>>- ds: unretentive
>>- zone rrsig: unretentive
>>- key rrsig: hidden
>>
>> key: 6207 (ECDSAP256SHA256), CSK
>>published: yes - since Wed Dec 16 07:33:24 2020
>>key signing:no
>>zone signing: no
>>
>>Key is retired, will be removed on Fri Jan 1 11:43:24 2021
>>- goal: hidden
>>- dnskey: omnipresent
>>- ds: unretentive
>>- zone rrsig: unretentive
>>- key rrsig: hidden
>>
>> key: 15769 (ECDSAP256SHA256), CSK
>>published: yes - since Wed Dec 23 07:33:24 2020
>>key signing:yes - since Wed Dec 23 07:33:24 2020
>>zone signing: yes - since Wed Dec 23 09:38:24 2020
>>
>>Next rollover scheduled on Wed Dec 30 07:33:24 2020
>>- goal: omnipresent
>>- dnskey: omnipresent
>>- ds: rumoured
>>- zone rrsig: rumoured
>>- key rrsig: omnipresent
>>
>>
>> Daniel
>>
>> On 23.12.20 10:33, Matthijs Mekking wrote:
>>> Hi Daniel,
>>>
>>> With which specific 9.16 version are you testing? The first versions
>>> used an unsafe time based rollover, assuming the DS would be published
>>> withing a certain time. In 9.16.7 a new rndc command "rndc dnssec
>>> -checkds" was introduced to tell BIND 9 that the DS for a given key has
>>> been published.
>>>
>>> Best regards,
>>>
>>> Matthijs
>>>
>>> On 23-12-2020 09:53, Daniel Stirnimann wrote:
Hi all,
I'm testing the key rollover behavior of BIND 9.16 with the new
introduced "dnssec-policy" statement.
The ISC DNSSEC Guide, chapter Working with the Parent Zone (2) [1] states:
"At the time of this writing (mid-2020) BIND does not check for the
presence of a DS record in the parent zone before completing the KSK or
CSK rollover and withdrawing the old key. Instead, you need to use the
rndc tool to tell named that the DS record has been published."
The last sentence that one has to tell named that the DS record has been
published is not what I'm observing. My tests show that BIND continues
(finishes) the key rollover. The use of the rndc tool is not required.
Is this an error in the documentation?
dnsviz output of the test domain:
badware.ch signed with key 39414 but no trust anchor in .ch yet:
https://dnsviz.net/d/badware.ch/X9DD2w/dnssec/
badware.ch DNSSEC boostrap completed (with trust anchor in .ch,
automatically picked up by CDS/CDNSKEY polling by the parent):
https://dnsviz.net/d/badware.ch/X9ZGPA/dnssec/
badware.ch key rollover from key 39414 to key 6207 in progress:
https://dnsviz.net/d/badware.ch/X9oemQ/dnssec/
badware.ch previous key rollover finished. key 39414 is unused and will
be removed from the DNSKEY rrset soon. No "rndc" command has been used
to tell named to complete the key rollover.
Next key rollover started with the introduction of key 15769:
https://dnsviz.net/d/badware.ch/X-L1BQ/dnssec/
DNSSEC Policy:
dnssec-policy "test" {
keys {
csk key-directory lifetime 7d algorithm 13;
};
// Key timings
dnskey-ttl 3600;
publish-safety 1h;
retire-safety 1h;
// Zone parameters
max-zone-ttl 3600;
zone-propagation-delay 300;
// Parent parameters
parent-ds-ttl 1h;
parent-propagation-delay 1h;
};
Thank you,
Daniel
[1]
https://dnssec-guide.readthedocs.io/en/latest/signing.html#working-with-the-parent-zone-2
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
Re: ISC DNSSEC Guide - Working with the Parent Zone
Hi Daniel,
This zone was signed before, prior to switching to 'dnssec-policy'? Or
did you enable DNSSEC by adding 'dnssec-policy'?
If you have them, would you be able to share with me (off list) the logs
and the key (state) files?
- Matthijs
On 23-12-2020 10:47, Daniel Stirnimann wrote:
Hello Matthijs,
I'm testing with version 9.16.9.
Ok, I'm more confused now.
For the current key rollover the DNSKEY RRset is not signed with both
the old key 6207 and the new key 15769 but only with the new key 15769.
The domain is now bogus:
https://dnsviz.net/d/badware.ch/X-MRAg/dnssec/
rndc dnssec -status badware.ch
dnssec-policy: test
current time: Wed Dec 23 10:42:00 2020
key: 39414 (ECDSAP256SHA256), CSK
published: no
key signing:no
zone signing: no
Key has been removed from the zone
- goal: hidden
- dnskey: unretentive
- ds: unretentive
- zone rrsig: unretentive
- key rrsig: hidden
key: 6207 (ECDSAP256SHA256), CSK
published: yes - since Wed Dec 16 07:33:24 2020
key signing:no
zone signing: no
Key is retired, will be removed on Fri Jan 1 11:43:24 2021
- goal: hidden
- dnskey: omnipresent
- ds: unretentive
- zone rrsig: unretentive
- key rrsig: hidden
key: 15769 (ECDSAP256SHA256), CSK
published: yes - since Wed Dec 23 07:33:24 2020
key signing:yes - since Wed Dec 23 07:33:24 2020
zone signing: yes - since Wed Dec 23 09:38:24 2020
Next rollover scheduled on Wed Dec 30 07:33:24 2020
- goal: omnipresent
- dnskey: omnipresent
- ds: rumoured
- zone rrsig: rumoured
- key rrsig: omnipresent
Daniel
On 23.12.20 10:33, Matthijs Mekking wrote:
Hi Daniel,
With which specific 9.16 version are you testing? The first versions
used an unsafe time based rollover, assuming the DS would be published
withing a certain time. In 9.16.7 a new rndc command "rndc dnssec
-checkds" was introduced to tell BIND 9 that the DS for a given key has
been published.
Best regards,
Matthijs
On 23-12-2020 09:53, Daniel Stirnimann wrote:
Hi all,
I'm testing the key rollover behavior of BIND 9.16 with the new
introduced "dnssec-policy" statement.
The ISC DNSSEC Guide, chapter Working with the Parent Zone (2) [1] states:
"At the time of this writing (mid-2020) BIND does not check for the
presence of a DS record in the parent zone before completing the KSK or
CSK rollover and withdrawing the old key. Instead, you need to use the
rndc tool to tell named that the DS record has been published."
The last sentence that one has to tell named that the DS record has been
published is not what I'm observing. My tests show that BIND continues
(finishes) the key rollover. The use of the rndc tool is not required.
Is this an error in the documentation?
dnsviz output of the test domain:
badware.ch signed with key 39414 but no trust anchor in .ch yet:
https://dnsviz.net/d/badware.ch/X9DD2w/dnssec/
badware.ch DNSSEC boostrap completed (with trust anchor in .ch,
automatically picked up by CDS/CDNSKEY polling by the parent):
https://dnsviz.net/d/badware.ch/X9ZGPA/dnssec/
badware.ch key rollover from key 39414 to key 6207 in progress:
https://dnsviz.net/d/badware.ch/X9oemQ/dnssec/
badware.ch previous key rollover finished. key 39414 is unused and will
be removed from the DNSKEY rrset soon. No "rndc" command has been used
to tell named to complete the key rollover.
Next key rollover started with the introduction of key 15769:
https://dnsviz.net/d/badware.ch/X-L1BQ/dnssec/
DNSSEC Policy:
dnssec-policy "test" {
keys {
csk key-directory lifetime 7d algorithm 13;
};
// Key timings
dnskey-ttl 3600;
publish-safety 1h;
retire-safety 1h;
// Zone parameters
max-zone-ttl 3600;
zone-propagation-delay 300;
// Parent parameters
parent-ds-ttl 1h;
parent-propagation-delay 1h;
};
Thank you,
Daniel
[1]
https://dnssec-guide.readthedocs.io/en/latest/signing.html#working-with-the-parent-zone-2
___
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
___
Please visit
Re: ISC DNSSEC Guide - Working with the Parent Zone
Hello Matthijs,
I'm testing with version 9.16.9.
Ok, I'm more confused now.
For the current key rollover the DNSKEY RRset is not signed with both
the old key 6207 and the new key 15769 but only with the new key 15769.
The domain is now bogus:
https://dnsviz.net/d/badware.ch/X-MRAg/dnssec/
rndc dnssec -status badware.ch
dnssec-policy: test
current time: Wed Dec 23 10:42:00 2020
key: 39414 (ECDSAP256SHA256), CSK
published: no
key signing:no
zone signing: no
Key has been removed from the zone
- goal: hidden
- dnskey: unretentive
- ds: unretentive
- zone rrsig: unretentive
- key rrsig: hidden
key: 6207 (ECDSAP256SHA256), CSK
published: yes - since Wed Dec 16 07:33:24 2020
key signing:no
zone signing: no
Key is retired, will be removed on Fri Jan 1 11:43:24 2021
- goal: hidden
- dnskey: omnipresent
- ds: unretentive
- zone rrsig: unretentive
- key rrsig: hidden
key: 15769 (ECDSAP256SHA256), CSK
published: yes - since Wed Dec 23 07:33:24 2020
key signing:yes - since Wed Dec 23 07:33:24 2020
zone signing: yes - since Wed Dec 23 09:38:24 2020
Next rollover scheduled on Wed Dec 30 07:33:24 2020
- goal: omnipresent
- dnskey: omnipresent
- ds: rumoured
- zone rrsig: rumoured
- key rrsig: omnipresent
Daniel
On 23.12.20 10:33, Matthijs Mekking wrote:
> Hi Daniel,
>
> With which specific 9.16 version are you testing? The first versions
> used an unsafe time based rollover, assuming the DS would be published
> withing a certain time. In 9.16.7 a new rndc command "rndc dnssec
> -checkds" was introduced to tell BIND 9 that the DS for a given key has
> been published.
>
> Best regards,
>
> Matthijs
>
> On 23-12-2020 09:53, Daniel Stirnimann wrote:
>> Hi all,
>>
>> I'm testing the key rollover behavior of BIND 9.16 with the new
>> introduced "dnssec-policy" statement.
>>
>> The ISC DNSSEC Guide, chapter Working with the Parent Zone (2) [1] states:
>>
>> "At the time of this writing (mid-2020) BIND does not check for the
>> presence of a DS record in the parent zone before completing the KSK or
>> CSK rollover and withdrawing the old key. Instead, you need to use the
>> rndc tool to tell named that the DS record has been published."
>>
>> The last sentence that one has to tell named that the DS record has been
>> published is not what I'm observing. My tests show that BIND continues
>> (finishes) the key rollover. The use of the rndc tool is not required.
>> Is this an error in the documentation?
>>
>> dnsviz output of the test domain:
>>
>> badware.ch signed with key 39414 but no trust anchor in .ch yet:
>> https://dnsviz.net/d/badware.ch/X9DD2w/dnssec/
>>
>> badware.ch DNSSEC boostrap completed (with trust anchor in .ch,
>> automatically picked up by CDS/CDNSKEY polling by the parent):
>> https://dnsviz.net/d/badware.ch/X9ZGPA/dnssec/
>>
>> badware.ch key rollover from key 39414 to key 6207 in progress:
>> https://dnsviz.net/d/badware.ch/X9oemQ/dnssec/
>>
>> badware.ch previous key rollover finished. key 39414 is unused and will
>> be removed from the DNSKEY rrset soon. No "rndc" command has been used
>> to tell named to complete the key rollover.
>> Next key rollover started with the introduction of key 15769:
>> https://dnsviz.net/d/badware.ch/X-L1BQ/dnssec/
>>
>>
>> DNSSEC Policy:
>>
>> dnssec-policy "test" {
>> keys {
>> csk key-directory lifetime 7d algorithm 13;
>> };
>>
>> // Key timings
>> dnskey-ttl 3600;
>> publish-safety 1h;
>> retire-safety 1h;
>>
>> // Zone parameters
>> max-zone-ttl 3600;
>> zone-propagation-delay 300;
>>
>> // Parent parameters
>> parent-ds-ttl 1h;
>> parent-propagation-delay 1h;
>> };
>>
>> Thank you,
>> Daniel
>>
>> [1]
>> https://dnssec-guide.readthedocs.io/en/latest/signing.html#working-with-the-parent-zone-2
>>
>> ___
>> 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
>
--
SWITCH
Daniel Stirnimann, SWITCH-CERT
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 15, direct +41 44 268 16 24
daniel.stirnim...@switch.ch,
Re: ISC DNSSEC Guide - Working with the Parent Zone
Hi Daniel,
With which specific 9.16 version are you testing? The first versions
used an unsafe time based rollover, assuming the DS would be published
withing a certain time. In 9.16.7 a new rndc command "rndc dnssec
-checkds" was introduced to tell BIND 9 that the DS for a given key has
been published.
Best regards,
Matthijs
On 23-12-2020 09:53, Daniel Stirnimann wrote:
Hi all,
I'm testing the key rollover behavior of BIND 9.16 with the new
introduced "dnssec-policy" statement.
The ISC DNSSEC Guide, chapter Working with the Parent Zone (2) [1] states:
"At the time of this writing (mid-2020) BIND does not check for the
presence of a DS record in the parent zone before completing the KSK or
CSK rollover and withdrawing the old key. Instead, you need to use the
rndc tool to tell named that the DS record has been published."
The last sentence that one has to tell named that the DS record has been
published is not what I'm observing. My tests show that BIND continues
(finishes) the key rollover. The use of the rndc tool is not required.
Is this an error in the documentation?
dnsviz output of the test domain:
badware.ch signed with key 39414 but no trust anchor in .ch yet:
https://dnsviz.net/d/badware.ch/X9DD2w/dnssec/
badware.ch DNSSEC boostrap completed (with trust anchor in .ch,
automatically picked up by CDS/CDNSKEY polling by the parent):
https://dnsviz.net/d/badware.ch/X9ZGPA/dnssec/
badware.ch key rollover from key 39414 to key 6207 in progress:
https://dnsviz.net/d/badware.ch/X9oemQ/dnssec/
badware.ch previous key rollover finished. key 39414 is unused and will
be removed from the DNSKEY rrset soon. No "rndc" command has been used
to tell named to complete the key rollover.
Next key rollover started with the introduction of key 15769:
https://dnsviz.net/d/badware.ch/X-L1BQ/dnssec/
DNSSEC Policy:
dnssec-policy "test" {
keys {
csk key-directory lifetime 7d algorithm 13;
};
// Key timings
dnskey-ttl 3600;
publish-safety 1h;
retire-safety 1h;
// Zone parameters
max-zone-ttl 3600;
zone-propagation-delay 300;
// Parent parameters
parent-ds-ttl 1h;
parent-propagation-delay 1h;
};
Thank you,
Daniel
[1]
https://dnssec-guide.readthedocs.io/en/latest/signing.html#working-with-the-parent-zone-2
___
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
ISC DNSSEC Guide - Working with the Parent Zone
Hi all,
I'm testing the key rollover behavior of BIND 9.16 with the new
introduced "dnssec-policy" statement.
The ISC DNSSEC Guide, chapter Working with the Parent Zone (2) [1] states:
"At the time of this writing (mid-2020) BIND does not check for the
presence of a DS record in the parent zone before completing the KSK or
CSK rollover and withdrawing the old key. Instead, you need to use the
rndc tool to tell named that the DS record has been published."
The last sentence that one has to tell named that the DS record has been
published is not what I'm observing. My tests show that BIND continues
(finishes) the key rollover. The use of the rndc tool is not required.
Is this an error in the documentation?
dnsviz output of the test domain:
badware.ch signed with key 39414 but no trust anchor in .ch yet:
https://dnsviz.net/d/badware.ch/X9DD2w/dnssec/
badware.ch DNSSEC boostrap completed (with trust anchor in .ch,
automatically picked up by CDS/CDNSKEY polling by the parent):
https://dnsviz.net/d/badware.ch/X9ZGPA/dnssec/
badware.ch key rollover from key 39414 to key 6207 in progress:
https://dnsviz.net/d/badware.ch/X9oemQ/dnssec/
badware.ch previous key rollover finished. key 39414 is unused and will
be removed from the DNSKEY rrset soon. No "rndc" command has been used
to tell named to complete the key rollover.
Next key rollover started with the introduction of key 15769:
https://dnsviz.net/d/badware.ch/X-L1BQ/dnssec/
DNSSEC Policy:
dnssec-policy "test" {
keys {
csk key-directory lifetime 7d algorithm 13;
};
// Key timings
dnskey-ttl 3600;
publish-safety 1h;
retire-safety 1h;
// Zone parameters
max-zone-ttl 3600;
zone-propagation-delay 300;
// Parent parameters
parent-ds-ttl 1h;
parent-propagation-delay 1h;
};
Thank you,
Daniel
[1]
https://dnssec-guide.readthedocs.io/en/latest/signing.html#working-with-the-parent-zone-2
___
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
