Skip to main content

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.