Special Use Domain Name 'ipv4only.arpa'
draft-cheshire-sudn-ipv4only-dot-arpa-17

** 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).

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"

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.

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.