In message <4a9c783e.8090...@dougbarton.us>, Doug Barton writes: > Mark Andrews wrote: > > > This was on the adgena for DNSOP at the last IETF 75. There was > > much discussion. > > Sorry if I'm rehashing this unnecessarily. I did (an admittedly > cursory) search of my list archive and didn't see anything similar. > > > Not all of use agree with the analysis in that > > document though I think there was consensus that ISP's shouldn't > > need to per-populate reverse IPv6 zones. > > Yeah, that more or less sums up my feelings as well, although .... > > I did read recently about the idea of using DLZ for this. Any > reasonably sized relational database ought to be able to handle the > load here. I plan to look at scripting something for this purpose as > soon as I get the requisite number of round 'tuits. > > Doug
You don't need a database. The number of machines involved doesn't magically explode so you don't magically need lots more PTR records. Typical households have a handful of machines. All that's really needed is a agreed method to populate the reverse name space. If you deploy BCP 38 to the customer level TCP is a good enough authenticator for updating a reverse zone via UPDATE. If you don't do BCP 38 to the customer level, e.g. there is shared media involved that allows spoofing to occur for customers on that media, then TSIG will work and is scaleable at the ISP level for UPDATE. Windows already attempts to do UPDATE. It just does it over UDP. Switching to TCP for the UPDATE message should be trivial. Since this is IPv6 give each customer their own address block and corresponding reverse zone. You don't need a single big machine to do this. 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
