Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt

[Philip Homburg <[e-mail]>]

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.