dnssec - some NSEC3 salts destroy NSEC3 validation #14226

git-tec · 2024-05-22T07:50:43Z

git-tec
May 22, 2024

[] This is not a support question, I have read about opensource and will send support questions to the IRC channel, Github Discussions or the mailing list.
[] I have read and understood the 'out in the open' support policy

Program: Authoritative
Issue type: Bug report

Short description

As soon as we use specific salts in our DNSSEC zones, NSEC3 validation no longer works. We create ECDSAP256SHA256 keys. We work with a hidden master that provides the DNSSEC material, and we then transfer this via AXFR to the public name servers. The same PowerDNS Authoritative version is installed on all servers.

Environment

Operating system: Debian 11
Software version: 4.8.2
Software source: PowerDNS repository

Steps to reproduce

You take any secure zone and set one of the two NSEC3 salts

pdnsutil set-nsec3 DOMAIN.TLD '1 0 0 a70a2c4321f88fb4'
or
pdnsutil set-nsec3 DOMAIN.TLD '1 0 0 d70a2c7321f88fb4'

Afterwards, transfer it to the name servers via AXFR. After that, NSEC3 validation is no longer possible.

Other information

If you use the following salt or none at all, there are no problems.

pdnsutil set-nsec3 DOMAIN.TLD '1 0 0 7c75470678d947fe'
pdnsutil set-nsec3 DOMAIN.TLD '1 0 0 -'

This is our first bug report here, so please forgive us if any information is missing. We are happy to provide additional details if needed.

Habbie · 2024-05-22T08:42:17Z

Habbie
May 22, 2024
Maintainer

can you also provide a domain name for which this is true given that salt?

0 replies

Habbie · 2024-05-22T08:42:34Z

Habbie
May 22, 2024
Maintainer

and can you show the validation failure in some way?

0 replies

git-tec · 2024-05-22T09:34:19Z

git-tec
May 22, 2024
Author

I'll try, we're relatively new to this dnssec-topic. Unfortunately, with the regular dig command, we don't know how to demonstrate this accurately enough.

We're testing it with the Zonemaster engine because, for example, DNSViz did not show the error.

You can see the result of a test here: https://zonemaster.fi/result/cfb21f4fff62dcc1

I have created a test domain for you; you can query it live.

Domain: 1713972008a2.de @ns1.dov4.de / ns2.dov4.de

additional details:

Metadata items:
ALLOW-AXFR-FROM 49.13.70.254
ALLOW-AXFR-FROM 2a01:4f8:c012:a41b::1
ALSO-NOTIFY 49.13.70.254
ALSO-NOTIFY 2a01:4f8:c012:a41b::1
NSEC3PARAM 1 0 0 d70a2c7321f88fb4
Zone has hashed NSEC3 semantics, configuration: 1 0 0 d70a2c7321f88fb4
keys:
ID = 471 (ZSK), flags = 256, tag = 11883, algo = 13, bits = 256 Active Published ( ECDSAP256SHA256 )
ID = 470 (KSK), flags = 257, tag = 36465, algo = 13, bits = 256 Active Published ( ECDSAP256SHA256 )
KSK DNSKEY = 1713972008a2.de. IN DNSKEY 257 3 13 gL3nVKmxzkEB3Wzl1wjc7vMfqVsZvAF2Y2bFwtBljm/P6IGWPSwmctF+0jMWFjWRUSU1AX4kBCq+VjnjRZ9dMQ== ; ( ECDSAP256SHA256 )
DS = 1713972008a2.de. IN DS 36465 13 2 77fe3e7da72386c3ba581fdd8c73fe3ae7c0e50022404d7fe9b66e2d20b6123d ; ( SHA256 digest )
DS = 1713972008a2.de. IN DS 36465 13 4 506cf0f63161c20f4c364348c4ce9266412dbaca9f7c18d483db0a974c671a9f06297fb3102e80eea75fba81b9a9f915 ; ( SHA-384 digest )

0 replies

omoerbeek · 2024-05-22T11:31:41Z

omoerbeek
May 22, 2024
Maintainer

I setup a recursor forwarding the domain to 49.13.70.254, added a trustanchor as the domain does not seem to be published.
Following dig succeeds and validates (note the ad flag):

$ mydig 1713972008a2.de +dnssec

; <<>> DiG 9.18.26 <<>> +retry -p 5301 @127.0.0.1 1713972008a2.de +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62962
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;1713972008a2.de.               IN      A

;; ANSWER SECTION:
1713972008a2.de.        900     IN      A       116.203.213.72
1713972008a2.de.        900     IN      A       116.202.9.166
1713972008a2.de.        900     IN      A       116.202.21.136
1713972008a2.de.        900     IN      RRSIG   A 13 2 900 20240530000000 20240509000000 11883 1713972008a2.de. /i5w1SNsXFgcOEa3vZnyWSjAHSQU1RUa4lwSa1SS8Rx7wIJOjbLdKsm3 PLPqDKSHCJ4DWzdqfIiZCnLiar11AA==

;; Query time: 62 msec
;; SERVER: 127.0.0.1#5301(127.0.0.1) (UDP)
;; WHEN: Wed May 22 13:28:05 CEST 2024
;; MSG SIZE  rcvd: 203

A query for nonexistent.1713972008a2.de fails:

$ mydig nonexistent.1713972008a2.de +dnssec

; <<>> DiG 9.18.26 <<>> +retry -p 5301 @127.0.0.1 nonexistent.1713972008a2.de +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 53991
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;nonexistent.1713972008a2.de.   IN      A

;; Query time: 427 msec
;; SERVER: 127.0.0.1#5301(127.0.0.1) (UDP)
;; WHEN: Wed May 22 13:29:30 CEST 2024
;; MSG SIZE  rcvd: 56

Part of trace:

May 22 13:29:30 [1] nonexistent.1713972008a2.de: Nameservers: -49.13.70.254:53(25.77ms)
May 22 13:29:30 [1] nonexistent.1713972008a2.de: Resolved '1713972008a2.de' NS (empty) to: 49.13.70.254
May 22 13:29:30 [1] nonexistent.1713972008a2.de: Trying IP 49.13.70.254:53, asking 'nonexistent.1713972008a2.de|A'
May 22 13:29:30 [1] nonexistent.1713972008a2.de: Got 7 answers from (empty) (49.13.70.254), rcode=3 (Non-Existent domain), aa=1, in 42ms
May 22 13:29:30 [1] nonexistent.1713972008a2.de: Accept answer '1713972008a2.de|SOA|ns1.dov4.de. hostmaster.greenmark-it.de. 1716369800 14400 3600 604800 3600' from '1713972008a2.de' nameservers? ttl=3600, place=2 YES! - This answer was received from a server we forward to.
May 22 13:29:30 [1] nonexistent.1713972008a2.de: Accept answer '1713972008a2.de|RRSIG|SOA 13 2 86400 20240530000000 20240509000000 11883 1713972008a2.de. jg+2euchFOyUSw2otZnZFIW9oQFFVJYSz2fqfWnDxkGWH7wBcErpz6dxUil4N6IjCc5sZcF7DkUQk5RQe5FXfw==' from '1713972008a2.de' nameservers? ttl=3600, place=2 RRSIG - separate
May 22 13:29:30 [1] nonexistent.1713972008a2.de: Accept answer '9m9cm3t5v861srlg30dd4gnitortdga4.1713972008a2.de|NSEC3|1 0 0 d70a2c7321f88fb4 GD8JPTNFH6SJJBSFP1L3IJK5A6IPU461 A NS SOA MX TXT AAAA RRSIG DNSKEY NSEC3PARAM' from '1713972008a2.de' nameservers? ttl=3600, place=2 YES! - This answer was received from a server we forward to.
May 22 13:29:30 [1] nonexistent.1713972008a2.de: Accept answer '9m9cm3t5v861srlg30dd4gnitortdga4.1713972008a2.de|RRSIG|NSEC3 13 3 3600 20240530000000 20240509000000 11883 1713972008a2.de. bpI4iVx1dzZyAtxHGJX0ghevSPirgEMdHbZVBc5itrh8vTShndkJ0/kj2X6ULBdLKDbwQEOda+GxAkYsfG3+Pg==' from '1713972008a2.de' nameservers? ttl=3600, place=2 RRSIG - separate
May 22 13:29:30 [1] nonexistent.1713972008a2.de: Accept answer '8j8p5cvlk7pjeqp77tc6sac993qp87b5.1713972008a2.de|NSEC3|1 0 0 d70a2c7321f88fb4 9M9CM3T5V861SRLG30DD4GNITORTDGA4 TXT RRSIG' from '1713972008a2.de' nameservers? ttl=3600, place=2 YES! - This answer was received from a server we forward to.
May 22 13:29:30 [1] nonexistent.1713972008a2.de: Accept answer '8j8p5cvlk7pjeqp77tc6sac993qp87b5.1713972008a2.de|RRSIG|NSEC3 13 3 3600 20240530000000 20240509000000 11883 1713972008a2.de. KVDDO6PVTWQA+BtFA/PYq68NTGK5TwUUCpPIFQPR1cNKXAUKhmYVl00l8r0iT01Tl+NfHDd48bnfF9N1BQRtfw==' from '1713972008a2.de' nameservers? ttl=3600, place=2 RRSIG - separate
May 22 13:29:30 [1] nonexistent.1713972008a2.de: OPT answer '.' from '1713972008a2.de' nameservers
May 22 13:29:30 [1] 1713972008a2.de: Got status Secure for name 1713972008a2.de
May 22 13:29:30 [1] nonexistent.1713972008a2.de: Got initial zone status Secure for record 1713972008a2.de|SOA
May 22 13:29:30 [1] nonexistent.1713972008a2.de: Validating non-additional SOA record for 1713972008a2.de
May 22 13:29:30 [1] 1713972008a2.de: Retrieving DNSKEYs
May 22 13:29:30 [1]  1713972008a2.de: Got TA
May 22 13:29:30 [1]  QM 1713972008a2.de: doResolve
May 22 13:29:30 [1]  1713972008a2.de: Wants DNSSEC processing, auth data required by query for DNSKEY
May 22 13:29:30 [1]  1713972008a2.de: Found cache hit for DNSKEY: 257 3 13 gL3nVKmxzkEB3Wzl1wjc7vMfqVsZvAF2Y2bFwtBljm/P6IGWPSwmctF+0jMWFjWRUSU1AX4kBCq+VjnjRZ9dMQ==[ttl=3593] 256 3 13 qQa+5g9fRtE2EEsvcqdHcOzhWjjKjmsPlHbS2As8Lb89vrMV7o1rMUCOEMht6QjDalVUn0Aa55DrIFdfwhsWFA==[ttl=3593] 
May 22 13:29:30 [1]  1713972008a2.de: Updating validation state with cache content for 1713972008a2.de to Secure
May 22 13:29:30 [1]  QM 1713972008a2.de: Step0 Found in cache
May 22 13:29:30 [1] 1713972008a2.de: Retrieved 2 DNSKeys, state is Secure
May 22 13:29:30 [1] 1713972008a2.de: Going to validate 1 record contents with 1 sigs and 2 keys for 1713972008a2.de|SOA
May 22 13:29:30 [1] 1713972008a2.de: Signature by key with tag 11883 and algorithm ECDSAP256SHA256 was valid
May 22 13:29:30 [1] 1713972008a2.de: Validated 1713972008a2.de/SOA
May 22 13:29:30 [1] 1713972008a2.de: Secure!
May 22 13:29:30 [1] nonexistent.1713972008a2.de: Validation result is Secure, current state is Indeterminate
May 22 13:29:30 [1] nonexistent.1713972008a2.de: Validation state was Indeterminate, state update is Secure, validation state is now Secure
May 22 13:29:30 [1] nonexistent.1713972008a2.de: Got initial zone status Secure for record 9m9cm3t5v861srlg30dd4gnitortdga4.1713972008a2.de|NSEC3
May 22 13:29:30 [1] nonexistent.1713972008a2.de: Validating non-additional NSEC3 record for 9m9cm3t5v861srlg30dd4gnitortdga4.1713972008a2.de
May 22 13:29:30 [1] 1713972008a2.de: Retrieving DNSKEYs
May 22 13:29:30 [1]  1713972008a2.de: Got TA
May 22 13:29:30 [1]  QM 1713972008a2.de: doResolve
May 22 13:29:30 [1]  1713972008a2.de: Wants DNSSEC processing, auth data required by query for DNSKEY
May 22 13:29:30 [1]  1713972008a2.de: Found cache hit for DNSKEY: 257 3 13 gL3nVKmxzkEB3Wzl1wjc7vMfqVsZvAF2Y2bFwtBljm/P6IGWPSwmctF+0jMWFjWRUSU1AX4kBCq+VjnjRZ9dMQ==[ttl=3593] 256 3 13 qQa+5g9fRtE2EEsvcqdHcOzhWjjKjmsPlHbS2As8Lb89vrMV7o1rMUCOEMht6QjDalVUn0Aa55DrIFdfwhsWFA==[ttl=3593] 
May 22 13:29:30 [1]  1713972008a2.de: Updating validation state with cache content for 1713972008a2.de to Secure
May 22 13:29:30 [1]  QM 1713972008a2.de: Step0 Found in cache
May 22 13:29:30 [1] 1713972008a2.de: Retrieved 2 DNSKeys, state is Secure
May 22 13:29:30 [1] 9m9cm3t5v861srlg30dd4gnitortdga4.1713972008a2.de: Going to validate 1 record contents with 1 sigs and 2 keys for 9m9cm3t5v861srlg30dd4gnitortdga4.1713972008a2.de|NSEC3
May 22 13:29:30 [1] 9m9cm3t5v861srlg30dd4gnitortdga4.1713972008a2.de: Signature by key with tag 11883 and algorithm ECDSAP256SHA256 was NOT valid
May 22 13:29:30 [1] 9m9cm3t5v861srlg30dd4gnitortdga4.1713972008a2.de: signature invalid
May 22 13:29:30 [1] Bogus - No valid RRSIG!

0 replies

git-tec · 2024-05-22T12:11:29Z

git-tec
May 22, 2024
Author

Oh, right, that's an important piece of information I forgot to mention. The resolution of non-existent subdomains no longer works. This happens whenever there isn't an explicit entry, but only a wildcard. In our tests, these were always A or AAAA records.

0 replies

omoerbeek · 2024-05-22T12:12:57Z

omoerbeek
May 22, 2024
Maintainer

Can you attach the zone file for the testdomain?

0 replies

git-tec · 2024-05-22T12:24:37Z

git-tec
May 22, 2024
Author

I hope that is sufficient.

zonefile-1713972008a2_de.txt

0 replies

omoerbeek · 2024-05-22T12:52:44Z

omoerbeek
May 22, 2024
Maintainer

Did you rectify the zone after setting/changing NSEC3 parameters?

$ pdnsutil rectify-zone 1713972008a2.de

0 replies

git-tec · 2024-05-22T13:00:20Z

git-tec
May 22, 2024
Author

Sorry, I sent you the zone file from the hidden master. The rectify is done through the AXFR. We don't perform a rectify on the hidden master.

Here is the zone file from the public name server again.

zonefile-primary_1713972008a2_de.txt

0 replies

omoerbeek · 2024-05-22T13:16:33Z

omoerbeek
May 22, 2024
Maintainer

Hmm, this is getting a bit out of my area of expertise. I do note that last file lacks a NSEC3PARAM record.

0 replies

Habbie · 2024-05-22T13:17:56Z

Habbie
May 22, 2024
Maintainer

Hmm, this is getting a bit out of my area of expertise. I do note that last file lacks a NSEC3PARAM record.

pdnsutil list-zone exports the records table. NSEC3PARAM is stored in domainmetadata. NSEC3s are generated from records.ordername. Neither show up in list-zone.

0 replies

omoerbeek · 2024-05-22T13:19:48Z

omoerbeek
May 22, 2024
Maintainer

I now wonder how a secondary server serves the NSEC3PARAM record

0 replies

Habbie · 2024-05-22T13:25:54Z

Habbie
May 22, 2024
Maintainer

@git-tec can you 'dig axfr' from the hidden signing primary, and from the secondary, and paste both?

0 replies

git-tec · 2024-05-22T13:55:09Z

git-tec
May 22, 2024
Author

yes, in the attachment

axfr-secondary.txt
axfr-hidden_primary.txt

0 replies

Habbie · 2024-05-23T06:52:40Z

Habbie
May 23, 2024
Maintainer

Interestingly, those are identical. If you do a dig that causes validation failure, do the NSEC3s in that response match those in your AXFRs?

0 replies

Habbie · 2024-05-23T08:25:41Z

Habbie
May 23, 2024
Maintainer

Shouldn't at least 3 RRSIGs be returned for a non-existent record?

a non-existence proof involves up to 3 NSEC3s. In this case, the NSEC3 9m9cm..gd8jpt

proves the existence of 1713972008a2.de (that name hashes to 9mcm)
proves the absence of notexist (that name hashes to aej4, which is between 9mcm and gd8)
proves the absence of * (which hashes to f9aeb, also between 9mcm and gd8)

However, the NSEC3 9mcm..gd8jpt is not present in the AXFRs. There we see

9m9cm .. ehsu0
ehsu0 .. gd8jp

so, whatever ehsu0 is the hash of, is being mis-handled here. I'll go investigate now.

0 replies

Habbie · 2024-05-23T08:45:41Z

Habbie
May 23, 2024
Maintainer

so, whatever ehsu0 is the hash of, is being mis-handled here. I'll go investigate now.

that's _domainkey.1713972008a2.de.

Can you, on your hidden primary, SELECT name,ordername FROM records where name='_domainkey.1713972008a2.de' please?

0 replies

git-tec · 2024-05-23T08:53:39Z

git-tec
May 23, 2024
Author

no result.

there are only a *._domainkey.1713972008a2.de record

0 replies

Habbie · 2024-05-23T08:54:20Z

Habbie
May 23, 2024
Maintainer

Did you rectify, as @omoerbeek asked in #14220 (comment) ?

0 replies

Habbie · 2024-05-23T09:15:28Z

Habbie
May 23, 2024
Maintainer

Can you, on your hidden primary, SELECT name,ordername FROM records where name='_domainkey.1713972008a2.de' please?

and can you do the same query on your secondary?

0 replies

git-tec · 2024-05-23T11:00:37Z

git-tec
May 23, 2024
Author

We have done some further research and testing.

Basically, on our hidden master, the max-ent-entries is enabled, but on the secondaries, max-ent-entries=0, so it is disabled.

If we also disable max-ent-entries (max-ent-entries=0) on the hidden master, it refuses the AXFR -> AXFR-out zone 'DOMAIN.TLD', client 'XXXX', zone has too many empty non-terminals, aborting AXFR.

We have disabled this option on our secondaries because otherwise, the behavior of wildcard queries changes significantly; see #7381 / #7292

The question is, however, what does all this have to do with the salt? This current issue does not arise with a "-" salt.

0 replies

Habbie · 2024-05-23T11:01:20Z

Habbie
May 23, 2024
Maintainer

but on the secondaries, max-ent-entries=0, so it is disabled.

ah! that fits -my- testing, where deleting the ENT on the secondary reproduces your issue.

0 replies

git-tec · 2024-05-23T11:03:46Z

git-tec
May 23, 2024
Author

If we enable max-ent-entries on both sides, it works with all salts. Is it intentional that non-secure zones also get ENTs?

0 replies

Habbie · 2024-05-23T11:10:06Z

Habbie
May 23, 2024
Maintainer

The question is, however, what does all this have to do with the salt? This current issue does not arise with a "-" salt.

with nsec3 settings 1 0 0 -, the _domainkey entry hashes to 9sfttujvqrlsf5463hchr7l3ipcnv4kl

the partial nsec3 chain that fits into is

98m0n3l4i7kkopbaf5gv3hm08qk0hq8f
9sfttujvqrlsf5463hchr7l3ipcnv4kl
ijnlir8jmekbae5n0sdju8667706f5r7

and noexist hashes to 9tamim23nuf1v44o8c7c34ktmvi1l801, which means that on the primary, with max-ent-entries=high, I get 9sfttujvqrlsf5463hchr7l3ipcnv4kl..IJNLIR8JMEK but on the secondary with max-ent-entries=0, I get 98m0n3l4i7kkopbaf5gv3hm08qk0hq8f.1713972008a2..IJNLIR8JMEK, so the issue should in fact arise.

0 replies

Habbie · 2024-05-23T11:10:59Z

Habbie
May 23, 2024
Maintainer

We have disabled this option on our secondaries because otherwise, the behavior of wildcard queries changes significantly

Disabling ENTs breaks DNSSEC. The wildcard behaviour you want is fundamentally incompatible with DNSSEC (and DNS, really, but without DNSSEC you mostly get away with it).

If we enable max-ent-entries on both sides, it works with all salts. Is it intentional that non-secure zones also get ENTs?

yes

0 replies

Habbie · 2024-05-23T11:11:54Z

Habbie
May 23, 2024
Maintainer

I'm closing this ticket now as the problem was a misconfiguration and not a software bug. We can continue in https://github.com/PowerDNS/pdns/discussions if you like - in fact, shall I convert this issue to a discussion thread?

0 replies

git-tec · 2024-05-23T11:43:36Z

git-tec
May 23, 2024
Author

Yes, we can convert it into a discussion.

Do we have a way to compensate you for the effort?

We just find it very strange that the combination with DNSSEC and the wildcard works with Cloudflare.

dig xyz.meine-testdomain.de A +dnssec @wally.ns.cloudflare.com

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> xyz.meine-testdomain.de A +dnssec @wally.ns.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22987
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;xyz.meine-testdomain.de.       IN      A

;; ANSWER SECTION:
xyz.meine-testdomain.de. 300    IN      A       1.1.1.1
xyz.meine-testdomain.de. 300    IN      RRSIG   A 13 3 300 20240524124243 20240522104243 34505 meine-testdomain.de. n4FcrbqaJD68s0Pi8PTj2h6UBQn92AjkC6Q/dCexj4Vq9tInwiaJCGnq MylXJZH2xebUUF4tbFJhcYKsxoeA1A==

dig doesnotexist.meine-testdomain.de A +dnssec @wally.ns.cloudflare.com

; <<>> DiG 9.18.18-0ubuntu0.22.04.2-Ubuntu <<>> doesnotexist.meine-testdomain.de A +dnssec @wally.ns.cloudflare.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 769
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;doesnotexist.meine-testdomain.de. IN   A

;; ANSWER SECTION:
doesnotexist.meine-testdomain.de. 300 IN A      1.1.1.1
doesnotexist.meine-testdomain.de. 300 IN RRSIG  A 13 3 300 20240524124203 20240522104203 34505 meine-testdomain.de. juaGE5X6nHwLJtAzlzrwfbg48COdoZVJ3S0O7vxyZ69PsMmIUab6XKZM 5ZbUA2/iEfcIaREjePXwzmKebbjvLQ=

1 reply

Habbie May 23, 2024
Maintainer

We just find it very strange that the combination with DNSSEC and the wildcard works with Cloudflare.

Cloudflare uses NSEC in a very different way, described in https://datatracker.ietf.org/doc/draft-ietf-dnsop-compact-denial-of-existence/. Because their NSECs do not tell you anything about the shape of the zone at all, they get away with implementing wildcards incorrectly, and can do what users (like you) expect instead.

git-tec · 2024-05-23T11:52:16Z

git-tec
May 23, 2024
Author

Okay, thanks for the report.

But we still don't understand why it works with NSEC3 when we set the salt to a minus ("-")? we have set it for the domain 1713972008a2.de with secondary max-ent-entries=0.

2 replies

Habbie May 23, 2024
Maintainer

can you show that?

git-tec May 23, 2024
Author

sure, with another domain -> 1714397044a5b4.de

Metadata items:
        ALLOW-AXFR-FROM 49.13.70.254
        ALLOW-AXFR-FROM 2a01:4f8:c012:a41b::1
        ALSO-NOTIFY     49.13.70.254
        ALSO-NOTIFY     2a01:4f8:c012:a41b::1
        NSEC3PARAM      1 0 0 -
Zone has hashed NSEC3 semantics, configuration: 1 0 0 -
keys:
ID = 1251 (ZSK), flags = 256, tag = 54764, algo = 13, bits = 256          Active         Published  ( ECDSAP256SHA256 )
ID = 1250 (KSK), flags = 257, tag = 12270, algo = 13, bits = 256          Active         Published  ( ECDSAP256SHA256 )
KSK DNSKEY = 1714397044a5b4.de. IN DNSKEY 257 3 13 gZEF3rSjHTD574k+fwB1xhrkeTbb8chQ14Tb83x/L/vJ0d2YFnRkUuwB0tfnvKLSwBSgU5EQlMZ5h+/zcVD1sA== ; ( ECDSAP256SHA256 )
DS = 1714397044a5b4.de. IN DS 12270 13 2 41c903a6a6b95e83b1d083eb674f5a298a623360e855ed9fc51dce78a02e42ec ; ( SHA256 digest )
DS = 1714397044a5b4.de. IN DS 12270 13 4 9f2c724a745371c412f0a1152716370e5f47cf983a6cf97d5582faa343a60c291af0603437cab83be1af634b8eca49a7 ; ( SHA-384 digest )

dig

dig @127.0.0.1 -p 1053 notexist.1714397044a5b4.de A +dnssec

; <<>> DiG 9.16.48-Debian <<>> @127.0.0.1 -p 1053 notexist.1714397044a5b4.de A +dnssec
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 5925
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;notexist.1714397044a5b4.de.    IN      A

;; AUTHORITY SECTION:
1714397044a5b4.de.      86400   IN      SOA     ns1.dov4.de. hostmaster.greenmark-it.de. 1716422400 14400 3600 604800 86400
1714397044a5b4.de.      86400   IN      RRSIG   SOA 13 2 86400 20240606000000 20240516000000 54764 1714397044a5b4.de. ryRx8wz0q0YWFI/PN5L0gNgFIWc2+071E8h5lrFZXj5l3gdOtliw9yPV SznSGQD6HiPoWj+AOMMZy8ONrr9sng==
obtvgm6sn0lemkno856vtl96ikgrc477.1714397044a5b4.de. 86400 IN NSEC3 1 0 0 - P9M1L18I4K2U7R3HV2M6285OLEGS8V1N A NS SOA MX TXT AAAA RRSIG DNSKEY NSEC3PARAM
obtvgm6sn0lemkno856vtl96ikgrc477.1714397044a5b4.de. 86400 IN RRSIG NSEC3 13 3 86400 20240606000000 20240516000000 54764 1714397044a5b4.de. CFfXifQ13oIZPBel7qKyDsvXb2jXHzw71gzrztxfWItKgSRjbdF8HqEG KkxxhbOI+jtIs+Qh+vg92oDhAVeCxg==
jo60oiob8kjp8h4ike86j5bn4m5kciq6.1714397044a5b4.de. 86400 IN NSEC3 1 0 0 - KQ1FQOQIM7IPF4F0U6Q6B574JC5JJHA7 TXT RRSIG
jo60oiob8kjp8h4ike86j5bn4m5kciq6.1714397044a5b4.de. 86400 IN RRSIG NSEC3 13 3 86400 20240606000000 20240516000000 54764 1714397044a5b4.de. LO9BSFg30Xg6uMl09gleq5+HXPVRDO08mhuxWUxyx+ykWsczIPbe2IN3 zTKl1CgGq2Rv+/wu9BDgDMTf2Gi5Lg==
4peo7p1os1at6d2089ckbal47ouvgf2i.1714397044a5b4.de. 86400 IN NSEC3 1 0 0 - 9MPNSICN1IMRSISENUDAIH6O512GRBQF TXT RRSIG
4peo7p1os1at6d2089ckbal47ouvgf2i.1714397044a5b4.de. 86400 IN RRSIG NSEC3 13 3 86400 20240606000000 20240516000000 54764 1714397044a5b4.de. u5tvkjPLOpqfyr6XQFp+kjHdOCZL/rTCKP7o/XUZ6rIRwNwfrNCyVPGa TpAF4FKwEGPwKAG7d2v9FxI9Jx4Vow==

;; Query time: 28 msec
;; SERVER: 127.0.0.1#1053(127.0.0.1)
;; WHEN: Thu May 23 12:30:19 UTC 2024
;; MSG SIZE  rcvd: 814

Result im Zonemaster -> https://zonemaster.fi/result/18aecb3593381bc3

omoerbeek · 2024-05-23T12:43:26Z

omoerbeek
May 23, 2024
Maintainer

I suspect this works by accident, depending on if the NSEC3 records needed for the proof are the same or distinct, something that is influenced by the seed (or the number of iterations for that matter).

0 replies

omoerbeek · 2024-05-23T13:08:42Z

omoerbeek
May 23, 2024
Maintainer

On a side note, https://datatracker.ietf.org/doc/rfc9276/ recommends to use no salt and iteration count 0.

0 replies

dnssec - some NSEC3 salts destroy NSEC3 validation #14226

git-tec May 22, 2024

Short description

Environment

Steps to reproduce

Other information

Replies: 31 comments · 3 replies

Habbie May 22, 2024 Maintainer

Habbie May 22, 2024 Maintainer

git-tec May 22, 2024 Author

omoerbeek May 22, 2024 Maintainer

git-tec May 22, 2024 Author

omoerbeek May 22, 2024 Maintainer

git-tec May 22, 2024 Author

omoerbeek May 22, 2024 Maintainer

git-tec May 22, 2024 Author

omoerbeek May 22, 2024 Maintainer

Habbie May 22, 2024 Maintainer

omoerbeek May 22, 2024 Maintainer

Habbie May 22, 2024 Maintainer

git-tec May 22, 2024 Author

Habbie May 23, 2024 Maintainer

Habbie May 23, 2024 Maintainer

Habbie May 23, 2024 Maintainer

git-tec May 23, 2024 Author

Habbie May 23, 2024 Maintainer

Habbie May 23, 2024 Maintainer

git-tec May 23, 2024 Author

Habbie May 23, 2024 Maintainer

git-tec May 23, 2024 Author

Habbie May 23, 2024 Maintainer

Habbie May 23, 2024 Maintainer

Habbie May 23, 2024 Maintainer

git-tec May 23, 2024 Author

Habbie May 23, 2024 Maintainer

git-tec May 23, 2024 Author

Habbie May 23, 2024 Maintainer

git-tec May 23, 2024 Author

omoerbeek May 23, 2024 Maintainer

omoerbeek May 23, 2024 Maintainer

git-tec
May 22, 2024

Replies: 31 comments 3 replies

Habbie
May 22, 2024
Maintainer

Habbie
May 22, 2024
Maintainer

git-tec
May 22, 2024
Author

omoerbeek
May 22, 2024
Maintainer

git-tec
May 22, 2024
Author

omoerbeek
May 22, 2024
Maintainer

git-tec
May 22, 2024
Author

omoerbeek
May 22, 2024
Maintainer

git-tec
May 22, 2024
Author

omoerbeek
May 22, 2024
Maintainer

Habbie
May 22, 2024
Maintainer

omoerbeek
May 22, 2024
Maintainer

Habbie
May 22, 2024
Maintainer

git-tec
May 22, 2024
Author

Habbie
May 23, 2024
Maintainer

Habbie
May 23, 2024
Maintainer

Habbie
May 23, 2024
Maintainer

git-tec
May 23, 2024
Author

Habbie
May 23, 2024
Maintainer

Habbie
May 23, 2024
Maintainer

git-tec
May 23, 2024
Author

Habbie
May 23, 2024
Maintainer

git-tec
May 23, 2024
Author

Habbie
May 23, 2024
Maintainer

Habbie
May 23, 2024
Maintainer

Habbie
May 23, 2024
Maintainer

git-tec
May 23, 2024
Author

Habbie May 23, 2024
Maintainer

git-tec
May 23, 2024
Author

Habbie May 23, 2024
Maintainer

git-tec May 23, 2024
Author

omoerbeek
May 23, 2024
Maintainer

omoerbeek
May 23, 2024
Maintainer