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

Philip Homburg <pch-dnsop-1@u-1.phicoh.com> Thu, 16 March 2017 11:02 UTC

Return-Path: <pch-bF054DD66@u-1.phicoh.com>
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 42A94127097 for <dnsop@ietfa.amsl.com>; Thu, 16 Mar 2017 04:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 jkLcNfA3KTHS for <dnsop@ietfa.amsl.com>; Thu, 16 Mar 2017 04:02:10 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) by ietfa.amsl.com (Postfix) with ESMTP id 925DF126C7A for <dnsop@ietf.org>; Thu, 16 Mar 2017 04:02:09 -0700 (PDT)
Received: from stereo.hq.phicoh.net ([::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (Smail #127) id m1coTAQ-0000EXC; Thu, 16 Mar 2017 12:02:02 +0100
Message-Id: <m1coTAQ-0000EXC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
Cc: Lee Howard <lee@asgard.org>
From: Philip Homburg <pch-dnsop-1@u-1.phicoh.com>
Sender: pch-bF054DD66@u-1.phicoh.com
References: <148960242305.14237.6433299035570274359@ietfa.amsl.com> <D4EF170B.700A9%lee@asgard.org>
In-reply-to: Your message of "Wed, 15 Mar 2017 16:37:35 -0400 ." <D4EF170B.700A9%lee@asgard.org>
Date: Thu, 16 Mar 2017 12:02:01 +0100
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/1wUZOgDjuElriOaENW4SAmBClY4>
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: Thu, 16 Mar 2017 11:02:12 -0000

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

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.

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.

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.

Extracting geo information from reverse DNS is very hard. As far as I know,
geo location services for IPv4 mostly rely on other sources. 

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.

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