DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?

Thu Feb 8 19:56:32 UTC 2024

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 at 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 at 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240208/a0d75180/attachment.htm>