Re: CDNSKEY / CDS for key is now published - but why?

2024-10-04 Thread Matthijs Mekking

Hi Danilo,

Assuming from your message you are using inline-signing, where the 
unsigned and signed zone are maintained separately. If so, you should be 
able to make changes to the zone file and just bump the serial in the 
unsigned zone and the changes should be picked up.


Best regards,

Matthijs

On 10/3/24 13:39, Danilo Godec via bind-users wrote:

Thanks,

so patience is really the name of the game here. )


One more question, if I may - I noticed that the serial number in signed 
zone gets 'out-of-sync' compared to my source text zone file. I guess 
that happens when Bind publishes CDS / CDNSKEY records etc.


Is the serial number in my source text zone file still relevant? If it 
is, I suppose increasing it by one is no longer good enough - I probably 
need to check the actual SOA and then use that as 'base' and increase 
that by 1, right?



    Regards,

     Danilo




On 2. 10. 24 15:13, Matthijs Mekking wrote:

Hi,

The change from rumoured to omnipresent is TTL dependent. To be 
precise: it is the sum of the configured parent-ds-ttl, 
parent-propagation-delay, and retire-safety.


- Matthijs

On 10/2/24 14:55, Danilo Godec via bind-users wrote:

Hi Matthijs,


thanks,  that explains a bunch.

I checked both domain with '/rndc dnssec -status/' and they do show 
different states:


# rndc dnssec -status psihopat.si
dnssec-policy: nsec3_no_rotate
current time:  Wed Oct  2 14:25:31 2024

key: 37651 (ECDSAP256SHA256), ZSK
   published:  yes - since Tue Oct  1 20:23:24 2024
   zone signing:   yes - since Tue Oct  1 20:23:24 2024

   No rollover scheduled
   - goal:   omnipresent
   - dnskey: omnipresent
*- zone rrsig: rumoured*

key: 7162 (ECDSAP256SHA256), KSK
   published:  yes - since Tue Oct  1 20:23:24 2024
   key signing:    yes - since Tue Oct  1 20:23:24 2024

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


# rndc dnssec -status sociopat.si
dnssec-policy: nsec3_no_rotate
current time:  Wed Oct  2 14:25:34 2024

key: 17354 (ECDSAP256SHA256), ZSK
   published:  yes - since Tue Oct  1 10:09:53 2024
   zone signing:   yes - since Tue Oct  1 10:09:53 2024

   No rollover scheduled
   - goal:   omnipresent
   - dnskey: omnipresent
   - zone rrsig: omnipresent

key: 61220 (ECDSAP256SHA256), KSK
   published:  yes - since Tue Oct  1 10:09:53 2024
   key signing:    yes - since Tue Oct  1 10:09:53 2024

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


So I ran /rndc dnssec -checkds published**/for both zones:

# rndc dnssec -checkds published sociopat.si
Marked DS as published since 02-Oct-2024 14:33:33.000

# rndc dnssec -checkds published legenda.si
Marked DS as published since 02-Oct-2024 14:33:47.000

That changed KSK DS state from *hidden* to *rumoured* for 
psihopat.si, but made no change to sociopat.si.



Should the change be immediate or is it also TTL dependent?



    Regards,

    Danilo


--
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: Determining case of REFUSED queries

2024-10-04 Thread tale via bind-users
On Thu, Oct 3, 2024 at 6:23 PM Lyle Giese via bind-users
 wrote:
> I get this:
> ; <<>> DiG 9.16.50-Debian <<>> ns socialinnovation.ca
>...
> socialinnovation.ca.3600IN  NS  dns.rebel.ca.
> socialinnovation.ca.3600IN  NS  sean.ns.cloudflare.com.
> socialinnovation.ca.3600IN  NS  kami.ns.cloudflare.com.
> socialinnovation.ca.3600IN  NS  dns2.rebel.ca.
>...>
> But a whois query for this domain only lists dns.rebel.ca and dns2.rebel.ca 
> for name servers.

The Cloudflare NSs are coming from the apex NS RRset as returned by rebel.ca.

> Wonder if the cloudflare server are not getting a good axfr from the rebel.ca 
> servers or something else is wrong.

REFUSED would tend to indicate that Cloudflare is just not configured
for the zone at all.
-- 
tale
-- 
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