On Mon, Apr 25, 2016 at 04:50:42PM -0400, Tim Wicinski <[email protected]> wrote a message of 24 lines which said:
> This starts a Working Group Last Call for draft-ietf-dnsop-isp-ip6rdns Summary: I think it must *not* be published as it is. The biggest problem is that it fails to explain why it is necessary to provide a PTR. RFC 1912, quoted, is just informational and its sentence "Every Internet-reachable host should have a name" does not use RFC 2119 terms. RFC 1912 was written in 1996 when one computer per home was already a lot! Now, every home has four or five connected machines and it will probably increase a lot in the next years. I see no point in giving a PTR to any Internet-connected printer or webcam. (And it raises privacy issues, see my last remark.) It seems this document did not take into account the lessons from the failure of draft-ietf-dnsop-reverse-mapping-considerations (which is in the references but never mentioned in the draft, something that the RFC editor will complain about). Basically, it seems there is no consensus inside IETF about the PTR so this draft should be careful. Now, the details: > Some network services perform a PTR lookup on the source address of > incoming packets before performing services. True, but it does not say what they do with the result. Example: by default, Postfix does a PTR request on the IP address of the incoming client but, by default, does nothing if it returns a NXDOMAIN. > 2.1. Negative Response The entire paragraph is very confused and mixes a timeout and a NXDOMAIN. It must be rewritten to say that timeouts (whether because a lame delegation or not) MUST NOT happen but a NXDOMAIN is a perfectly legitimate response. > In fact, this kind of delegation will not work for devices complying > with [RFC6092], which includes the requirement, This requirment is for resolvers (because of RFC 5358) and does not apply here where you talk about authoritative service. > Most users have neither the equipment nor the expertise to run DNS > servers, so this option is unavailable to the residential ISP. Let's be more careful: "this option cannot be a general solution today to the residential ISP." > Providing location information in PTR records is useful for > troubleshooting, law enforcement, and geolocation services, but for > the same reasons can be considered sensitive information. You could also mention that these information are not validated in any way; the people can lie. And, if you force them to provide a PTR, they will lie, for privacy reasons. _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
