Future of BIND's built-in empty zone list

[Chris Thompson]

On May 16 2015, Mark Andrews wrote:
[...]
>When IANA and ARIN finally gets around to doing 64.100.IN-ADDR.ARPA
>et al., which has been waiting over a year for the of DNSOP to write
>up the last call of draft-ietf-dnsop-rfc6598-rfc6303 to be written
>up, it should be done similar to this with a insecure delegation
>to 64.100.IN-ADDR.ARPA, to allow the ISP's using this range and
>others to server their own instances of 64.100.IN-ADDR.ARPA without
>DNSSEC validation failures, and a DNAME to the AS112 traffic sink
>for the leaked traffic.
>
>64.100.IN-ADDR.ARPA  SOA ...
>64.100.IN-ADDR.ARPA  NS ...
>64.100.IN-ADDR.ARPA  NS ...
>64.100.IN-ADDR.ARPA  DNAME EMPTY.AS112.ARPA
>
>Note: there are no DNSKEY records.  This is deliberate.

I notice, however, that this is not what RFC 7535 suggests (e.g. for
the similar case of 2.0.192.IN-ADDR.ARPA). Instead a DNAME directly
in the (signed) parent zone is described.

Would this actually break a validating resolver with a locally defined
(unsigned) empty zone 2.0.192.IN-ADDR.ARPA ? The parent zone can produce
a proof that there is no signed delegation, but only by revealing the
signed DNAME.

-- 
Chris Thompson
Email: cet1 at cam.ac.uk