This is/was the plan when I move to 22.04. I did a quick test of this (inplace upgrade to 22.04) but the slaves blew up because I didn’t have inline-signing set to yes on the zones. I rolled my snapshots back and figured I should sort this first.
Is this issue easier to sort out on 9.18.x? If so I can do that but I was attempting to sort my issues before I attempt an upgrade. Thanks! Jordan From: Ondřej Surý <ond...@isc.org> Date: Thursday, February 8, 2024 at 2:03 PM To: Jordan Larson <jlar...@ocient.com> Cc: bind-users@lists.isc.org <bind-users@lists.isc.org> Subject: Re: DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys? I would recommend to start with upgrading BIND (9.16.1) to a version: - that's not 4 years old - that's not going to be EOL in just couple of weeks e.g. latest 9.18.x version. ISC provides PPA for BIND 9.18 here: https://launchpad.net/~isc/+archive/ubuntu/bind Ondřej. -- 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. > On 8. 2. 2024, at 20:56, Jordan Larson via bind-users > <bind-users@lists.isc.org> wrote: > > Greetings! > I have what is hopefully a simple question regarding proper setup around > DNS. I feel somewhat comfortable navigating around BIND but possibly am > getting confused around the DNSSEC portion. > This is for an internally facing DNS, not exposed to the internet. > High level setup is as follows: > We have 1 master/primary and 4 slaves/secondaries. These are running Ubuntu > 20.04 with OS installed BIND (9.16.1). > Any DNS updates/changes are made on the stealth master and the zones are > propagated to the slaves and entries are added and removed. Slaves handle all > DNS requests and forward out to google for any externally facing DNS requests. > I have the dnssec-policy set to default on the master AND slaves at the > global level via the named.conf.options. > While reviewing the following doc > https://kb.isc.org/v1/docs/dnssec-key-and-signing-policy#ksk-rollover it > appeared that perhaps I was missing a critical settings for inline-signing > set to yes for all of the zones on the slaves/secondaries. This is a recent > addition as of a few days ago. I now have that set. > While watching the key state and waiting for all them to go to omnipresent I > noticed that DSState has been sitting at rumored for over 48+ hours. > I saw this very helpful mailing list thread: > https://lists.isc.org/pipermail/bind-users/2022-May/106182.html > I was hopeful that after 26 hours (default settings) that this would > eventually roll over to omnipresent. However upon reading further down in the > first link it makes mention of the following: > “DSState stuck in rumoured? > If you see the DSState stuck in rumoured after the migration, you need to run > rndc dnssec -checkds published example.com to tell BIND that the DS is > already published in the parent zone. Be sure and confirm that the DS has > actually been published before performing the command (see KSK rollover for > details about checking the DS state).” > On my hidden master: > root@master:~# cat /var/cache/bind/Kexample.com.+013+64370.state > ; This is the state of key 64370, for example.com. > Algorithm: 13 > Length: 256 > Lifetime: 0 > KSK: yes > ZSK: yes > Generated: 20231117041456 (Fri Nov 17 04:14:56 2023) > Published: 20231117041456 (Fri Nov 17 04:14:56 2023) > Active: 20231117041456 (Fri Nov 17 04:14:56 2023) > DNSKEYChange: 20231117061956 (Fri Nov 17 06:19:56 2023) > ZRRSIGChange: 20231118051956 (Sat Nov 18 05:19:56 2023) > KRRSIGChange: 20231117061956 (Fri Nov 17 06:19:56 2023) > DSChange: 20231120071956 (Mon Nov 20 07:19:56 2023) > DNSKEYState: omnipresent > ZRRSIGState: omnipresent > KRRSIGState: omnipresent > DSState: omnipresent > GoalState: omnipresent > Slaves can query the master (nothing else can and recursion is also off). If > I do a check for the key, I can see it here: > root@slave1:~# dig @10.0.0.20 example.com DNSKEY +multiline > ; <<>> DiG 9.16.1-Ubuntu <<>> @10.0.0.20 example.com DNSKEY +multiline > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48018 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 > ;; WARNING: recursion requested but not available > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ; COOKIE: 766c81fa38f5d4580100000065c52a97cbca37018dd97375 (good) > ;; QUESTION SECTION: > ;example.com. IN DNSKEY > ;; ANSWER SECTION: > example.com. 3600 IN DNSKEY 257 3 13 ( > > rvOPupnLJkkYyrVI9dr7EygIBF3yLLnjR1UIpIj7+Wcy > > MeoUVuCY0lAEkOlseCm5d0RGlBtOXC6gpV6SZuFwRg== > ) ; KSK; alg > = ECDSAP256SHA256 ; key id = 64370 > ;; Query time: 0 msec > ;; SERVER: 10.0.0.20#53(10.4.2.36) > ;; WHEN: Thu Feb 08 19:25:11 UTC 2024 > ;; MSG SIZE rcvd: 152 > Since I enabled inline-signing on my slaves I also have a key there now: > root@slave1:~# cat /var/cache/bind/Kexample.com.+013+12698.state > ; This is the state of key 12698, for example.com. > Algorithm: 13 > Length: 256 > Lifetime: 0 > KSK: yes > ZSK: yes > Generated: 20240206042516 (Tue Feb 6 04:25:16 2024) > Published: 20240206042516 (Tue Feb 6 04:25:16 2024) > Active: 20240206042516 (Tue Feb 6 04:25:16 2024) > DNSKEYChange: 20240206063016 (Tue Feb 6 06:30:16 2024) > ZRRSIGChange: 20240207053017 (Wed Feb 7 05:30:17 2024) > KRRSIGChange: 20240206063016 (Tue Feb 6 06:30:16 2024) > DSChange: 20240207053017 (Wed Feb 7 05:30:17 2024) > DNSKEYState: omnipresent > ZRRSIGState: omnipresent > KRRSIGState: omnipresent > DSState: rumoured > GoalState: omnipresent > I feel like that I might be stuck here and some sort of manual intervention > is required? Am I not patient enough? Also some of the “rndc dnssec” commands > don’t exist in 9.16 which make it harder to follow some of the examples. Was > I wrong to enable “inline-signing yes” for my slave zones? I would assume > each slave would need its own DS key? Can I do that? > Trying to sort through some of this before I start cutting clients over. > Thank you! > ~Jordan > -- > 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
-- 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
