[Opendnssec-develop] Supporting DNS64 with a wild trick

[Matthijs Mekking]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

If I'm right, the DNS64 covers three cases. One is implementing the
DNS64 functionality at the stub, another is implementing it at the
resolver and the third puts the functionality in the authoritative name
server.

The third case might be of interest for OpenDNSSEC. AAAA synthesis may
be done when receiving a query, or when creating/adapting the zone. The
latter is preferred, which require no DNS64 functionality.

Unless Dynamic Update is used. I agree that we could design for DNS64
synthesis in the DynUpdate module.

Matthijs

Rick van Rein wrote:
> 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
> _______________________________________________
> Opendnssec-develop mailing list
> Opendnssec-develop at lists.opendnssec.org
> https://lists.opendnssec.org/mailman/listinfo/opendnssec-develop

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEcBAEBAgAGBQJLeRpgAAoJEA8yVCPsQCW5nFgH/247xxU73YRcb6NuMt8mpbtI
kiUT0kVqo9pvnlRbypkNN/BsA/Ail8Nz7EzVnScd19c5pxrSgV+cqqqqhHWjL2Wa
ZeKypwrLZHzvG70UsJ+qZ8vp/mijEf9f1p9+tCpKFC0oorls7Y7/4AcoR9jCNtDe
+/TPhWbXIUpu44+36u56ACF8SwvFi2EH+r9lwxFEWPm9nbM3mAKrhNAOWqrE+NbQ
mnnnZLem7JOCd5UY9oWrc65rTibUAf+HtE6y8ROsxb3S+wOnRfecs/ERuz6twLRW
iYzpNYigAex1IyAu+Ha6LZgKiDS1gtGOfBuXx80GvfXh5y7LMgVYk+Bu6ewR31E=
=2U1I
-----END PGP SIGNATURE-----