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

From: [email-masked]
Date: Wed, 15 Mar 2017 11:27:03 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

        Title           : Reverse DNS in IPv6 for Internet Service Providers
        Author          : Lee Howard
	Filename        : draft-ietf-dnsop-isp-ip6rdns-03.txt
	Pages           : 14
	Date            : 2017-03-04

Abstract:
   In IPv4, Internet Service Providers (ISPs) commonly provide IN-
   ADDR.ARPA information for their customers by prepopulating the zone
   with one PTR record for every available address.  This practice does
   not scale in IPv6.  This document analyzes different approaches and
   considerations for ISPs in managing the ip6.arpa zone for IPv6
   address space assigned to many customers.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-isp-ip6rdns/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-isp-ip6rdns-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-isp-ip6rdns-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Lee Howard <[email-masked]>
Date: Wed, 15 Mar 2017 16:37:35 -0400

This was posted a couple of weeks ago, but got wedged in systems.

Diff is at 

I think this version is responsive to all of the comments from the
previous WGLC.

Some specific changes:
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.²
The same theme is supported by watering the second paragraph: ³
Administrators at ISPs should consider whether customer PTR records are
needed, and if so, evaluate methods for responding to reverse DNS queries
in IPv6."

2. Privacy considerations.
Added section: 6.  Privacy Considerations     Given considerations in
[hostname], hostnames that provide    information about a user compromises
that user's privacy.  Some users    may want to identify their hosts using
user-specified hostnames, but    the default behavior should not be to
identify a user, their    location, their connectivity, or other
information in a PTR record.

I¹ve also changed the example PTRs from ³user.town.AW.² to ³string.region."

3. Dynamic DNS, on how to find a dDNS server
Ammended the sentence: There is no
   standard way to indicate to a host what server it should send dDNS
   updates to; the master listed in the SOA is often assumed to be a
   dDNS server, but this may not scale.

4. Manual user updates.
Inserted a section on this:
It is possible to create a user interface, such as a web page, that
would allow end users to enter a hostname to associate with an    address.
 Such an interface would need to be authenticated (only the    authorized
user could add/change/delete entries).  It would need to    specify only
the host bits if the ISP changes prefixes assigned to    customers, and
the back end would therefore need to be integrated    with prefix
assignments, so that when a new prefix was assigned to a    customer, the
DNS service would look up user-generated hostnames and    delete the old
record and create the new one.     Considerations about some records being
static and others dynamic or    dynamically generated (section 2.5) and
the creativity of users    (section 2.3) still apply.

Also inserted a note inside ³on the fly² records: It may be possible to
allow user-specified    hostnames for some records and generate others on
the fly; looking up    a record before generating on the fly may slow
responses or may not    scale well.

5. One more use case: "Service discovery: [RFC6763] specifies "DNS-based
Service Discovery"    and section 11 specifically describes how PTRs are
used."

6. Noted that several servers are capable of DNS on-the-fly and removed
concerns about load.
 
A couple of comments to which this document is not responsive:
I did not make any changes proposing new solutions: this is an operations
document, not a technical spec.
I did not describe what additional applications do when there¹s no PTR;
there are six examples.
I did not revise the paragraph on negative response; I couldn¹t think how
to make the difference between timeout (lame) and NXDomain clearer. In
reading these notes I see I¹ve used different capitalization; oops.
I did not insist that ISPs must allow residential users to host mail
servers, or provide static addresses; it is out of scope.

The point of this document is that ISPs deploying IPv6 keep (still!)
saying, ³What do we do about PTRs?² If somebody wants to propose a new
technical solution, I encourage them to do so; I¹m not up to it. A lot of
people think PTRs for residential users; while I sympathize with that
position, I am certain that there is not consensus on that point, and
therefore we cannot say it is stupid in a consensus document.

Since these changes are substantive and substantial, there should be
another WGLC. Please comment! No need to wait for WGLC!

Thanks,

Lee

On 3/15/17, 2:27 PM, "[email-masked] on behalf of
[email-masked]" <[email-masked] on behalf of
[email-masked]> wrote:

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

---

From: Philip Homburg <[email-masked]>
Date: Thu, 16 Mar 2017 12:02:01 +0100

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