Subject: [DNSOP] relax the requirement for PTR records?

From: Lee Howard <[email-masked]>
Date: Wed, 13 May 2015 10:57:21 -0400

I'm revising draft-howard-isp-ip6rdns again. Several folks have said
something like, "There should be no expectation that a residential ISP will
populate PTRs for all of its customers." When I started this document, five
or six years ago, there didn't seem to be consensus on that point. I hear a
lot of support for it these days, and disdain for people who rely on PTRs.
(I think we generally agree that PTRs for servers are good).

Is there consensus now that ISPs don't need to provide PTRs for their
customers?

Thanks,
Lee

From:  Shumon Huque <[email-masked]>
Reply-To:  <[email-masked]>
Date:  Wednesday, April 1, 2015 at 10:05 PM
To:  Alain Durand <[email-masked]>
Cc:  Lee Howard <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [DNSOP] draft-howard-isp-ip6rdns-07.txt

> On Tue, Mar 31, 2015 at 4:31 PM, Alain Durand <[email-masked]> wrote:
>> 
>> 3) There is another solution, that is do nothing, i.e. Do NOT populate the
>> reverse tree.
>>    Probably ISPs on that path would like to see an update to RFC1033 &
>> RFC1912 to
>>    explicitly say that the PTR record requirement is relaxed in IPv6 (and
>> maybe
>>    in IPv4 as well?)
>> 
>> The mere fact that this draft is still here many years after the effort
>> was started should tell us somethingŠ It would appear as if the world is
>> on path 3) above.
> 
> I agree with Alain.
> 
> With widespread use of stateless address auto-configuration and privacy
> addresses, I don't think the blanket PTR requirements/recommendations in those
> old RFCs are practical or relevant to IPv6. They make sense for IPv6 servers
> and statically configured computers, but not dynamically configured clients.
> And it might make sense to update those documents not only to relax those
> requirements for IPv6, but also to dissuade IPv6 services deployers from using
> reverse DNS checks as a pre-condition to providing service.
> 
> If the ISP is offering DHCPv6, they might be able to prepopulate the reverse
> DNS for a sufficiently small address pool. For non-residential/business
> customers that are planning to run servers, I assume they'd get static address
> assignments and either run their own DNS, and/or have the ISP configure static
> reverse DNS entries for them.
> 
> When I was involved in running a large IPv6-enabled campus network, no client
> computers (predominantly using SLAAC/privacy addresses) got IPv6 PTR records
> and I never heard of any issues encountered by them in accessing IPv6
> services. Same goes for many of my peers in the R&E world (many of whom were
> early adopters of IPv6). SMTP servers are one category of services where it's
> still popular to do client PTR checks even for v6, but most IPv6 clients don't
> deliver to mail servers directly (they usually talk to a submission server,
> where user authentication is the access control mechanism used, rather than
> PTR checks).
> 
> Shumon Huque
> 
> _______________________________________________ DNSOP mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Wouters <[email-masked]>
Date: Wed, 13 May 2015 11:05:16 -0400 (EDT)

On Wed, 13 May 2015, Lee Howard wrote:

> Is there consensus now that ISPs don’t need to provide PTRs for their customers?

No.

As long as the anti-spam meassures include refusing email from IPv6
without PTR's, such a consensus would mean taking the ability away from
people running their own mail servers with IPv6 on ISP controlled IPv6.

Without the PTRs, sadly those IPv6 addresses are not equal peers on the
internet, but only marginally better than a NATed IPv4 address.

Paul

---

From: Shane Kerr <[email-masked]>
Date: Wed, 13 May 2015 15:08:17 +0000

Lee,

I think this is reasonable.

(I'd actually like to go further and say "there is no expectation that
there is a PTR for any address", but I recognize this is a minority
view.) ;)

Cheers,

--
Shane

On Wed, 13 May 2015 10:57:21 -0400

---

From: Tony Finch <[email-masked]>
Date: Wed, 13 May 2015 16:12:11 +0100

> Is there consensus now that ISPs don't need to provide PTRs for their

ISPs should delegate the relevant part of the IPv6 reverse DNS tree to the
customer, so the customer can provision PTR records as required.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay: West or southwest 4 or 5, increasing 6 or 7. Moderate, becoming rough
later. Rain or showers. Moderate or good.

---

From: Rubens Kuhl <[email-masked]>
Date: Wed, 13 May 2015 12:16:24 -0300

> Em 13/05/2015, à(s) 12:05:000, Paul Wouters <[email-masked]> escreveu:
> 

I don't see why they would be exclusive. ISPs could have authority servers for all their assigned IPv6 space, but do not have records in the zone unless for users that specifically require them. So, for most usages which don't include running mail servers, there would be no records but a NXDOMAIN/NSEC/NSEC3 response will be provided in order for MTA to use in anti-spam decisions, closed systems authentication factor etc. 

If the user has a fixed IPv6 delegation (possibly a /64) and/or the provider has Dynamic DNS allowing a PTR to be populated by a dynamic IPv6 allocation (either the WAN address or a DHPC-PD allocated LAN address), then the provisioning system / processes would add a proper PTR for the user. 

What is useless is populating a gazillion of PTRs with an auto-generated pattern... and since the pattern is not standard, anti-spam designers have to chase whether is dynamic.provider.net or adsl.otherprovider.co.cc etc. Non-existent DNS is a standard way to say there is no information for that query. 

Rubens

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 May 2015 11:18:40 -0400

> customer, so the customer can provision PTR records as required.

Yes, this is what we should recommend. I don't expect all ISPs to do this, but it's the right thing to do on a technical level, unless we want to deprecate PTR records. The idea that this shouldn't happen goes against the notion of end-to-end service on the internet: it presumes that "providers" are not "end users," and while this is a prevalent business model at the moment, I don't think it's a business model the IETF should be favoring (or, to be clear, that we should be discouraging either).

---

From: Shane Kerr <[email-masked]>
Date: Wed, 13 May 2015 15:18:48 +0000

On Wed, 13 May 2015 11:05:16 -0400 (EDT)

> internet, but only marginally better than a NATed IPv4 address.

I thought it was best practice to block SMTP from residential
customers? This is the case for my past 3 ISPs (although one had an
opt-out if you really wanted to run a mail server).

Cheers,

--
Shane

---

From: Bill Owens <[email-masked]>
Date: Wed, 13 May 2015 11:20:10 -0400

> internet, but only marginally better than a NATed IPv4 address.

In their (desperate) efforts to prevent spam, my provider blocks tcp/25 outbound. It makes no difference whether I have a PTR or not, I can't connect to any mail servers. And AFAIK that's fairly common, at least in the US.

My provider doesn't support v6 yet, so I don't know whether this policy will extend there; I have every expectation that it will.

Bill.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 May 2015 11:22:31 -0400

> opt-out if you really wanted to run a mail server).

It's probably not a good idea to descend into flames on this here. This is certainly accepted common practice, but it does cause a lot of operational problems as well, not the least of which is that it means ISPs have to operate firewalls to block traffic from their customers. I don't think we are in a position to advise against this practice, but it's entirely orthogonal to the PTR record question, so we shouldn't factor it into the discussion.

---

From: Lee Howard <[email-masked]>
Date: Wed, 13 May 2015 11:30:50 -0400

On 5/13/15, 11:05 AM, "Paul Wouters" <[email-masked]> wrote:

>> Is there consensus now that ISPs don¹t need to provide PTRs for their
>>customers?
>
>No.
>

I would contend that those IPv6 addresses are NOT equal peers, for the
sake of SMTP.

But just because I disagree with you doesn¹t mean I won¹t count your
opinion.

Lee

---

From: Daniel Migault <[email-masked]>
Date: Wed, 13 May 2015 15:33:54 +0000

In homenet we discussed how the CPE can outsource the reverse zone to a third party. This means that we considered the reverse zone generation could be delegated to each customer by the ISP. 

BR, 
Daniel
-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Wednesday, May 13, 2015 11:19 AM
To: Tony Finch
Cc: Lee Howard; [email-masked]
Subject: Re: [DNSOP] relax the requirement for PTR records?

On May 13, 2015, at 11:12 AM, Tony Finch <[email-masked]> wrote:
> ISPs should delegate the relevant part of the IPv6 reverse DNS tree to 
> the customer, so the customer can provision PTR records as required.

Yes, this is what we should recommend. I don't expect all ISPs to do this, but it's the right thing to do on a technical level, unless we want to deprecate PTR records. The idea that this shouldn't happen goes against the notion of end-to-end service on the internet: it presumes that "providers" are not "end users," and while this is a prevalent business model at the moment, I don't think it's a business model the IETF should be favoring (or, to be clear, that we should be discouraging either). 
_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Lee Howard <[email-masked]>
Date: Wed, 13 May 2015 11:34:50 -0400

>customer, so the customer can provision PTR records as required.

This is already addressed in the draft.
draft-howard-isp-ip6rdns-07 section 2.3.3 and 2.4, and in the
recommendations.

Lee

---

From: Jim Reid <[email-masked]>
Date: Wed, 13 May 2015 16:49:50 +0100

> customer, so the customer can provision PTR records as required.

An ISP should have the ability to *provision* that. Whether they actually delegate this or not is another matter.

The typical retail customer doesn't even know DNS exists or how to make changes to it and why they might need to do so. Their ISP will not want them messing with CPE (or whatever) either. In these cases, delegating reverse zones and expecting customers to do anything worthwhile with them would be misguided at best. YMMV.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 13 May 2015 09:02:25 -0700

Lee Howard wrote:
> I’m revising draft-howard-isp-ip6rdns again. Several folks have said
> something like, “There should be no expectation that a residential ISP
> will populate PTRs for all of its customers.” When I started this
> document, five or six years ago, there didn’t seem to be consensus on
> that point. I hear a lot of support for it these days, and disdain for
> people who rely on PTRs. (I think we generally agree that PTRs for
> servers are good).
>

i can't judge consensus, but i would join one on this point.
manufacturing PTR RR's for every IoT device we connect is crazy talk. in
1995 or so william simpson proposed an ICMP message to ask an endpoint
its name, and at the expected density, this is still a better plan for
anything that's not a server.

note that i will continue to filter my inbound SMTP based on the
presence/absence of a PTR. in other words if the consensus turns out to
be that other than for "servers" PTR's are unnecessary, we'll be helping
anti-spam.

-- 
Paul Vixie

---

From: Tony Finch <[email-masked]>
Date: Wed, 13 May 2015 17:16:29 +0100

Jim Reid <[email-masked]> wrote:
>
> The typical retail customer doesn't even know DNS exists or how to make
> changes to it and why they might need to do so.

That is an argument for delegating relevant zones to the customer's
equipment so that it can be auto-configured. e.g. the customer clicks a
"sharing" tickybox and DNS-SD records get automatically added.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall: Southeasterly backing easterly 5 to 7, occasionally gale 8 in
southwest. Moderate or rough. Rain for a time in south. Good, occasionally
moderate.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 13 May 2015 09:39:36 -0700

> internet, but only marginally better than a NATed IPv4 address.

yet with those PTR's, we must all laboriously survey and record every
machine-generated PTR pattern so that we can train our SMTP servers to
pretend that machine-generated PTR RR's don't exist. this is either
foolishness or damn foolishness depending on where you are in the spam
chain.

providers should delegate PTR space with the address space, and let each
consumer decide what to do. if a provider does not do this because they
don't want their customers to be able to transmit SMTP or otherwise be
"equal peers" that is a business decision (and perhaps a political one
if last-mile monopoly is involved) not a technical one. this WG's job is
to recommend a standard practice, based on engineering matters, which
includes engineering economics such as total system cost.

simply put, the total system cost with machine-generated PTR's is
uselessly high.

-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Wed, 13 May 2015 09:44:44 -0700

> "sharing" tickybox and DNS-SD records get automatically added.

+1. i've been talking to jim gettys and dave taht about exactly that,
and it's clear to me this will be built, with or without homenet, and
that it will become as common a CPE option as "dynamic dns" is today.
so, yes, providers should delegate.
 
-- 
Paul Vixie

---

From: 神明達哉 <[email-masked]>
Date: Wed, 13 May 2015 10:51:09 -0700

At Wed, 13 May 2015 09:02:25 -0700,

> anything that's not a server.

(maybe an off-topic for this thread but FYI) We have a "standard" of
this for IPv6: RFC4620.  Unfortunately it's mostly useless in practice
since it MUST be refused for global use by default.

--
JINMEI, Tatuya

---

From: Richard Lamb <[email-masked]>
Date: Wed, 13 May 2015 17:58:56 +0000

FWIW, I agree w/ Paul and Ted.  Customer should have the option to fill in reverse IPv6 tree.  
Arent we headed toward a society where we all become content providers with "the cloud" just a recurring fad?
-Rick

-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of Lee Howard
Sent: Wednesday, May 13, 2015 8:35 AM
To: Tony Finch
Cc: [email-masked]
Subject: Re: [DNSOP] relax the requirement for PTR records?

This is already addressed in the draft.
draft-howard-isp-ip6rdns-07 section 2.3.3 and 2.4, and in the recommendations.

Lee

>Biscay: West or southwest 4 or 5, increasing 6 or 7. Moderate, becoming 
>rough later. Rain or showers. Moderate or good.
>

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 14 May 2015 13:10:59 +0900

> Is there consensus now that ISPs don't need to provide PTRs for their

You are effectively saying that ISPs can forbid their customers
run good servers.

						Masataka Ohta

---

From: Edward Lewis <[email-masked]>
Date: Thu, 14 May 2015 10:14:34 +0000

I lost a more comprehensive response due to an application crash...

IMHO, asking this in DNSOP is not the right place. Judging from messages
about spam, some rely on PTRs and some rely on other approaches.  That's a
better discussion, not one in front of DNS people.  In the sense that no
RFC can "force" an operator into publishing anything it doesn't want to
publish.

On 5/13/15, 17:18, "Ted Lemon" <[email-masked]> wrote:

>>the
>Yes, this is what we should recommend.

Absolutely not (recommend ISPs should delegate).  While it would be good
if an ISP offered this to interested parties, don't expect to saddle the
operator with yet another service that expects the customer to
reply/provide out-of-band information.

I know I wouldn't bother.  Simply because I do not, for my home life, have
any DNS servers.  For one, my ISP provides me one IPv4 address, from a
DHCP pool.  For two, I don't want to spend my life beyond work replicating
what I do for work.

And with the kids these days...with their mobile devices...I'm sure they
don't either.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 May 2015 07:16:12 -0400

> reply/provide out-of-band information.

The point of delegating is is that in most cases the customer won't populate it, and in the cases where they want to, it is now their problem, not the ISP's problem. So Paul gets his "I am a luser" signal, and I get my PTR tree. All nodes are not equal on the Internet, but that should be by choice, not by design.

---

From: [email-masked]
Date: Thu, 14 May 2015 14:13:46 +0200 (CEST)

> The point of delegating is is that in most cases the customer won't populate it, and in the cases where they want to, it is now their problem, not the ISP's problem. So Paul gets his "I am a luser"…
Putting my ISP hat on:

- Our business customers can already have reverse zones delegated if
they ask.

- For our residential customers, should we be expected to delegate
lots of reverse zones that mostly wouldn't be populated? I can easily
see how this could lead to extra calls to customer support, extra
logging of failures on name servers, etc. In short, most likely extra
cost. Since residential service is a very low margin game, anything
which adds to the cost of providing the service is a non-starter. Not
gonna happen.

Steinar Haug, AS 2116

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 May 2015 09:05:46 -0400

On May 14, 2015, at 8:13 AM, <[email-masked]> <[email-masked]> wrote:
> 
> For our residential customers, should we be expected to delegate

It has to be automatically negotiated or it won't work. On a practical level there is significant work to do here; the question is, if we can make it cheap to manage, is it technically the right thing to do. IMHO it is. 

Bear in mind that there is no cheap path. If you don't populate the zone with fake crap, which imho you should not, you might get calls. If you populate it with crap, you will see a significant cost, because that is not easy. If you delegate, that may produce calls from folks who don't ask for the delegation, and from folks who do. 

I think the best early experiment is to do nothing and see how that goes. As a data point, this is what Comcast is currently doing with my delegated prefix. I'd be curious to know if they are getting phone calls about this.