In message <63fd8b00-b74f-465e-95c8-129a69f52...@nominum.com>, Ted Lemon writes
:
> 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.
/56 should be typical for homes
/48 should be typical for businesses
> 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.
The size of the name space has NOTHING to do with it. If
I have 1 name I can add billions of records at that name.
> 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.
Pure FUD.
> > 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.
Which is basically because ISP's had to work around a problem
before there was technology for a solution and they havn't
rethought the problem since. Additionall the solution was
designed when residential customers dialed up over the PSTN
so there was not stability in the reverse space. The solution
won't work for IPv6 without specialised servers so they MUST
rethink the issue.
ISP's do support customer generated reverse zones for their
commercial customers. It really isn't that hard to do it
for all customers. It's just inertia that has stopped it.
> > 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.
All of these can be made very easy.
> > 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.
Really? Lots of log processing is done in batches.
> 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.
Mark
--
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
