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

[JORDI PALET MARTINEZ <[e-mail]>]

Hi Fred,



I think is much simpler than all that.



DNSSEC is *only* broken if the dual-stack host is doing DNSSEC validation over the synthetized AAAA.



That's why, according Jen work, it only happens around 1.7% of the times, because not many OSs/apps/hosts do that (today). Of course, the goal of DNSSEC deployment is that it always done, so this % may increase.



Of course, it may happen as well in the ISP DNSSEC validator (or other validators being used, etc.), if is a DNS which is now aware of DNS64. For example, default DNS64 in bind, doesn't cause that problem, unless you wrongly configure it.



The point is if I'm an ISP, even if 1.7% is very small fraction, do I want that to come back to my call-center?



Even if I'm an ISP deploying DNS64, users change DNSs ... so they may break other aspects (NAT64 prefix discovery), or they will end up using 8.8.8.8 and of course this is not a DNS64.



I think I've explained that in the document but will make sure to review any relevant text where it is not clear.



Regards,

Jordi

 

 



-----Mensaje original-----

De: Fred Baker <[e-mail]>

Fecha: lunes, 2 de julio de 2018, 21:55

Para: JORDI PALET MARTINEZ <[e-mail]>

CC: "[e-mail] list" <[e-mail]>

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



    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.

    




**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.