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

[Lee Howard <[e-mail]>]

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

Diff is at 
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-isp-ip6rdns-03

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, "[e-mail] on behalf of
[e-mail]" <[e-mail] on behalf of
[e-mail]> wrote:

>
>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/
>
>_______________________________________________
>DNSOP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dnsop
>