DNSSEC setup for stealth master and multi slave/recursive - Multiple DS keys?
Jordan Larson
jlarson at ocient.com
Thu Feb 8 20:11:56 UTC 2024
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ý <ondrej at isc.org>
Date: Thursday, February 8, 2024 at 2:03 PM
To: Jordan Larson <jlarson at ocient.com>
Cc: bind-users at lists.isc.org <bind-users at 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)
ondrej at 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 at 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 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
> --
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20240208/b97f7597/attachment-0001.htm>
More information about the bind-users
mailing list