At Mon, 25 Apr 2016 16:50:42 -0400, Tim Wicinski <tjw.i...@gmail.com> wrote:
> This starts a Working Group Last Call for draft-ietf-dnsop-isp-ip6rdns > > Current versions of the draft is available here: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/ > > Please review the draft and offer relevant comments. Also, if someone > feels the document is *not* ready for publication, please speak out with > your reasons. I've read the latest version (01) of the draft. I don't think this document is ready for publication. I think a good summary of why not is this comment by Stephane Bortzmeyer: "It seems this document did not take into account the lessons from the failure of draft-ietf-dnsop-reverse-mapping-considerations". The draft as currently written looks quite awkward, especially if considering the role of reverse mapping that many of this wg participants seemingly have in their mind. In my understanding everyone agrees a revers mapping can be useful for purposes like debugging or pure logging, but many of us doubt the use of reverse mapping for purposes like access controls. And, because of the second point, the attempt of making a reverse-forward match is pretty dubious, especially if it involves technical difficulties such as scalability issues, since this matching is quite tightly coupled to the practices like PTR-(and matching with forward)-based access control; for the purpose of logging helpful information only human-readable PTR should suffice. Yet the focus of this document is about how to ensure the forward-reverse match. It may be true that this draft does not encourage that practice. But if the wg is generally suspicious about the practice in the first place, it would look quite awkward that the same wg is going to publish something that describes how to do that practice. One common "excuse" to resolve such conflict is to say that we are just describing what operators want or might do without either encouraging or discouraging the practice. But, again, if the wg generally thinks such a practice doesn't make sense, this logic doesn't make much sense either to me. If we really think such a practice has no sense, we should more explicitly say so and even discourage it; or, if we actually think we should change our own mind so it's consistent with what operators want to do, we should rather encourage it more explicitly. In my view, this is one of the main reasons why draft-ietf-dnsop-reverse-mapping-considerations failed: it tried to provide some balanced position between what operators out there think/want with reverse mapping and what (most of?) wg participants consider those practices with reverse mapping, but its vague tone was confusing or misleading, and yet we couldn't agree on providing a stronger statement on either side. draft-ietf-dnsop-isp-ip6rdns seems to inherit this particular problem from reverse-mapping-considerations. I'm not sure how we can move forward from here *if* my above concerns are valid. I can think of a few possibilities, but I'm afraid the author (and probably other people) don't like these: - drop the focus on ensuring reverse-forward match and just state some ideas of how we can provide IPv6 reverse mappings if someone wants them - keep the current content, but clearly state that the IETF (and dnsop) wg thinks these are bad ideas but document it since operators don't listen what wg thinks anyway - publish it as an individual draft rather than a wg document so that it will be clearer that it's independent from wg's view on practices with revers mappings. dnsop can still provide superficial technical comments. Some other general comments on the draft body follow. They are generally irrelevant to the bigger issue I stated above: - Section 2.1: [...] For best user experience, then, it is important to return a response, rather than have a lame delegation. Although a general statement this is true, and while the definition of "lame delegation" may not be robust, I don't think we generally use the term "lame delegation" for issues described around here (e.g., simply meaning some name doesn't exist). - Section 2.3 [...] There is no standard way to indicate to a host what server it should send dDNS updates to. This may be true in a strict sense, but I thought it's widely adopted practice to use SOA's MNAME to identify the server to which a particular DNS update should be sent. - Section 2.3.1 Once it learns its address, and has a resolving name server, the host must perform an SOA lookup on the ip6.arpa record to be added, to find the owner, eventually to find the server authoritative for the zone (which might accept dynamic updates). [...] [...] Once found, the host sends dynamic AAAA and PTR updates using the concatenation defined above ("hostname.customer.example.com"). I see what it tries to say, but this doesn't seem to be very accurate. Usually those AAAA and PTR would belong to different zones. In particular the owner name of the AAAA wouldn't belong to an ip6.arpa domain. - Section 2.3.2 The alternate option is for the gateway to relay dynamic DNS updates from hosts to the servers and domain provided by the ISP. I don't understand this "forwarding" behavior. Can this be described in more detail? - Section 2.3.3 If a device requests a DHCPv6 Prefix Delegation, that may be considered a reasonably reliable indicator that it is a gateway, [...] If and when the recommendation of using DHCPv6 PD by end hosts in draft-ietf-v6ops-host-addr-availability is more widely used this may become not true. - Section 2.3.3 [...] In fact, this kind of delegation will not work for devices complying with [RFC6092], which includes the requirement, "By DEFAULT, inbound DNS queries received on exterior interfaces MUST NOT be processed by any integrated DNS resolving server." Is this true? I thought this restriction is about queries with the RD bit on, and in case of an auth-recursive hybrid server, only about queries that don't belong to zones that the server has authority. - Section 2.5 [...] unsigned records can indicate that these records are less trusted, which might be acceptable. I don't understand this...if this is a signed zone and some RRset in that zone is provided as an answer without an RRSIG, that answer is not just "less trusted", but should be considered to be invalid. - Section 3 [...] lame delegation should be avoided. I suspect this use of 'lame delegation' is not appropriate (see above). Minor points/editorial matters: - Section 1.1: I guess '\.' should be '.' \. - Section 1.2: s/f00/f00::/ 2001:db8:f00/48 zone alone, even with automation it is impractical to - Section 2.3: s/ERROR/error/? ('ERROR' is not a mnemonic of a standard DNS RCODE): not assured, though the host should expect an ERROR or NOERROR message from the server [RFC2136]; TCP provides transmission control, -- JINMEI, Tatuya _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
