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

Fri Feb 9 08:26:45 UTC 2024

Couple of things...

Use the words Primary and Secondary... don't use Master and Slave - as 
it upsets many people.
(I teach DNS/DNSSEC and still say dumb things at times, and I live in 
South Africa)

The Secondary Nameservers should not have any additional DNSSEC 
configurations if the Primary is doing all the DNSSEC signing, and it 
sounds like the Primary is working fine from a DNSSEC point of view. You 
want the Secondaries to simply give the same responses (e.g. the same 
DNSKEY records) when queried - not a bunch of variations depending on 
who is asked.

On the Primary Nameserver - there should now be some CDS records, or at 
least one. This should become the DS record in the Parent zone.

Try and update the BIND software on all your servers to something that 
is supported by the community. There is no time delay required for this, 
just do it. (I've read the other comments regarding this and agree with 
them).

Using Algorithm 13 is a good choice - well done.
You only need to provide the (C)DS SHA-256 version (digest type 2) to 
the parent....

After providing the parent zone with the correct DS record, you then may 
need to tell the Primary nameserver that you have done this.

On 2024/02/08 21:56, Jordan Larson via bind-users 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 
> <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 
> <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
>
>
-- 

Mark James ELKINS  -  Posix Systems - (South) Africa
mje at posix.co.za       Tel: +27.826010496 <tel:+27826010496>
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za 
<https://ftth.posix.co.za>

Posix SystemsVCARD for MJ Elkins

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240209/873a3a01/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: abessive_logo.jpg
Type: image/jpeg
Size: 6410 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240209/873a3a01/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QR-MJElkins.png
Type: image/png
Size: 2163 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240209/873a3a01/attachment-0001.png>