Reverse DNS in IPv6 for Internet Service Providers
RFC 8501

Note: This ballot was opened for revision 06 and is now closed.

Warren Kumari Yes

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2018-09-26 for -06)
No email
send info
Abstract: Can "commonly provide IN-ADDR-ARPA information" be stated more conceptually in the abstract?

Alissa Cooper No Objection

Comment (2018-09-27)
No email
send info
Please respond to the Gen-ART reviewer. He had valuable comments.

Benjamin Kaduk No Objection

Comment (2018-09-27)
No email
send info
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?

Suresh Krishnan No Objection

Comment (2018-09-26)
No email
send info
* 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

Mirja Kühlewind No Objection

Comment (2018-09-20 for -06)
No email
send info
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….

(Terry Manderson) No Objection

Alexey Melnikov No Objection

Comment (2018-09-26 for -06)
No email
send info
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.

Alvaro Retana No Objection

Adam Roach No Objection

Comment (2018-09-25 for -06)
No email
send info
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)

Martin Vigoureux No Objection