Ballot for draft-ietf-dnsop-isp-ip6rdns
Yes
No Objection
Note: This ballot was opened for revision 06 and is now closed.
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….