Thanks for the lively discussion!
Here's what I heard, in addition to several useful, non-controversial text
suggestions:
1. Uses for reverse DNS
a. Several people think it's unnecessary to require PTRs. A few even
think a lack of PTRs might be a good thing (in the case of mail servers
rejecting connections).
b. A few people think they are useful, because their servers can put the
PTR response in logs and they have some idea where a connection came from.
Others point out that WHOIS is a better source, with debate about the
usefulness and utility of WHOIS. In my opinion, the need should be filled
as close as possible to those who need it: don't rely on ISPs to develop
infrastructure for your convenience, without any benefit to them.
c. I did not see anyone say that PTRs are required. Some people have
asked me to take a position, in this or another document, that PTRs are not
required (for residential Internet users). Someone else may submit that
document.
2. Delegation: Several people support delegating to the home gateway.
a. There is no mechanism to tell a home gateway that it is now
authoritative for "12345.customer.example.net." Or is there? Without that,
it also wouldn't know what FQDN to put in PTR RRs.
b. Violates RFC6092 REQ-8.
c. Delegating to a single auth nameserver may or may not be acceptable.
d. (from v6ops) ISP should slave from customer CPE
3. Dynamic DNS
a. Several people like dDNS, but it isn't clear that there's an existing
mechanism for telling hosts to whom to send their dDNS updates.
b. dDNS does help the case of privacy or other temporary addresses
Of ~13 people commenting, I heard three people explicitly say, "Please
publish this document" and one say, "This doesn't provide enough practical
advice about how to do in IPv6 what we did in IPv4; maybe write a
requirements doc instead."
One approach to finding consensus then:
1. Update the document to reflect the points in #1 above.
2. Support someone else writing a draft called "PTRs unnecessary" or
whatever. I have someone in mind.
3. Document the problems with #2(a) and #3(a) above. Since there is
currently no mechanism, no requirements document, and no charter to change
these limitations, this provides the best information available at this
time.
4. Write a requirements document to fill gaps in #2 and #3. This may
coincidentally fall into work spinning off from 6renum. I would very much
like co-authors for this, since I will not be able to give it my full
attention.
As I make responsive changes, I will also try to change the tone a bit, from
a survey of possible mechanisms, to guidance for operators ("Here's what
operators should do; here are other possible mechanisms, and why they aren't
worth bothering about.")
Thanks again for the very useful feedback and discussion. I hope this
message will reflect rough consensus, or at least clearer detail of where
I've missed the point.
Lee
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
