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

From: "Howard, Lee" <[email-masked]>
Date: Mon, 2 May 2016 20:59:45 +0000

Sorry for not replying last week; I somehow got unsubscribed from the list a few days before WGLC was started.

So let me reply to a few points made so far:

Privacy Considerations (Christian Huitema)
Thanks to you and other for pointing out this gap.  How about:
Change Title of "4. Security Considerations" to "4. Security and Privacy Considerations"
Add:
4.4 Privacy considerations
Delegating to a residential user, where automated systems will populate DNS records, may reveal host name information that is not generally known, which might reveal private information such as a person's name or the system's operating system ("Lee's MacBook").  Users who intentionally populate the DNS may do this knowingly.  Using a convention of describing geography in the name ("town.AW.example.com.") may reveal private information. The combination of the two (name and geography) is, in some cases, enough to physically locate a user based on their IP address.

Having forward and reverse match isn't BCP (Stephane Bortzmeyer, and others)
Yes, it's fair to say that best practice has changed. I'll swap in Christian's proposed text:

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.

"My problem with the draft is that it doesn't distinguish between hosts

with static addresses (configured manually or by DHCP) and hosts with
dynamic addresses. " (John Levine)

I thought that was clearly implied by the second paragraph, and in the "Considerations and Recommendations" section where I say, "when a host has a static address and name, AAAA and PTR records should exist and match."

However, I could revise the introduction:
OLD:
For large Internet service providers who serve residential users

NEW:

        For large Internet service providers who dynamically assign addresses

Some DNS vendors now offer signing DNS records on the fly (Alain Durand)
Yes; the industry has changed since the concern about DNSsec scaling was raised and written. Enough to add a sentence to the section saying, "Several DNS vendors now offer signing and record generation on the fly, so this may no longer be a concern." ?

There are a couple of other concerns that I'll address in other messages.

Thanks for all the constructive input,

Lee

________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 3 May 2016 11:00:54 +0200

On Mon, May 02, 2016 at 08:59:45PM +0000,
 Howard, Lee <[email-masked]> wrote 

> Having forward and reverse match isn't BCP (Stephane Bortzmeyer, and

No, that was not my point. My point was that having a PTR isn't
BCP. _If_ there is a PTR, it's certainly better if the A/AAAA and the
PTR match.

---

From: "Howard, Lee" <[email-masked]>
Date: Tue, 3 May 2016 13:50:35 +0000

>BCP. _If_ there is a PTR, it's certainly better if the A/AAAA and the

Ah, thank you for clarifying.
I think there are a few people who think that having a PTR is a BCP. Not a majority, but I'm not sure it's "in the rough" of consensus. Would it be sufficient for me to say it's "debatable"?

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."   While the need for a PTR record and for it to match is debatable as 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.

I could also link to the "Five common uses for PTR lookups" in the "Considerations and Recommendations" section.

Lee