[Opendnssec-develop] Supporting DNS64 with a wild trick

[Rick van Rein]

Hi all,

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

I had to think over your angle.  I think you are proposing that the
user defines a prefix (96 bits to be placed in front of the IPv4
address), and that your are proposing to not use the well-known
prefix 64:FF9B::/96 as a _default_ value.  Not yet, at least.

If you'd do that then the DNS administrator could setup NAT64/NAT46
translation for incoming traffic to their servers, and translate the
IPv6 traffic to the IPv4 addresses.  Sounds good to me, although I
wonder if it'd add anything w.r.t. setting up dual stack servers.

You could at some point move towards using a NAT64 translation
service that might be offered by an external party, perhaps
sixxs.net or comparable IPv6-drivers.  If that happens, a globally
routable (or user based alternative) prefix such as the well-known
prefix could be used.  Once that setup would work reliably, it could
become a default to be set in OpenDNSSEC.  It'd help in moving traffic
over to IPv6, which is a Good Thing(tm).

> AAAA synthesis may
> be done when receiving a query, or when creating/adapting the zone. The
> latter is preferred, which require no DNS64 functionality.

Whether it can be done dynamically would depend on whether the IPv6
prefix used is dynamic.  In practice, it is quite doable to get stable
addresses for a server; only 2002::/16 addresses are dynamic if the
IPv4 tunnel endpoint is dynamic.

But I doubt if anyone would setup a server (by which I mean, DNS-published
entities) using a 2002::/16 address.  A simple tunnel like AYIYA can provide
a static IPv6 address, even over a dynamic IPv4 address.

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

Sounds lovely to me.

What is left are the other places of supporting NAT64/DNS64.  I don't
care very much about the stub, as it seems simpler to use a dual stack
instead; but a DNS64 resolver serving a LAN and passing traffic through
NAT64 could be a more difficult case.  This was what I had in mind with
my original, immediately withdrawn, idea.

I'm afraid it's going to be useful to support the resolver-case for DNS64.
Matthijs told me a patch for Unbound is already available.  This makes
Unbound sit in a split: you can use it for strict DNSSEC on your LAN,
or for DN64-enabled strict IPv6 on your LAN, but not both.

A horrible way out (it'd work, but I'd love to see a better solution)
could be to publish the AAAA record signatures for such applications on
a subdomain, as in

	www		IN A	123.45.67.89
	;		IN AAAA to be generated by DNS64
	dns64sig.www	IN RRSIG AAAA ...

This dns64sig.www would sign the "www IN AAAA" record with the well-known
prefix, thus enabling network administrators to setup such an extension
internally.  There would be a recommendation along the lines of "a network
that uses DNS64 alongside DNSSEC resolvers in clients MUST use the
well-known prefix for DNS64 and it MUST use the dns64sig sub-zones to
get hold of the AAAA signatures".

Let the record show that I find the above very ugly.  But it would be a
way of supporting DNSSEC in combination with DNS64.  Better ideas and
opinions are quite welcome!  (One that I can see is the introduction
of a special RR "DNS64RRSIGforAAAA" but I haven't thought that through.)


Cheers,
 -Rick