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@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
--
Mark James ELKINS - Posix Systems - (South) Africa
m...@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
--
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
