Reverse DNS in IPv6 for Internet Service Providers
draft-ietf-dnsop-isp-ip6rdns-07

Thanks for the thought and work that went into this well-written document. I
have only two relatively minor comments.

---------------------------------------------------------------------------

§2.1:

>  For best user experience, then, it is important to
>  return a response, rather than have a lame delegation.

In light of [1] (and its ensuing thread) and [2], the authors may wish to
consider a different term than "lame" for this description.

____
[1] https://mailarchive.ietf.org/arch/msg/ietf/W6wSh3TDfetVY6eeDAu8FNcCKeA
[2] https://en.wikipedia.org/wiki/List_of_disability-related_terms_with_negative_connotations

---------------------------------------------------------------------------

§2.5:

If I read things correctly, A naïve implementation of what is described in
this section would result in the nameserver using some amount of state for
each IPv6 PTR record that was queried, for the duration of the TTL. Given the
extraordinary expanse of IPv6 space that such a server is likely delegated, it
seems that there's an attack in here whereby an attacker asks for an arbitrary
number of PTR records within a single server's range, each resulting in
additional memory consumption for whatever time period the TTL represents.

There probably should be some text in here warning implementations to guard
against such attacks either by limiting such storage, or by generating such
names in a deterministic way such that they don't require cacheing or
pre-populating AAAA records (instead generating them on the fly)

I feel a bit underwhelmed by this document: it defines problems, list some solutions, but doesn't always provide an advice. Statements like "The string of inferences is questionable, and may become unneeded if other means for evaluating trustworthiness (such as positive reputations) become predominant in IPv6." are true, but doesn't really help me if I need to solve the problem.

Nit: CPE acronym is used without being defined.

Please respond to the Gen-ART reviewer. He had valuable comments.

Abstract: Can "commonly provide IN-ADDR-ARPA information" be stated more conceptually in the abstract?

Thanks for the well-written document!  I wrote down some thoughts
I had while reading, but they should be treated as very weak suggestions
and no pressure to apply them is implied.

Section 2.1

                                            DNS administrators should
   consider the uses for reverse DNS records and the number of services
   affecting the number of users when evaluating this option.

nit: maybe this could be qualified as "number of services relying on PTR
records", as otherwise it can be read as a bit of a non sequitur.

Section 2.3

   Administrators may want to consider user creativity if they provide
   host names, as described in Section 5.4 "User Creativity."

Perhaps "the risks of user creativity"?

Section 2.3.1

                                    This option may be scalable,
   although registration following an outage may cause significant load,
   and hosts using privacy extensions [RFC4941] may update records
   daily.  [...]

I think I've heard of deployments that update more often than daily, though
it's unclear that there's a need for this document to mention such
possibilities.

Section 4

   There are six common uses for PTR lookups:

I'm a little uncomfortable asserting this as a complete and exhaustive
listing in an Informational document, but I also can't dispute its
veracity.  I'll trust that the authors and WG have done sufficient research
and not request any change here.

                                                 For residential users,
   if these four use cases are important to the ISP, the administrator
   will then need to consider how to provide PTR records.

... but I do have to wonder which four of the six the ISPs are supposed to
be considering.

                        A valid negative response (such as NXDOMAIN) is
   a valid response, if the four cases above are not essential;
   delegation where no name server exists should be avoided.

... and similarly here.

Section 5.1

   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.

It may be worth clarifying that the sensitive nature is an argument for not
publishing, since there aren't really well-established schemes for
filtering access to the relevant DNS records.

Section 5.3

Maybe say something about "for use in other protocols" if we're not trying
to limit to DNSKEY and friends?

One comment on terminology: I don't think "transmission control" is actually a well-defined term, besides that TCP stands for transmission control protocol. However, the services TCP provides are usually called connection-orientation and reliability (and flow and congestion control aso.). I guess what's most import in your case is reliability….

* Section 1.2.

"and may be short-lived."

Maybe worth adding a reference to RFC4941 here (already in the references). "and may be short-lived. e.g. temporary addresses from [RFC4941]"

* Section 2.3.1. and 2.3.2.

RFC6106 has been obsoleted. Replace with reference to RFC8106