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

[Björn Persson]

Jordan Larson via bind-users wrote:
> 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?

That sounds very wrong. Your zone shall have one DNSsec key, or set of
keys, that is the same on all slave servers. A client shall see the
same set of DNSKEY records regardless of which DNS server it queries.

If you sign the zone on the master, then you shouldn't sign it again on
the slaves. The slaves shall receive RRSIG records from the master just
like any other records, and serve them to clients. Only the master has
the secret keys.

If the master can't sign for some reason, then you can do "bump in the
wire" signing: A single signing server receives the unsigned zone from
the hidden master over a secure link, signs it, and distributes the
signed zone to multiple slaves. Only the signing server has the secret
keys. That way there's still a single consistent set of DNSKEY records.

If you need to give different answers to different clients, then you
configure separate views, and you must ensure that each client sees the
same view – including the same keys – on all DNS servers it can query.

Björn Persson


pgpE01Zbo9k0D.pgp
Description: OpenPGP digital signatur
-- 
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

Re: acl in also-nofify

[Greg Choules via bind-users]

Hi both.
You can't do it using ACLs. But you can do it using primaries. This is
hinted at in the section about the primaries statement, but not clearly
expanded on.
For example:

# define a primaries list called "also-notifed" (or anything you like).
Define as many lists as you need.
primaries also-notified {a.b.c.d; e.f.g.h;};
...
zone "example.com {
   type primary;
   file "db.example.com";
# apply the primaries list (or lists) to the also-notify statement.
   also-notify {also-notified;};
};

I hope that helps.
Cheers, Greg



On Thu, 8 Feb 2024 at 21:55, Elmar K. Bins  wrote:

> Randy,
>
> ra...@psg.com (Randy Bush) wrote:
>
> > can i use an acl{} or other macro in `also-notify`?  i have a bunch of
> > zones where i want the same `also-notify` list.
>
> Been running into the same issue and tried to find out. My master lists
> and acls
> are identical as yours seem to be. I've been told that internally they are
> very
> different and handled differently, so I had to duplicate my work (yes,
> they're
> copy+paste for me) :-(
>
> Best,
> Elmar.
>
>
> --
> 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
>
-- 
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

Re: acl in also-nofify

[Elmar K. Bins]

Randy,

ra...@psg.com (Randy Bush) wrote:

> can i use an acl{} or other macro in `also-notify`?  i have a bunch of
> zones where i want the same `also-notify` list.

Been running into the same issue and tried to find out. My master lists and acls
are identical as yours seem to be. I've been told that internally they are very
different and handled differently, so I had to duplicate my work (yes, they're
copy+paste for me) :-(

Best,
Elmar.


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

acl in also-nofify

[Randy Bush]

have spent a bit searching but no result.  so ...

can i use an acl{} or other macro in `also-notify`?  i have a bunch of
zones where i want the same `also-notify` list.

thanks

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

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

[Jordan Larson via bind-users]

Thanks for the recommendation. I will step up to the latest 9.16.X and then 
9.18.X and then reassess.

Is there any period I should wait between 9.16 and the 9.18 update?

Thanks!


From: Ondřej Surý 
Date: Thursday, February 8, 2024 at 2:18 PM
To: Jordan Larson 
Cc: bind-users@lists.isc.org 
Subject: Re: DNSSEC setup for stealth master and multi slave/recursive - 
Multiple DS keys?
9.16.1 has bugs that have been fixed in more recent releases. There’s no point 
in trying to even start thinking what could be wrong in something old as this. 
It would be just a waste of time on both sides.

You can do the upgrades in lockstep - first upgrade to latest 9.16 and then to 
latest 9.18 if that helps.

Alternatively, you can bug Ubuntu to provide you with fixed packages ;). This 
whole “we support everything for 10 years” is just a sales pitch, not a 
something that can be fulfilled.

Ondrej
--
Ondřej Surý — ISC (He/Him)

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 21:12, Jordan Larson  wrote:

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ý 
Date: Thursday, February 8, 2024 at 2:03 PM
To: Jordan Larson 
Cc: bind-users@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)
ond...@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 
>  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@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 

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

[Ondřej Surý]

9.16.1 has bugs that have been fixed in more recent releases. There’s no point 
in trying to even start thinking what could be wrong in something old as this. 
It would be just a waste of time on both sides.

You can do the upgrades in lockstep - first upgrade to latest 9.16 and then to 
latest 9.18 if that helps.

Alternatively, you can bug Ubuntu to provide you with fixed packages ;). This 
whole “we support everything for 10 years” is just a sales pitch, not a 
something that can be fulfilled.

Ondrej
--
Ondřej Surý — ISC (He/Him)

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 21:12, Jordan Larson  wrote:
> 
> 
> 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ý 
> Date: Thursday, February 8, 2024 at 2:03 PM
> To: Jordan Larson 
> Cc: bind-users@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)
> ond...@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 
> >  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@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 

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

[Jordan Larson via bind-users]

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ý 
Date: Thursday, February 8, 2024 at 2:03 PM
To: Jordan Larson 
Cc: bind-users@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)
ond...@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 
>  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@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: 766c81fa38f5d458010065c52a97cbca37018dd97375 (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)
> ;; 

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

[Ondřej Surý]

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)
ond...@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 
>  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@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: 766c81fa38f5d458010065c52a97cbca37018dd97375 (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)
> 

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

[Jordan Larson via bind-users]

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@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: 766c81fa38f5d458010065c52a97cbca37018dd97375 (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


-- 
Visit 

Re: Non-improving referral

[Petr Menšík]

Yes, but I doubt you would like it more. You can always create your own 
parent zone copy and make modified delegation only in it. Then if it 
should be DNSSEC signed, you would have to setup trust anchor for your 
TLD. But this way, you can test any changes to zone in your lab, without 
affecting production zone.


But I think this is an increased work and the result might be very 
different. If you want just testing of alternative server deployment, 
DNAT (production) server address to your temporary instance(s). That may 
work better without extra preparation steps. Again, this would make it 
accessible only in your lab, but might allow you testing whatever you 
want. I expect you can access any private keys, which might be used by 
your own zone.


Hope that helps.

Cheers,
Petr

On 2/4/24 12:13, Gabi Nakibly wrote:
Thanks for the response. However,  I strongly prefer not to update the 
parent zone as this is only a temporary nameserver for testing purposes.
Is there anyway to add a new name server (with a new name) without 
updating the parent zone?


On Sun, Feb 4, 2024, 12:01 Mark Andrews  wrote:

You have your answer. Update the parent zone.

-- 
Mark Andrews



On 4 Feb 2024, at 18:27, Gabi Nakibly  wrote:


Hi,
I would like to set up a new temporary nameserver for my zone
(say 'example.com '), however for
various reasons I prefer not to change the delegation of my
parent zone ('.com'). So I need the current name server
('ns.example.com ') to refer resolvers to
my new temporary name server ('ns-temp.example.com
'). However, when I tried to test
this set-up with a BIND resolver, when the resolver got the
delegation to the temporary name server it failed with
'non-improving referral'.
How can I resolve this so the delegation will work for a BIND
resolver having default config (or with any other resolver for
that matter)? I know that I can simply update delegation at the
parent zone to point directly to the new name server, but I
prefer not to do this right now and I am looking for ways to do
this without changing the parent delegation.
-- 
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




--
Petr Menšík
Software Engineer, RHEL
Red Hat,https://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-- 
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