synthrecord: reverse mode returns NXDOMAIN for empty non-terminals (RFC 8020)

[Colin Vidal]

Hi,

> 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.

Thanks for the report. This looks like a legit bug indeed. Please do open a Gitlab issue, I'll investigate this.

Regards,

-- 
Colin Vidal -- colin at isc.org
Internet Systems Consortium