synthrecord: reverse mode returns NXDOMAIN for empty non-terminals (RFC 8020)
vom513
vom513 at gmail.com
Thu Nov 5 02:29:52 UTC 2026
Hi all,
BIND version info, I know this is not as current as it could be. Since this is just serving auth only synth. records I’m a little lazy on that front:
vom at auth-synth:~$ /usr/local/sbin/named -V
BIND 9.21.18-dev (Development Release) <id:0d9facb>
Following up on my thread from January about synthesizing v6 PTRs -- I now have the synthrecord plugin running in reverse mode for a /64, and it's working well for actual PTR lookups. However, DNSViz flags an RFC 8020 inconsistency, and I've reproduced it with dig.
Zone: 4.6.0.0.0.0.0.c.e.f.0.0.0.2.6.2.ip6.arpa (unsigned; DNSSEC-signed parent with a proper NSEC3 no-DS proof)
A full-length name gets a synthesized PTR as expected:
$ dig @auth-synth.burn.net -x 2620:fe:c000:64:cf4:5b82:2d40:8dd2 +norec
status: NOERROR, flags: qr aa, ANSWER: 1
... PTR dynamic-2620-fe-c000-64-cf4-5b82-2d40-8dd2.synth.burn.net.
But an ancestor of that name -- an empty non-terminal -- gets NXDOMAIN:
$ dig @auth-synth.burn.net 0.4.6.0.0.0.0.0.c.e.f.0.0.0.2.6.2.ip6.arpa PTR +norec
status: NXDOMAIN, flags: qr aa, ANSWER: 0, AUTHORITY: 1 (SOA)
Per RFC 8020, NXDOMAIN means nothing exists below that name, so the two answers contradict each other. Resolvers doing an NXDOMAIN cut or QNAME minimisation could stop at the ENT. In practice I'm not seeing failures, presumably because the zone is unsigned and resolvers in relaxed mode fall back to the full qname -- but it seems worth fixing.
Looking at bin/plugins/synthrecord.c on main, synthrecord_reverse() calls dns_byaddr_parseptrname(), and when that fails (as it will for any partial nibble name) it returns NS_HOOK_CONTINUE, so the zone's normal NXDOMAIN goes out.
Interestingly, the same function already returns NOERROR/NODATA for a full-length name with a non-PTR qtype, on the grounds that the name "exists" from a protocol perspective. Would it make sense to extend that to partial names? I.e., if the qname is under the zone origin, consists only of single-hex-digit labels (fewer than a full address), and the prefix those nibbles describe overlaps allow-synth, answer NOERROR/NODATA rather than falling through. Something similar would apply for in-addr.arpa with partial octets.
Is this a known limitation, or should I open a GitLab issue? Happy to test patches.
Obviously this is not critical - but I just did distro level package upgrades on this machine + reboot - and after checking dnsviz to make sure all was well I fell into this rabbit hole on this “error”.
Thanks
More information about the bind-users
mailing list