[Opendnssec-develop] Supporting DNS64 with a wild trick

[Matthijs Mekking]

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

Rick van Rein wrote:
> 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.

Whatever the prefix is, you can put it in configuration.

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

DNS64 only deals with IPv4-only to/from IPv6-only communications.

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

Of course, without knowing the prefix, you cannot synthesize. The prefix
can be learned through configuration, although there are other
approaches submitted within the behave wg.

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

But that is at the resolver side. OpenDNSSEC will be at the
authoritative side, and thus in that case, there are no changes required
for us (and with us, I mean the OpenDNSSEC project group).

DNS64 is a contributed module in Unbound that you can turn on. In that
case, Unbound will do synthesis after validation. I don't see the
'split' issue.

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

As you mentioned, a horrible idea ;). And not compliant with the current
DNS64 specification.

DNS64 is mainly a resolver thingie. On the authoritative side,
implementors have little worries supporting DNS64, unless you are going
to do Dynamic Updates.


Matthijs

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

iQEcBAEBAgAGBQJLfTbFAAoJEA8yVCPsQCW58cAH/ifR3skqJ3klTCf8r2Uv15Ja
AeVW/MktINjXcjASV/1EotjgojAZbrNIkuHJdEpynUK8DoMEOSezcrW895iTMu4d
5a50NC9i0GfanU5abiq5ocTKVUnmEqXT4c2R6muzzfGsvEwZyN1H8UAaeVMzeiB8
Mx3Xak8acywDWYtjkf3/K2j1XRtSXzXpX7hgnjIFTrMNdHT1cMSfIUp4cfRuiGq1
bNoe4d6UULToHmbaz6gfBZbnedclXwjjRmrm49LH2oCfllppwf1YsUivxAYmU8tt
yQoovkQ7zbsbTYaBFt011XRB+gh7XiwDRB/C4iUSwD1QqHt4VV5NbuGCggjrIVg=
=MmQv
-----END PGP SIGNATURE-----