<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Couple of things...</p>
<p>Use the words Primary and Secondary... don't use Master and Slave
- as it upsets many people.<br>
(I teach DNS/DNSSEC and still say dumb things at times, and I live
in South Africa)<br>
</p>
<p>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.</p>
<p>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.</p>
<p>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).</p>
<p>Using Algorithm 13 is a good choice - well done.<br>
You only need to provide the (C)DS SHA-256 version (digest type 2)
to the parent....</p>
<p>After providing the parent zone with the correct DS record, you
then may need to tell the Primary nameserver that you have done
this.<br>
</p>
<div class="moz-cite-prefix">On 2024/02/08 21:56, Jordan Larson via
bind-users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:DM8PR19MB5272825916DC7F5A4A1E96F5C8442@DM8PR19MB5272.namprd19.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style>@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-ligatures:standardcontextual;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;}div.WordSection1
{page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Greetings!<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This is for an internally facing DNS, not
exposed to the internet.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">High level setup is as follows:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We have 1 master/primary and 4
slaves/secondaries. These are running Ubuntu 20.04 with OS
installed BIND (9.16.1).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I have the dnssec-policy set to default on
the master AND slaves at the global level via the
named.conf.options.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">While reviewing the following doc <a
href="https://kb.isc.org/v1/docs/dnssec-key-and-signing-policy#ksk-rollover"
moz-do-not-send="true">
https://kb.isc.org/v1/docs/dnssec-key-and-signing-policy#ksk-rollover</a>
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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I saw this very helpful mailing list
thread: <a
href="https://lists.isc.org/pipermail/bind-users/2022-May/106182.html"
moz-do-not-send="true">
https://lists.isc.org/pipermail/bind-users/2022-May/106182.html</a><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">“DSState stuck in rumoured?<o:p></o:p></p>
<p class="MsoNormal">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).”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">On my hidden master:<br>
root@master:~# cat
/var/cache/bind/Kexample.com.+013+64370.state<o:p></o:p></p>
<p class="MsoNormal">; This is the state of key 64370, for
example.com.<o:p></o:p></p>
<p class="MsoNormal">Algorithm: 13<o:p></o:p></p>
<p class="MsoNormal">Length: 256<o:p></o:p></p>
<p class="MsoNormal">Lifetime: 0<o:p></o:p></p>
<p class="MsoNormal">KSK: yes<o:p></o:p></p>
<p class="MsoNormal">ZSK: yes<o:p></o:p></p>
<p class="MsoNormal">Generated: 20231117041456 (Fri Nov 17
04:14:56 2023)<o:p></o:p></p>
<p class="MsoNormal">Published: 20231117041456 (Fri Nov 17
04:14:56 2023)<o:p></o:p></p>
<p class="MsoNormal">Active: 20231117041456 (Fri Nov 17 04:14:56
2023)<o:p></o:p></p>
<p class="MsoNormal">DNSKEYChange: 20231117061956 (Fri Nov 17
06:19:56 2023)<o:p></o:p></p>
<p class="MsoNormal">ZRRSIGChange: 20231118051956 (Sat Nov 18
05:19:56 2023)<o:p></o:p></p>
<p class="MsoNormal">KRRSIGChange: 20231117061956 (Fri Nov 17
06:19:56 2023)<o:p></o:p></p>
<p class="MsoNormal">DSChange: 20231120071956 (Mon Nov 20
07:19:56 2023)<o:p></o:p></p>
<p class="MsoNormal">DNSKEYState: omnipresent<o:p></o:p></p>
<p class="MsoNormal">ZRRSIGState: omnipresent<o:p></o:p></p>
<p class="MsoNormal">KRRSIGState: omnipresent<o:p></o:p></p>
<p class="MsoNormal">DSState: omnipresent<o:p></o:p></p>
<p class="MsoNormal">GoalState: omnipresent<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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:<o:p></o:p></p>
<p class="MsoNormal">root@slave1:~# dig @10.0.0.20 example.com
DNSKEY +multiline<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">; <<>> DiG 9.16.1-Ubuntu
<<>> @10.0.0.20 example.com DNSKEY +multiline<o:p></o:p></p>
<p class="MsoNormal">; (1 server found)<o:p></o:p></p>
<p class="MsoNormal">;; global options: +cmd<o:p></o:p></p>
<p class="MsoNormal">;; Got answer:<o:p></o:p></p>
<p class="MsoNormal">;; ->>HEADER<<- opcode: QUERY,
status: NOERROR, id: 48018<o:p></o:p></p>
<p class="MsoNormal">;; flags: qr aa rd; QUERY: 1, ANSWER: 1,
AUTHORITY: 0, ADDITIONAL: 1<o:p></o:p></p>
<p class="MsoNormal">;; WARNING: recursion requested but not
available<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">;; OPT PSEUDOSECTION:<o:p></o:p></p>
<p class="MsoNormal">; EDNS: version: 0, flags:; udp: 4096<o:p></o:p></p>
<p class="MsoNormal">; COOKIE:
766c81fa38f5d4580100000065c52a97cbca37018dd97375 (good)<o:p></o:p></p>
<p class="MsoNormal">;; QUESTION SECTION:<o:p></o:p></p>
<p class="MsoNormal">;example.com. IN DNSKEY<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">;; ANSWER SECTION:<o:p></o:p></p>
<p class="MsoNormal">example.com. 3600 IN DNSKEY 257 3 13 (<o:p></o:p></p>
<p class="MsoNormal">
rvOPupnLJkkYyrVI9dr7EygIBF3yLLnjR1UIpIj7+Wcy<o:p></o:p></p>
<p class="MsoNormal">
MeoUVuCY0lAEkOlseCm5d0RGlBtOXC6gpV6SZuFwRg==<o:p></o:p></p>
<p class="MsoNormal">
) ; KSK; alg = ECDSAP256SHA256 ; key id = 64370<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">;; Query time: 0 msec<o:p></o:p></p>
<p class="MsoNormal">;; SERVER: 10.0.0.20#53(10.4.2.36)<o:p></o:p></p>
<p class="MsoNormal">;; WHEN: Thu Feb 08 19:25:11 UTC 2024<o:p></o:p></p>
<p class="MsoNormal">;; MSG SIZE rcvd: 152<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Since I enabled inline-signing on my slaves
I also have a key there now:<o:p></o:p></p>
<p class="MsoNormal">root@slave1:~# cat
/var/cache/bind/Kexample.com.+013+12698.state<o:p></o:p></p>
<p class="MsoNormal">; This is the state of key 12698, for
example.com.<o:p></o:p></p>
<p class="MsoNormal">Algorithm: 13<o:p></o:p></p>
<p class="MsoNormal">Length: 256<o:p></o:p></p>
<p class="MsoNormal">Lifetime: 0<o:p></o:p></p>
<p class="MsoNormal">KSK: yes<o:p></o:p></p>
<p class="MsoNormal">ZSK: yes<o:p></o:p></p>
<p class="MsoNormal">Generated: 20240206042516 (Tue Feb 6
04:25:16 2024)<o:p></o:p></p>
<p class="MsoNormal">Published: 20240206042516 (Tue Feb 6
04:25:16 2024)<o:p></o:p></p>
<p class="MsoNormal">Active: 20240206042516 (Tue Feb 6 04:25:16
2024)<o:p></o:p></p>
<p class="MsoNormal">DNSKEYChange: 20240206063016 (Tue Feb 6
06:30:16 2024)<o:p></o:p></p>
<p class="MsoNormal">ZRRSIGChange: 20240207053017 (Wed Feb 7
05:30:17 2024)<o:p></o:p></p>
<p class="MsoNormal">KRRSIGChange: 20240206063016 (Tue Feb 6
06:30:16 2024)<o:p></o:p></p>
<p class="MsoNormal">DSChange: 20240207053017 (Wed Feb 7
05:30:17 2024)<o:p></o:p></p>
<p class="MsoNormal">DNSKEYState: omnipresent<o:p></o:p></p>
<p class="MsoNormal">ZRRSIGState: omnipresent<o:p></o:p></p>
<p class="MsoNormal">KRRSIGState: omnipresent<o:p></o:p></p>
<p class="MsoNormal">DSState: rumoured<o:p></o:p></p>
<p class="MsoNormal">GoalState: omnipresent<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">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?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Trying to sort through some of this before
I start cutting clients over.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thank you!<br>
~Jordan<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
<div class="moz-signature">-- <br>
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<title></title>
<p>Mark James ELKINS - Posix Systems - (South) Africa<br>
<a class="moz-txt-link-abbreviated" href="mailto:mje@posix.co.za">mje@posix.co.za</a> Tel: <a href="tel:+27826010496">+27.826010496</a><br>
For fast, reliable, low cost Internet in ZA: <a
href="https://ftth.posix.co.za">https://ftth.posix.co.za</a><br>
<br>
<img moz-do-not-send="false"
src="cid:part5.E8AD96F9.4453735C@posix.co.za" alt="Posix
Systems" width="250" height="165"><img moz-do-not-send="false"
src="cid:part6.FE9A23A6.16E0ECEE@posix.co.za" alt="VCARD for
MJ Elkins" title="VCARD, Scan me please!" width="164"
height="164"><br>
</p>
</div>
</body>
</html>