auth: invalid NSEC response when queried with 8bit DNS name

[romuald]

• 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

When a client queries powerdns with a non-existing 8bit label, the server is not replying with the proper previous / next labels (jump to TLDR for the why)

Environment

• Operating system: Ubuntu
• Software version: 4.7.4
• Software source: https://github.com/PowerDNS/pdns.git tags/auth-4.7.4
• reproduced with the default gsql backend (sqlite3)

Configuration

local-address=0.0.0.0,::
launch=gsqlite3
gsqlite3-dnssec
gsqlite3-database=./powerdns.sqlite
local-port=5355
socket-dir=/tmp/vanila
8bit-dns=yes

Zone contents

The zone content has no real relation with the issue, I've only used it to illustrate it

@    IN    SOA    ns1.ignore.me. root.ignore.me. 2024011001 7200 7200 2419200 1200
0 IN TXT A
a IN TXT A
z IN TXT A

Steps to reproduce

• start a powerdns with the 8bit-dns option enabled
• pdnsutil load-zone example.net zone-with-a-few-records
• pdnsutil add-zone-key example.net active
• pdnsutil rectify-zone example.net
• dns query with a 8bit label: dig +noidnin +dnssec ANY é.example.net -p 5355 @localhost

Expected behaviour

Using "8bit" (binary) ordering, the query is [0xC3, 0xA9], the previous record should be z (0x7A), and the next one the origin:

z.example.net.		1200	IN	NSEC	example.net. TXT RRSIG NSEC

Actual behavior

The NSEC previous record is the origin, and the next is 0:

example.net.		1200	IN	NSEC	0.example.net. A NS SOA MX RRSIG NSEC DNSKEY

TLDR;

Looking into the backend code, getBeforeAndAfterNamesAbsolute() is using qname.labelReverse().toString(), which is actually the textual representation of the qname.

So when searching for "é", it is instead looking up the\195\169 string (with the ASCII backslashes, and ASCII numbers) and returning the previous / next records of the zone relative to those characters.

Unfortunately I'm not confortable enough with the source to find a proper fix, .toDNSString() was a good candidate but it is using the wire format it seems