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

From: Ted Lemon <[email-masked]>
Date: Fri, 29 Apr 2016 22:48:39 -0400

On Apr 29, 2016 4:15 PM, "John Levine" <[email-masked]> wrote:
[Christian Huitema wrote:]

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

The document as written just documents the available options for populating
the reverse tree, should the reader wish to do so.   It does not specify
any particular behavior.   Describing it as privacy-hostile is nonsensical,
since it doesn't recommend any behavior.   The document could be improved
by a privacy considerations section that describes the privacy
considerations relating to those solutions that have privacy implications.
  This should be relatively straightforward and I can contribute text if
Christian doesn't want to.

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

This document was adopted by the working group.   At that time, Lee
explained in great detail what the motivation for the document is.   I can
actually picture him explaining.   I am fairly sure he's done it more than
once.   Now that we are at last call, it is no longer the time for Lee to
justify why this document exists.   If there is a problem with it, you
should tell us what it 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.
>

That's what I do too, frustratingly.   But bearing in mind that this
document is enumerating the set of possible approaches that ISPs could
take,  I think that's the context: the options ISPs have for addressing
this problem, should they choose to do so (indeed, one of the options
presented is "don't bother.")

Responding to Stephane's criticism of the references to RFC 1912, I think I
agree that referring to 1912 as BCP is not valid.   1912 was published
quite a long time ago.   I think there is substantial agreement within the
IETF that the practices described in 1912 are not in any way "best."   So
publishing a document now that affirms what 1912 says isn't the right thing
to do.

This is easily fixed, though.   Just don't refer to 1912 advice on PTR
records as best practice.  E.g.,:

OLD:
   Best practice is that "Every Internet-reachable host should have a
   name" [RFC1912] that is recorded with a PTR resource record in the
   .ARPA zone, and "PTR's should use official names and not aliases"
   [RFC1033].  Some network services perform a PTR lookup on the source
   address of incoming packets before performing services.

NEW:
   RFC 1912 recommended that "every internet-reachable host should have a
name" and says "Failure to have matching PTR and A records can cause loss
of Internet services similar to not being registered in the DNS at all."
Although the second of these two recommendations is no longer considered to
be a "best practice," some network services still do perform a PTR lookip
on the source address of incoming connections and verify that the PTR and A
records match before providing service.

This actually looks like an oversight--everywhere else in the document the
text is clear that supporting this particular behavior as documented in RFC
1912 is not required, but just something ISPs might do to support services
that require RFC 1912 compliance.

---

From: <[email-masked]>
Date: Sat, 30 Apr 2016 04:43:02 -0700

Yes, I can provide text.

A lot of the problems come from the specific name examples, so that requires some work. Early next week at best.

Sent from my Windows 10 phone

From: Ted Lemon
Sent: Friday, April 29, 2016 7:50 PM
To: John R Levine
Cc: dnsop WG; Christian Huitema
Subject: Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-isp-ip6rdns

>John is correct there. This draft appears to solve a marginal problem, while
>consideration in the text, while provisions such are placing a user name and
>should seriously look at the privacy issues and rewrite the draft before it
>progresses any further.

The document as written just documents the available options for populating the reverse tree, should the reader wish to do so.   It does not specify any particular behavior.   Describing it as privacy-hostile is nonsensical, since it doesn't recommend any behavior.   The document could be improved by a privacy considerations section that describes the privacy considerations relating to those solutions that have privacy implications.   This should be relatively straightforward and I can contribute text if Christian doesn't want to.

This document was adopted by the working group.   At that time, Lee explained in great detail what the motivation for the document is.   I can actually picture him explaining.   I am fairly sure he's done it more than once.   Now that we are at last call, it is no longer the time for Lee to justify why this document exists.   If there is a problem with it, you should tell us what it is.

That's what I do too, frustratingly.   But bearing in mind that this document is enumerating the set of possible approaches that ISPs could take,  I think that's the context: the options ISPs have for addressing this problem, should they choose to do so (indeed, one of the options presented is "don't bother.")

Responding to Stephane's criticism of the references to RFC 1912, I think I agree that referring to 1912 as BCP is not valid.   1912 was published quite a long time ago.   I think there is substantial agreement within the IETF that the practices described in 1912 are not in any way "best."   So publishing a document now that affirms what 1912 says isn't the right thing to do.

This is easily fixed, though.   Just don't refer to 1912 advice on PTR records as best practice.  E.g.,:

OLD:

NEW:
   RFC 1912 recommended that "every internet-reachable host should have a name" and says "Failure to have matching PTR and A records can cause loss of Internet services similar to not being registered in the DNS at all."   Although the second of these two recommendations is no longer considered to be a "best practice," some network services still do perform a PTR lookip on the source address of incoming connections and verify that the PTR and A records match before providing service.

This actually looks like an oversight--everywhere else in the document the text is clear that supporting this particular behavior as documented in RFC 1912 is not required, but just something ISPs might do to support services that require RFC 1912 compliance.

---

From: Richard Clayton <[email-masked]>
Date: Sat, 30 Apr 2016 13:32:41 +0100

In message <[email-masked]
il.com>, Ted Lemon <[email-masked]> writes

>    NEW:
>       RFC 1912 recommended that "every internet-reachable host should 
>    have a name" and says "Failure to have matching PTR and A records 
>    can cause loss of Internet services similar to not being registered 
>    in the DNS at all."   Although the second of these two 
>    recommendations is no longer considered to be a "best practice," 
>    some network services still do perform a PTR lookip on the source 
>    address of incoming connections and verify that the PTR and A 

"some network services still do" is rather vague (and thus unnecessarily
encourages those of a conservative viewpoint to continue a practice that
I still think is beyond its sell-by date).

... is it not possible to indicate that the only services ever believed
to have acted upon this type of check are email and (in the last
century) FTP ? Or is that an incorrect statement ?

It is, I suppose, relatively common for logging systems to do a reverse
lookup with a view to improving log readability. However, logging
systems don't generally attempt to check that forward and reverse match,
and so there is significant risk of being misled by the wicked. Asking
the bad guy to tell you their name and not checking their answer is
never the most solid of approaches.

- -- 
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: "John Levine" <[email-masked]>
Date: 30 Apr 2016 15:33:05 -0000

>century) FTP ? Or is that an incorrect statement ?

It is my impression that IRC has been a fairly enthusiastic user of rDNS.

Matching forward and reverse DNS is a hint that a host is supposed to
be visible to the outside world, but I wouldn't read a lot more into
it than that.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Sat, 30 Apr 2016 20:13:08 -0400

> I still think is beyond its sell-by date).

This document really doesn't seem to me to be encouraging this practice.
If anything, what this document lacks is an indication that the only
rational use of PTR records is for debugging and source-address-based
rendezvous in the DNS (e.g., publishing a public key for a host on its IP
address).   But the purpose of this document isn't to do that--it's just to
enumerate the set of choices available to ISPs.

Bear in mind that dnsop is an operations working group, and our main remit
is to give operational advice to operators of DNS servers.   This document
gives operational advice to operators of DNS servers.   It is outside of
our remit to give advice to providers of non-DNS services.   Realistically,
that is what you are proposing we do.