Re: [v6ops] draft-palet-v6ops-nat64-deployment-02 comments

[Fred Baker <[e-mail]>]

No hats, and a comment to get picked up next week, not before 23:59 UTC today.

I'm thinking further about the statement that "DNS64 breaks DNSSEC". I think that is just incorrect.

Here's the scenario. I'm thinking from the perspective of the user of DNS64 in

                         +----+                +----+
                         |DNS |     +-----+    |DNS |
                         |IPv6|     |DNS64|    |IPv4|
                         +--+-+     +-----+    +--+-+
 +------+ v6 +------+       |      /       \      |
 |      +----+      |    ,--+--.  /         \  ,--+--.
 |Dual  |    | IPv6 |   /       \/   ,---.   \/       \
 |Stack |  +-+Router+--(  IPv6   )--( PLAT)--(  IPv4   )
 |Device|v4|C|      |   \Network/`.  `---'    \Network/
 |      +--+L|      |    `--+--'   `.         /`-----'
 +------+  |A|      |       |        `+------+
           |T|      |    +--+---+     | Peer |
           +-+------+    | IPv6 |     |Device|
                         |Device|     +------+
                         +------+

which might be the IPv6 side of the "Dual Stack Device" or might be the "IPv6 Device". There are two sets of possibilities:

From an IPv6 perspective (either device), assuming the response contains correct data, a request for a AAAA record will yield one of four things:

1) NXDOMAIN
2) a signed AAAA record
3) an unsigned but valid native AAA record
4) an unsigned DNS64-generated IPv4-embedded IPv6 Address, the synthesis of an IPv6 prefix and an IPv4 address.

Barring a few exclusions, #4 will never happen if a native AAAA record is known by the DNS64 device (https://tools.ietf.org/html/rfc6147#section-5.1.1).

From an IPv4 perspective, the "Dual Stack Device" will also request an A record, and might get:

1) NXDOMAIN
2) a signed A record
3) an unsigned but valid native A record

In either case, NXDOMAIN (option #1) kind of closes the options. I should expect the device(s) will prefer a signed record to an unsigned one, which might mean that the "Dual Stack Device" prefers a signed A record to an unsigned DNS64 AAAA record. If it gets two signed records, it's cook's choice, and the "Dual Stack Device" is likely to prefer the signed AAAA record to the signed A record "just because". If it gets no signed records, I don't know offhand how it would tell a native address from a DNS64 address without parsing the address in the AAAA record. So it might use a generated address to get to the PLAT or let the CLAT create an address to get to the PLAT. But in either case, if DNS64 is in use, it gets to the PLAT, so it probably doesn't matter.

                +--------+--------+----------+
  IPv6:    IPv4:|NXDOMAIN|Signed A|Unsigned A|
 +--------------+========+========+==========+
 |NXDOMAIN      |  fail  |use A   | use A    |
 +--------------+--------+--------+----------+
 |Signed AAAA   |use AAAA|choice  | use AAAA |
 +--------------+--------+--------+----------+
 |Unsigned AAAA |use AAAA|use A   | choice   |
 +--------------+--------+--------+----------+
 |DNS64 AAAA    |use AAAA|use A   | choice   |
 +--------------+--------+--------+----------+

But I don't see any case in which an unsigned record replaces a signed record, or a signed record cannot be verified, which is what would break DNSSEC.

Hence, I don't think DNS64 "breaks" DNSSEC. It enables connectivity in cases where NXDOMAIN would disable connectivity, and the user goes through a NAT, with all the evils that implies.