In message <20141105222034.5fe40a92...@fafnir.remote.dragon.net>, Paul Ebersman writes: > > marka> Or we could stop debating whether we should maintain it and > marka> assume that if we give people tools that will allow it to be > marka> automatically maintained they will eventually deploy them. > [...] > marka> Document what a node should do to register itself in the reverse > marka> tree and to cleanup when its address changes. Write some code to > marka> do it. > > To put things another way, I think you're trying to optimize for a > problem most folks don't want solved.
You don't know that. At the moment most people that would want these records have give up because the barriers raised have been to hard mostly because it requires a human to be in the loop and there is no standarisation. > Anti-spam folks *like* it that it's not trivial to get "correct" > rDNS/PTRs. It's easy to find consumer connections based on the ISP doing > bulk/lazy PTR generation and just reject SMTP traffic from them. Which won't work in IPv6 unless you syntesize the records on demand. They also have other databases so don't really need PTR records to workout static vs dynamic. > Large ISPs don't care about clean PTRs as long as no customers complain > and they don't care if end customers can't do SMTP without having to ask > for it in some special way. They do care about and probably don't want > complicated automated systems with all sorts of complicated behavior > when autogen'ed PTRs solve most customer problems. Except autogenerated PTR records don't solve the problem. > While I as an individual may find it annoying to have to go to a web > page to get a port 25 block removed and I may have to find someone > better connected than me to get my email to "real" folks like google, > I'm not most of the internet. Not even a teeny weeny fraction of it. Getting a firewall block removed is a othogonal issue. > And while I admit that I tend to disable auto-update on most of my > devices and do updates by hand, at $DAYJOB, it's a feature when we can > push new versions out to fix things and not wait for consumer gear to > spout smoke and get replaced in 3-5 years. > > So for a large chunk of the providers out there, the recommendations in > this draft solve a real problem in a mostly non-painful way and I think > it's done a decent job of laying out the tradeoffs. > > There have been some comments about making it clear that providers that > do bulk $GENERATE equivs in IPv6 will find that those addrs won't be > able to send email. Seems like a fine thing to point out. > > What else in the way of tradeoffs is missing? That people want IP to name mappings for their internal networks. With things like DNSSEC you need break DNSSEC trust chains at the ISP level for this to work. We also don't know what else will come along to use the reverse namespace. It is a good place to hang keying material which is tied to IP address. Having a well defined method to update this name space will be useful. There is a opportunity cost in not having the ability to do this already deployed. Remember it is just as easy to add a delegation as it is a PTR record if the amount of material that needs to be stored gets too big. 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
