On Sep 3, 2009, at 6:37 PM, Mark Andrews wrote:
First what DoS that doesn't exist today? Updates already get sent
to the ISP's {IN-ADDR,IP6}.ARPA servers.
If you do prefix delegation, you're delegating typically 64 bits of
address space. If you allow your customer to do arbitrary DNS
updates to the reverse tree for the entire /64, that could wind up
being a tremendous amount of data. So on the one hand, you're
opening yourself up to the potential for a buggy client to cause
operational problems.
And on the other hand, what makes DoS attacks work is that you have
some resource that people really care about, and you are able to
exhaust it by sending too many queries to it. One really great
defense against DoS is distribution of load. So delegating the
reverse tree for a customer's zone to the customer's equipment
protects against DoS that way.
Secondly of CPE equipement can automate this so can a ISP so there
isn't a bad configuration issue.
The problem is that I've never had an ISP that would actually populate
the reverse tree based on hints from the client, despite the fact that
this technology has existed for over a decade. I know there are ISPs
out there who do it, because I've worked with them in getting it
working. But in general, ISPs don't do this.
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.
I think CGA is a viable solution, but it's a *lot* harder to set up
than just delegating the tree and insisting that the customer take
care of it if they care to.
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.
A single point of failure in this case isn't an issue: if your
residential gateway dies, nobody's going to be querying your PTR
records, because you're not going to be communicating with anyone.
If we were talking about A records, I'd agree with you, but for PTR
records this is really a non-issue. I don't see ISP-based slaving of
zones as a viable thing to do, for the same reason that I don't think
ISPs will ever correctly maintain the PTR tree for clients.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
