Re: Resolving and caching illegal names

[John Thurston]

I hadn't had enough coffee when I wrote that. I was doing in-addr.arpa 
translation in my head and confusing what was the TLD of the query being 
submitted. If a customer is stupid enough to ask for an A-record for 
10.1.2.3, then the TLD of that name is "3", not "10" . . duh.


So to make the RPZ work, I needed to stuff the zone file with 256 new 
entries. I did this by dusting off my knowledge of the GENERATE 
directive (which involved RTFM):


   $GENERATE 0-255 *.$ CNAME   .

I also needed to populate the "validate-except" option with 256 new 
entries. I could find no elegant way to generate, abstract, or 'include' 
this, so just needed to put the long string of characters inline:


   0; 1; 2; 3; 4; 5; 6; 7; 8; 9; 10; 11; 12; . . .

and it now behaves as desired; returning an unvalidated NXDOMAIN for 
queries for ip addresses.


--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska

On 1/25/2023 8:36 AM, John Thurston wrote:


Off-list, it was suggested to me that I _could_ handle this in my RPZ, 
by enumerating all 255 illegal TLDs (e.g. *.10  CNAME . )


I tried this, and it works as expected when dnssec validation is 
disabled (either globally, or with "validate-except". My idea right 
now is I can enumerate TLD of the numerics I see in my logs, and 
ignore the rest. I think this will get me what I want, at a level of 
complexity I can accept.
-- 
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: recursion yes/no?

[Evan Hunt]

On Wed, Jan 25, 2023 at 10:23:16AM -, David Carvalho wrote:
> Will there be any inconvenient setting minimal-responses to no?  Having
> that default behaviour when using "dig" can be useful.

No, it's quite harmless. Minimal-repsonses saves a bit of time when
processing a query, but unless your server gets an overwhelming amount
of traffic you won't notice it.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
-- 
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: Resolving and caching illegal names

[John Thurston]

- Why *must* you forward everything to Akamai?


I am forced to "forward only;" to Akamai for all external queries. It 
hasn't always been this way, but the decision was made "above my pay 
grade", and it is not open to negotiation.



- Was that a real example of a daft query: 10.11.12.13 type A?


"10.11.12.13 is, indeed, a query I found in my log.


what's the issue with returning SERVFAIL?


On my validating "recursive" servers, "SERVFAIL" is the response from 
_my_ server. That is the result of Akamai saying "Here's your answer!" 
and my server going through the work of trying to validate it (and failing).


On my non-validating "recursive" servers, I send back the answer Akamai 
sends me:



;; ANSWER SECTION:
10.11.12.13.    10  IN  A   10.11.12.13


I think SERVFAIL is the correct answer for all of these queries. I do 
not want to encourage any customers in thinking they can get an address 
back from me by asking for the address of an address.




- Do Akamai have any knobs you can tweak


{chuckle} I'm not allowed in the control room. And Akamai's response to 
my question was quoted in my original message. From their perspective, 
this behavior is a feature, not a defect. I don't expect them to let 
their customer disable their "features". If I want to change this 
behavior, I'm going to have to do it within my sphere of influence.


Off-list, it was suggested to me that I _could_ handle this in my RPZ, 
by enumerating all 255 illegal TLDs (e.g. *.10  CNAME . )


I tried this, and it works as expected when dnssec validation is 
disabled (either globally, or with "validate-except". My idea right now 
is I can enumerate TLD of the numerics I see in my logs, and ignore the 
rest. I think this will get me what I want, at a level of complexity I 
can accept.


--
Do things because you should, not just because you can.

John Thurston907-465-8591
john.thurs...@alaska.gov
Department of Administration
State of Alaska

On 1/24/2023 10:26 PM, Greg Choules wrote:

- Why *must* you forward everything to Akamai?
- Was that a real example of a daft query: 10.11.12.13 type A? If not, 
do you have some real examples of queries being made to your servers 
please?
- Notwithstanding the nature of these illegal queries, if they *are* 
illegal (or misguided, or errors, or malicious, or whatever - anything 
but valid), what's the issue with returning SERVFAIL? GIGO Or does 
that then prejudice genuine queries, for some reason?

- Are you *only* forwarding to Akamai?
- Do you have "forward only;" or "forward first;"?
- Do Akamai have any knobs you can tweak (I believe they have a 
customer web portal for viewing/changing settings?) that would make 
them behave like an RFC compliant DNS server?-- 
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

RHEL, Centos, Rocky, Fedora rpm 9.16.37

[Carl Byington via bind-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

https://www.five-ten-sg.com/mapper/bind contains links to the source
rpm, and build instructions. This .src.rpm contains a .tar.gz file with
the ARM documentation, so the rpm rebuild process does not need sphinx-
build and associated dependencies.



-BEGIN PGP SIGNATURE-

iHMEAREKADMWIQSuFMepaSkjWnTxQ5QvqPuaKVMWwQUCY9Fm1hUcY2FybEBmaXZl
LXRlbi1zZy5jb20ACgkQL6j7milTFsFozgCfb5FJRMhwKC0gnpa3T5l3ZUiunn4A
nisHLUwfoJtp+xdgxSzVfm7OmXA8
=Ys4u
-END PGP SIGNATURE-



-- 
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: recursion yes/no?

[David Carvalho via bind-users]

It helps a lot!!

I think I understand now.

Have a great day!

Regards

David

 

From: Greg Choules  
Sent: 25 January 2023 10:34
To: David Carvalho 
Cc: bind-users@lists.isc.org
Subject: Re: recursion yes/no?

 

Hi David.

With "minimal-responses", usually I would set it to "no" for a purely 
authoritative server because resolvers need all the help they can get. But for 
a purely recursive server I would set it to "yes" because end users don't need 
(any wouldn't do anything with it anyway) Authority or Additional data. So a 
hybrid server is a bit stuck between those two settings.

 

However, from 9.16 BIND now has extra choices (as Evan pointed out). To answer 
your follow up question I would stick with "no-auth-recursive" as this is 
exactly the scenario it is designed for.

 

"dig" (by default, like all stub clients) will make recursive queries; i.e. 
RD=1. If your server has "minimal-responses no-auth-recursive;" set (or nothing 
at all since that's the default) then a vanilla query from dig will *not* 
receive anything it doesn't need to, just like real users. If you *want* to see 
all the Authority and Additional data then add "+norecurse" to your dig 
command, which causes it to set RD=0. Your server is then not being asked to do 
recursion, so it will just reply with everything (if anything) it has.

 

Hope that helps.
Greg

 

On Wed, 25 Jan 2023 at 10:16, David Carvalho mailto:da...@di.ubi.pt> > wrote:

Good morning and thank you so much!

Now I understand. My servers are not pure authoritative, so I’ll have to keep 
the recursion enabled.

As for the answers in Authority and Additional sections, after setting 
minimal-responses to no, now I get the usual output when querying.

For what I understand, there is no downside in maintaining this setting, right?

Thank you!

 

Kind regards.

David

 

 

From: Greg Choules mailto:gregchoules%2bbindus...@googlemail.com> > 
Sent: 24 January 2023 18:12
To: David Carvalho mailto:da...@di.ubi.pt> >
Cc: bind-users@lists.isc.org  
Subject: Re: recursion yes/no?

 

Hi David.

"recursion yes;" tells named that it can (if it has to) make queries to other 
places if it needs more information in order to answer a client query. Pure 
authoritative servers shouldn't need it and should have "recursion no;". So the 
first question is, do your servers make queries out to other places? If so, 
recursion must be enabled.

Secondly, do you have "minimal-responses" configured on either/both servers? If 
so, what is it set to? There were changes in 9.16 so maybe these explain your 
observations.

 

Cheers, Greg

 

On Tue, 24 Jan 2023 at 16:49, David Carvalho via bind-users 
mailto:bind-users@lists.isc.org> > wrote:

Hello.

I hope someone could help to understand the following.

I have “my.domain.pt  ” and a master and slave server for 
the “my” part. I have been using “recursion yes” in both named.conf, as I want 
them to be both authoritative and cache for my clients.

Last week I migrated my slave DNS server to version 9.16 and only today, after 
having issues with the primary server migration, I realized that for most 
queries, my slave DNS does not answer the “ADDITIONAL SECTION” unless I specify 
“+norec” with the dig command.

 

My named.conf files only differ in IPs and “master/slave” setting.

 

My questions:

Should I use recursion on both? (Bear in mind that I also want them to provide 
chache to clients)

Why do I need “dig +norec” to get the exact output on my slave server? 

 

Kind regards

David

-- 
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: recursion yes/no?

[Greg Choules via bind-users]

Hi David.
With "minimal-responses", usually I would set it to "no" for a purely
authoritative server because resolvers need all the help they can get. But
for a purely recursive server I would set it to "yes" because end users
don't need (any wouldn't do anything with it anyway) Authority or
Additional data. So a hybrid server is a bit stuck between those two
settings.

However, from 9.16 BIND now has extra choices (as Evan pointed out). To
answer your follow up question I would stick with "no-auth-recursive" as
this is exactly the scenario it is designed for.

"dig" (by default, like all stub clients) will make recursive queries; i.e.
RD=1. If your server has "minimal-responses no-auth-recursive;" set (or
nothing at all since that's the default) then a vanilla query from dig will
*not* receive anything it doesn't need to, just like real users. If you
*want* to see all the Authority and Additional data then add "+norecurse"
to your dig command, which causes it to set RD=0. Your server is then not
being asked to do recursion, so it will just reply with everything (if
anything) it has.

Hope that helps.
Greg

On Wed, 25 Jan 2023 at 10:16, David Carvalho  wrote:

> Good morning and thank you so much!
>
> Now I understand. My servers are not pure authoritative, so I’ll have to
> keep the recursion enabled.
>
> As for the answers in Authority and Additional sections, after setting
> minimal-responses to no, now I get the usual output when querying.
>
> For what I understand, there is no downside in maintaining this setting,
> right?
>
> Thank you!
>
>
>
> Kind regards.
>
> David
>
>
>
>
>
> *From:* Greg Choules 
> *Sent:* 24 January 2023 18:12
> *To:* David Carvalho 
> *Cc:* bind-users@lists.isc.org
> *Subject:* Re: recursion yes/no?
>
>
>
> Hi David.
>
> "recursion yes;" tells named that it can (if it has to) make queries to
> other places if it needs more information in order to answer a client
> query. Pure authoritative servers shouldn't need it and should have
> "recursion no;". So the first question is, do your servers make queries out
> to other places? If so, recursion must be enabled.
>
> Secondly, do you have "minimal-responses" configured on either/both
> servers? If so, what is it set to? There were changes in 9.16 so maybe
> these explain your observations.
>
>
>
> Cheers, Greg
>
>
>
> On Tue, 24 Jan 2023 at 16:49, David Carvalho via bind-users <
> bind-users@lists.isc.org> wrote:
>
> Hello.
>
> I hope someone could help to understand the following.
>
> I have “my.domain.pt” and a master and slave server for the “my” part. I
> have been using “recursion yes” in both named.conf, as I want them to be
> both authoritative and cache for my clients.
>
> Last week I migrated my slave DNS server to version 9.16 and only today,
> after having issues with the primary server migration, I realized that for
> most queries, my slave DNS does not answer the “ADDITIONAL SECTION” unless
> I specify “+norec” with the dig command.
>
>
>
> My named.conf files only differ in IPs and “master/slave” setting.
>
>
>
> My questions:
>
> Should I use recursion on both? (Bear in mind that I also want them to
> provide chache to clients)
>
> Why do I need “dig +norec” to get the exact output on my slave server?
>
>
>
> Kind regards
>
> David
>
> --
> 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: [KASP] Key rollover

[Matthijs Mekking]

On 1/24/23 15:18, adrien sipasseuth wrote:

Hello,

I don't why DSState: hidden, it's ok with some online check tools like :
- https://dnssec-analyzer.verisignlabs.com/ 


- https://zonemaster.net/fr/run-test 


DSState: hidden is what BIND thinks. Note that it does not query yet to 
determine the DSState.





my master is hidden, it can be related ? How i can debug this DSState: 
hidden ?


It has nothing to do with hidden primaries.



I found this command to check actual status : rndc dnssec -status **
This is the output :

key: 46358 (ECDSAP256SHA256), KSK
   published:      yes - since Tue Jan 17 17:55:03 2023
   key signing:    yes - since Tue Jan 17 17:55:03 2023

   Next rollover scheduled on Tue Jan 24 17:55:03 2023
   - goal:           omnipresent
   - dnskey:         omnipresent
   - ds:             hidden
   - key rrsig:      omnipresent


It is hard to determine why your DS is hidden. If all other elements are 
omnipresent, the DS should be rumoured (because you may submit it to the 
parent).


I have a feeling this is because your publish-safety is 3 days. It takes 
an additional 3 days before continuing with the rollover, thus also with 
"making the DS known to the world". In other words, I think BIND does 
not yet think it is safe to publish the DS, hence DS is hidden.


I understand this may not reflect the real world, and perhaps it is a 
bug. If someone issues a "rndc dnssec -checkds published" command", we 
probably should force move the DS state from "hidden" to "rumoured".


Best regards,

Matthijs





...

Regards Adrien

Le mar. 24 janv. 2023 à 09:27, Matthijs Mekking > a écrit :


Hi Adrien,

I don't think it is fine yet. I see in your state file the following
line:

  > DSState: hidden

This means the DS is not published according to BIND.

  > From my understanding, the second KSK should appear because I
put the
  > parameter "publish-safety 3d;" that is to say 3 days before the
  > expiration ("retired") of the key in use. is that right?

In addition to the DNSKEY TTL yes. The successor KSK should be
pre-published the sum of dnskey-ttl, publish-safety, and
zone-propagation-delay, prior to its retirement.

Best regards,

Matthijs

On 1/24/23 09:08, adrien sipasseuth wrote:
 > Hello Matthijs,
 >
 > Indeed I had not published the DS at my registar because I
thought that
 > the second KSK would have appeared anyway at the time of the
rollover.
 >
 > I published the DS yesterday and I reported to BIND with the
command you
 > gave me. I didn't find any error in the logs so everything must have
 > been fine!
 >
 > here is the state file of the KSK in use :
 > ; This is the state of key 46358, for ***.
 > Algorithm: 13
 > Length: 256
 > Lifetime: 604800
 > Predecessor: 28887
 > KSK: yes
 > ZSK: no
 > Generated: 20230117165503 (Tue Jan 17 17:55:03 2023)
 > Published: 20230117165503 (Tue Jan 17 17:55:03 2023)
 > Active: 20230120180003 (Fri Jan 20 19:00:03 2023)
 > Retired: 20230127180003 (Fri Jan 27 19:00:03 2023)
 > Removed: 20230131190003 (Tue Jan 31 20:00:03 2023)
 > DSPublish: 20230123081513 (Mon Jan 23 09:15:13 2023)
 > PublishCDS: 20230120180003 (Fri Jan 20 19:00:03 2023)
 > DNSKEYChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
 > KRRSIGChange: 20230120180003 (Fri Jan 20 19:00:03 2023)
 > DSChange: 20230117165503 (Tue Jan 17 17:55:03 2023)
 > DNSKEYState: omnipresent
 > KRRSIGState: omnipresent
 > DSState: hidden
 > GoalState: omnipresent
 >
 >  From my understanding, the second KSK should appear because I
put the
 > parameter "publish-safety 3d;" that is to say 3 days before the
 > expiration ("retired") of the key in use. is that right?
 >
 > that is to say tonight at 7pm, I will see tomorrow if this one
appears.
 >
 > regards, Adrien
 >
 >
 >
 > Le jeu. 19 janv. 2023 à 09:13, Matthijs Mekking mailto:matth...@isc.org>
 > >> a écrit :
 >
 >     Hi Adrien,
 >
 >     Without any logs or key **state** files, I can't really tell
what is
 >     going on.
 >
 >     My only gut feeling is that you have never signaled BIND 9
that the DS
 >     has been published. You can run 'rndc dnssec -checkds -key 12345
 >     published example.com 
>' or set up
 >     parental-agents to do it for you.
 >
 >     Best regards,
 >
 >     Matthijs
 >
 >     On 1/17/23 09:38, adrien sipasseuth wrote:
 >      > Hello,
 >      >
 >      > I put the management of DNSSEC with KASP, the zone is well
 >     functional.
   

RE: recursion yes/no?

[David Carvalho via bind-users]

Hello and thank you so much.
"   no-auth-recursive is meant for use in mixed-mode servers that
   handle both authoritative and recursive queries" - So I guess the default 
setting is intended for my purpose.

Will there be any inconvenient setting minimal-responses to no?  Having that 
default behaviour when using "dig" can be useful.


Thank you!

Kind regards.
David

Os melhores cumprimentos
David Alexandre M. de Carvalho
═══
Especialista de Informática
Departamento de Informática
Universidade da Beira Interior

-Original Message-
From: Evan Hunt  
Sent: 24 January 2023 20:12
To: David Carvalho 
Cc: bind-users@lists.isc.org
Subject: Re: recursion yes/no?

On Tue, Jan 24, 2023 at 04:48:34PM -, David Carvalho via bind-users wrote:
> Hello.
> 
> I hope someone could help to understand the following.
> 
> I have "my.domain.pt" and a master and slave server for the "my" part. 
> I have been using "recursion yes" in both named.conf, as I want them 
> to be both authoritative and cache for my clients.
> 
> Last week I migrated my slave DNS server to version 9.16 and only 
> today, after having issues with the primary server migration, I 
> realized that for most queries, my slave DNS does not answer the 
> "ADDITIONAL SECTION" unless I specify "+norec" with the dig command.

You didn't mention what version you were upgrading from, but I guess 9.11, 
because the default setting of "minimal-responses" was changed in 9.12. It used 
to default to "no", but it now defaults to "no-auth-recursive". From the ARM:

  minimal-responses takes one of four values:

   -  no: the server is as complete as possible when generating responses.
   -  yes: the server only adds records to the authority and additional
  sections when such records are required by the DNS protocol (for
  example, when returning delegations or negative responses). This
  provides the best server performance but may result in more client
  queries.
   -  no-auth: the server omits records from the authority section except
  when they are required, but it may still add records to the
  additional section.
   -  no-auth-recursive: the same as no-auth when recursion is requested
  in the query (RD=1), or the same as no if recursion is not requested.

   no-auth and no-auth-recursive are useful when answering stub
   clients, which usually ignore the authority section.
   no-auth-recursive is meant for use in mixed-mode servers that
   handle both authoritative and recursive queries.

So when recursion is requested in the query, the server omits the NS records 
from the authority section, and if there's no NS records then there won't need 
to be corresponding A or  records in the additional section.

--
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.

-- 
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: recursion yes/no?

[David Carvalho via bind-users]

Good morning and thank you so much!

Now I understand. My servers are not pure authoritative, so I’ll have to keep 
the recursion enabled.

As for the answers in Authority and Additional sections, after setting 
minimal-responses to no, now I get the usual output when querying.

For what I understand, there is no downside in maintaining this setting, right?

Thank you!

 

Kind regards.

David

 

 

From: Greg Choules  
Sent: 24 January 2023 18:12
To: David Carvalho 
Cc: bind-users@lists.isc.org
Subject: Re: recursion yes/no?

 

Hi David.

"recursion yes;" tells named that it can (if it has to) make queries to other 
places if it needs more information in order to answer a client query. Pure 
authoritative servers shouldn't need it and should have "recursion no;". So the 
first question is, do your servers make queries out to other places? If so, 
recursion must be enabled.

Secondly, do you have "minimal-responses" configured on either/both servers? If 
so, what is it set to? There were changes in 9.16 so maybe these explain your 
observations.

 

Cheers, Greg

 

On Tue, 24 Jan 2023 at 16:49, David Carvalho via bind-users 
mailto:bind-users@lists.isc.org> > wrote:

Hello.

I hope someone could help to understand the following.

I have “my.domain.pt  ” and a master and slave server for 
the “my” part. I have been using “recursion yes” in both named.conf, as I want 
them to be both authoritative and cache for my clients.

Last week I migrated my slave DNS server to version 9.16 and only today, after 
having issues with the primary server migration, I realized that for most 
queries, my slave DNS does not answer the “ADDITIONAL SECTION” unless I specify 
“+norec” with the dig command.

 

My named.conf files only differ in IPs and “master/slave” setting.

 

My questions:

Should I use recursion on both? (Bear in mind that I also want them to provide 
chache to clients)

Why do I need “dig +norec” to get the exact output on my slave server? 

 

Kind regards

David

-- 
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: [KASP] Key rollover

[adrien sipasseuth]

Hi Matthijs ,

my next key was generated yesterday as expected by policy (parameter
"publish-safety 3d;"). My current key has been deleted from Bind (according
to the logs) but it still exists on my primary server (I can still find the
key and its status file).

When I do a "dig DNSKEY ..." from the primary server I only see the next
KSK.

I published the DS of my next key at my registrar and I notified Bind that
it was done via the command: rndc dnssec -checkds -key 24167 published
***'

In the logs here is what I have :
janv. 24 17:55:03 named[1197184]: keymgr: DNSKEY
/ECDSAP256SHA256/24167 (KSK) created for policy
client-generique
janv. 24 17:55:03 named[1197184]: DNSKEY
/ECDSAP256SHA256/46358 (KSK) is now deleted
janv. 24 17:55:03 named[1197184]: Fetching
/ECDSAP256SHA256/24167 (KSK) from key repository.
janv. 24 17:55:03 named[1197184]: DNSKEY
/ECDSAP256SHA256/24167 (KSK) is now published
janv. 24 17:55:03 named[1197184]: zone /IN (signed):
next key event: 24-Jan-2023 19:00:03.893
janv. 24 17:55:03 named[1197184]: zone /IN (signed):
sending notifies (serial 2022123004)
...
janv. 24 17:55:08 named[1197184]: zone /IN (signed):
sending notifies (serial 2022123005)
janv. 24 19:00:03 named[1197184]: zone /IN (signed):
reconfiguring zone keys
janv. 24 19:00:03 named[1197184]: keymgr: purge DNSKEY
/ECDSAP256SHA256/13323 (ZSK) according to policy
client-generique
janv. 24 19:00:03 named[1197184]: DNSKEY
/ECDSAP256SHA256/24167 (KSK) is now inactive
janv. 24 19:00:03 named[1197184]: zone /IN (signed):
next key event: 25-Jan-2023 17:55:03.897
janv. 25 09:11:34 named[1197184]: received control channel command 'dnssec
-checkds -key 24167 published '
janv. 25 09:11:34 named[1197184]: keymgr: checkds DS for key
/ECDSAP256SHA256/24167 seen published at Wed Jan 25
09:11:34 2023
janv. 25 09:11:34 named[1197184]: zone /IN (signed):
reconfiguring zone keys
janv. 25 09:11:34 named[1197184]: DNSKEY
/ECDSAP256SHA256/24167 (KSK) is now inactive
janv. 25 09:11:34 named[1197184]: zone /IN (signed):
next key event: 25-Jan-2023 17:55:03.026
janv. 25 09:19:02 named[1197184]: received control channel command 'dnssec
-status '
janv. 25 09:19:59 named[1197184]: zone /IN (signed):
reconfiguring zone keys
janv. 25 09:19:59 named[1197184]: DNSKEY
/ECDSAP256SHA256/24167 (KSK) is now inactive
janv. 25 09:19:59 named[1197184]: zone /IN (signed):
next key event: 25-Jan-2023 17:55:03.062


When I look at the state files of my 2 KSKs, I always have "DSState:
hidden", I can't find any documentation on it, how Bind decides that the DS
is hidden? Because my primary server is hidden (not exposed to internet)?

Here is a "dig DS ..." I can see my current key :
...
***. 104974 IN DS 46358 13 2 (
0715AC00A9C4349AA627F098A20B6716EE7334CBE261
34D6281B36453C99D6C2 )


If it can help , here are the contents of the status files of my 2 KSKs :

KSK current but deleted (according to Bind logs):
; This is the state of key 46358, for ***
Algorithm: 13
Length: 256
Lifetime: 604800
Predecessor: 28887
Successor: 24167
KSK: yes
ZSK: no
Generated: 20230117165503 (Tue Jan 17 17:55:03 2023)
Published: 20230117165503 (Tue Jan 17 17:55:03 2023)
Active: 20230120180003 (Fri Jan 20 19:00:03 2023)
Retired: 20230127180003 (Fri Jan 27 19:00:03 2023)
Removed: 20230131190003 (Tue Jan 31 20:00:03 2023)
DSPublish: 20230125082125 (Wed Jan 25 09:21:25 2023)
PublishCDS: 20230120180003 (Fri Jan 20 19:00:03 2023)
DNSKEYChange: 20230124180003 (Tue Jan 24 19:00:03 2023)
KRRSIGChange: 20230124180003 (Tue Jan 24 19:00:03 2023)
DSChange: 20230117165503 (Tue Jan 17 17:55:03 2023)
DNSKEYState: hidden
KRRSIGState: hidden
DSState: hidden
GoalState: hidden



The following KSK was generated, published at my registrar, notified to
Bind via the command "rndc dnssec -checkds..." and visible via a "dig
DNSKEY..." :
; This is the state of key 24167, for ***
Algorithm: 13
Length: 256
Lifetime: 604800
Predecessor: 46358
KSK: yes
ZSK: no
Generated: 20230124165503 (Tue Jan 24 17:55:03 2023)
Published: 20230124165503 (Tue Jan 24 17:55:03 2023)
Active: 20230127180003 (Fri Jan 27 19:00:03 2023)
Retired: 20230203180003 (Fri Feb  3 19:00:03 2023)
Removed: 20230207190003 (Tue Feb  7 20:00:03 2023)
DSPublish: 20230125082155 (Wed Jan 25 09:21:55 2023)
PublishCDS: 20230127180003 (Fri Jan 27 19:00:03 2023)
DNSKEYChange: 20230124165503 (Tue Jan 24 17:55:03 2023)
KRRSIGChange: 20230124165503 (Tue Jan 24 17:55:03 2023)
DSChange: 20230124165503 (Tue Jan 24