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

From: Lee Howard <[email-masked]>
Date: Tue, 02 May 2017 15:03:15 -0400

On 3/16/17, 7:02 AM, "Philip Homburg" <[email-masked] on
behalf of [email-masked]> wrote:

>>1. I do not think there is consensus that having PTRs is or is not a best
>>practice, so emphasizing the lack of consensus lets us move on to what an
>>ISP can do, if they care to do anything.
>>The first paragraph has been overhauled to say "While the need for a PTR
>>record and for it to match
>>   is debatable as a best practice, some network services [see Section 3]
>>still do rely on PTR lookups, and some check the source address of
>>incoming connections and verify that the PTR and A records match before
>>providing service.=B2
>
>Is it possible to have a separate section about e-mail?
>
>In my experience, without reverse DNS it is essentially impossible to have
>mail delivered to the internet at large.

Yes.

>
>So where most uses of PTR records are a nice to have to can be decided
>locally,
>for e-mail it is other parties on the internet that force the use of PTR
>records.
>
>At the same time, if someone is capable of operating a mail server then
>operating an auth. DNS server is not really out of line.

I agree that people reject mail if there¹s no PTR; I think this is used in
fighting spam, based on an inference that if there¹s no PTR, you¹re a spam
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.

The draft currently doesn't say the opposite, which is ³A mail server is
therefore expected to have a PTR.²
It does say, in 5.1 Using Reverse DNS for Security:
For instance,
   most email providers will not accept incoming connections on port 25
   unless forward and reverse DNS entries match.  If they match, but
   information higher in the stack (for instance, mail source) is
   inconsistent, the packet is questionable.  These records may be
   easily forged though, unless DNSsec or other measures are taken.  The
   string of inferences is questionable, and may become unneeded if
   other means for evaluating trustworthiness (such as positive
   reputations) become predominant in IPv6.

[continued below]

>
>So I'd like some text that describes the importance of reverse DNS for
>e-mail
>and then basically says that if an ISP allows customers to handle their
>own outgoing e-mail then that ISP SHOULD provide customers with a way of
>setting up PTR records for those mail servers, even if it is just
>delegating
>part of the name space by setting up NS records.

I¹ve 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¹s possible to
reconcile them, does this document need an affirmative statement about
mail servers? 

If so, I think I would revise this text:
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.

to say:

Evaluating mail servers: no PTR, or a PTR with a certain string, may
indicate
"This host is not a mail server," which may be useful for rejecting
probable spam. Therefore, legimitate mail servers are expected to
have a PTR matching forward.

But I do think this recommendation is covered under:
when a host has a static address and name,
   AAAA and PTR records should exist and match.

>
>Do you have a reference for the following statement
>Serving ads: "This host is probably in town.province."  An ISP that does
>not
>provide PTR records might affect somebody else's geolocation.

No. Given the privacy considerations, I¹ve changed the example from
³x.town.province² to ³string.region² and added privacy considerations. So
I need to fix this text anyway.

>
>Extracting geo information from reverse DNS is very hard. As far as I
>know,
>geo location services for IPv4 mostly rely on other sources.

That¹s 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, ³But reverse DNS is not a great source for geolocation
information²?

> 
>
>The following is not clear to me:
>Some ISP DNS administrators may choose to provide only a NXDomain
>response to PTR queries for subscriber addresses. [...]
>Providing a negative response in response to PTR
>queries does not satisfy the expectation in [RFC1912] for entries to
>match.  Users of services which are dependent on a successful lookup
>will have a poor experience.  For instance, some web services and SSH
>connections wait for a DNS response, even NXDOMAIN, before
>responding.
>
>Why would a NXDOMAIN response to a PTR query have a negative impact
>on performance? If any, it would be faster because it saves a forward
>lookup.
>
>Maybe you want to say that a PTR lookup has to result in a quick reply,
>even it is an NXDOMAIN. A delegation to a name server that does not
>respond
>will cause a delay in applications that wait for the reverse DNS lookup to
>complete.

Good note. I think I revised this paragraph several times, and it didn¹t
keep its integrity.

Old sentence:
Users of services which are dependent on a successful lookup
will have a poor experience.

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.

Old sentence:
For best user experience, then, it is important to
return a response, rather than have a lame delegation.

Proposed new sentence:
For best user experience, then, it is important to
return a response, including NXDomain, rather than have a lame delegation.

Resulting new paragraph (unformatted):
Some ISP DNS administrators may choose to provide only a NXDomain
response to PTR queries for subscriber addresses. In some ways, this
is the most accurate response, since no name information is known
about the host. Providing a negative response in response to PTR
queries does not satisfy the expectation in [RFC1912
<https://tools.ietf.org/html/rfc1912>] for entries to
match. 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.
 For instance, some web services and SSH
connections wait for a DNS response, even NXDOMAIN, before
responding. For best user experience, then, it is important to
return a response, including NXDomain, rather than have a lame delegation.
 On the other hand, external mail servers are likely to reject
connections, which
might be an advantage in fighting spam. DNS administrators should
consider the uses for reverse DNS records and the number of services
affecting the number of users when evaluating this option.

>
>I don't see a discussion about DNAME. Maybe that's worth adding?

Is it? There are several places where the document talks about delegating
authority for a prefix, but it never says how. Now that you mention it, I
see how it¹s relevant, but I¹m on the fence about whether there¹s anything
important to say that hasn¹t already been said in better documents.

Lee

---

From: Paul Vixie <[email-masked]>
Date: Tue, 02 May 2017 12:16:09 -0700

>> mail delivered to the internet at large.

since this isn't an ideal or intended state of affairs, let's consider
the size and shape of the box, not just what's in there.

http://www.circleid.com/posts/20110607_two_stage_filtering_for_ipv6_electronic_mail/

-- 
P Vixie

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 2 May 2017 17:00:09 -0400

> add text saying, ³But reverse DNS is not a great source for geolocation

For whatever it's worth, I know of one geolocation effort that uses
the names in the reverse as clues about geolocation improvement.  I am
not able to state who it is or how they use this, but I can testify
that it is in fact used that way.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Lee Howard <[email-masked]>
Date: Wed, 03 May 2017 07:10:01 -0400

>http://www.circleid.com/posts/20110607_two_stage_filtering_for_ipv6_electr

I think I read that post six years ago, too. :)

I don¹t think that recommendations on fighting spam are in scope for this
document, though. Is there text you think should be added?

Lee

---

From: Paul Vixie <[email-masked]>
Date: Wed, 03 May 2017 12:18:29 +0000

> document, though. Is there text you think should be added?

if you think the draft you have is the approach you must follow, then no.

however, the people fighting about PTR's are doing so because of spam control. 
there is no other operable modern need for these records in IP6.ARPA. it's a 
fight you can't win, because there is no right answer.

i suggest that you offer the PTR people a better way to do what they want to 
do, so that you can create an exit scenario from this debacle that would 
actually please somebody.

vixie

---

From: Philip Homburg <[email-masked]>
Date: Mon, 08 May 2017 18:30:31 +0200

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

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.
>plus the guidance that the information should match if it=B9s possible to
>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
>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.

>NXDomain response is faster.

Yes, that's clear and an important issue.

>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.

---

From: "John Levine" <[email-masked]>
Date: 11 May 2017 16:58:52 -0000

>the size and shape of the box, not just what's in there.

What would be the operational advantage of accepting mail from IPv6 hosts
too lame to set up rDNS?

R's,
John

---

From: Bjørn Mork <[email-masked]>
Date: Thu, 11 May 2017 19:14:52 +0200

> What would be the operational advantage of accepting mail from IPv6 hosts

The answer is pretty much the same as the answer to the question:
"What would be the operational advantage of accepting mail?"

Bjørn

---

From: Paul Vixie <[email-masked]>
Date: Thu, 11 May 2017 10:28:09 -0700

> What would be the operational advantage of accepting mail from IPv6 hosts

we will never know, because every v6 end system will have a ptr, either
naturally, or machine-generated for it, because v6 providers will not
want their rank-and-file v6 endsystems to be excluded from important
activities such as transmitting e-mail.

the operational advantage of not having ptr's for rank and file end
systems is much easier to explain, except to v6 endsystem providers.

-- 
P Vixie

---

From: "John R Levine" <[email-masked]>
Date: 11 May 2017 13:33:40 -0400

> activities such as transmitting e-mail.

You might want to talk to large providers that do v6 now.  With only one 
exception I can think of, they have no plans to do synthesized v6 rDNS, 
and they routinely block port 25 from all their consumer networks.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Paul Vixie <[email-masked]>
Date: Thu, 11 May 2017 10:34:47 -0700

> and they routinely block port 25 from all their consumer networks.

i'd like to meet your friends. but i'd also like them write an rfc about it.

-- 
P Vixie

---

From: "John R Levine" <[email-masked]>
Date: 11 May 2017 13:41:18 -0400

> i'd like to meet your friends. but i'd also like them write an rfc about it.

You've met a lot of them at M3AAWG.  Also see draft-ietf-dnsop-isp-ip6rdns

I hope we are not so foolish as to repeat the NAT fiasco and stick our 
fingers in our ears becuse the rest of the world doesn't work in a way 
some of us might prefer.

The reality is that if you want people to accept your v6 mail, your mail 
hosts need rDNS, and not rDNS that looks like it was autogenerated by 
kludges like BULK.

Regards,

---

From: Lee Howard <[email-masked]>
Date: Fri, 12 May 2017 08:16:42 -0400

>activities such as transmitting e-mail.

If ³v6 provider² includes ³residential ISP² (the topic and audience for
this draft), then the inability to transmit email is by design.
That is: ISPs commonly prevent residential users from sending email (by
default). They say this in their Terms of Service, they block port 25, and
they don¹t publish PTRs. This is consistent with recommendations by
M3AAWG[1] and BITAG[2], for instance.

[1] 
https://www.m3aawg.org/sites/default/files/document/MAAWG_Port25rec0511.pdf
 
[2] https://www.bitag.org/documents/Port-Blocking.pdf

I¹m pretty sure this is a consensus position.

>systems is much easier to explain, except to v6 endsystem providers.

People who run mail servers generally understand these limitations. The
BITAG paper does recommend clear disclosure and methods to opt-out. Makes
sense to me: I want a human decided they want their system to send mail,
not a bot.

Lee

---

From: Philip Homburg <[email-masked]>
Date: Sun, 14 May 2017 12:13:30 +0200

>If =B3v6 provider=B2 includes =B3residential ISP=B2 (the topic and audience=
> for
>they don=B9t publish PTRs. This is consistent with recommendations by

>sense to me: I want a human decided they want their system to send mail,

I wonder if with the EU netneutrality laws it is possible to have a blanket 
block if port 25 outbound. 

Historically, many ISP that wanted to upsell business accounts would
actually block port 25 inbound. Which does prevent relays but not bots
sending spam.

Of course having an option where the customer can request to port to be
opened and then have it closed by default is best. But that may be too
expensive for many ISPs.

But my goal was not to say something about whether port 25 should be
blocked or not. But just that based on todays internet and spam filtering,
if an ISP allows customers to send mail, then the ISP has to provide
the customer with a way of setting up reverse DNS.

I don't really care whether a reverse DNS check is good or bad when it
comes to filtering spam. It is just a reality that enough parties are
using such checks that without reverse DNS you have a serious issue
getting mail delivered.