On Sep 3, 2009, at 3:37 PM, Lee Howard wrote:
I agree that I don't like this answer, and I think I said that in
the draft,
for exactly those reasons. If this draft is worth pursuing but you
think
section 3 is unclear, could you help me improve it?
The problem with section 3 is that aside from section 3.2.3, it
presumes that the customer will be updating the DNS using dynamic DNS
updates, which does not match current practice, and is difficult to
deploy due to the lack of shared authentication information that could
be used to authenticate the updates. Mark Andrews' suggestion of
using CGA to authenticate the updates isn't bad, but as you also
mention in section 3, DDNS from clients doesn't really scale well.
In practice, what works is DDNS from the DHCP server. This is fairly
widely deployed (although unfortunately no ISP I've ever had supports
it). It's as secure as the DHCP transaction, which for better or for
worse is generally considered secure enough - if you got an IP address
from the DHCP server, there's no harm in populating the PTR record for
it.
My point is that this is a far, far better solution than what many
large ISPs do now - populating the reverse tree with nonsense names.
But, do those problems get better if you delegate to the user? Isn't
the user potentially susceptible to DoS attacks, bad configuration,
and
getting fed up and calling their ISP?
Yes. However, it's very unlikely that the user will care, and thus
very unlikely that they'll be making phone calls. In most cases, the
absence of a PTR record for a particular IP address has no effect on
the end user - their web surfing is unaffected, their FTP downloads
are unaffected, Skype works, streaming video works, VPN works, etc.
The only situations where the lack of a PTR tree will actually affect
the end user are when they are using (forgive me) ancient protocols
with ancient implementations that still place trust in the PTR tree,
which they should not, and in cases where they actually care about
providing PTR information for debugging purposes. This sort of
customer will be very happy to get a PTR delegation, and will do the
right thing with it.
In theory, but I don't know of any residential gateways that have this
support, and I don't know that end users would be willing to pay for
it.
The only end users who will care about it are people like you and me,
and we will probably run OpenWRT or have a linux box as our
residential gateway anyway.
Pointer? I'm not following you. PTR is sent in DHCP messages?
Or do you mean that when a device requests a Prefix Delegation, the
DHCPv6 server notifies the DNS server to delegate the zone to that
device? If that, then when the gateway assigns addresses to
hosts in
the home, they send dynamic updates to it.
Read RFC4701, 4702 and 4703 (don't panic - they're short). The
technologies described here work for DHCPv4 and DHCPv6. The next-hop
address can be populated using these techniques; we'd have to add
something to support any sort of signaling or negotiation about
delegation, although the default behavior of delegating to the next-
hop address could work well enough.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
