[Opendnssec-develop] Supporting DNS64 with a wild trick

[Rick van Rein]

Hello all,

I've been reading into the proposals that the IETG behave WG is
drafting about IPv4 <--> IPv6 translation.  One of their components
is DNS64, which translates A records into AAAA.  A counterpart
component, DNS46, is also in the making.

DNS64 cooperates with NAT64, a translator to which mapped traffic
is routed so internal IPv6 traffice gets translated into external
IPv4 traffic.

DNS64 assembles the AAAA records from the A records in a deterministic
manner; as a result we know exactly what those AAAA records will look
like, based on the zone.  The only variable is a prefix that could be
network-local (in which case the network admin will have to worry
about DNSSEC) and there is a standardised prefix, 0064:FF9B::/96 which
is used to route traffic to the NAT64 translator.

Needless to say that this causes severe headaches for secure resolvers
if they fall behind this DNS64 translator.  It wouldn't be good if
DNSSEC and IPv6 would hold each other hostage.  Speaking for myself, I
don't like to expand my trust in a network at the same time its reach
is expanded...

What I am wondering now is if the following would be acceptable for
DNSSEC signer tools like OpenDNSSEC:

1. To derive such AAAA records from any A that has no AAAA records
   explicitly defined by the DNS operator;

2. To create signatures, NSEC/NSEC3, anything that DNSSEC needs;

3. To publish the DNSSEC aspects in DNS, but not the AAAA records
   themselves (oops!)

   Not publishing the AAAA records themselves is vital, as it is a
   site-local decision to employ DNS64 -- not everybody will have a
   NAT64 translator in reach.  But correct RRSIG AAAA records can
   only be constructed at the time of signing.


How ugly is this?  Would there be operational issues?  Without this, I
fear end-to-end DNSSEC would require a trust path from resolver/cache
to each individual network device...  or IPv6 would suffer from yet
another reason for delay.  We can ask ourselves if that warrants an
ugly hack like this one.


Links:

http://tools.ietf.org/html/draft-ietf-behave-dns64-05
http://tools.ietf.org/html/draft-ietf-behave-address-format-04
http://tools.ietf.org/wg/behave/


Cheers,
 -Rick