In your letter dated Tue, 02 May 2017 15:03:15 -0400 you wrote: >I agree that people reject mail if there=B9s no PTR; I think this is used in >fighting spam, based on an inference that if there=B9s no PTR, you=B9re a s= >pam >bot rather than a legitimate mail server. >The first case listed in 4. Considerations and Recommendations says > > There are six common uses for PTR lookups: > > Rejecting mail: A PTR with a certain string or missing may indicate > "This host is not a mail server," which may be useful for rejecting > probable spam. The absence of a PTR leads to the desired behavior.
In the case of e-mail, my issue is more with the structure of the document than the actual text. To give an example where I'm coming from. The ISP I use for my home internet connection started out with IPv6 by offering tunnels. Given that tunnels are only used by tech savvy people, a simple editor where you could provide name servers for reverse DNS was offered and this worked well. Now that they offer native IPv6 there is no reverse DNS anymore. For two reasons. The first is that delegating reverse DNS is deemed to be to complex for ordinary users. The solution they want to implement, an editor where users can set individual records for hosts, has such a low priority that it never gets done. It has a low priority because oridinary users don't really need reverse DNS. What seems lost is that the IPv6 users that really need reverse DNS at the moment are the ones that try to have mail delivered and at the same time all of the reasons why oridinary users can't run DNS servers don't apply to that group. Reading the document, those two arguments are hard to find. I.e., in Section 4, I would say that most points are nice-to-haves, except for the one related to e-mail. At the same time, most options in Section 2 are quite tricky, except 2.4. So an ISP reading this draft may not realise that reverse DNS is really important for some customers and is relatively easy to provide to those users. >I=B9ve quoted much of that text above. >Given that the document is about residential ISPs, and given the above, >plus the guidance that the information should match if it=B9s possible to >reconcile them, does this document need an affirmative statement about >mail servers? = So my preference would be something that really stands out and not grouped together with, in my opinion, less important benefits. >That=B9s probably true. Given that I need to update it to match what it says >in the Privacy Considerations section and the examples, should I just >remove mention of geolocation? Or should I tweak it to match the rest, and >add text saying, =B3But reverse DNS is not a great source for geolocation >information=B2? I'd say that if having a location in reverse DNS serves the operational need for the ISP itself, then it's a good idea. Third parties may try to use that information, but it doesn't seem to be essential. By and large geo-location of eyeballs works fine even without location information in DNS. >Proposed new sentence: >Users of services which are dependent on a successful lookup >will have a poor experience if they have to wait for a timeout; an >NXDomain response is faster. Yes, that's clear and an important issue. >Proposed new sentence: >For best user experience, then, it is important to >return a response, including NXDomain, rather than have a lame delegation. I think that technically a lame delegation includes getting an error from the server. So by itself a lame delegation is not a problem. The problem is getting a timeout. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
