Re: Struggling with dnssec-policy timers

2022-11-28 Thread Matthijs Mekking 



On 29-11-2022 00:39, vom513 wrote:




On Nov 28, 2022, at 3:12 PM, vom513  wrote:

Thanks for the reply and info…

I would have thought the CDS would be published before the key went
active.  I.e. there would be a period of TWO DS’es at the parent
(I’m assuming the parent supports CDS/CDNSKEY which mine
(registrar) does).


This is called Double-DS rollover (RFC 7583, Section 3.3.2). BIND 
implements the Double-KSK method (RFC 7583, Section 3.3.1) for 
dnssec-policy.




Since the new key goes active, CDS is published, and the old key is
retired at the same time - isn’t this going to cause a (lack of
coverage/chain of trust) problem ?  I’m really trying to get to a
point of a “one command” rollover.  I.e. no API, no uploading DS,
etc.  I guess I’ll see tonight when it happens, but I can’t help
but feel when the clock strikes I’m going to be missing DS for the
new key at the parent.



Sorry to self reply…

So it did “work” as you said Matthijs… I don’t think I necessarily
need those timers (publish/retire-safety) that I tweaked.  I’d rather
use as many bind defaults as possible.  I think a big part of my
issue was misunderstanding “retired” status.  I nuked everything
clean and will try this again once everything settles down.  Thanks
for your patience with me and pointers.


The default publish-safety and retire-safety are set to 3600 seconds.
They are meant to delay rollovers to deal with unforeseen events. I
don't think you need to change them unless you have a good reason to do so.



PS: My registrar says they check CDS/CDNSKEY once a day.  Do you
think that’s reasonable ?  I certainly appreciate them being
cognizant/careful of too much load on their systems with too many
frequent checks, but a day seems long to me...


KSK rollovers are meant to happen infrequently, so once a day seems
reasonable to me.

Note that you would still have to check the parent when the DS has
changed. The DS may be published and withdrawn automatically in the
parent zone if your registar polls the CDS/CDNSKEY, but BIND by default
does not check whether the DS has actually been published.

Either check it manually, or scripted, and use "rndc dnssec -checkds" to
signal BIND that a certain DS has been published or withdrawn.

Or set up a "parental-agents" in your named.conf, that is a server that
BIND will use to query the DS RRset to fully automate the KSK rollover.


Best regards,

Matthijs
--
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: Add TXT records for SPF when CNAME exists in same sub-domain

2022-11-28 Thread Mark Andrews 
Place the TXT record at the target of the CNAME.

> On 29 Nov 2022, at 11:03, Chris Liesfield  wrote:
> 
> Hi All. Hopefully my terminology is correct and I make sense.
> 
> We have a main domain "something.com.au" with a few sub-domains, "this", 
> "that", etc.
> 
> For all of our 'A' records in something.com.au, we have specified TXT records 
> for SPF, however our sub-domains contain CNAMEs only.
> 
> It appears TXT and CNAME records for the same string/host cannot co-exist. We 
> are able to specify an SPF record for the origin only in each sub-domain.
> 
> Open to any suggestions on how to get around this issue.
> 
> Thanks in advance.
> 
> $TTL 3600
> @   IN  SOA  something.com.au. bofh.something.com.au. 
> (
> 2022112901 ; serial
> 10800  ; refresh (3 hours)
> 3600   ; retry (1 hour)
> 604800 ; expire (1 week)
> 3600   ; minimum (1 hour)
> )
> NS  ns1.something.com.au.
> NS  ns2.something.com.au.
> MX  10 mail.something.com.au.
> 
> ; A Records
> 
> localhost   A   127.0.0.1
> www   A   1.2.3.4
> @ IN  A   1.2.3.4
> 
> ; SPF records
> 
> ; working without a problem.
> www TXT "v=spf1 -all"
> 
> $ORIGIN this.something.com.au.
> $TTL 3600   ; 1 hour
> www CNAME   stuff.somewhereelse.com.au.
> @   CNAME   stuff.somewhereelse.com.au.
> 
> ; SPF records
> 
> ; BIND considers this an invalid statement - no corresponding 'A' record - 
> conflict with CNAME?
> www TXT "v=spf1 -all"
> ; working without a problem.
> @   TXT "v=spf1 -all"
> 
> $ORIGIN that.something.com.au.
> $TTL 3600   ; 1 hour
> www CNAME   stuff.overthere.com.au.
> @   CNAME   stuff.overthere.com.au.
> 
> ; SPF records
> 
> ; BIND considers this an invalid statement - no corresponding 'A' record - 
> conflict with CNAME?
> www TXT "v=spf1 -all"
> ; working without a problem.
> @   TXT "v=spf1 -all"
> 
> -- 
> Chris.
>  
>  
> 
> -- 
> 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

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

-- 
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: Add TXT records for SPF when CNAME exists in same sub-domain

2022-11-28 Thread John W. Blue via bind-users 
RFC 1034

3.6.2 second paragraph:

“If a CNAME RR is present at a node, no other data should be
present; this ensures that the data for a canonical name and its aliases
cannot be different.  This rule also insures that a cached CNAME can be
used without checking with an authoritative server for other RR types.”

There may be an updated RFC that states the same thing differently but it is a 
well-known DNS rule.

valimail.com’s blackbox might be able to get around it but I would not know for 
sure.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Chris 
Liesfield
Sent: Monday, November 28, 2022 6:03 PM
To: bind-users@lists.isc.org
Subject: Add TXT records for SPF when CNAME exists in same sub-domain

Hi All. Hopefully my terminology is correct and I make sense.

We have a main domain "something.com.au" with a few 
sub-domains, "this", "that", etc.

For all of our 'A' records in something.com.au, we 
have specified TXT records for SPF, however our sub-domains contain CNAMEs only.

It appears TXT and CNAME records for the same string/host cannot co-exist. We 
are able to specify an SPF record for the origin only in each sub-domain.

Open to any suggestions on how to get around this issue.

Thanks in advance.

$TTL 3600
@   IN  SOA  something.com.au. 
bofh.something.com.au. (
2022112901 ; serial
10800  ; refresh (3 hours)
3600   ; retry (1 hour)
604800 ; expire (1 week)
3600   ; minimum (1 hour)
)
NS  
ns1.something.com.au.
NS  
ns2.something.com.au.
MX  10 
mail.something.com.au.

; A Records

localhost   A   127.0.0.1
www   A   1.2.3.4
@ IN  A   1.2.3.4

; SPF records

; working without a problem.
www TXT "v=spf1 -all"

$ORIGIN this.something.com.au.
$TTL 3600   ; 1 hour
www CNAME   
stuff.somewhereelse.com.au.
@   CNAME   
stuff.somewhereelse.com.au.

; SPF records

; BIND considers this an invalid statement - no corresponding 'A' record - 
conflict with CNAME?
www TXT "v=spf1 -all"
; working without a problem.
@   TXT "v=spf1 -all"

$ORIGIN that.something.com.au.
$TTL 3600   ; 1 hour
www CNAME   
stuff.overthere.com.au.
@   CNAME   
stuff.overthere.com.au.

; SPF records

; BIND considers this an invalid statement - no corresponding 'A' record - 
conflict with CNAME?
www TXT "v=spf1 -all"
; working without a problem.
@   TXT "v=spf1 -all"

--
Chris.




-- 
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: when does bind calls plugin_destroy ?

2022-11-28 Thread Evan Hunt 
On Tue, Nov 29, 2022 at 12:08:30AM +, Marcus Kool wrote:
> I see random behavior while I do the same test: start named with unmodified
> config file with 2 views (each a plugin instance), run the same 40+ queries
> and reconfigure.  repeat: a few more queries and reconfigure
> 
> 9.16.1 rarely sees plugin_destroy at first reconfigure, 40% at the second
> reconfigure for the first time, 60% at the third reconfigure for the first
> time.  Thereafter, after each plugin_register there is a plugin_destroy.
> 
> 9.18.9 never seen  plugin_destroy at first reconfigure, may take up to 4
> reconfigures for plugin_destroy being called.  Thereafter, after each
> plugin_register there is a plugin_destroy.

That does seem strange. My only guess is that somethng is holding on to a
reference to the original view after the reconfig, and the view isn't
destroyed until that last reference is released.

-- 
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: when does bind calls plugin_destroy ?

2022-11-28 Thread Marcus Kool 


On 28/11/2022 22:07, Evan Hunt wrote:

On Mon, Nov 28, 2022 at 12:53:16PM +, Marcus Kool wrote:

In a test setup there are two instances of the same plugin and everything
works as expected (plugin_register is called twice - once for each view).

However, "rndc reconfig" calls plugin_register again twice but does not call
plugin_destroy...

Are you sure it's not being run?


It is run, but...

I see random behavior while I do the same test: start named with unmodified config file with 2 views (each a plugin instance), run the same 40+ queries and reconfigure.  repeat: a few more queries and 
reconfigure


9.16.1 rarely sees plugin_destroy at first reconfigure, 40% at the second reconfigure for the first time, 60% at the third reconfigure for the first time.  Thereafter, after each plugin_register there 
is a plugin_destroy.


9.18.9 never seen  plugin_destroy at first reconfigure, may take up to 4 
reconfigures for plugin_destroy being called.  Thereafter, after each 
plugin_register there is a plugin_destroy.


So, does anyone know when plugin_destroy is called and perhaps how a plugin
can detect a reconfig is done and can deallocate resources for the plugins
registered at startup?

For each view, "rndc reconfig" is supposed to create and configure a new view,
move the zones from the old view to the new one, and then destroy the one.
The destroy function for the view should clean up plugins:

|   if (view->plugins != NULL && view->plugins_free != NULL) {
|   view->plugins_free(view->mctx, >plugins);
|   }

view->plugins_free is a pointer to ns_plugins_free(), which calls
unload_plugin() for each plugin configured in the view, and that calls
the plugin_destroy() function defined in the module.

If you have the logging level set to debug(1), you should see "unloading
plugin" in your log file when this happens.

Yes, the "unloading plugin" matches the log messages of the plugin.
--
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

Add TXT records for SPF when CNAME exists in same sub-domain

2022-11-28 Thread Chris Liesfield 
Hi All. Hopefully my terminology is correct and I make sense.

We have a main domain "something.com.au" with a few sub-domains, "this",
"that", etc.

For all of our 'A' records in something.com.au, we have specified TXT
records for SPF, however our sub-domains contain CNAMEs only.

It appears TXT and CNAME records for the same string/host cannot co-exist.
We are able to specify an SPF record for the origin only in each sub-domain.

Open to any suggestions on how to get around this issue.

Thanks in advance.

$TTL 3600
@   IN  SOA  something.com.au. bofh.something.com.au.
(
2022112901 ; serial
10800  ; refresh (3 hours)
3600   ; retry (1 hour)
604800 ; expire (1 week)
3600   ; minimum (1 hour)
)
NS  ns1.something.com.au.
NS  ns2.something.com.au.
MX  10 mail.something.com.au.

; A Records

localhost   A   127.0.0.1
www   A   1.2.3.4
@ IN  A   1.2.3.4

; SPF records

; working without a problem.
www TXT "v=spf1 -all"

$ORIGIN this.something.com.au.
$TTL 3600   ; 1 hour
www CNAME   stuff.somewhereelse.com.au.
@   CNAME   stuff.somewhereelse.com.au.

; SPF records

; BIND considers this an invalid statement - no corresponding 'A' record -
conflict with CNAME?
www TXT "v=spf1 -all"
; working without a problem.
@   TXT "v=spf1 -all"

$ORIGIN that.something.com.au.
$TTL 3600   ; 1 hour
www CNAME   stuff.overthere.com.au.
@   CNAME   stuff.overthere.com.au.

; SPF records

; BIND considers this an invalid statement - no corresponding 'A' record -
conflict with CNAME?
www TXT "v=spf1 -all"
; working without a problem.
@   TXT "v=spf1 -all"

-- 
Chris.
-- 
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: Struggling with dnssec-policy timers

2022-11-28 Thread vom513 


> On Nov 28, 2022, at 3:12 PM, vom513  wrote:
> 
> Thanks for the reply and info…
> 
> I would have thought the CDS would be published before the key went active.  
> I.e. there would be a period of TWO DS’es at the parent (I’m assuming the 
> parent supports CDS/CDNSKEY which mine (registrar) does).
> 
> Since the new key goes active, CDS is published, and the old key is retired 
> at the same time - isn’t this going to cause a (lack of coverage/chain of 
> trust) problem ?  I’m really trying to get to a point of a “one command” 
> rollover.  I.e. no API, no uploading DS, etc.  I guess I’ll see tonight when 
> it happens, but I can’t help but feel when the clock strikes I’m going to be 
> missing DS for the new key at the parent.
> 

Sorry to self reply…

So it did “work” as you said Matthijs… I don’t think I necessarily need those 
timers (publish/retire-safety) that I tweaked.  I’d rather use as many bind 
defaults as possible.  I think a big part of my issue was misunderstanding 
“retired” status.  I nuked everything clean and will try this again once 
everything settles down.  Thanks for your patience with me and pointers.

PS: My registrar says they check CDS/CDNSKEY once a day.  Do you think that’s 
reasonable ?  I certainly appreciate them being cognizant/careful of too much 
load on their systems with too many frequent checks, but a day seems long to 
me...
-- 
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: when does bind calls plugin_destroy ?

2022-11-28 Thread Evan Hunt 
On Mon, Nov 28, 2022 at 12:53:16PM +, Marcus Kool wrote:
> In a test setup there are two instances of the same plugin and everything
> works as expected (plugin_register is called twice - once for each view).
> 
> However, "rndc reconfig" calls plugin_register again twice but does not call
> plugin_destroy...

Are you sure it's not being run?

> So, does anyone know when plugin_destroy is called and perhaps how a plugin
> can detect a reconfig is done and can deallocate resources for the plugins
> registered at startup?

For each view, "rndc reconfig" is supposed to create and configure a new view,
move the zones from the old view to the new one, and then destroy the one.
The destroy function for the view should clean up plugins:

|   if (view->plugins != NULL && view->plugins_free != NULL) {
|   view->plugins_free(view->mctx, >plugins);
|   }

view->plugins_free is a pointer to ns_plugins_free(), which calls
unload_plugin() for each plugin configured in the view, and that calls
the plugin_destroy() function defined in the module.

If you have the logging level set to debug(1), you should see "unloading
plugin" in your log file when this happens.

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

copr.fedorainfracloud.org for Fedora 37

2022-11-28 Thread Fred Morris 
Hey there, that was me (a linguistic "sturdy indefensible"), trying to
enable it so I could download the package for Fedora 37.

Don't panic, I comiserate. Somebody made Fedora 37 (Python 3.11,
actually) an Issue for another asyncio reliant project I support so I
thought I'd get ahead of it and bring ShoDoHFlo up to spec. I'll compile
from source.

(Although it would be nice if somebody from Fedora could speak to
support for Dnstap in the available BIND package...)

--

Fred Morris, internet plumber


-- 
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: Struggling with dnssec-policy timers

2022-11-28 Thread vom513 
Thanks for the reply and info…

I would have thought the CDS would be published before the key went active.  
I.e. there would be a period of TWO DS’es at the parent (I’m assuming the 
parent supports CDS/CDNSKEY which mine (registrar) does).

Since the new key goes active, CDS is published, and the old key is retired at 
the same time - isn’t this going to cause a (lack of coverage/chain of trust) 
problem ?  I’m really trying to get to a point of a “one command” rollover.  
I.e. no API, no uploading DS, etc.  I guess I’ll see tonight when it happens, 
but I can’t help but feel when the clock strikes I’m going to be missing DS for 
the new key at the parent.

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

when does bind calls plugin_destroy ?

2022-11-28 Thread Marcus Kool 

Hi,

I am developing a plugin for Bind.  The API has 4 functions: plugin_register, 
plugin_check, plugin_version and plugin_destroy.

In a test setup there are two instances of the same plugin and everything works 
as expected (plugin_register is called twice - once for each view).

However, "rndc reconfig" calls plugin_register again twice but does not call 
plugin_destroy...

This surprises me since the plugin has no knowledge of the reconfig and just 
initializes two more instances of the plugin without destroying the two that it 
created during startup.

So, does anyone know when plugin_destroy is called and perhaps how a plugin can 
detect a reconfig is done and can deallocate resources for the plugins 
registered at startup?

Thanks,

Marcus

--
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: bind-users Digest, Vol 4123, Issue 2

2022-11-28 Thread Matus UHLAR - fantomas 

On 28.11.22 06:00, GAJENDRA CHOUBISA wrote:

Please sir in future no mail send on me sir.


Benny has explained you how to unsubscribe.
It's even shown in the mail you are quoting:


To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/bind-users


visit that page, enter your e-mail address and confirm the unsubscription 
e-mail you will receive.


Confirmation is required to prevent anyone from unsubscribing random person.



On Mon, 28 Nov, 2022, 4:03 am ,  wrote:


Send bind-users mailing list submissions to
bind-users@lists.isc.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/bind-users
or, via email, send a message with subject or body 'help' to
bind-users-requ...@lists.isc.org

You can reach the person managing the list at
bind-users-ow...@lists.isc.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of bind-users digest..."


Today's Topics:

   1. Re: bind-users Digest, Vol 4123, Issue 1 (GAJENDRA CHOUBISA)
   2. Re: bind-users Digest, Vol 4123, Issue 1 (Benny Pedersen)
   3. Re: lame-servers: SERVFAIL unexpected RCODE resolving (Alex)
   4. Struggling with dnssec-policy timers (vom513)


--

Message: 1
Date: Sun, 27 Nov 2022 20:02:34 +0530
From: GAJENDRA CHOUBISA 
To: bind-users@lists.isc.org
Subject: Re: bind-users Digest, Vol 4123, Issue 1
Message-ID:

Content-Type: text/plain; charset="utf-8"

Please no more emails on future sir.

On Sun, 27 Nov, 2022, 5:30 pm ,  wrote:

> Send bind-users mailing list submissions to
> bind-users@lists.isc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isc.org/mailman/listinfo/bind-users
> or, via email, send a message with subject or body 'help' to
> bind-users-requ...@lists.isc.org
>
> You can reach the person managing the list at
> bind-users-ow...@lists.isc.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bind-users digest..."
>
>
> Today's Topics:
>
>1. Re: lame-servers: SERVFAIL unexpected RCODE resolving
>   (Anders L?winger)
>
>
> --
>
> Message: 1
> Date: Sun, 27 Nov 2022 04:04:09 +
> From: Anders L?winger 
> To: bind-users@lists.isc.org
> Subject: Re: lame-servers: SERVFAIL unexpected RCODE resolving
> Message-ID: <1669521774156.1242792614.949363...@abundo.se>
> Content-Type: text/plain; charset="utf-8"
>
> 26-Nov-2022 09:19:13.969 lame-servers: SERVFAIL unexpected RCODE
resolving
> 'lists.opensuse.org/NS/IN': 195.135.221.195#53
> Lots of errors in the zone:
>
>
> https://zonemaster.net/result/ff3dacdfc1e41199
>
>
>
>
> --
> MVH/Regards
> Anders L?winger, Abundo AB, +46 72 206 0322
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
>
https://lists.isc.org/pipermail/bind-users/attachments/20221127/d10d299d/attachment-0001.htm
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> 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
>
>
> --
>
> End of bind-users Digest, Vol 4123, Issue 1
> ***
>
-- next part --
An HTML attachment was scrubbed...
URL: <
https://lists.isc.org/pipermail/bind-users/attachments/20221127/fdf188a4/attachment-0001.htm
>

--

Message: 2
Date: Sun, 27 Nov 2022 16:04:21 +0100
From: Benny Pedersen 
To: bind-users@lists.isc.org
Subject: Re: bind-users Digest, Vol 4123, Issue 1
Message-ID: <3bd213e33a7f5e50e9834d89b8233...@junc.eu>
Content-Type: text/plain; charset=US-ASCII; format=flowed

GAJENDRA CHOUBISA skrev den 2022-11-27 15:32:
> Please no more emails on future sir.

its a self service, no one can help you get more or less mails here

List-Id: BIND Users Mailing List 
List-Unsubscribe: ,

List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,


try using above


--

Message: 3
Date: Sun, 27 Nov 2022 15:54:45 -0500
From: Alex 
To: Anders L?winger , bind-users@lists.isc.org
Subject: Re: lame-servers: SERVFAIL unexpected RCODE resolving
Message-ID:

Content-Type: text/plain;

Re: Struggling with dnssec-policy timers

2022-11-28 Thread Matthijs Mekking 

Hi,

On 27-11-2022 23:32, vom513 wrote:

Hello all,

I’m still having a really hard time understanding and getting my
timings right.  At least I think I am (from the way I’m reading the
status/logs/state files).

I let my current CSK get completely “omnipresent” for all it’s timers
(I’m not even sure if this is really necessary…)  I did a rollover,
and I’m very confused by the various timers I’m seeing.

FYI - I added:

publish-safety 1d; retire-safety 1d;

To the policy “default”.  Other than that and NSEC3, everything is
using values from the “default” policy.  With this, it seems that my
successor key will go active but CDS won’t be published until the
same exact time.  This seems to defeat the purpose of doing an
overlapping rollover.  I would think I would want CDS published
before the new key goes active.  Is the old key going to keep being
used for signing as well ?  I don’t think so because it’s retirement
is also at this exact moment.

The CDS cannot be published before the new key is active. BIND 9
performs a Double DNSKEY rollover, so only after the new key is active,
the DS may be published in the parent (and publishing CDS is an
indication that the DS may be published).



So simultaneously, it seems that I have:

- New key start to be used for signing - CDS is published - Old key
is retired

If I’m reading this right - did my timers screw this up ?  I would
have hoped/assumed that the “default” policy would have timers
arranged as such as there there *should* not be any gaps in coverage
(assuming everything else goes swimmingly…)  I’ll be honest - I’m
kind of feeling like an idiot because of how difficult this seems.


I assume you used "rndc dnssec -rollover" to initiate a rollover 
(because the default policy has key lifetime unlimited).


I don't know what times you expect, but the timings look fine to me. The 
current key 35731 will be retired today (20221128231500 (Mon Nov 28 
18:15:00 2022), and at that time the successor key 3697 will become active.


Because at this point there are two DNSKEY's omnipresent (i.e. known to 
the world), it is safe to swap the DS.


So unless I am misunderstanding, I think all is fine?

Best regards,

Matthijs




Can someone please set me straight ?  I can “nuke” this zone’s keys
and state and start over (which I’ve done several times already).
It’s just getting a bit tiresome because of course when I do this all
the various timers start over.

Here are my state files, 2 keys.  Current and a successor.  Thanks in
advance.

— ; This is the state of key 3697, for acuity.tech. Algorithm: 13 
Length: 256 Lifetime: 0 Predecessor: 35731 KSK: yes ZSK: yes 
Generated: 20221127221000 (Sun Nov 27 17:10:00 2022) Published:

20221127221000 (Sun Nov 27 17:10:00 2022) Active: 20221128231500 (Mon
Nov 28 18:15:00 2022) PublishCDS: 20221128231500 (Mon Nov 28 18:15:00
2022) DNSKEYChange: 20221127221000 (Sun Nov 27 17:10:00 2022) 
ZRRSIGChange: 20221127221000 (Sun Nov 27 17:10:00 2022) KRRSIGChange:

20221127221000 (Sun Nov 27 17:10:00 2022) DSChange: 20221127221000
(Sun Nov 27 17:10:00 2022) DNSKEYState: rumoured ZRRSIGState: hidden 
KRRSIGState: rumoured DSState: hidden GoalState: omnipresent


; This is the state of key 35731, for acuity.tech. Algorithm: 13 
Length: 256 Lifetime: 546573 Successor: 3697 KSK: yes ZSK: yes 
Generated: 20221122152527 (Tue Nov 22 10:25:27 2022) Published:

20221122152527 (Tue Nov 22 10:25:27 2022) Active: 20221122152527 (Tue
Nov 22 10:25:27 2022) Retired: 20221128231500 (Mon Nov 28 18:15:00
2022) Removed: 20221209232000 (Fri Dec  9 18:20:00 2022) DSPublish:
20221123043555 (Tue Nov 22 23:35:55 2022) PublishCDS: 20221124153027
(Thu Nov 24 10:30:27 2022) DNSKEYChange: 20221123163027 (Wed Nov 23
11:30:27 2022) ZRRSIGChange: 20221124153027 (Thu Nov 24 10:30:27
2022) KRRSIGChange: 20221123163027 (Wed Nov 23 11:30:27 2022) 
DSChange: 20221125053555 (Fri Nov 25 00:35:55 2022) DNSKEYState:
omnipresent ZRRSIGState: omnipresent KRRSIGState: omnipresent 
DSState: omnipresent GoalState: hidden



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