Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-isp-ip6rdns

[Stephane Bortzmeyer <[e-mail]>]

On Mon, Apr 25, 2016 at 04:50:42PM -0400,
 Tim Wicinski <[e-mail]> 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.