Special Use Domain Name 'ipv4only.arpa'
Note: This ballot was opened for revision 16 and is now closed.
Warren Kumari Yes
Comment (2020-02-25 for -16)
Notes for reviewers / background: RFC7050 ("Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis") says that you should resolver the "well-known IPv4-only fully qualified domain name "ipv4only.arpa."" to determine the NAT64 prefix. Unfortunately RFC7050 didn't request that the name "ipv4only.arpa" be added to the Special Use Domain Name registry -- this document rectifies this oversight. I asked DNSOP (and BEHAVE) to review and provide feedback, and the authors have addressed the comments. Some additional (largely supportive) comments were received during IETF LC, and have been addressed as well. I figured some background / history might be helpful when you review this document. : This is oversimplified, but good enough for this purpose. : "one or more AAAA resource records indicates that the access network is utilizing IPv6 address synthesis."
Benjamin Kaduk (was Discuss) No Objection
Thanks for the updates in the -17, addressing much more than just my Discuss point! In Section 3.1, the sentence we now start with "Both for privacy reasons, and also because" now has a grammar nit, since the "so" in the second clause is now superfluous.
Roman Danyliw No Objection
Comment (2020-03-11 for -16)
** I appreciate that “.arpa” is “different” and that the behavior described in this draft is needed to make “things work”. However, I’m a concerned about requiring hard-coded behavior contrary to the intent (understanding?) of the user especially due to the discussion in Section 3.1 of why users/configurations are overriding the network’s preference. The text currently says: Section 4. Specifically: When querying for the name 'ipv4only.arpa', name resolution APIs and libraries should use the recursive resolver recommended by the network for the interface in question, rather than a recursive resolver configured manually, Section 7.1. Step 3. Learning a network's NAT64 prefix is by its nature an interface-specific operation, and the special DNS query used to learn this interface-specific NAT64 prefix MUST be sent to the DNS recursive resolver address(es) the client learned via the configuration machinery for that specific client interface. Put in another way, this guidance could be read as “even though the user might have explicitly configured a given setting (a particular DNS server) on an interface, ignore that, and use untrusted input off the network.”. Clearly this is a special case. Nevertheless, IMO, this needs some explicit mention to belabor the obvious in the Security Considerations (on the order of something like): -- Regardless of the user configured DNS setting, in this single case of resolving ipv4only.arpa, this setting will be ignored, in favor of the network provided configuration. This is acceptable because … <.arpa is special, etc.> -- The network provided DNS server MUST NOT be used for anything other than ipv4only.arpa if the user has set another DNS server. ** Section 3.1. Per “However, it is becoming increasingly common for users to manually override their default DNS configuration”, no disagreement on the phenomenon, but it is likely necessary to scope this to circumstances involving unmanaged endpoint outside of management enterprises. ** Section 3.1. Per the “corporate VPN client software” scenario where the VPN overrides the local network’s default configuration, this is also done outside of the corporate environment (e.g., on consumer-grade mobile device VPN services) to enhance privacy. ** Editorial -- Abstract and Section 1. Editorial. Missing word. OLD “… but in its Domain Name Reservation Considerations section that specification indicates that the name actually has no particularly special properties would require …” NEW “… but in its Domain Name Reservation Considerations section that specification indicates that the name actually has no particularly special properties the would require …” -- Section 2. It was jarring for me to read that we expect that clients should “already know” something because an RFC exists. I would have used softer language, perhaps like “conformant clients” and couched things as “expected behavior”. -- Section 4. Per “… so that software can legitimately implement the correct behavior necessary …”, using “legitimately” reads as judgement. The underlying spec didn’t mark ‘ipv4only.arpa’ as special after all (which is the whole point of this document).
Éric Vyncke No Objection
Comment (2020-03-12 for -16)
Thank you for the work put into this document. With the heavy load on this week telechat and all meetings related to the cancellation of the IETF-107 in-person meeting, I must admit that this review was not as thorough as I would hope :-( Please find below some non-blocking COMMENTs and NITs. Regards, -éric == COMMENTS == I agree with Barry's comment on the repetitions, and a rather verbose wording. -- Section 3.1 -- For my own curiosity, is there an impact by application having their own "hardcoded" DNS recursive servers? == NITS == -- Abstract and section 1 -- For non English-native speaker, I would suggest to add a "that" in "has no particularly special properties *that* would require special handling"
(Alexey Melnikov; former steering group member) Yes
Yes ( for -16)
(Barry Leiba; former steering group member) Yes
Yes (2020-03-09 for -16)
I have a few editorial comments only, none of which require any response: — Section 1.1 — Please use the boilerplate directly from 8174: it was debated and worded as it is (citing BCP 14) intentionally. — Section 2 — This is clearly not a typical DNS name. In normal operation, clients never query for the two records that do in fact exist; instead clients query for records that are known to not exist, and then get positive answers to those abnormal queries. Clients are using DNS to perform queries for this name, but they are certainly not using DNS to learn legitimate answers from the name's legitimate authoritative server. Instead, the DNS protocol has, in effect, been co-opted as an impromptu client-to-middlebox communication protocol, to communicate with the NAT64/DNS64 [RFC6146] [RFC6147] gateway, if present, and request that it disclose the prefix it is using for IPv6 address synthesis. This paragraph strikes me as a combination of duplication and verbosity. May I humbly suggest replacing it with something like this?: NEW This odd query behaviour comes not because clients are using DNS to learn legitimate answers from the name's legitimate authoritative server. Instead, the DNS protocol has, in effect, been co-opted as an improvised client-to-middlebox communication protocol, to look for a NAT64/DNS64 [RFC6146] [RFC6147] gateway and, if one is present, to request that it disclose the prefix it is using for IPv6 address synthesis. END I’ll note that this isn’t the only place where this document repeats itself (another example is the second paragraph of Section 3.2, and another is the repetition of “the 'ipv4only.arpa' zone MUST be an insecure delegation” in Secton 5). I’d prefer if the repeating repetitiousness were cleaned up, but I’m not going to push it further. — Section 3.1 — At the time of writing, examples of widely known public recursive resolver services include 22.214.171.124 [DNS1], 126.96.36.199 [DNS8], and 188.8.131.52 [DNS9]. What’s the value to this document or its readers to list these, in particular? It seems to me that the text leading up to this is adequate, and that this sentence and the associated references should be struck.
(Suresh Krishnan; former steering group member) Yes
Yes (2020-03-11 for -16)
Thanks for writing this document to correct the oversight in RFC7050. I do have a trivial nit that you might want to address (or feel free to ignore). * Section 3.1 While talking about public recursive resolvers being used in IPv6-only networks with NAT64, using their IPv4 addresses as their identifier makes me cringe. I would greatly prefer if they are referred to by their common names. Something like this would work At the time of writing, examples of widely known public recursive resolver services include Cloudflare Public DNS [DNS1], Google Public DNS [DNS8], and Quad9 [DNS9]
(Adam Roach; former steering group member) No Objection
No Objection ( for -16)
(Alissa Cooper; former steering group member) No Objection
No Objection ( for -16)
(Deborah Brungard; former steering group member) No Objection
No Objection ( for -16)
(Magnus Westerlund; former steering group member) No Objection
No Objection ( for -16)
(Mirja Kühlewind; former steering group member) No Objection
No Objection (2020-03-10 for -16)
One purely editorial comment: In section 2: "Instead, the DNS protocol has, in effect, been co-opted as an impromptu client-to-middlebox communication protocol,..." To be honest this confused me initially because for a while I thought there actually is some kind of proprietary protocol people use here while it's rather a "neat" hack. I would recommend to rather first clearly explain how and why this is used than just calling it a "impromptu client-to-middlebox communication protocol" right from the beginning.