On Sun, Dec 7, 2014 at 6:04 PM, Michael Richardson <mcr+ietf@xxxxxxxxxxxx> wrote:
Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> wrote:
> The point of DNS64 is to provide a mechanism that makes it easy to turn on
> IPv6 today. All the client needs is a connection to a DNS router that
> supports DNS64.
You worded that wrong.
DNS64 lets people turn off IPv4 (and/or avoid NAT4*4).
Turn off or not have the code in the stack at all. Yep.
For a lot of embedded devices, I think this is the ideal. They don't really need full Internet connectivity in any case. They might have a ten or twenty year service life though so I care rather more that they are IPv6 capable than a desktop that might last seven years tops.
> Because of network circumstances a client using DNS64 is almost certainly
> going to need to use DPRIV for access simply because port 53 has been
> sabotaged so thoroughly. So we are going to have to trust the DPRIV
> resolver to level 1 at minimum
That's an interesting observation: can you elaborate on the sabotage?
I think I know, but I'd rather you were more clear about this.
There are two types of sabotage: Ignorance and malice.
Ignorance includes stupidity like chopping DNS messages to 512 (sometimes 500) bytes, filtering out unknown RRs and such. And the usual IETF approach is to wait for people to learn better (hey we have been waiting 40 years...)
Malice is increasingly common though. Like when I found my ISP had redirected ALL port 53 traffic through their own resolver so they could do a sitefinder hack if NXT showed up. The DNS is a powerful control point, people will make use of it unless it is properly secured.
You can't ignore or wish away malice when writing a security spec.
I have been arguing that DNSSEC requires a new client resolver protocol to be practical for ten years now. And the need has only increased.
I've wanted DNS64 to happen in the host, and given that a number of hosts had
to be fixed to function in IPv6 only environments, a change to include DNS64
would not be crazy in my opinion, and eliminates much of the end-to-end
DNSSEC-breakage that DNS64 can imply.
(or to put it another way: when you turn on end-host DNSSEC validation,
and enable DPRIV, you had better provide DNS64 at the same time)
This bit isn't clear to me.
My main point is that if you are playing NAT64 games and example.com only has an A record, then a DNSSEC signature on the A record is like a chocolate teapot to an IPv6 only device.
Sure we could come up with some mechanism for describing the NAT64 mapping so that the end host could read it. But where would the mapping come from, who would sign that? Doing validation in the client does not actually provide leverage here.
Perhaps what would help here is a trust calculus that would expose what the assumptions are that a device is relying on. The problem with PKI is that it is so easy to add a layer of indirection.