Subject: [DNSOP] Working Group Last Call draft-ietf-dnsop-isp-ip6rdns

From: Tim Wicinski <[email-masked]>
Date: Mon, 25 Apr 2016 16:50:42 -0400

This starts a Working Group Last Call  for draft-ietf-dnsop-isp-ip6rdns

Current versions of the draft is available here:

https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/

Please review the draft and offer relevant comments. Also, if someone 
feels the document is *not* ready for publication, please speak out with 
your reasons.

There was a large amount of feedback on the draft prior to it being 
adopted, and we feel the author addressed all the outstanding issues.
Please let us know if this is not the case.

This starts a two week Working Group Last Call process, and ends on
9 May 2016.

thanks
tim

---

From: Bob Harold <[email-masked]>
Date: Thu, 28 Apr 2016 12:45:07 -0400

> This starts a two week Working Group Last Call process, and ends on
The last sentence in section 2.3, at the top of page 5:
"There is no standard way to indicate to a host what server it should send
dDNS updates to."

I thought it was standard for the client to do an SOA query to find the
master server for the zone.
(Or see
https://www.ietf.org/internet-drafts/draft-spacek-dnsop-update-clarif-00.txt
)
And that method is spelled out in the second paragraph of section 2.3.1.

That also seems to conflict with the last sentence of section 2.3.2
"Host behavior is unchanged; the host sends the same dynamic updates,
   either to the ISP's server (as provided by the gateway), or to the
   gateway for it to forward."
Why would a host send an update to its resolver, instead of the host listed
in the SOA record?

Section 3 similarly says:
"Dynamic DNS updates can provide accurate data, but there is no
   standard way to indicate to residential devices where to send
   updates, if the hosts support it, and if it scales."

-- 
Bob Harold

---

From: Alain Durand <[email-masked]>
Date: Thu, 28 Apr 2016 23:43:11 +0000

Section 2.5. "Dynamically Generate PTR When Queried ('On the Fly')" was originally written years ago. Some recent announcement from DNS vendors generating and signing DNS records on the fly seem to be an existence proof that this would actually work and the scalability concerns, certainly valid a few years ago, may not be that critical now.

Alain, speaking on my own behalf.

> On Apr 25, 2016, at 4:51 PM, Tim Wicinski <[email-masked]> wrote:
> 
> Please review the draft and offer relevant comments. Also, if someone feels the document is *not* ready for publication, please speak out with your reasons.
> 
> There was a large amount of feedback on the draft prior to it being adopted, and we feel the author addressed all the outstanding issues.
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 29 Apr 2016 10:58:50 +0200

On Mon, Apr 25, 2016 at 04:50:42PM -0400,
 Tim Wicinski <[email-masked]> wrote 

> This starts a Working Group Last Call  for draft-ietf-dnsop-isp-ip6rdns

Summary: I think it must *not* be published as it is.

The biggest problem is that it fails to explain why it is necessary to
provide a PTR. RFC 1912, quoted, is just informational and its
sentence "Every Internet-reachable host should have a name" does not
use RFC 2119 terms. RFC 1912 was written in 1996 when one computer per
home was already a lot! Now, every home has four or five connected
machines and it will probably increase a lot in the next years. I see
no point in giving a PTR to any Internet-connected printer or
webcam. (And it raises privacy issues, see my last remark.)

It seems this document did not take into account the lessons from the
failure of draft-ietf-dnsop-reverse-mapping-considerations (which is
in the references but never mentioned in the draft, something that the
RFC editor will complain about). Basically, it seems there is no
consensus inside IETF about the PTR so this draft should be careful.

Now, the details:

> Some network services perform a PTR lookup on the source address of
> incoming packets before performing services.

True, but it does not say what they do with the result. Example: by
default, Postfix does a PTR request on the IP address of the incoming
client but, by default, does nothing if it returns a NXDOMAIN.

> 2.1.  Negative Response

The entire paragraph is very confused and mixes a timeout and a
NXDOMAIN. It must be rewritten to say that timeouts (whether because a
lame delegation or not) MUST NOT happen but a NXDOMAIN is a perfectly
legitimate response.

> In fact, this kind of delegation will not work for devices complying
> with [RFC6092], which includes the requirement,

This requirment is for resolvers (because of RFC 5358) and does not
apply here where you talk about authoritative service.

> Most users have neither the equipment nor the expertise to run DNS
> servers, so this option is unavailable to the residential ISP.

Let's be more careful: "this option cannot be a general solution today
to the residential ISP."

> Providing location information in PTR records is useful for
> troubleshooting, law enforcement, and geolocation services, but for
> the same reasons can be considered sensitive information.

You could also mention that these information are not validated in any
way; the people can lie. And, if you force them to provide a PTR, they
will lie, for privacy reasons.

---

From: Shane Kerr <[email-masked]>
Date: Fri, 29 Apr 2016 13:54:44 +0200

Stephane,

At 2016-04-29 10:58:50 +0200

> consensus inside IETF about the PTR so this draft should be careful.

Disclaimer: Personally I think that the whole notion of reverse IP is
ridiculous, especially in IPv6. I proposed that we skip the whole
notion in IPv6, possibly providing some alternate, non-DNS, method to
get hostname from IPv6 addresses for the rare case where that is useful.

However, administrators seem to really like reverse DNS. I don't know
why. It's a mystery to me, but they do.

Having said all of that, I don't see any strong requirement that this
document provide motivation for reverse DNS solutions for IPv6. People
ask about the problem, and want solutions, and it would be good to have
a document to point them to with some help.

Cheers,

--
Shane

---

From: Philip Homburg <[email-masked]>
Date: Fri, 29 Apr 2016 14:13:08 +0200

>a document to point them to with some help.

The problem I have with the current line of thinking (Section 2.4 in this
draft) is that there is a big disconnect between where reverse DNS is
needed and what ISPs are trying to do.

Whether we like it or not, mail admins are adding reverse DNS checks.
In fact, some really big mail providers require reverse DNS. Personally,
I also like to see names in tcpdump output, but that's just a nice to have.

So, ISPs not doing reverse DNS for IPv6, like my current ISP, are making it
impossible to use your own mail server to deliver mail over IPv6. I think
they are doing a serious disservice to the open internet.

In any case, people operating mail servers have to be more technical than
the average consumer. We are at the moment no where near just dropping a
box at somebody's home and expecting that to be a well maintained mail server.

But then, when reverse DNS is discussed, it tries to cater to the
non-technical consumers. The group that has no need for reverse DNS at the
moment.

For me, the obvious starting point for reverse DNS is to just delegate
the space of the prefix. Customers that want to run mail servers can also
set up a DNS server.

Instead there are too many options to automatic reverse DNS that are by and
large not needed.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 29 Apr 2016 14:21:26 +0200

On Fri, Apr 29, 2016 at 01:54:44PM +0200,
 Shane Kerr <[email-masked]> wrote 
 a message of 66 lines which said:

> Having said all of that, I don't see any strong requirement that
> this document provide motivation for reverse DNS solutions for
> IPv6. People ask about the problem, and want solutions, and it would
> be good to have a document to point them to with some help.

OK, but then the draft should be edited to remove things like "RFC
1912 says you should have a PTR". Let's make it just a catalog of
possible solutions "if you want to allow your customers to have PTRs",
with assessments of their price, ease of use, scalability, etc.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 29 Apr 2016 14:26:27 +0200

On Fri, Apr 29, 2016 at 02:13:08PM +0200,
 Philip Homburg <[email-masked]> wrote 
 a message of 40 lines which said:

> In fact, some really big mail providers require reverse DNS.

I know.

> So, ISPs not doing reverse DNS for IPv6, like my current ISP, are
> making it impossible to use your own mail server to deliver mail
> over IPv6.

I see two simple solutions for that. You mention one (ip6.arpa DNS
delegation), since, as you said, people who want to manage a mail
server probably can manage a DNS zone.

There is another one, apparently not mentioned by the draft but widely
used in the VPS / dedicated server world: give the users a Web
interface / API so they can add PTR themselves. After all, unlike what
the current draft seems to imply, there is zero need to give a PTR to
every thermostat or refrigerator in the house. You need PTR for a few
machines only, such as the mail server. This can be delegated to the
user.

---

From: Richard Clayton <[email-masked]>
Date: Fri, 29 Apr 2016 13:33:29 +0100

In message <[email-masked]>, Philip Homburg <pch-
[email-masked]> writes

>needed and what ISPs are trying to do.

"needed" is rather a strong word.... historically reverse DNS was a de
facto requirement for access to some anonymous FTP servers (a use case
that is now rather long in the tooth) and it was seized on by mail
systems that were trying to deal with spam because

a) checking for consistency between forward and reverse DNS and any
associated HELO command gave them a (totally unjustified) warm feeling
about the identity (and bona fides) of the machine sending them email

b) some reckoned to parse the name (in an entirely ad hoc and error
prone manner) and thereby identify mass-market ADSL/cable connected
machines that they did not think should be sending email directly.

I am not aware of ANY other protocols that have ever relied on the
presence of reverse DNS -- but experts here may recall some ??

Latterly, the existence of reverse DNS has been used as a "clue test"
for IPv6 email delivery (server to server, not email submission by end
user machines) and this is documented in the M3AAWG document on IPv6
email:

<https://www.m3aawg.org/sites/default/files/document/M3AAWG_Inbound_IPv6
_Policy_Issues-2014-09.pdf>

which says

     In the absence of a more appropriate mechanism for identifying
     hosts intended to act as outbound MTAs by their owners, M3AAWG
     recommends rejecting email from host IPv6 addresses without reverse
     DNS records. This technique should be deprecated once a more
     suitable standard mechanism is developed.

So in fact "reverse IPv6 DNS everywhere" risks being counterproductive
for email (or at best we'll be back in the ad hoc parsing world).

>In fact, some really big mail providers require reverse DNS.

Yes, that's what M3AAWG is documenting... but if you roll out reverse
DNS everywhere I confidently predict they will rapidly cease to bother !

>they are doing a serious disservice to the open internet.

Mayhap -- but reputation services for IPv6 are still in their infancy
and so there needs to be some way to distinguish "legitimate" mail
servers from malware infected end-user devices.

In my view the effort should all be devoted to addressing reputation
services for IPv6. In particular there is no standard for documenting
the "cut point" (what the allocation unit was to a particular customer)
and that is essential information for linking delivery events to an
entity and thereby forming a view as to their legitimacy (or otherwise)

If lots of work is to be done on reverse lookups in IPv6 (which I would
argue is entirely self-defeating) then being able to do a reverse lookup
which returns "/48" or "/56" or whatever is, in my view, significantly
more useful.

- -- 
richard                                                   Richard Clayton

Those who would give up essential Liberty, to purchase a little temporary 
Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755

---

From: Philip Homburg <[email-masked]>
Date: Fri, 29 Apr 2016 14:40:10 +0200

>machines only, such as the mail server. This can be delegated to the

Indeed. This second option is what my ISP is planning to do. Except that
they don't actually care about customers who need reverse DNS now.

But yes, manually adding a PTR is also a very good solution. Especially,
because it will be very hard for malware to automate that. Making it
hard for malware to send mail from a system with reverse DNS.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 29 Apr 2016 15:04:33 +0200

>servers from malware infected end-user devices.

I'm talking about operational experience today.

Not whether it is required by any standards document or not. And of course
I cannot predict the future in this regard.

But operationally, if you are a small party trying to deliver e-mail today,
you have to have reverse DNS for IPv6 otherwise some mail will be rejected or
discarded. And some really big mail providers are right now rejecting mail
if there is no reverse DNS.

---

From: "John Levine" <[email-masked]>
Date: 29 Apr 2016 16:28:49 -0000

>get hostname from IPv6 addresses for the rare case where that is useful.

My problem with the draft is that it doesn't distinguish between hosts
with static addresses (configured manually or by DHCP) and hosts with
dynamic addresses.  rDNS for static addresses is easy, and these days
a lot of people use the existence of rDNS as a hint that an IPv6 host
has a static address and is intended to be a server.

The discussions of all the ways to kludge rDNS for dynamic hosts is
fine, perhaps with a clearer note at the beginning that you probably
don't want to bother.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 29 Apr 2016 16:56:05 -0000

>they are doing a serious disservice to the open internet.

Aw, c'mon. This argument was over a decade ago.

If your ISP is like most other ISPs, retail connections have port 25
blocked, the IP ranges are listed in the MAPS DUL and Spamhaus PBL,
and the IPv4 addresses have rDNS with names that say don't connect to
me.  (The patterns that Richard derides work surprisingly well in
practice.)  The reason, as we all know, is that about 99% of mail from
retail connections is botnet spam, and it's sheer self defense.  You
don't have to like it, but it's not going to change, and it's a waste
of time to argue about it.

There are plenty of hosting providers that will rent you a VPS
for $5/mo with static v4 and v6 addresses and rDNS that matches
whatever forward DNS you point at it.  If it's not worth $5/mo,
well, OK.

R's,
John

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 29 Apr 2016 10:55:32 -0700

On Friday, April 29, 2016 9:56 AM, John Levine wrote:
> >making it impossible to use your own mail server to deliver mail over
> >IPv6. I think they are doing a serious disservice to the open internet.
> 
blocked, the
> IP ranges are listed in the MAPS DUL and Spamhaus PBL, and the IPv4
> addresses have rDNS with names that say don't connect to me.  (The
patterns
> that Richard derides work surprisingly well in
retail
> connections is botnet spam, and it's sheer self defense.  You don't have
to like
> it, but it's not going to change, and it's a waste of time to argue about
it.

John is correct there. This draft appears to solve a marginal problem, while
creating a huge privacy issues. In fact, I could not find any privacy
consideration in the text, while provisions such are placing a user name and
location in a PTR record are really privacy hostile. I think the authors
should seriously look at the privacy issues and rewrite the draft before it
progresses any further.

If the use case is, "allow a mail server from home," then the solution has
to involve some serious configuration, e.g. asking the ISP to remove the
port 25 filter for that IPv6 address. Entering a PTR would be part of the
same provisioning process. So that use case cannot be a reason to require
entering a PTR record for every IPv6 address. 

The stated requirement in the draft is the presumed best practices that "
Every Internet-reachable host should have a name" [RFC1912], and "PTR's
should use official names and not aliases". As many have already observed,
this supposedly best practice is ancient, i.e. "Before Snowden." It should
really be declared obsolete, given recent work on privacy. Check for example
the discussion of privacy threats in RFC 7624, the INTAREA draft on "Current
Hostname Practice Considered Harmful"
(https://datatracker.ietf.org/doc/draft-ietf-intarea-hostname-practice/), or
the recently concluded work on DHCP anonymity
(https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/), which
includes provisions to obfuscate or eliminate host names in DHCP requests
when privacy is requested.

The draft appears to recommend that PTR include host names of the form
"254.user.town.AW.example.com," which are quite problematic from a privacy
point of view. The short summary is that the proposed PTR would be a "super
cookie." Consider that some ISP periodically change the IPv4 addresses or
IPv6 subnets allocated to customers, in order to help protect the users'
privacy. Following the recommendation of this draft, the ISP should
immediately enter a PTR linking the new address to the user identity and
location. That is silly!

-- Christian Huitema

---

From: "John Levine" <[email-masked]>
Date: 29 Apr 2016 20:15:10 -0000

>should seriously look at the privacy issues and rewrite the draft before it

The author is Lee Howard, who works for a large cable ISP.  Perhaps he
could just tell us what the motivation for the document is.

It also occurs to me that it'd be worth pointing out that contexts
matter.  For example, since my hosting provider doesn't handle v6 yet,
I have the usual tunneled /64 from HE.  They delegate the rDNS to me,
I configure servers with fixed addresses and fixed rDNS and it works
fine.  That's a reasonable scenario (with or without the tunnel) for
hosting customers.

R's,
John