Re: CDS records created from ZSK records?

2022-01-25 Thread Mark Elkins 

Found it my problem.

I used to create the CDS records using a binary that has now been 
withdrawn by ISC (around November/December 2021) and now use...


dnssec-dsfromkey -C $key

...except I was running that on all keys - including ZSK's...

I have a bash shell script that does the signing. First written in 2011.
Yes - I am testing with "dnssec-policy"...

---

dnssec-policy "posix-ecdsa256-policy" {
    dnskey-ttl 3600;
    keys {
    ksk lifetime unlimited algorithm ecdsa256;
    zsk lifetime 34d algorithm ecdsa256;
    };
};

zone "smtp.co.za" {
    type master;
    file "/etc/ns.d/pri/smtp.co.za/db.smtp.co.za";
    key-directory "/etc/ns.d/pri/smtp.co.za/keys";
    dnssec-policy "posix-ecdsa256-policy";
    serial-update-method date;
};
---

... but until there is a trigger system so I can call code to do an EPP 
based KSK rollover to the parent, will keep what I've got as it 
(usually) works.


On 1/25/22 12:58 AM, Mark Andrews wrote:



On 25 Jan 2022, at 07:35, Mark Elkins  wrote:

I've just noticed that in the last few days that "BIND 9.16.22 (Extended Support Version) 
" appears to be generating CDS records for both KSK ***and ZSK*** 
records!

Nothing on my side has been changed although I do run automated updates. I'm on 
a Linux machine running Gentoo.

$ dig DNSKEY EDU.ZA

; <<>> DiG 9.16.6 <<>> DNSKEY EDU.ZA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22867
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;EDU.ZA.INDNSKEY

;; ANSWER SECTION:
EDU.ZA.9378INDNSKEY256 3 13 
U9/K052f1oBX5WYbedZhLM0jd+rNAwEYNfuRUAsf2S3U7UNaEKV2pYtM 
3dHSOdsNDiLkr0H77x9U2ZFtoN7U2A==
EDU.ZA.9378INDNSKEY256 3 13 
YPgTWLFxFXWMXlVaJB2bCA5F75l5yryFO/h9w+xXS/GfhhmvyZvh9NCv 
MLPZckLRGbeZ5/BkyH9ae4X0IyzKYA==
EDU.ZA.9378INDNSKEY257 3 13 
75OMA5R90131FVGX1QcJiCGAUboYSmazf3dPpAPL0t33YLcx7bBnio6Y 
qyrR77MRVZKNpWIBLcnz7YOLWNZXmQ==

---

$ dig CDS EDU.ZA

; <<>> DiG 9.16.6 <<>> CDS EDU.ZA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11376
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;EDU.ZA.INCDS

;; ANSWER SECTION:
EDU.ZA.86400INCDS569 13 2 
350F4414CB611C04AD829CD2C23A5C60296EA635BF59D7F0B44CD02F 6B396A94
EDU.ZA.86400INCDS9355 13 2 
B0A16FBB3F5D6274665DE272FE5FF182ABC89B3072B668589E5EC6F0 513E36C9
EDU.ZA.86400INCDS49988 13 2 
6F99A6D6A4657F0A528AD2791B8B3E02AFB34E5DB79F5C53EA022A55 1874D40A

These are also the values from inside my signed zone. Anyone have any thoughts?
This is going to screw up systems that poll for CDS records.

Well CDS records are for DNSKEYs without the SEP bit are perfectly valid as the 
SEP bit is purely advisory and
no it should screw up systems that poll for CDS records.  You will however have 
to manage them properly in the
future.

You haven’t said how you are managing DNSSEC and named supports several models 
so it is hard to a) tell if
there was a bug in our code or b) an error on your part.

Assuming that you are not using dnssec-policy you should be able to use 
'dnssec-settime -D sync date/offset’
on the ZSK’s to tell named to stop publishing the CDS records but remember you 
still need to account for the
fact that they where published as you go forward.

Mark

--

Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.826010496 
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za 



Posix SystemsVCARD for MJ Elkins

___
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: CDS records created from ZSK records?

2022-01-24 Thread Mark Andrews 


> On 25 Jan 2022, at 07:35, Mark Elkins  wrote:
> 
> I've just noticed that in the last few days that "BIND 9.16.22 (Extended 
> Support Version) " appears to be generating CDS records for both 
> KSK ***and ZSK*** records!
> 
> Nothing on my side has been changed although I do run automated updates. I'm 
> on a Linux machine running Gentoo.
> 
> $ dig DNSKEY EDU.ZA
> 
> ; <<>> DiG 9.16.6 <<>> DNSKEY EDU.ZA
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22867
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ;; QUESTION SECTION:
> ;EDU.ZA.INDNSKEY
> 
> ;; ANSWER SECTION:
> EDU.ZA.9378INDNSKEY256 3 13 
> U9/K052f1oBX5WYbedZhLM0jd+rNAwEYNfuRUAsf2S3U7UNaEKV2pYtM 
> 3dHSOdsNDiLkr0H77x9U2ZFtoN7U2A==
> EDU.ZA.9378INDNSKEY256 3 13 
> YPgTWLFxFXWMXlVaJB2bCA5F75l5yryFO/h9w+xXS/GfhhmvyZvh9NCv 
> MLPZckLRGbeZ5/BkyH9ae4X0IyzKYA==
> EDU.ZA.9378INDNSKEY257 3 13 
> 75OMA5R90131FVGX1QcJiCGAUboYSmazf3dPpAPL0t33YLcx7bBnio6Y 
> qyrR77MRVZKNpWIBLcnz7YOLWNZXmQ==
> 
> ---
> 
> $ dig CDS EDU.ZA
> 
> ; <<>> DiG 9.16.6 <<>> CDS EDU.ZA
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11376
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ;; QUESTION SECTION:
> ;EDU.ZA.INCDS
> 
> ;; ANSWER SECTION:
> EDU.ZA.86400INCDS569 13 2 
> 350F4414CB611C04AD829CD2C23A5C60296EA635BF59D7F0B44CD02F 6B396A94
> EDU.ZA.86400INCDS9355 13 2 
> B0A16FBB3F5D6274665DE272FE5FF182ABC89B3072B668589E5EC6F0 513E36C9
> EDU.ZA.86400INCDS49988 13 2 
> 6F99A6D6A4657F0A528AD2791B8B3E02AFB34E5DB79F5C53EA022A55 1874D40A
> 
> These are also the values from inside my signed zone. Anyone have any 
> thoughts?
> This is going to screw up systems that poll for CDS records.

Well CDS records are for DNSKEYs without the SEP bit are perfectly valid as the 
SEP bit is purely advisory and
no it should screw up systems that poll for CDS records.  You will however have 
to manage them properly in the
future.

You haven’t said how you are managing DNSSEC and named supports several models 
so it is hard to a) tell if
there was a bug in our code or b) an error on your part.

Assuming that you are not using dnssec-policy you should be able to use 
'dnssec-settime -D sync date/offset’
on the ZSK’s to tell named to stop publishing the CDS records but remember you 
still need to account for the
fact that they where published as you go forward.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

___
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

CDS records created from ZSK records?

2022-01-24 Thread Mark Elkins 
I've just noticed that in the last few days that "BIND 9.16.22 (Extended 
Support Version) " appears to be generating CDS records for 
both KSK ***and ZSK*** records!


Nothing on my side has been changed although I do run automated updates. 
I'm on a Linux machine running Gentoo.


$ dig DNSKEY EDU.ZA

; <<>> DiG 9.16.6 <<>> DNSKEY EDU.ZA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22867
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;EDU.ZA.                IN    DNSKEY

;; ANSWER SECTION:
EDU.ZA.            9378    IN    DNSKEY    256 3 13 
U9/K052f1oBX5WYbedZhLM0jd+rNAwEYNfuRUAsf2S3U7UNaEKV2pYtM 
3dHSOdsNDiLkr0H77x9U2ZFtoN7U2A==
EDU.ZA.            9378    IN    DNSKEY    256 3 13 
YPgTWLFxFXWMXlVaJB2bCA5F75l5yryFO/h9w+xXS/GfhhmvyZvh9NCv 
MLPZckLRGbeZ5/BkyH9ae4X0IyzKYA==
EDU.ZA.            9378    IN    DNSKEY    257 3 13 
75OMA5R90131FVGX1QcJiCGAUboYSmazf3dPpAPL0t33YLcx7bBnio6Y 
qyrR77MRVZKNpWIBLcnz7YOLWNZXmQ==


---

$ dig CDS EDU.ZA

; <<>> DiG 9.16.6 <<>> CDS EDU.ZA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11376
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;EDU.ZA.                IN    CDS

;; ANSWER SECTION:
EDU.ZA.            86400    IN    CDS    569 13 2 
350F4414CB611C04AD829CD2C23A5C60296EA635BF59D7F0B44CD02F 6B396A94
EDU.ZA.            86400    IN    CDS    9355 13 2 
B0A16FBB3F5D6274665DE272FE5FF182ABC89B3072B668589E5EC6F0 513E36C9
EDU.ZA.            86400    IN    CDS    49988 13 2 
6F99A6D6A4657F0A528AD2791B8B3E02AFB34E5DB79F5C53EA022A55 1874D40A


These are also the values from inside my signed zone. Anyone have any 
thoughts?

This is going to screw up systems that poll for CDS records.

--

Mark James ELKINS  -  Posix Systems - (South) Africa
m...@posix.co.za   Tel: +27.826010496 
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za 




___
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