date:20210202

Re: Updating a DNSSEC config to use a different algorithm

2021-02-02 Thread @lbutlr

On 02 Feb 2021, at 07:36, Matthijs Mekking  wrote:
> If the PDF is not working for you, perhaps https://bind9.readthedocs.io/ 
> suits you better?

The PDF works fine, and I can search for "dnssec" and "policy" but it is using 
some emdash or similar character for the - in between which makes searching an 
issue (even if I copy the text from the PDF and then search for what.I copied).

>> (This domain has a RRSIG range of 2021010953 - 20210221230953)
>> I am guessing as soon as I add that DNSSEC-policy I also need to change each 
>> domain record from "auto-dnssec maintain;" to "dnssec-policy default;" or do 
>> I do that after the .state files have been created? (That doesn't sound 
>> right, but best to check).
> 
> I guess with "each domain record" you mean "each zone".

Yes. I still think of them as domains (because they are all domains in my case).

> If you are migrating, don't change it to "dnssec-policy default;". This is a 
> built-in policy that does not match your existing keys.

OK, now I am a bit confused.

In named.conf there is dsnssec-policy alg13-ksk-unlimited-zsk-60day { … 

Then in the zone currently I have:

zone "kreme.com" { type primary; file "kreme.com.signed"; auto-dnssec maintain; 
allow-update { key "rndc-key"; }; }

Are you saying I need to change auto-dnssec maintain; to "dsnssec-policy 13;"?

> I would recommend to first check if the .state files look correct before 
> changing your dnssec-policy (do the keys in your zone match the .state file? 
> Are the states set to OMNIPRESENT? Is the goal set to OMNIPRESENT?

I did this with a domain that does not get email as a test:

#v+
named.conf:
dnssec-policy alg13-ksk-unlimited-zsk-60day {
keys {
   ksk key-directory lifetime unlimited algorithm 7 2048;
   zsk key-directory lifetime P60D algorithm 7 1024 ;
};
};

zone "example.com" { type primary; file "example.com.signed"; dnssec-policy 
default; allow-update { key "rndc-key";}; };

; This is the state of key 2611, for mrsbutler.com.
Algorithm: 13
Length: 256
Lifetime: 0
KSK: yes
ZSK: yes
Generated: 20210202134627 (Tue Feb  2 06:46:27 2021)
Published: 20210202134627 (Tue Feb  2 06:46:27 2021)
Active: 20210202134627 (Tue Feb  2 06:46:27 2021)
PublishCDS: 20210203145127 (Wed Feb  3 07:51:27 2021)
DNSKEYChange: 20210202155127 (Tue Feb  2 08:51:27 2021)
ZRRSIGChange: 20210202134627 (Tue Feb  2 06:46:27 2021)
KRRSIGChange: 20210202155127 (Tue Feb  2 08:51:27 2021)
DSChange: 20210202134627 (Tue Feb  2 06:46:27 2021)
DNSKEYState: omnipresent
ZRRSIGState: rumoured
KRRSIGState: omnipresent
DSState: hidden
GoalState: omnipresent
#v-

I also have new key and private and state files for the alg 7 KSK and ZSK files 
for the zone I am testing with, and the old files are gone, so I think it 
migrated correctly?

But I guess that is what you meant by it using a single key for KSK and ZSK?

Is there a reason NOT to use default? If I use default can I then eliminiate 
the dnssec-policy alg13-ksk-unlimited-zsk-60day { … } block entirely once the 
new keys and state files are created?

I tried to use `rndc dnssec -checkds published example.com" but it wants a -key 
and doesn't seem to want the name of the .key file, so not sure what the syntax 
is there and the man page on rndc isn't helping. Status, on the other hand:

# rndc dnssec -status example
dnssec-policy: default
current time:  Tue Feb  2 10:01:32 2021

key: 1058 (NSEC3RSASHA1), ZSK
  published:  no
  zone signing:   no

  Key has been removed from the zone
  - goal:   hidden
  - dnskey: hidden
  - zone rrsig: unretentive

key: 37515 (NSEC3RSASHA1), KSK
  published:  no
  key signing:no

  Key has been removed from the zone
  - goal:   hidden
  - dnskey: hidden
  - ds: hidden
  - key rrsig:  hidden

key: 2611 (ECDSAP256SHA256), CSK
  published:  yes - since Tue Feb  2 06:46:27 2021
  key signing:yes - since Tue Feb  2 06:46:27 2021
  zone signing:   yes - since Tue Feb  2 06:46:27 2021

  No rollover scheduled
  - goal:   omnipresent
  - dnskey: omnipresent
  - ds: hidden
  - zone rrsig: rumoured
  - key rrsig:  omnipresent

Am I concerned about "No rollover scheduled"? O do noe that the removal of the 
alg 7 from the records is a problem as the registrar still has them listed and 
I do not know what the digest or "Key tag" are to update the record on the 
registrar, so yep, I obviously did something wrong here.

Good thing I am testing.

-- 
"Are you pondering what I'm pondering?"
"I think so, Brain, but why would anyone want a depressed tongue?"

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

Re: Updating a DNSSEC config to use a different algorithm

2021-02-02 Thread Matthijs Mekking

On 02-02-2021 14:40, @lbutlr wrote:

On 02 Feb 2021, at 02:23, Matthijs Mekking wrote:

1. Create a dnssec-policy that matches your current keys (so in your case
algorithm 7, also make sure you use the same length).

So I guess something like:

dnssec-policy alg13-ksk-unlimited-zsk-60day {
keys {
ksk key-directory lifetime unlimited algorithm 7 2048;
zsk key-directory lifetime P60D algorithm 7 1024 ;
};
};

This is an assumption. Check the key length with your existing keys.

Yes, the current keys are alg 7 2048 bit. Is there a document on the various options here? I am
plowing through the "BIND 9 Administrator Reference Manual, Release BIND 9.16.5 (Stable
Release)" but it is slow going right now and "dnssec-policy" does not appear in the
pdf in a searchable form, which makes things even more fun).

No, I could add them to the ARM. But it is the same as dnssec-signzone:

If the PDF is not working for you, perhaps https://bind9.readthedocs.io/
suits you better?

(This domain has a RRSIG range of 2021010953 - 20210221230953)

I am guessing as soon as I add that DNSSEC-policy I also need to change each domain record from
"auto-dnssec maintain;" to "dnssec-policy default;" or do I do that after the
.state files have been created? (That doesn't sound right, but best to check).

I guess with "each domain record" you mean "each zone".

If you are migrating, don't change it to "dnssec-policy default;". This
is a built-in policy that does not match your existing keys.

Instead, change it to "dnssec-policy alg13-ksk-unlimited-zsk-60day;"

Once you have .state files, you should be able to change to a different
policy, including "default". Note that the default policy uses a single
key (as both KSK and ZSK).

Now that you have migrated your existing key files (they will now have a .state
file), you can reconfigure your dnssec-policy with a new algorithm,. The alg-7
keys will be gracefully removed from the zone, while new keys with a new
algorithm will be introduced.

So once all the domains have a .state file associated with them in the key
directory I can change the dnssec-policy to the sample I had before and it will
just migrate from the alg 7 keys above to alg ECDSAP256SHA256 (or I can just
say alg 13 instead).

#v+
dnssec-policy alg13-ksk-unlimited-zsk-60day {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime P60D algorithm 13;
};
};

Yes, once all keys for the zones in question have a .state file
associated with them, you should be able to change the dnssec-policy and
start using ECDSA (you can use the string ECDSAP256SHA256 or the number 13).

I would recommend to first check if the .state files look correct before
changing your dnssec-policy (do the keys in your zone match the .state
file? Are the states set to OMNIPRESENT? Is the goal set to OMNIPRESENT?

- Matthijs

#v-

That seems very straightforward, there must be a catch somewhere.

___
Please 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: Updating a DNSSEC config to use a different algorithm

2021-02-02 Thread @lbutlr

On 02 Feb 2021, at 02:23, Matthijs Mekking  wrote:
> 1. Create a dnssec-policy that matches your current keys (so in your case 
> algorithm 7, also make sure you use the same length).
> 
> So I guess something like:
> 
>dnssec-policy alg13-ksk-unlimited-zsk-60day {
>keys {
>ksk key-directory lifetime unlimited algorithm 7 2048;
>zsk key-directory lifetime P60D algorithm 7 1024 ;
>};
>};
> 
> This is an assumption. Check the key length with your existing keys.

Yes, the current keys are alg 7 2048 bit. Is there a document on the various 
options here? I am plowing through the "BIND 9 Administrator Reference Manual, 
Release BIND 9.16.5 (Stable Release)" but it is slow going right now and 
"dnssec-policy" does not appear in the pdf in a searchable form, which makes 
things even more fun).

(This domain has a RRSIG range of 2021010953 - 20210221230953) 

I am guessing as soon as I add that DNSSEC-policy I also need to change each 
domain record from "auto-dnssec maintain;" to "dnssec-policy default;" or do I 
do that after the .state files have been created? (That doesn't sound right, 
but best to check).

> Now that you have migrated your existing key files (they will now have a 
> .state file), you can reconfigure your dnssec-policy with a new algorithm,. 
> The alg-7 keys will be gracefully removed from the zone, while new keys with 
> a new algorithm will be introduced.

So once all the domains have a .state file associated with them in the key 
directory I can change the dnssec-policy to the sample I had before and it will 
just migrate from the alg 7 keys above to alg ECDSAP256SHA256 (or I can just 
say alg 13 instead).

#v+
dnssec-policy alg13-ksk-unlimited-zsk-60day {
keys {
ksk key-directory lifetime unlimited algorithm 13;
zsk key-directory lifetime P60D algorithm 13;
};
};
#v-

That seems very straightforward, there must be a catch somewhere.

-- 
I want a refund, I want a light, I want a reason for all this night
after night after night after night

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

bind9 DNS not responding to queries on LAN

2021-02-02 Thread JochenWolf

Hi,

I am new to Bind 9, and am trying to figure out how to set it up correctly,
however I cannot get the Bind 9 to respond to queries from other machines. I
have written up the problem in detail here:
https://stackoverflow.com/questions/66007365/bind9-dns-not-responding-to-queries-on-lan
Any suggestions about possible sources of this issue or avenues to debug it
gratefully received!

Best regards,
Jochen



--
Sent from: http://bind-users-forum.2342410.n4.nabble.com/
___
Please 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: Updating a DNSSEC config to use a different algorithm

2021-02-02 Thread Matthijs Mekking




On 01-02-2021 17:34, @lbutlr wrote:

On 01 Feb 2021, at 07:14, Matthijs Mekking  wrote:

Depends on what your DNSSEC configuration is. Are you using
dnssec-signzone/named? auto-dnssec maintain? inline-signing?
dnssec-policy? dnssec-keymgr?


These are all good questions, and when I set this up I could have
answered with some degree of confidence.

What I have in named.conf is simply dnssec-validation auto; and
domains have auto-dnssec maintain, so I guess that answers that
question.


Yes there are a lot of ways to maintain DNSSEC in BIND. The
recommended way forward is to use dnssec-policy. Migrating to it
may still be a bit tricky*, but once you use it, changing a new
signing algorithm is pretty simple:

1. Update your dnssec-policy, reload config.


Assuming there is no dnssec-policy (there is not) what would I update
it to?

This did give me enough to DDG on, does this link look reasonable?



 #v+ dnssec-policy alg13-ksk-unlimited-zsk-60day { keys { ksk
key-directory lifetime unlimited algorithm ECDSAP256SHA256; zsk
key-directory lifetime P60D algorithm ECDSAP256SHA256; }; }; #v-


If you switch to dnssec-policy, before you change your algorithm you 
have to migrate the old keys.


You can use two methods:

1. Create a dnssec-policy that matches your current keys (so in your 
case algorithm 7, also make sure you use the same length).


So I guess something like:

dnssec-policy alg13-ksk-unlimited-zsk-60day {
keys {
ksk key-directory lifetime unlimited algorithm 7 2048;
zsk key-directory lifetime P60D algorithm 7 1024 ;
};
};

This is an assumption. Check the key length with your existing keys.

2. You can also initialize the key states manually with dnssec-settime:

Key state options:
-s: update key state file (default no)
-g state: set the goal state for this key
-d state date/[+-]offset: set the DS state
-k state date/[+-]offset: set the DNSKEY state
-r state date/[+-]offset: set the RRSIG (KSK) state
-z state date/[+-]offset: set the RRSIG (ZSK) state

dnssec-settime -s -g OMNIPRESENT now -d OMNIPRESENT now \
-k OMNIPRESENT now -r OMNIPRESENT now 
dnssec-settime -s -g OMNIPRESENT now -k OMNIPRESENT now \
-z OMNIPRESENT now 

It is a bit technical, but this would make your existing key files ready 
to for dnssec-policy. Use this if your zone is correctly signed at the 
moment, and the DS is in the parent for some time.


Algorithm rollover:

Now that you have migrated your existing key files (they will now have a 
.state file), you can reconfigure your dnssec-policy with a new 
algorithm,. The alg-7 keys will be gracefully removed from the zone, 
while new keys with a new algorithm will be introduced.



If so, what are the possible values for the algorithm? And for the
actual policy (alg13-…)? I also see mention of a dissed-policy
default but that is out of context so I don't know if that is simply
telling the domain to use the policy defined separately in the the
named.conf as above. Alg13-ksk gives two hits on DDG, and the second
one is in Japanese.


Algorithm 13 (ECDSAP256SHA256) is a good choice. It is becoming best 
practice, it is as popular as algorithm 8 (RSASHA256)*, and the majority 
of resolvers can validate with this algorithm**


* https://stats.dnssec-tools.org/
** https://blog.apnic.net/2018/08/23/measuring-ecdsa-in-dnssec-an-update/



2. Wait a little bit. 3. When the new DS is in the parent, run
"rndc dnssec -checkds published on the right key id." 4. Also run
"rndc dnssec -checkds withdrawn" on the id of the key that has its
DS removed from the parent. 5. Have a celebratory drink.


Way ahead of you there! 弄


*In principal you can just switch to dnssec-policy with your
existing key files and BIND will initialize key state files for
those keys. But there is at least one known bug that deleted keys
may be used again for signing (those deleted keys still have their
key files in the key directory). [GL #2406]


Hopefully that will not be an issue as there are no old key files. Or
rather they are all about the same age of Jan-Feb of 2019,


This bug affects key files that exist but have their "Inactive" and/or
"Delete" timing metadata in the past.

Best regards,

Matthijs
___
Please 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: Updating a DNSSEC config to use a different algorithm

Re: Updating a DNSSEC config to use a different algorithm

Re: Updating a DNSSEC config to use a different algorithm

bind9 DNS not responding to queries on LAN

Re: Updating a DNSSEC config to use a different algorithm

5 matches

Site Navigation

Mail list logo

Footer information