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

Lee Howard <lee@asgard.org> Tue, 02 May 2017 19:07 UTC

Return-Path: <lee@asgard.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB36129C6F for <dnsop@ietfa.amsl.com>; Tue, 2 May 2017 12:07:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.781
X-Spam-Level:
X-Spam-Status: No, score=0.781 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vJpMs0IJsecp for <dnsop@ietfa.amsl.com>; Tue, 2 May 2017 12:07:34 -0700 (PDT)
Received: from atl4mhob22.registeredsite.com (atl4mhob22.registeredsite.com [209.17.115.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FD4012EACE for <dnsop@ietf.org>; Tue, 2 May 2017 12:03:22 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.208]) by atl4mhob22.registeredsite.com (8.14.4/8.14.4) with ESMTP id v42J3KJg116677 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dnsop@ietf.org>; Tue, 2 May 2017 15:03:20 -0400
Received: (qmail 5172 invoked by uid 0); 2 May 2017 19:03:20 -0000
X-TCPREMOTEIP: 68.100.68.25
X-Authenticated-UID: lee@asgard.org
Received: from unknown (HELO ?192.168.1.160?) (lee@asgard.org@68.100.68.25) by 0 with ESMTPA; 2 May 2017 19:03:19 -0000
User-Agent: Microsoft-MacOutlook/14.7.2.170228
Date: Tue, 02 May 2017 15:03:15 -0400
From: Lee Howard <lee@asgard.org>
To: Philip Homburg <pch-dnsop-1@u-1.phicoh.com>, <dnsop@ietf.org>
Message-ID: <D52E454B.7AA2D%lee@asgard.org>
Thread-Topic: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt
References: <148960242305.14237.6433299035570274359@ietfa.amsl.com> <D4EF170B.700A9%lee@asgard.org> <m1coTAQ-0000EXC@stereo.hq.phicoh.net>
In-Reply-To: <m1coTAQ-0000EXC@stereo.hq.phicoh.net>
Mime-version: 1.0
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KVwI4R3dgU7aAjUv8e2F3GFXMNw>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-isp-ip6rdns-03.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 May 2017 19:07:38 -0000


On 3/16/17, 7:02 AM, "Philip Homburg" <pch-bF054DD66@u-1.phicoh.com on
behalf of pch-dnsop-1@u-1.phicoh.com> 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,
   AAAA 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 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.

Good note. I think I revised this paragraph several times, and it didn¹t
keep its integrity.

Old sentence:
Users of services which are dependent on a successful lookup
will have a poor experience.


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.


Old sentence:
For best user experience, then, it is important to
return a response, rather than have a lame delegation.


Proposed new sentence:
For best user experience, then, it is important to
return a response, including NXDomain, rather than have a lame delegation.



Resulting new paragraph (unformatted):
Some ISP DNS administrators may choose to provide only a NXDomain
response to PTR queries for subscriber addresses. In some ways, this
is the most accurate response, since no name information is known
about the host. Providing a negative response in response to PTR
queries does not satisfy the expectation in [RFC1912
<https://tools.ietf.org/html/rfc1912>] for entries to
match. 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.
 For instance, some web services and SSH
connections wait for a DNS response, even NXDOMAIN, before
responding. For best user experience, then, it is important to
return a response, including NXDomain, rather than have a lame delegation.
 On the other hand, external mail servers are likely to reject
connections, which
might be an advantage in fighting spam. DNS administrators should
consider the uses for reverse DNS records and the number of services
affecting the number of users when evaluating this option.




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


Is it? There are several places where the document talks about delegating
authority for a prefix, but it never says how. Now that you mention it, I
see how it¹s relevant, but I¹m on the fence about whether there¹s anything
important to say that hasn¹t already been said in better documents.

Lee