Missing n in man page for rndc(8)?

2022-05-03 Thread Larry Rosenman

I did find a manpage bug for the rndc man page for 9.18.2:
 dnssec (-status | -rollover -key id [-alg algorithm] [-when time] |
   -checkds [-key id [-alg algorithm]] [-when time] published | 
withdraw))

   zone [class [view]]

s/withdraw/withdrawn/

withdraw garners a syntax error :(

Where should I report this?  Or is here sufficient?

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--
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: Why aren't the old keys going hidden?

2022-05-01 Thread Larry Rosenman

On 05/01/2022 8:53 pm, Mark Andrews wrote:

Why should you want them to go away while you still have DS records
referencing them?

You also have a CDS record referencing a DNSKEY that dnssec-policy
doesn’t seem to know about.

sienawx.us. 2892IN  CDS 49366 8 2
60E3D64328B3D8929838FD1F2AB03CD5C8C72E3185C667B059E00157 D95F8CED

The DS records need to be removed before the DNSKEYs referencing them
go. Also does your registrar support CDS/CDNSKEY or do you need to
manually update the DS records?  Based on
https://support.google.com/domains/answer/6387342?hl=en_topic=9018335
I’d say no


[SNIP]

Thanks, Mark.  I've cleaned up the DS records in Google, and fixed the 
sienawx.us
CDS issue (it was added by bind at some point, but wasn't in my unsigned 
zone,
so I stopped bind, removed the signed version of the zone, and upped the 
SOA
serial in the unsigned version to higher than what was in the signed 
version,

and restarted bind).

I also didn't realize I needed to do a rndc dnssec -checkds -key  
withdrawn .


I did find a manpage bug for the rndc man page for 9.18.2:
 dnssec (-status | -rollover -key id [-alg algorithm] [-when time] |
   -checkds [-key id [-alg algorithm]] [-when time] published | 
withdraw))

   zone [class [view]]

s/withdraw/withdrawn/

withdraw garners a syntax error :(

Thanks for the inbound clue-by-four.


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--
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


DNSSEC: Why aren't the old keys going hidden?

2022-05-01 Thread Larry Rosenman
I have 2 domains where I switched from Alg 8 to Alg 13, but the old keys 
don't seem to be going away.


Attached are the state files, and the rndc dnssec -status outputs.

Ideas?

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
dnssec-policy: ler2
current time:  Sun May  1 15:49:25 2022

key: 22146 (RSASHA256), ZSK
  published:  yes - since Sun Apr 10 13:59:22 2022
  zone signing:   yes - since Sun Apr 10 13:59:22 2022

  Rollover is due since Mon Apr 25 09:30:37 2022
  - goal:   hidden
  - dnskey: omnipresent
  - zone rrsig: omnipresent

key: 29251 (ECDSAP256SHA256), KSK
  published:  yes - since Sat Apr 16 21:41:31 2022
  key signing:yes - since Sat Apr 16 21:41:31 2022

  No rollover scheduled
  - goal:   omnipresent
  - dnskey: omnipresent
  - ds: omnipresent
  - key rrsig:  omnipresent

key: 17471 (RSASHA256), KSK
  published:  yes - since Sun Apr 10 13:59:22 2022
  key signing:yes - since Sun Apr 10 13:59:22 2022

  Rollover is due since Mon Apr 25 11:35:57 2022
  - goal:   hidden
  - dnskey: omnipresent
  - ds: unretentive
  - key rrsig:  omnipresent

key: 17274 (ECDSAP256SHA256), ZSK
  published:  yes - since Sat Apr 16 21:41:31 2022
  zone signing:   yes - since Sat Apr 16 21:41:31 2022

  Next rollover scheduled on Fri Jul 15 19:36:31 2022
  - goal:   omnipresent
  - dnskey: omnipresent
  - zone rrsig: omnipresent

dnssec-policy: ler2
current time:  Sun May  1 15:48:59 2022

key: 43159 (ECDSAP256SHA256), KSK
  published:  yes - since Sat Apr 16 21:41:31 2022
  key signing:yes - since Sat Apr 16 21:41:31 2022

  Rollover is due since Mon Apr 25 13:41:36 2022
  - goal:   hidden
  - dnskey: omnipresent
  - ds: unretentive
  - key rrsig:  omnipresent

key: 12796 (RSASHA256), KSK
  published:  yes - since Sun Apr 10 13:59:22 2022
  key signing:yes - since Sun Apr 10 13:59:22 2022

  Rollover is due since Mon Apr 25 11:36:50 2022
  - goal:   hidden
  - dnskey: omnipresent
  - ds: unretentive
  - key rrsig:  omnipresent

key: 39581 (ECDSAP256SHA256), KSK
  published:  yes - since Mon Apr 25 09:31:36 2022
  key signing:yes - since Mon Apr 25 09:31:36 2022

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

key: 5844 (RSASHA256), ZSK
  published:  yes - since Sun Apr 10 13:59:22 2022
  zone signing:   yes - since Sun Apr 10 13:59:22 2022

  Rollover is due since Wed Apr 27 10:54:16 2022
  - goal:   hidden
  - dnskey: omnipresent
  - zone rrsig: omnipresent

key: 3879 (ECDSAP256SHA256), ZSK
  published:  yes - since Sat Apr 16 21:41:31 2022
  zone signing:   yes - since Sat Apr 16 21:41:31 2022

  Next rollover scheduled on Fri Jul 15 19:36:31 2022
  - goal:   omnipresent
  - dnskey: omnipresent
  - zone rrsig: omnipresent



bind-keys-issue.tar.gz
Description: application/gzip
-- 
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

2022-04-25 Thread Larry Rosenman

On 04/25/2022 8:31 am, The Doctor via bind-users wrote:

Any easy repices to get your domains DNSSEC compilant?
--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware 
AntiChrist rising!
Look at Psalms 14 and 53 on Atheism 
https://www.empire.kred/ROOTNK?t=94a1f39b

God will not fix the vessel which insists it isn't broken. -unknown
Beware https://mindspring.com


I'm just using the dnssec-policy stuff with 9.18, and manually add the 
DS records to my registrar
(Google in my case), and ARIN for my IPv4 block, and my provider for the 
delegated IPv6 block.


dnssec-policy "ler2" {
   keys {
   ksk lifetime unlimited algorithm 13;
   zsk lifetime 90d algorithm 13;
   };
   // Key timings
   dnskey-ttl 3600;
   publish-safety 1h;
   retire-safety 1h;
   purge-keys P90D;
   // Signature timings
   signatures-refresh 5d;
   signatures-validity 14d;
   signatures-validity-dnskey 14d;
   // Zone parameters
   max-zone-ttl 86400;
   zone-propagation-delay 300;
   // Parent parameters
   parent-ds-ttl 3600;
   parent-propagation-delay 300;
   nsec3param iterations 0 salt-length 0;
};

If I can help, let me know.



--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--
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: Reading secondary PTR files

2022-04-20 Thread Larry Rosenman



this is what I use with 9.18.1
named-compilezone -f raw -F text -o - 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa.signed


On 04/20/2022 8:42 am, King, Harold Clyde (Hal) via bind-users wrote:

I  need to read the reverse zone in txt and I'm not sure how to decode 
the file with named-compilezone. Does anyone know the part I'm missing?
named-compilezone -f raw -F text -o 
/etc/named/secondary/9.249.192.in-addr.arpa.db 9.249.192 
/etc/named/secondary/9.249.192.in-addr.arpa.db


--

Hal King  - h...@utk.edu
Systems Administrator
Office of Information Technology
Shared Services

The University of Tennessee
103c5 Kingston Pike Building
2309 Kingston Pk. Knoxville, TN 37996
Phone: 974-1599


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106-- 
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: Why does DNSVIZ complain about the NS RRSET here?

2022-04-18 Thread Larry Rosenman

Do you know what a windows DNS admin needs to do to fix that?


On 04/18/2022 5:12 pm, Mark Andrews wrote:

The parent servers are configured to allow recursion (ra) and rather
than returning referrals that are returning
answers provided it is cached.

Also it is pointless to use NSEC3 in the reverse trees as they contain
too much structure.

To find
4.b.3.2.b.1.e.f.f.f.5.b.3.e.a.7.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa.
3600 IN PTR thebighonker.lerctr.org you
just need to query for [0-9a-f].ip6.arpa which will elicit a non
NXDOMAIN for 2.ip6.arpa. Then you query for [0-9a-f].2.ip6.arpa, all
the way down to
[0-9a-f].b.3.2.b.1.e.f.f.f.5.b.3.e.a.7.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa.
which gives you a non NXDOMAIN response for
4.b.3.2.b.1.e.f.f.f.5.b.3.e.a.7.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa.


% dig @pdns05.thin-nology.com ns 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +norec


; <<>> DiG 9.17.22 <<>> @pdns05.thin-nology.com ns
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +norec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13592
;; flags: qr ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. IN NS

;; ANSWER SECTION:
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns1.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns2.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-a.lerctr.org.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns4.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns3.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns5.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-b.lerctr.org.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-c.lerctr.org.

;; Query time: 225 msec
;; SERVER: 216.82.192.148#53(pdns05.thin-nology.com) (UDP)
;; WHEN: Tue Apr 19 07:53:04 AEST 2022
;; MSG SIZE  rcvd: 242

%

% dig @pdns06.thin-nology.com type1000
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +norec +dnssec

; <<>> DiG 9.17.22 <<>> @pdns06.thin-nology.com type1000
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +norec +dnssec
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11871
;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 10, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4000
;; QUESTION SECTION:
;0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. IN TYPE1000

;; AUTHORITY SECTION:
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns3.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-c.lerctr.org.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-b.lerctr.org.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns-a.lerctr.org.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns2.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns1.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns4.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 0 IN NS ns5.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN DS 63984 13 2
F9B8E3F0A1E15E38C32E71BA1D7150B7FB68CC8C06943B065C75C985 0732B48E
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN RRSIG DS 13 18 3600
20220423141314 20220416131314 1535 0.b.d.c.f.2.0.6.2.ip6.arpa.
2Bn8Qtoac1rIpL6IPvUP8EFewC0XLlxidGM6lIT8q12wmSUj3o3jxSxY
xQMsK+j/b9nuMPlir+3m+mR7g5nvVQ==

;; Query time: 217 msec
;; SERVER: 216.82.192.149#53(pdns06.thin-nology.com) (UDP)
;; WHEN: Tue Apr 19 07:55:29 AEST 2022
;; MSG SIZE  rcvd: 452

%



[snip]
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--
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


Why does DNSVIZ complain about the NS RRSET here?

2022-04-16 Thread Larry Rosenman
00IN RRSIG NSEC3 13 19 3600 20220429102734 20220415092810 3046 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
M5iCnOTqQfxGbBzQMMp185MybaFn+TPM6/cvXftntBP2lxoCqBa+D0JF 
ukevEF45bwa/lM5b6MnxpmtGxo6G2A==

; resign=20220429102734
V19VIJ6AAN1D64QDIEF79283KDEIVANC.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
3600IN NSEC3 1 0 0 - VESHMAE8A0EHNCU2LUKO219Q45DC3AMN PTR RRSIG
V19VIJ6AAN1D64QDIEF79283KDEIVANC.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
3600IN RRSIG NSEC3 13 19 3600 20220425145843 20220411144736 3046 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
Sp484ke6qCXwnIQkFcfKjT0/XH0hS/VXxUMtU2R3z45+LMHpk2x9RR43 
stiySqTONSgkcfKI4EPZcxUA7CFOYg==

; resign=20220425145843
VESHMAE8A0EHNCU2LUKO219Q45DC3AMN.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
3600IN NSEC3 1 0 0 - VN8PV32TE8HA3D86M3EKHIMUIT7CRSOD
VESHMAE8A0EHNCU2LUKO219Q45DC3AMN.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
3600IN RRSIG NSEC3 13 19 3600 20220429234033 20220415233042 3046 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
bk0r3k3klZhxaoJ5wZJ2ZDITSmWhIArssryIv0vcvFnXcNgshzeyEoVP 
MOcYcib+b0Hs1pi3Nwf2IELGqgQRfw==

; resign=20220429234033
VN8PV32TE8HA3D86M3EKHIMUIT7CRSOD.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
3600IN NSEC3 1 0 0 - VQPETA4DEIURD31CGOS6P364LS8EMT6H
VN8PV32TE8HA3D86M3EKHIMUIT7CRSOD.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
3600IN RRSIG NSEC3 13 19 3600 20220429234033 20220415233042 3046 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
WIaDu6Ry3pTZe7+3sUAwwIb1BgeQ6syrhoz3/WDnU918MPX7lbhemwTh 
EdiWq5oYsSZXFvPWd8XB7LYqyemVPA==

; resign=20220429234033
VQPETA4DEIURD31CGOS6P364LS8EMT6H.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
3600IN NSEC3 1 0 0 - 0ISU75L6B23R9E1ONBHID7HSRK6Q8QT6 PTR RRSIG
VQPETA4DEIURD31CGOS6P364LS8EMT6H.0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
3600IN RRSIG NSEC3 13 19 3600 2022043121 20220415233042 3046 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 
eJpspM18ueeLh67CqrWrhAb32SamzaNdJMFUb21Owk+kpHS5C1qX4Bav 
u523WA+JqrVanEuewjGMDyk+UxgeTQ==

; resign=2022043121

and dig only shows my RRSet:
❯ dig 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +dnssec +nocrypto ns 
@1.0.0.1

zsh: correct 'ns' to 'nws' [nyae]? n

; <<>> DiG 9.16.27 <<>> 0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa +dnssec 
+nocrypto ns @1.0.0.1

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54238
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. IN NS

;; ANSWER SECTION:
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN NS 
ns1.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN NS 
ns2.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN NS 
ns3.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN NS 
ns4.dnsunlimited.com.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN NS 
ns5.dnsunlimited.com.

0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN NS ns-a.lerctr.org.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN NS ns-b.lerctr.org.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN NS ns-c.lerctr.org.
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. 3600 IN RRSIG	NS 13 18 3600 
20220427104028 20220413100533 3046 
0.1.0.0.0.0.0.0.b.d.c.f.2.0.6.2.ip6.arpa. [omitted]


;; Query time: 676 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Sat Apr 16 09:52:06 CDT 2022
;; MSG SIZE  rcvd: 414


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--
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: ds showing hidden 3+ days after key roll

2022-02-10 Thread Larry Rosenman via bind-users

On 02/10/2022 10:10 am, Matthijs Mekking wrote:

Hi,

There are several things wrong here. The gist of it is that there is
no valid ZSK and since the zone is not properly signed, BIND does not
want to publish the DS record (even if outside BIND you already
published the DS).

You can tell that BIND does not agree because it did not publish a CDS
record in your zone.

I also noticed two different algorithms. I hadn't noticed it before
but your policy says:

keys {
ksk lifetime unlimited algorithm 8 2048 ;
zsk lifetime 30d algorithm 13;
};

This is a garbage policy because you specify different algorithms for
the ksk and the zsk. This can never result in a validly signed zone.

Change the algorithm of the keys so that they match.

Perhaps we can add a named-checkconf check for this.


Best regards,

Matthijs


[snip]

Thanks!   Is that little nuance documented?  (The need for KSK and ZSK 
to be aligned on type of key)


--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--
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: ds showing hidden 3+ days after key roll

2022-02-10 Thread Larry Rosenman
-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: can we 
transition ZSK lerctr.org/RSASHA256/34851 type ZRRSIG state UNRETENTIVE 
to state HIDDEN?
<183>1 2022-02-09T02:18:28.588225-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: dnssec 
evaluation of ZSK lerctr.org/RSASHA256/34851 record ZRRSIG: 
rule1=(~false or false) rule2=(~true or true) rule3=(~true or true)
<183>1 2022-02-09T02:18:28.588244-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: time says no 
to ZSK lerctr.org/RSASHA256/34851 type ZRRSIG state UNRETENTIVE to state 
HIDDEN (wait 592212 seconds)
<183>1 2022-02-09T02:18:28.588256-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: examine KSK 
lerctr.org/RSASHA256/20014 type DNSKEY in state HIDDEN
<183>1 2022-02-09T02:18:28.588266-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: KSK 
lerctr.org/RSASHA256/20014 type DNSKEY in stable state HIDDEN
<183>1 2022-02-09T02:18:28.588276-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: examine KSK 
lerctr.org/RSASHA256/20014 type KRRSIG in state HIDDEN
<183>1 2022-02-09T02:18:28.588286-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: KSK 
lerctr.org/RSASHA256/20014 type KRRSIG in stable state HIDDEN
<183>1 2022-02-09T02:18:28.588296-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: examine KSK 
lerctr.org/RSASHA256/20014 type DS in state HIDDEN
<183>1 2022-02-09T02:18:28.588306-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: KSK 
lerctr.org/RSASHA256/20014 type DS in stable state HIDDEN
<183>1 2022-02-09T02:18:28.588317-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: examine ZSK 
lerctr.org/ECDSAP256SHA256/6539 type DNSKEY in state OMNIPRESENT
<183>1 2022-02-09T02:18:28.588328-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: ZSK 
lerctr.org/ECDSAP256SHA256/6539 type DNSKEY in stable state OMNIPRESENT
<183>1 2022-02-09T02:18:28.588338-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: examine ZSK 
lerctr.org/ECDSAP256SHA256/6539 type ZRRSIG in state OMNIPRESENT
<183>1 2022-02-09T02:18:28.588348-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: ZSK 
lerctr.org/ECDSAP256SHA256/6539 type ZRRSIG in stable state OMNIPRESENT
<183>1 2022-02-09T02:18:28.588359-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: examine KSK 
lerctr.org/RSASHA256/269 type DNSKEY in state OMNIPRESENT
<183>1 2022-02-09T02:18:28.588369-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: KSK 
lerctr.org/RSASHA256/269 type DNSKEY in stable state OMNIPRESENT
<183>1 2022-02-09T02:18:28.588379-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: examine KSK 
lerctr.org/RSASHA256/269 type KRRSIG in state OMNIPRESENT
<183>1 2022-02-09T02:18:28.588389-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: KSK 
lerctr.org/RSASHA256/269 type KRRSIG in stable state OMNIPRESENT
<183>1 2022-02-09T02:18:28.588399-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: examine KSK 
lerctr.org/RSASHA256/269 type DS in state HIDDEN
<183>1 2022-02-09T02:18:28.588410-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: can we 
transition KSK lerctr.org/RSASHA256/269 type DS state HIDDEN to state 
RUMOURED?
<183>1 2022-02-09T02:18:28.588432-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: dnssec 
evaluation of KSK lerctr.org/RSASHA256/269 record DS: rule1=(~false or 
true) rule2=(~true or true) rule3=(~true or false)
<183>1 2022-02-09T02:18:28.588453-06:00 thebighonker.lerctr.org named 
44101 - - 09-Feb-2022 02:18:28.588 dnssec: debug 1: keymgr: dnssec says 
no to KSK lerctr.org/RSASHA256/269 type DS state HIDDEN to state 
RUMOURED


ler in thebighonker in ~ via ☕ v1.8.0 via  v5.32.1 via  v2.7.5 as 慄
❯

On 02/10/2022 6:20 am, Matthijs Mekking wrote:

Hi Larry,

There has been several bug fixes for dnssec-policy since its
introduction. What version of 9.17 are you running?

I can't tell what causes the ds to stay in the hidden state. The
timings in the state file should allow it to move to the next state.

If you were able to turn on logging, on each run the keymgr will tell
you the reason why it cannot move the DS to 

dnssec: ds showing hidden 3+ days after key roll

2022-02-08 Thread Larry Rosenman

Greetings,
new poster.  I just converted over to DNSSEC-policy,  and rolled my 
KSK.  I see:

key: 269 (RSASHA256), KSK
  published:  yes - since Sun Feb  6 14:31:32 2022
  key signing:yes - since Sun Feb  6 14:31:32 2022

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


ler in thebighonker in namedb on  master [!] as 慄
❯

Is it normal to see the ds as hidden?  It IS published, and I told rndc 
that.


Any insight appreciated.

--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: l...@lerctr.org
US Mail: 5708 Sabbia Dr, Round Rock, TX 78665-2106
--
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