In message <e2dcddf0-5aba-4bb0-aaff-0113cea4a...@nominum.com>, Ted Lemon writes
:
> 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.
First what DoS that doesn't exist today? Updates already get sent
to the ISP's {IN-ADDR,IP6}.ARPA servers.
Secondly of CPE equipement can automate this so can a ISP so there
isn't a bad configuration issue.
Thirdly I've already presented two different authentication methods
both of which have working implementations. A third is to define
how to use the public key associated with a CGA's to sign a update.
This shouldn't be too hard.
> 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.
Delegating to the CPE leads to a single point of failure. If the
ISP automatically slaved the zones it delegates to the CPE this
problem would go away. This would require the ability to tell the
CPE what other nameservers to put in the NS RRset. The CPE device
would process the UPDATEs and the ISP would provide the redunancy
required.
> 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.
Static is just long term dynamic.
> 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.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
