On Sep 3, 2009, at 11:58 AM, Lee Howard wrote:
Education needed: how do you tell a residential user what server will accept their dynamic PTR updates?
I think this is an unnecessarily difficult answer. Maintaining the zones at the ISP is a recipe for DoS attacks, bad configuration, angry phone calls from end users, and, frankly, ISPs simply not doing it because it's too hard. The problem of authenticating the DNS updates is another dozen miles of bad road on top of that. It's better to delegate to the customer, and it's not that hard to do.
Residential gateways are, in practice, almost always configured using DHCP. For DHCPv6 prefix delegation, it would be a fairly simple matter to set up a DNS delegation for the zone containing PTR records for that prefix. The delegation could be to an IP address designated by the residential gateway, which would typically be its own IP address. The residential gateway could also present DNSSEC information in its DHCP messages for insertion into the parent zone if that was considered valuable.
This sounds like a security problem, but it's not: if the residential gateway is getting its configuration through the DHCP server, then it is permitted both to use the delegated prefix and to control the zone documenting the contents of that prefix. As long as the DHCPv6 transaction is acceptably secure, so is the zone delegation.
There is existing technology for populating PTR records via DHCP, and this would work for the next-hop address to the prefix - the outward facing IP address of the home gateway, which would be allocated via DHCPv6. AFAIK this functionality already works on several commercial and at least one open source DHCP implementation, and support in DHCPv4 clients is widespread, so it's not unreasonable to think that DHCPv6 clients would have support for it as well. I haven't checked the Microsoft client, but I'd be surprised if it didn't do this.
Following this plan, end users who care about the reverse tree will spend the extra money to run gateways that support the delegation; end users who do not would have no reverse DNS. This seems like a winning solution to me, since the incentives and effort are all placed on the interested parties. There would be some minimal effort required by the ISP to set this up, but it really would be pretty minimal - for instance, it's a lot easier to get right than the routing for prefix delegation.
Of course, this solution doesn't work for ISPs that use static allocation, but they've bought a whole manual process anyway, so the additional expense for them of doing this is minimal, and existing ISPs that allocate IP addresses this way (e.g., Speakeasy in the U.S.) in practice support maintaining the DNS this way anyway - the big change here would be that rather than maintaining the customer's reverse tree for them, they'd be able to delegate it.
For ISPs that do neither manual allocation nor DHCPv6, implementation is problematic, but I don't know of any. I'd be curious to know if anybody is aware of any alternativees for doing this that would work in practice.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
