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 revision | 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 | |
I-D 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 O. Bradner (diff) Intdir Telechat review of -16 by Bernie Volz (diff) |
|
Assignment | Reviewer | Rich Salz |
State | Completed | |
Request | Last Call review on draft-cheshire-sudn-ipv4only-dot-arpa by Security Area Directorate Assigned | |
Posted at | https://mailarchive.ietf.org/arch/msg/secdir/A78yNC9g4Mt6G7CDc5hrca0ZdqU | |
Reviewed revision | 15 (document currently at 17) | |
Result | Ready | |
Completed | 2020-01-23 |
review-cheshire-sudn-ipv4only-dot-arpa-15-secdir-lc-salz-2020-01-23-00
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.