Last Call Review of draft-cheshire-sudn-ipv4only-dot-arpa-15
review-cheshire-sudn-ipv4only-dot-arpa-15-secdir-lc-salz-2020-01-23-00

Request Review of draft-cheshire-sudn-ipv4only-dot-arpa
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2020-02-17
Requested 2020-01-20
Authors Stuart Cheshire, David Schinazi
Draft last updated 2020-01-23
Completed reviews Secdir Last Call review of -15 by Rich Salz (diff)
Genart Last Call review of -15 by Erik Kline (diff)
Opsdir Last Call review of -15 by Scott Bradner (diff)
Intdir Telechat review of -16 by Bernie Volz (diff)
Assignment Reviewer Rich Salz
State Completed
Review review-cheshire-sudn-ipv4only-dot-arpa-15-secdir-lc-salz-2020-01-23
Posted at https://mailarchive.ietf.org/arch/msg/secdir/A78yNC9g4Mt6G7CDc5hrca0ZdqU
Reviewed rev. 15 (document currently at 17)
Review result Ready
Review completed: 2020-01-23

Review
review-cheshire-sudn-ipv4only-dot-arpa-15-secdir-lc-salz-2020-01-23

This is the security directorate review done on behalf of the Security AD's.  Others should treat this like a regular last-call review.

This document fills in a hole: RFC 7050  reserved the special DNS name "ipv4only.arpa" for determining how a client can find out its local network NAT64 prefix, but did not finish the job by not registering that name in the Special-Use Domain Name registry (SUDN).

I was surprised to see that this was an AD-sponsored document; various AD's may wish to discuss the rationale during IESG review.  The paranoic in me finds it interesting that https://datatracker.ietf.org/doc/draft-cheshire-sudn-ipv4only-dot-arpa/shepherdwriteup/ has no answer to question 9. :)

This is a good document plugging a hole, and explaining the impact on DNS in a variety of configurations.  Ship it.

Sec 3 discusses the intent and why ipv4only.arpa is special. Sec 4 discusses what happens when software doesn't do the implied/required special-casing.  It covers several types of deployments. Sec 5 provides what is missing from RFC 7050, but arguably is "better" because of the experience learned.  There is interaction between DNS64 and DNSSEC that is described in Sec 6. A variety of mechanisms are discussed and a migration path is proposed, ultimately justifying why the zone must be insecure. Sec 8, the SUDN registration section, recapitulates the previous sections without rationale or side-notes: if you read only one setion, read this.