Re: Difference in validating behavior 9.18 / 9.20

[John Thurston]

Comparing the ARM for 9.18 
 
and 9.20, I see the same text in both regarding time, RRSIG, and validity


In DNSSEC, every record comes with at least one RRSIG, and each RRSIG 
contains two timestamps: one indicating when it becomes valid, and one 
when it expires. If the validating resolver’s current system time does 
not fall within the two RRSIG timestamps, error messages appear in the 
BIND debug log.


And both 9.18 and 9.20 log the described error message (i.e "verify 
failed . . RRSIG has expired"), but the 9.18 server goes on to log a 
failure message (i.e. "no valid signature found") and the 9.20 server 
returns a validated answer with no errors logged.


If I understand the merge-flow, issue #4586 says an expired RRSIG can be 
ignored when validating if there is a valid RRSIG which will do the job. 
And that this behavior was incorporated into 9.18 with release .27  
Which means the ARM is incomplete. BIND /does/ log an error message when 
it discovers the expired RRSIG, but the validation does not necessarily 
fail with this discovery (which I feel is implied in the ARM).


And that isn't the behavior we were seeing yesterday with 9.18.31/33 :( 
Yes, cdc.gov corrected their RRSIG records, so validation succeeds 
again, but I really need to understand why our 9.18 and 9.20 servers 
behaved differently. We have reasons to be running some 9.18 and some 
9.20, but if the two are going to behave so differently when validating 
responses we will need to re-visit that decision.


Right now, the only way I can think to nail down this behavior is to:

 * delegate a subdomain to myself
 * sign it
 * intentionally publish an expired RRSIG in it

Which makes my next question:

    Will BIND even let me do this? Or will it the automation rake out 
the expired records and refuse to serve them




--
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 2/7/2025 10:56 AM, Darren Ankney wrote:

Hi John,

About the release note you mention with the [GL #4586], this indicates
the Gitlab issue that was fixed and resulted in this release note.
  . . .

I was going to test but it seems that the expired RRSIG was removed
from transfer3.rastglb.cdc.gov

Thank you,
Darren Ankney

On Thu, Feb 6, 2025 at 8:49 PM John Thurston  wrote:

We run both 9.18 and 9.20. We currently have servers running:

9.18.31
9.18.33
9.20.3
9.20.5

The 9.18 and 9.20 validating resolvers behave differently when exposed to 
expired RRSIG records.

Both versions log errors of the type

validating transfer3.rastglb.cdc.gov/A: verify failed due to bad signature 
(keyid=13215): RRSIG has expired

but 9.18 goes on to log

validating transfer3.rastglb.cdc.gov/A: no valid signature found

and returns a SERVFAIL

9.20 returns a fully validated response.

Both servers will return the same set of records (9.18 must be queried with the 
+cd flag) when asked:

transfer3.rastglb.cdc.gov. 5IN  A   198.246.125.128

transfer3.rastglb.cdc.gov. 5IN  RRSIG   A 5 4 5 20250126201505 
20241028201505 13215 rastglb.cdc.gov. 
Kx+n+gsnq0BSko0tl/B3HftLDp1XtiIyImBnlE/dAWgv8VD8xwq4bPns 
CO1R3k3beerK1UB/OpP9VKViRnN+3E4S5fg9vpZOFsDXB4T7PmDg5N12 
PwN26IJC8BrvUnqkPFdYEJGzb+orKHZsa949shODtnAVkttC4NsYvIRq MR8=

transfer3.rastglb.cdc.gov. 5IN  RRSIG   A 8 4 5 20250309140556 
20241209140556 43989 rastglb.cdc.gov. 
XSLHv9vpeY9O0JdfxPzIrkJjU8CkfioV4S0dorRK6GL8DLHjqwpyyM1k 
km2MjF/2lXMjAl+D4+QrNhQFfDo50njTbSKfDsDSWUZC/QffESlw6t6x 
XdCrShtJ6YVYltK1FgWf5xOepxEFLw0pn7I2ntDmXVLwsNkapdKqGugt vzc=

But 9.18 appears to stumble, and consider the presence of 13215 to be the end 
of the validation-road.

I found this in the release notes

 --- 9.18.27 released ---

6374.   [bug]   Skip to next RRSIG if signature has expired or is in
 the future rather than failing immediately. [GL #4586]

But I'm not sure how to interpret it. Is it saying that GL#4586 has left a bug, 
and should be corrected as described? or is it describing the behavior we should 
see in versions >= 9.18.27 ?
-- 
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: Difference in validating behavior 9.18 / 9.20

[Darren Ankney]

Hi John,

About the release note you mention with the [GL #4586], this indicates
the Gitlab issue that was fixed and resulted in this release note.
Here it is: https://gitlab.isc.org/isc-projects/bind9/-/issues/4586
The fix for 9.18 would have been implemented here:
https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8749 which
would have been a backport from here:
https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8746 which
would have fixed the problem in main.

I was going to test but it seems that the expired RRSIG was removed
from transfer3.rastglb.cdc.gov

Thank you,
Darren Ankney

On Thu, Feb 6, 2025 at 8:49 PM John Thurston  wrote:
>
> We run both 9.18 and 9.20. We currently have servers running:
>
> 9.18.31
> 9.18.33
> 9.20.3
> 9.20.5
>
> The 9.18 and 9.20 validating resolvers behave differently when exposed to 
> expired RRSIG records.
>
> Both versions log errors of the type
>
> validating transfer3.rastglb.cdc.gov/A: verify failed due to bad signature 
> (keyid=13215): RRSIG has expired
>
> but 9.18 goes on to log
>
> validating transfer3.rastglb.cdc.gov/A: no valid signature found
>
> and returns a SERVFAIL
>
> 9.20 returns a fully validated response.
>
> Both servers will return the same set of records (9.18 must be queried with 
> the +cd flag) when asked:
>
> transfer3.rastglb.cdc.gov. 5IN  A   198.246.125.128
>
> transfer3.rastglb.cdc.gov. 5IN  RRSIG   A 5 4 5 20250126201505 
> 20241028201505 13215 rastglb.cdc.gov. 
> Kx+n+gsnq0BSko0tl/B3HftLDp1XtiIyImBnlE/dAWgv8VD8xwq4bPns 
> CO1R3k3beerK1UB/OpP9VKViRnN+3E4S5fg9vpZOFsDXB4T7PmDg5N12 
> PwN26IJC8BrvUnqkPFdYEJGzb+orKHZsa949shODtnAVkttC4NsYvIRq MR8=
>
> transfer3.rastglb.cdc.gov. 5IN  RRSIG   A 8 4 5 20250309140556 
> 20241209140556 43989 rastglb.cdc.gov. 
> XSLHv9vpeY9O0JdfxPzIrkJjU8CkfioV4S0dorRK6GL8DLHjqwpyyM1k 
> km2MjF/2lXMjAl+D4+QrNhQFfDo50njTbSKfDsDSWUZC/QffESlw6t6x 
> XdCrShtJ6YVYltK1FgWf5xOepxEFLw0pn7I2ntDmXVLwsNkapdKqGugt vzc=
>
> But 9.18 appears to stumble, and consider the presence of 13215 to be the end 
> of the validation-road.
>
> I found this in the release notes
>
> --- 9.18.27 released ---
>
> 6374.   [bug]   Skip to next RRSIG if signature has expired or is in
> the future rather than failing immediately. [GL #4586]
>
> But I'm not sure how to interpret it. Is it saying that GL#4586 has left a 
> bug, and should be corrected as described? or is it describing the behavior 
> we should see in versions >= 9.18.27 ?
>
> --
> --
> Do things because you should, not just because you can.
>
> John Thurston907-465-8591
> john.thurs...@alaska.gov
> Department of Administration
> State of Alaska
>
> --
> 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: Primary/Secondary

[Bjørn Mork via bind-users]

Greg Choules via bind-users  writes:

> What's a "primary master" as opposed to (presumably?) a "secondary master"?

Some servers will be both masters and slaves when using hierarchical
replication.  It is useful to define the root of the tree as "primary
master" and refer to any upstream from a "slave" as "master".

IMHO, "primary"and "secondary" alone are confusing terms in this
context.  But I guess it's possible to make the distinction clearer by
adding more text, so it's not a big deal.

Personally I am mostly worried about the potentional number of technical
terms we have not yet identified as "bad".  The set of words we may have
to replace in the future is virtually unlimited.  Most colours are
obviously risky.  So are any terms which could be used to describe a
person or body part. In any language if we're going to be translation
safe.

Not sure where to draw the line.  Are the 2024 rules final, or are we
going to continue this whack-a-mole game forever?


Bjørn
-- 
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

dnsviz.net: has errors; select the "Denial of existence" DNSSEC option to see them.

[Hans Mayer via bind-users]

Dear All,

I realized that dnsviz.net is showing me 5 errors for some domain names, 
even some which do not exist.

This is not only for one domain. I see this for some domains I manage.
I am running BIND 9.18.34-dev (Extended Support Version) 

This is for example such an error message at dnsviz:
ok7gd.aw5sp.iiasa.ac.at/A has errors; select the "Denial of existence" 
DNSSEC option to see them.


Searching for solutions didn't really help.
Any idea how to solve this issue ? Or where to dig deeper to find a 
solution ?


Kind regards
Hans

--




--
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: dnsviz.net: has errors; select the "Denial of existence" DNSSEC option to see them.

[Taavi Eomäe via bind-users]

Hi,

If you select the "Denial of existence" under options, then you will see 
the exact details behind those errors.


It seems like your NSEC3 iterations count is not 0, but it should be 0 
to alleviate computational burdens. See RFC9276, Sec. 3.1.



Best regards
Taavi



smime.p7s
Description: S/MIME Cryptographic 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