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

From: Lee Howard <[email-masked]>
Date: Wed, 13 May 2015 17:01:24 -0400

From:  Lee Howard <[email-masked]>
Date:  Wednesday, May 13, 2015 at 10:57 AM
To:  <[email-masked]>, Alain Durand <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  [DNSOP] relax the requirement for PTR records?

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

Nope, there is not such consensus.
What I've seen on this list reflects what's currently in the document, so
I'll just update based on the reviews I've received, (thank you!), and let
the list know when the update is posted.

Thanks,
Lee

> 
> 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]://www.ietf.org/mailman/listinfo/dnsop
> _______________________________________________ DNSOP mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop

---

From: Shane Kerr <[email-masked]>
Date: Thu, 14 May 2015 08:15:42 +0000

All,

On Wed, 13 May 2015 17:01:24 -0400

> Nope, there is not such consensus.

Lee is correct, there is no consensus. :)

However, as far as I can tell everyone insisting that PTR is important
is arguing that the world would be a better place if every endpoint on
the Internet was equal.

The main argument seems to be that because e-mail uses reverse DNS as
input into spam detection, it is important. The argument proceeds to
then say that we want every computer on the Internet to run an SMTP
server, so every computer needs a PTR record.

This reminds me of the late 20th century/early 21st century IETF, when
it was filled with anti-NAT rage. This dedication to the pure end-to-end
principle resulted in broken protocols which allowed closed solutions
like Skype to dominate.

Network operators don't block port 25 because they want to sell e-mail
service. They do it because they end up originating spam otherwise.
Their networks get blackholed then. This seems perfectly pragmatic to
me. Anyone who wants to run a mail server can get their own VPS more
cheap than their home Internet connection so it doesn't seem like a
huge problem.

I know I won't convince anyone, so really this is just a rage post. I
apologize, but somehow couldn't stop myself.

Cheers,

--
Shane

---

From: Paul Vixie <[email-masked]>
Date: Thu, 14 May 2015 01:31:04 -0700

Shane Kerr wrote:
> ...

if by "equal" you mean "so expensive that it won't be an open relay,
won't get infected with relaying malware, will be monitored, will be
upgraded, and its owner will accept complaints about it" then yes i'd
argue that the world would be a better place if every endpoint on the
internet was "equal".

however, it ain't so, and ain't ever gonna be so. most devices are
cheap, mobile, proprietary shankware. IoT is going to accelerate that
trend unimaginably (unless you have an exquisitely dark imagination.)

so, given that endpoints aren't equal, and that by sheer mass of
numbers, most endpoints are dangerous to themselves and others, i'd like
some method by which i, as an SMTP responder, can tell the difference.

lack of PTR, and machine-generated PTR, are pretty good telltales, just
expensive in the case of machine-generated. any rules change should
either make that situation better, or at minimum, not make it worse.

but i think i'm offering a minor summary-correction, in that i'm not
arguing for endpoint equality. rather, i'm arguing that in the proved
absence of such equality, we have other steps we MUST take as receivers.
("be liberal in what you accept" stopped being a good idea in 1995 or so
when commercialization/privatization took hold.)

-- 
Paul Vixie

---

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

> server, so every computer needs a PTR record.

No, the argument _against_ letting ISP customers have PTR records is that it makes it easier for them to send spam. But nobody is advancing this argument seriously, so let's not get distracted by it. Paul is the main proponent of this, and he's also said that he is okay with delegating PTR zones.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 14 May 2015 11:25:11 -0700

> No, the argument _against_ letting ISP customers have PTR records is that it makes it easier for them to send spam. But nobody is advancing this argument seriously, so let's not get distracted by i…

for clarity: yes. if the owner of an ISP-connected computer wants it to
have PTR's, either so that they can send e-mail or for other purposes, i
think that's great, and i think DNSOP should recommend that ISP's
support this configuration.

it's when the owner doesn't know they are running software that sends or
relays spam -- which is now and has for the last few years been the most
common case of sending and relaying spam -- that i'd prefer there be no
PTR. but even in this case, the PTR's that are machine-generated by
ISP's will ultimately show up on steve champeon's list of
machine-generated PTR's, so i can reverse their impact by adding more
moving parts to the equation.

so, my hope is that we could recommend against machine-generated PTR's,
and recommend in favour of PTR delegation when a customer requests it,
all while understanding that ISP's will do whatever they want after they
see whatever recommendations we make.

-- 
Paul Vixie

---

From: joel jaeggli <[email-masked]>
Date: Thu, 14 May 2015 11:52:41 -0700

...

> see whatever recommendations we make.

I would vastly prefer to get a signed nxdomain from an isp then some BS
machine generated record...

It would be super-annoying for delegations to nameservers that do not
exist to occur for these, because not only will there be trillions of
them but I get to wait for them to time out, so delegation to cpe for
example seems like a non-starter.

---

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

> machine generated record...

Machine generated PTR records are a non-starter for IPv6 in any case.
We're planning to skip them entirely.

> example seems like a non-starter.

This is my worry too. Even if there is a protocol which ensures that
delegations only take place to working name servers - what do you do
when the customer goes off net, or acquires a new dynamic address?
Does the protocol take care to *remove* the old delegation then? In
general I would be worried about a (probably) much higher error rate
for such delegations.

Steinar Haug, AS 2116

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Thu, 14 May 2015 22:15:54 +0000

My 2 cents...

The presence or absence of a PTR record is, to me, like a reverse-DNS Literacy Test.  

History records that Literacy Tests didn't fare too well, as voting requirements, in the "real" (non-IT) world. In fact, they were just thin pretexts for racial bigotry, recognized as such, and eradicated. http://en.wikipedia.org/wiki/Literacy_test#voting

Do we think that a reverse-DNS Literacy Test will fare any better, as a way to ensure that only "fine, upstanding, properly-complected" TCP/IP-capable devices send mail? I'm all for combatting spam, and I'm all for populating reverse DNS, where it makes sense for certain device classes or types, but I just don't see the value of linking those things together. It's a bad marriage.

Lastly, what causes us, as a private enterprise, more heartburn in practice, is not missing PTRs, but *mismatched* PTRs (the RDATA of the PTR resolves to a *different* A/AAAA record). The compulsive drive to machine-generate PTRs, combined with sloppy maintenance processes and controls, actually exacerbates *that* problem. It would actually be better "if you can't do it right, then don't do it at all", with respect to PTR-record creation, among many of our hosting providers.

										- Kevin

-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of Paul Vixie
Sent: Thursday, May 14, 2015 4:31 AM
To: Shane Kerr
Cc: [email-masked]
Subject: Re: [DNSOP] Rejecting Practice for Theory (was Re: relax the requirement for PTR records?)

> is arguing that the world would be a better place if every endpoint on 

if by "equal" you mean "so expensive that it won't be an open relay, won't get infected with relaying malware, will be monitored, will be upgraded, and its owner will accept complaints about it" then yes i'd argue that the world would be a better place if every endpoint on the internet was "equal".

however, it ain't so, and ain't ever gonna be so. most devices are cheap, mobile, proprietary shankware. IoT is going to accelerate that trend unimaginably (unless you have an exquisitely dark imagination.)

so, given that endpoints aren't equal, and that by sheer mass of numbers, most endpoints are dangerous to themselves and others, i'd like some method by which i, as an SMTP responder, can tell the difference.

lack of PTR, and machine-generated PTR, are pretty good telltales, just expensive in the case of machine-generated. any rules change should either make that situation better, or at minimum, not make it worse.

but i think i'm offering a minor summary-correction, in that i'm not arguing for endpoint equality. rather, i'm arguing that in the proved absence of such equality, we have other steps we MUST take as receivers.
("be liberal in what you accept" stopped being a good idea in 1995 or so when commercialization/privatization took hold.)

--
Paul Vixie

_______________________________________________
DNSOP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 May 2015 21:48:25 -0400

> example seems like a non-starter.

It would help if you would consider the existing body of work that's been discussed on this very topic before drawing unwarranted conclusions.   I alluded to it in an earlier message when I said that the delegation should be automatically negotiated.   There's work on this going on in homenet, and I also wrote a draft for the dhc working group before I became an AD and all work stopped.   I'm sure you can still find it in the archive.   I suspect that particular proposal has become moot as a result of work that occurred in the intervening years, but it could be revived if necessary.

That was a long way of saying that I agree with you that delegations shouldn't dangle, but disagree with you that this means delegations are a bad idea.   Dangling delegations are a bad idea!   :)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 May 2015 21:54:56 -0400

On May 14, 2015, at 3:55 PM, <[email-masked]> <[email-masked]> wrote:
> what do you do
> Does the protocol take care to *remove* the old delegation then?

Yes.

As to the error rate, actually if this is designed and implemented properly the error rate could be zero.   But even if it is not zero, best is the enemy of good enough.   If we only delegate to those devices that specifically negotiate delegations, and the vast majority of devices do not negotiate delegations, this won't be a problem.   If you don't routinely change your customer's numbering, the opportunities for that error to occur are reduced.  If this becomes something that people actually use and benefit from, then there will be an incentive to get it right, and vendors who do not get it right will lose business.

And, as I said in response to Joel, the homenet working group is actually describing a mechanism for doing this that avoids the dangling delegation problem by using a hidden primary/public secondary arrangement, so that if the delegation temporarily fails during renumbering, it's not visible to hosts on the internet anyway, because queries were never going to the CPE device.   Personally I think this is actually the best solution, whether it's an ISP-hosted secondary or something more like what dyndns.net used to do.

---

From: joel jaeggli <[email-masked]>
Date: Mon, 18 May 2015 11:07:13 -0700

On 5/14/15 6:48 PM, Ted Lemon wrote:
>> It would be super-annoying for delegations to nameservers that do
>> not exist to occur for these, because not only will there be
>> trillions of them but I get to wait for them to time out, so
>> delegation to cpe for example seems like a non-starter.
> 
> It would help if you would consider the existing body of work that's
> been discussed on this very topic before drawing unwarranted
> conclusions.  

managing on behalf of a customer and automatically delegating are rather
different I agree.

I am aware of

https://tools.ietf.org/html/draft-ietf-homenet-front-end-naming-delegation-02

which is where homenet seems to be.

I look somewhat unfavorably on the act of automatically populating zones
 on a customers behalf upstream of their cpe for the same reason I not
so interested in autmatically injecting host-id signaling, or in fact
from dynmic dns updates using host-id. if the data has meaning it has
privacy implications and that involves consent and if it doesn't then
I'm not sure what utility it has over wildcard records.

>  I alluded to it in an earlier message when I said that
> the delegation should be automatically negotiated.   There's work on
> this going on in homenet, and I also wrote a draft for the dhc
> working group before I became an AD and all work stopped.   I'm sure
> you can still find it in the archive.   I suspect that particular
> proposal has become moot as a result of work that occurred in the
> intervening years, but it could be revived if necessary.
> 
> That was a long way of saying that I agree with you that delegations
> shouldn't dangle, but disagree with you that this means delegations
> are a bad idea.   Dangling delegations are a bad idea!   :)

---

From: Ted Lemon <[email-masked]>
Date: Mon, 18 May 2015 14:43:33 -0400

> I'm not sure what utility it has over wildcard records.

Yup, this is an issue that the current documents don't adequately address (indeed, I don't recall that they address it at all). Send text?  :)