[DNSOP] RFC 4470 Section 4: next name \000.QNAME and validators

[Rifat Jumagulov <[e-mail]>]

Hello,

RFC 4470 Section 4 builds the next name this way: "To increment a name, add
a leading label with a single null (zero-value) octet." For
https://www.google.com/url?q=http://foo.example.com&source=gmail&ust=1793623136948000&sa=E
it gives an NSEC record with next name \
https://www.google.com/url?q=http://000.foo.example.com&source=gmail&ust=1793623136948000&sa=E,
and it says: "The first of these NSEC RRs proves that no exact match for
https://www.google.com/url?q=http://foo.example.com&source=gmail&ust=1793623136948000&sa=E
exists"

RFC 8198 Appendix B reads the same form differently: "If the next domain
name is a subdomain of the given name, you have an ENT. Otherwise, you have
an NXDOMAIN." \
https://www.google.com/url?q=http://000.foo.example.com&source=gmail&ust=1793623136948000&sa=E
is a subdomain of
https://www.google.com/url?q=http://foo.example.com&source=gmail&ust=1793623136948000&sa=E,
so this NSEC shows an empty non-terminal, not a missing name. Section 3 of
RFC 4470 also says: "This change is expected to be fully compatible with
all existing DNSSEC validators."

Erratum 6734 (Reported, Mark Andrews) makes the general point: \000.domain
can only prove no data at domain, not that domain does not exist. It has no
corrected text yet. RFC 7129 Appendix A prints the same form, NSEC \
https://www.google.com/url?q=http://000.b.example.org&source=gmail&ust=1793623136948000&sa=E
.

Local test: a zone with the two NSEC records of the Section 4 example,
signed with ECDSAP256SHA256, served by NSD 4.15.4 and by Knot DNS 3.6.2,
which both return NXDOMAIN with both records. Query
https://www.google.com/url?q=http://foo.example.com&source=gmail&ust=1793623136948000&sa=E.
A with DO=1. BIND 9.20.30, Unbound 1.24.0, Knot Resolver 6.5.1 and PowerDNS
Recursor 5.4.9 all answer SERVFAIL.
https://www.google.com/url?q=http://example.com&source=gmail&ust=1793623136948000&sa=E.
SOA gets AD from all four, so the key and anchor work. As a control I
signed the same zone with next names foo\
https://www.google.com/url?q=http://000.example.com&source=gmail&ust=1793623136948000&sa=E.
and *\
https://www.google.com/url?q=http://000.example.com&source=gmail&ust=1793623136948000&sa=E.,
which are not children. All four then answer NXDOMAIN with AD.

Could the WG give erratum 6734 corrected text that stops recommending
\000.QNAME as a next name for an NXDOMAIN proof?

AI models helped review the text and build small test models; Arxo ran the
checks, and I take responsibility for the reports.

Rifat Jumagulov
Arxo Law · [e-mail]