On Sun, Dec 7, 2014 at 6:04 PM, Michael Richardson
<mcr+ietf(_at_)sandelman(_dot_)ca>
wrote:
Phillip Hallam-Baker <phill(_at_)hallambaker(_dot_)com> 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.