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