In message <f4529f1d-1a2f-48be-bf7c-e06419c07...@nominum.com>, Ted Lemon writes : > On Sep 7, 2009, at 6:52 PM, Mark Andrews wrote: > > /56 should be typical for homes > > /48 should be typical for businesses > > I don't think this is germane to the discussion. My point in > mentioning /64 was simply that if you go narrower than that, important > things break, so it's a pretty good number to assume as an absolute > minimum. > > >> 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. > > True, and with an IPv4 delegation I can have a filter that prevents > you from adding names that don't make sense, stopping that particular > failure mode. But there is no filter that could similarly disallow > an excessive number of names in an IPv6 delegation. > > >> 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. > > ? > > >> The problem is that I've never had an ISP that would actually > >> populate > >> the reverse tree based on hints from the client, > > > > 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. > > No, that's not the case at all. The technology I'm talking about > predates the existence of most of the really big ISPs, and there are > ISPs that have been doing DNS updates right for over a decade. The > problem is a lack of motivation to implement, not a lack of working > technology.
Residential was basically dialup for a long time. This has shifted to cable, dsl and wireless which are essentially always on technologies. > > 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. > > Do they do it with DDNS, or with web forms? The only commercial > support for the reverse tree that I know of for sub-class-C subnets is > done with web forms. Which is a matter of tools which is what we are talking about developing. It isn't that hard to make a update tool that works with RFC 2317 style delegations but you don't really need have a delegation if you are doing dynamic updates in the first place. nsupdate was designed to allow the CNAME to be removed. A slightly different tool is needed to follow the CNAME and construct a PTR using the CNAME's rdata as the ownername. This can be done outside of nsupdate by whatever is translating the IP address into the in-addr.arpa/ip6.arpa name. DNAME's are likely to be in the ip6.arpa which have the same issues. > >> 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. > > Sure, and PTR queries can always fail. There is no way to guarantee > that PTR queries will succeed when processing logs, no matter what > solution an ISP implements. An auditing mechanism that depends on > the PTR tree is not valid. Any mechanism necessary for > interoperation that fails in the absence of a PTR record is invalid. -- 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
