pdns auth secondary serving a pre-signed DNSSEC zone can generate invalid NSEC records

[elburb]

• 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
• I have read and understood the PowerDNS AI policy

• Program: Authoritative
• Issue type: Bug report

Short description

A PowerDNS Authoritative secondary serving a pre-signed DNSSEC zone with NSEC semantics generates an incorrect NSEC successor when the zone contains a delegation with names below the delegation.

The primary is NSD and serves a correctly pre-signed zone. PowerDNS receives the correct NSEC and RRSIG through AXFR, but synthesizes a different NSEC on the secondary. The generated NSEC points into the delegated subtree, causing the existing pre-signed RRSIG to become invalid.

In the example below, the primary correctly serves:

9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NSEC a.d.c.0.3.2.0.0.2.4.d.f.ip6.arpa. NS RRSIG NSEC

The PowerDNS secondary instead serves:

9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NSEC 0.0.0.0.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. NS RRSIG NSEC

The latter is not the NSEC record covered by the transferred RRSIG, so DNSSEC validation fails.

Environment

Operating system: Debian 13 (amd64)
Software version: PowerDNS Authoritative Server 5.0.5
Software source: Debian package built from PowerDNS 5.0.5 source
Backend: SQLite3
Zone type: Secondary/slave
DNSSEC: Pre-signed zone (PRESIGNED=1)
NSEC semantics
Primary: NSD

Steps to reproduce

Configure a primary with a pre-signed DNSSEC zone containing a delegation such as:

9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NS ns1.grmml.dn42.
9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NS ns2.grmml.dn42.
9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NS ns3.grmml.dn42.

The delegated subtree contains names such as:

0.0.0.0.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NS ns1.grmml.dn42.
1.0.0.0.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NS ns1.grmml.dn42.
2.0.0.0.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NS ns1.grmml.dn42.
3.0.0.0.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NS ns1.grmml.dn42.

The next name in the parent zone is:

a.d.c.0.3.2.0.0.2.4.d.f.ip6.arpa.

The correctly signed NSEC therefore is:

9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NSEC a.d.c.0.3.2.0.0.2.4.d.f.ip6.arpa. NS RRSIG NSEC

Configure PowerDNS Authoritative as a secondary for the zone and set:

PRESIGNED=1

Verify that the zone reports:

This is a Slave zone
Zone is presigned
Zone has NSEC semantics

Allow the secondary to transfer the zone from the primary.

The transferred zone contains the correct NSEC and RRSIG:

9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NSEC a.d.c.0.3.2.0.0.2.4.d.f.ip6.arpa. NS RRSIG NSEC

9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN RRSIG NSEC 10 14 900 ... 1647 d.f.ip6.arpa. ...

Query the NSEC record directly from the primary:

drill -t -D ANY a.d.c.0.3.2.0.0.2.4.d.f.ip6.arpa. @

The primary returns the expected NSEC:

a.d.c.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NSEC 9.9.0.0.8.2.0.0.2.4.d.f.ip6.arpa. NS RRSIG NSEC

Query the corresponding name from the PowerDNS secondary:

drill -D PTR 9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. @

The secondary returns:

9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NSEC 0.0.0.0.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. NS RRSIG NSEC

but returns the original RRSIG received from the primary, which covers:

9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. NSEC a.d.c.0.3.2.0.0.2.4.d.f.ip6.arpa.

Inspect the PowerDNS SQLite database:

SELECT name, type, auth, ordername
FROM records
WHERE domain_id = (
SELECT id FROM domains WHERE name = 'd.f.ip6.arpa'
)
AND name LIKE '%.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa'
ORDER BY ordername;

The delegated descendants are present in the parent zone database with ordernames immediately following the delegation:

0.0.0.0.9.4.1... 4 2 0 0 2 3 0 1 4 9 0 0 0 0
1.0.0.0.9.4.1... 4 2 0 0 2 3 0 1 4 9 0 0 0 1
2.0.0.0.9.4.1... 4 2 0 0 2 3 0 1 4 9 0 0 0 2
3.0.0.0.9.4.1... 4 2 0 0 2 3 0 1 4 9 0 0 0 3

The delegation itself has:

9.4.1.0.3.2.0.0.2.4... 4 2 0 0 2 3 0 1 4 9

This causes the next-order-name lookup to select 0.0.0.0.9.4.1... rather than the next name in the parent NSEC chain.

Expected behaviour

For a pre-signed secondary zone, PowerDNS should serve the NSEC records represented by the transferred pre-signed zone such that the NSEC owner/next-name pair matches the corresponding transferred RRSIG.

In particular, the NSEC at:

9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa.

should remain:

9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. NSEC a.d.c.0.3.2.0.0.2.4.d.f.ip6.arpa.

The names below the delegation at 9.4.1... should not be treated as candidates for the NSEC chain of the parent zone.

Actual behaviour

PowerDNS synthesizes the NSEC successor by selecting the lexicographically next ordername in the database.

Because the delegated descendants are present immediately after the delegation in ordername order, PowerDNS selects:

0.0.0.0.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa.

The secondary therefore returns:

9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NSEC 0.0.0.0.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. NS RRSIG NSEC

while retaining the RRSIG transferred from the primary, which signs the NSEC whose next name is:

a.d.c.0.3.2.0.0.2.4.d.f.ip6.arpa.

Consequently the NSEC RRSIG does not validate.

The relevant database records are:

9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. NS auth=0 ordername=4 2 0 0 2 3 0 1 4 9
0.0.0.0.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. NS auth=0 ordername=4 2 0 0 2 3 0 1 4 9 0 0 0 0
1.0.0.0.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. NS auth=0 ordername=4 2 0 0 2 3 0 1 4 9 0 0 0 1
2.0.0.0.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. NS auth=0 ordername=4 2 0 0 2 3 0 1 4 9 0 0 0 2
3.0.0.0.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. NS auth=0 ordername=4 2 0 0 2 3 0 1 4 9 0 0 0 3
a.d.c.0.3.2.0.0.2.4.d.f.ip6.arpa. NS auth=0 ordername=4 2 0 0 2 3 0 c d a

The issue appears to be related to NSEC successor selection not accounting for DNS zone cuts/delegations when selecting the next ordername in a pre-signed secondary zone.

Other information

The primary is NSD and the zone is pre-signed externally.

The AXFR received by PowerDNS contains the correct NSEC and RRSIG. For example:

9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NSEC a.d.c.0.3.2.0.0.2.4.d.f.ip6.arpa. NS RRSIG NSEC

9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN RRSIG NSEC 10 14 900 20260811060615 20260807060615 1647 d.f.ip6.arpa. ...

The PowerDNS database confirms that the NSEC RRSIG was imported, but no NSEC record is stored for this owner name; PowerDNS synthesizes the NSEC response.

The relevant ordername lookup in the generic SQL backend appears to select the minimum ordername greater than the queried name without excluding names below a delegation. In this case that results in the delegated descendant 0.0.0.0.9.4.1... being selected as the NSEC successor.

[Habbie]

Thank you for the extensive documentation in this ticket. We love receiving such well researched reports. I do have a few small questions to start with.

Is

0.0.0.0.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NS ns1.grmml.dn42.

in the zone file that also contains the delegation

9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NS ns1.grmml.dn42.

?

And, if this happens to be easy for you: can you share a full zone file that has this problem? I can likely construct one from your ticket but if you have one already (which I think you do!) that saves us time.

[elburb]

Is

0.0.0.0.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NS ns1.grmml.dn42.

in the zone file that also contains the delegation

9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NS ns1.grmml.dn42.

Yes it is.

And, if this happens to be easy for you: can you share a full zone file that has this problem? I can likely construct one from your ticket but if you have one already (which I think you do!) that saves us time.

Sure, no problem.

Attached are an AXFR from the NSD primary, showing (I think) that the AXFR from the primary is ok; together with an AXFR from the PowerDNS secondary.

primary-nsd.axfr.txt
secondary-pdns.axfr.txt

For additional context this is the IPv6 reverse zone for the dn42 network, so it consists of a large number of delegations to dn42 member's own nameservers. Users are typically allocated a /48 but some members may subnet their networks which is how we end up with both fd42:23:149::/48 and fd42:23:149::/64 (and more) in the same zone.

[Habbie]

Users are typically allocated a /48 but some members may subnet their networks which is how we end up with both fd42:23:149::/48 and fd42:23:149::/64 (and more) in the same zone.

in which case that /64 entry should fully disappear from view in DNS because it is occluded by the shorter delegation (maybe you can check what NSD gives you if you ask for more zeroes to get into the /64, I hope it just gives you the /48 delegation).

I replicated your problem by taking the NSD AXFR, running it through ldns-read-zone -s, loading it with pdnsutil zone load, enabling DNSSEC (with NSEC) by pdnsutil zone secure, and asking for dig any 9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. (which yields 9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. 900 IN NSEC 0.0.0.0.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. NS RRSIG NSEC which is wrong). That is not the "secondary" code so the bug might be in two places.

Asking for 0.0.0.0.9.4.1.0.3.2.0.0.2.4.d.f.ip6.arpa. in that state gives the /64 delegation, which is wrong. Removing one zero from the front yields the /48 delegation, which is right.

[Habbie]

The relevant ordername lookup in the generic SQL backend appears to select the minimum ordername greater than the queried name without excluding names below a delegation. In this case that results in the delegated descendant 0.0.0.0.9.4.1... being selected as the NSEC successor.

The select code is okay. The 0.0.0 ordername should never have ended up in the database.

[elburb]

The dn42 member with the original problem (fd42:23:149::/48) ended up removing the subnets, and therefore also my original test case, however we also have fd3d:4e14::/32 and fd3d:4e14:f963::/48 which show the same thing. I've included just the relevant sections below.

Queries against the NSD primary:

For fd3d:4e14::/32

$ drill -D NSEC 4.1.e.4.d.3.d.f.ip6.arpa @b.master.delegation-servers.dn42                                                   

;; ANSWER SECTION:                                                                                                                         

;; AUTHORITY SECTION:                                                                                                                      
4.1.e.4.d.3.d.f.ip6.arpa.       900     IN      NS      ns2.auth.twink0r.dn42.                                                             
4.1.e.4.d.3.d.f.ip6.arpa.       900     IN      NSEC    4.5.7.0.5.b.e.4.d.3.d.f.ip6.arpa. NS RRSIG NSEC                                    
4.1.e.4.d.3.d.f.ip6.arpa.       900     IN      RRSIG   NSEC 10 10 900 20260811222740 20260807222740 1647 d.f.ip6.arpa. dbMt/5zQ8rc/SEjzrLR
38OqmyaxH3XnCfqB5mVYhG6V0jJL9VNBPBOld31O7g9aBbiOWhB3sLXQ3AHCBs/Hg8gvMZ3euy0/2xaXIYPyu8mq12Whboccxe2S5hSyauK4niM67Qk6BjpkcB0XCtZwlUtVbCXWXso
NqrFIhmfm/c55/3AvqJ43tT5BdyXkq7V19tNAO48zshArl752AHVka6J7rSjAJyZOlDdjTvrNQbdL5hkGFUeiEqKz/JDIpbW2zSGgG/uiJDFE6SjztytCx6W2zFN165h5ll59DN6eox
A9n/arVo+PqVYHnoE2ZilGi62P4PgiZnilZzIqltEduxQ==                                                                                            

And for fd3d:4e14:f963::/48 which, as you suggested, is occluded by the /32 delegation

$ drill -D NSEC 3.6.9.f.4.1.e.4.d.3.d.f.ip6.arpa @b.master.delegation-servers.dn42 

;; ANSWER SECTION:                                                                                                                         

;; AUTHORITY SECTION:                                                                                                                      
4.1.e.4.d.3.d.f.ip6.arpa.       900     IN      NS      ns2.auth.twink0r.dn42.                                                             
4.1.e.4.d.3.d.f.ip6.arpa.       900     IN      NSEC    4.5.7.0.5.b.e.4.d.3.d.f.ip6.arpa. NS RRSIG NSEC                                    
4.1.e.4.d.3.d.f.ip6.arpa.       900     IN      RRSIG   NSEC 10 10 900 20260811222740 20260807222740 1647 d.f.ip6.arpa. dbMt/5zQ8rc/SEjzrLR
38OqmyaxH3XnCfqB5mVYhG6V0jJL9VNBPBOld31O7g9aBbiOWhB3sLXQ3AHCBs/Hg8gvMZ3euy0/2xaXIYPyu8mq12Whboccxe2S5hSyauK4niM67Qk6BjpkcB0XCtZwlUtVbCXWXso
NqrFIhmfm/c55/3AvqJ43tT5BdyXkq7V19tNAO48zshArl752AHVka6J7rSjAJyZOlDdjTvrNQbdL5hkGFUeiEqKz/JDIpbW2zSGgG/uiJDFE6SjztytCx6W2zFN165h5ll59DN6eox
A9n/arVo+PqVYHnoE2ZilGi62P4PgiZnilZzIqltEduxQ==                                                                                            

Queries against the pdns secondary

For fd3d:4e14::/32, which shows the problem of the original RRSIG coupled with a different NSEC

$ drill -D NSEC 4.1.e.4.d.3.d.f.ip6.arpa @b.delegation-servers.dn42
                     
;; ANSWER SECTION:                                                                                                                         
4.1.e.4.d.3.d.f.ip6.arpa.       900     IN      RRSIG   NSEC 10 10 900 20260811222740 20260807222740 1647 d.f.ip6.arpa. dbMt/5zQ8rc/SEjzrLR
38OqmyaxH3XnCfqB5mVYhG6V0jJL9VNBPBOld31O7g9aBbiOWhB3sLXQ3AHCBs/Hg8gvMZ3euy0/2xaXIYPyu8mq12Whboccxe2S5hSyauK4niM67Qk6BjpkcB0XCtZwlUtVbCXWXso
NqrFIhmfm/c55/3AvqJ43tT5BdyXkq7V19tNAO48zshArl752AHVka6J7rSjAJyZOlDdjTvrNQbdL5hkGFUeiEqKz/JDIpbW2zSGgG/uiJDFE6SjztytCx6W2zFN165h5ll59DN6eox
A9n/arVo+PqVYHnoE2ZilGi62P4PgiZnilZzIqltEduxQ==
4.1.e.4.d.3.d.f.ip6.arpa.       900     IN      NSEC    2.6.9.f.4.1.e.4.d.3.d.f.ip6.arpa. NS RRSIG NSEC 

;; AUTHORITY SECTION:

And for fd3d:4e14:f963::/48, which seems just incorrect:

$ drill -D NSEC 3.6.9.f.4.1.e.4.d.3.d.f.ip6.arpa @b.delegation-servers.dn42                                                  

;; ANSWER SECTION:
3.6.9.f.4.1.e.4.d.3.d.f.ip6.arpa.       900     IN      NSEC    4.5.7.0.5.b.e.4.d.3.d.f.ip6.arpa. NS RRSIG NSEC 

;; AUTHORITY SECTION:

Removing a digit returns the /32 as the authority:

$ drill -D NSEC 6.9.f.4.1.e.4.d.3.d.f.ip6.arpa @b.delegation-servers.dn42

;; ANSWER SECTION:

;; AUTHORITY SECTION:
4.1.e.4.d.3.d.f.ip6.arpa.       900     IN      NS      ns2.auth.twink0r.dn42.
4.1.e.4.d.3.d.f.ip6.arpa.       900     IN      NSEC    2.6.9.f.4.1.e.4.d.3.d.f.ip6.arpa. NS RRSIG NSEC 
4.1.e.4.d.3.d.f.ip6.arpa.       900     IN      RRSIG   NSEC 10 10 900 20260811222740 20260807222740 1647 d.f.ip6.arpa. dbMt/5zQ8rc/SEjzrLR38OqmyaxH3XnCfqB5mVYhG6V0jJL9VNBPBOld31O7g9aBbiOWhB3sLXQ3AHCBs/Hg8gvMZ3euy0/2xaXIYPyu8mq12Whboccxe2S5hSyauK4niM67Qk6BjpkcB0XCtZwlUtVbCXWXsoNqrFIhmfm/c55/3AvqJ43tT5BdyXkq7V19tNAO48zshArl752AHVka6J7rSjAJyZOlDdjTvrNQbdL5hkGFUeiEqKz/JDIpbW2zSGgG/uiJDFE6SjztytCx6W2zFN165h5ll59DN6eoxA9n/arVo+PqVYHnoE2ZilGi62P4PgiZnilZzIqltEduxQ==