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

[Woodworth, John R]

> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of John R Levine
> Sent: Thursday, May 11, 2017 1:41 PM
> To: Paul Vixie
> Cc: dnsop@ietf.org
> Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt
>
> >> 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.
> >
> > 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.
>

Looks like the radioactive spider that bit me was from the control group
because there was no tingling of my spidey sense :)

I echo the point of email servers being assigned a real rDNS to cut down
on heartburn.  Thankfully one of BULK's features ensures real RRs can
easily coexist within a synthesized range.

BTW: kludge seems harsh for a carefully thought-out solution


/John

>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
-- THESE ARE THE DROIDS TO WHOM I REFER:
This communication is the property of CenturyLink and may contain confidential 
or privileged information. Unauthorized use of this communication is strictly 
prohibited and may be unlawful. If you have received this communication in 
error, please immediately notify the sender by reply e-mail and destroy all 
copies of the communication and any attachments.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Philip Homburg]

>>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.
>
>If =B3v6 provider=B2 includes =B3residential ISP=B2 (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=B9t publish PTRs. This is consistent with recommendations by
>M3AAWG[1] and BITAG[2], for instance.

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

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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John R Levine]

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.


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,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

John R Levine wrote:
> 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.

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

-- 
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John R Levine]

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


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.


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, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

John Levine wrote:
 In my experience, without reverse DNS it is essentially impossible to have
 mail delivered to the internet at large.
>>> Yes.
>> 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.
> 
> What would be the operational advantage of accepting mail from IPv6 hosts
> too lame to set up rDNS?

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Bjørn Mork]

"John Levine"  writes:

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

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



Bjørn

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[John Levine]

In article <5908daf9.90...@redbarn.org> you write:

>> behalf of pch-dnso...@u-1.phicoh.com> wrote:
>> 
>>> In my experience, without reverse DNS it is essentially impossible to have
>>> mail delivered to the internet at large.
>> 
>> Yes.
>
>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.

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

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Philip Homburg]

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

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

[Lee Howard]

On 5/2/17, 3:16 PM, "DNSOP on behalf of Paul Vixie"
 wrote:

>
>
>Lee Howard wrote:
>> 
>> On 3/16/17, 7:02 AM, "Philip Homburg" > behalf of pch-dnso...@u-1.phicoh.com> wrote:
>> 
>>> In my experience, without reverse DNS it is essentially impossible to
>>>have
>>> mail delivered to the internet at large.
>> 
>> Yes.
>
>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_electr
>onic_mail/

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


>
>-- 
>P Vixie


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Andrew Sullivan]

On Tue, May 02, 2017 at 03:03:15PM -0400, Lee Howard wrote:
> >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²?

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
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Vixie]

Lee Howard wrote:
> 
> On 3/16/17, 7:02 AM, "Philip Homburg"  behalf of pch-dnso...@u-1.phicoh.com> wrote:
> 
>> In my experience, without reverse DNS it is essentially impossible to have
>> mail delivered to the internet at large.
> 
> Yes.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Lee Howard]

On 3/16/17, 7:02 AM, "Philip Homburg"  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,
    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 

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

[Philip Homburg]

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

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.

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.

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.

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

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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

Title   : Reverse DNS in IPv6 for Internet Service Providers
Author  : Lee Howard
Filename: draft-ietf-dnsop-isp-ip6rdns-03.txt
Pages   : 14
Date: 2017-03-04

Abstract:
   In IPv4, Internet Service Providers (ISPs) commonly provide IN-
   ADDR.ARPA information for their customers by prepopulating the zone
   with one PTR record for every available address.  This practice does
   not scale in IPv6.  This document analyzes different approaches and
   considerations for ISPs in managing the ip6.arpa zone for IPv6
   address space assigned to many customers.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-isp-ip6rdns-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-isp-ip6rdns-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop