marka> For in-addr.arpa you already have a PTR records. Allowing the marka> end user to set its content does not increase the amount of data marka> you are serving. It does increase the amount of churn in the marka> zone.
This draft isn't talking about v4. And $GENERATE or equiv already works in that most customers don't scream. I have no incentive to change to a more risky and complicated and hard to maintain system for v4. I'd contend that the folks who check v4 PTRs will have the same level of trust with auto-gen'ed v6 that they do with v4. Folks that don't trust it now still won't and those that find it acceptible in v4 will accept it in v6. marka> The occasional customer will add a offensive PTR record which marka> won't be seen by 99.99999% of the world. [...] marka> If we recommend that this is only done when a forward record is marka> also successfully added UPDATE + TSIG (yes, this does scale for marka> this use) you get rid of the PTR/A mis-match issues. And we're definitely not talking about allowing customers to do dynamic updates of forward records in this draft. If you want that currently, you get a business account or use one of the many services that allows that. Yes, it costs money. But most folks don't seem to miss it in the consumer world and those that do find someone willing to do it. marka> For ip6.arpa you delegate to the customer along with the prefix marka> delegation. The customer has to deal with the space issues but marka> uses the same mechanisms to add the PTR records and cleanup. Because the mythical grandmother wants to deal with their own address space. Right... Most customers don't even know what DNS is, much less PTRs. They want to get content, send emails and pictures of cats. As an ISP, it's our job to make sure this works. $GENERATE in v4 does work. Auto-gen'ed PTRs in v6 works as well as $GENERATE, no better, no worse. marka> You get the equivalent of $GENERATE with customer settable marka> overrides using UPDATE over TCP. And I want 10s of millions of users doing TCP to my auth servers? I think not. Certainly not for something of so little gain to my customers. ebersman> Anti-spam folks *like* it that it's not trivial to get ebersman> "correct" rDNS/PTRs. It's easy to find consumer connections ebersman> based on the ISP doing bulk/lazy PTR generation and just ebersman> reject SMTP traffic from them. marka> Which won't work in IPv6 unless you syntesize the records on marka> demand. And that's the plan, at least for $DAYJOB. And sign on the fly for those of us signing our zones. ebersman> Large ISPs don't care about clean PTRs as long as no customers ebersman> complain and they don't care if end customers can't do SMTP ebersman> without having to ask for it in some special way. marka> Except autogenerated PTR records don't solve the problem. How not? Works fine for v4 right now. Customers that want to do their own email usually have to make a special request to their ISP but can do it. Biz connections are allowed to do their own PTRs at most ISPs, assuming the customers want and need it. And if they do "clean" PTRs as part of this, the anti-spam folks are happy. ebersman> What else in the way of tradeoffs is missing? marka> That people want IP to name mappings for their internal networks. Get a biz connection or a service to allow this. marka> With things like DNSSEC you need break DNSSEC trust chains at the marka> ISP level for this to work. Even our biz customers mostly don't do or want DNSSEC on PTRs. As this changes, we'll figure out how to do this as a service. But all the work of getting in DS and doing clean zone cut and delegation has nothing to do with this draft either. marka> We also don't know what else will come along to use the reverse marka> namespace. It is a good place to hang keying material which is marka> tied to IP address. So you're volunteering to work on a draft mentioned documenting how folks are using PTR space? Thanks! marka> Having a well defined method to update this name space will be marka> useful. Another draft. But not this one. If such a method did already exist, worked and had at least reference implementations, it would certainly be worth mentioning in this draft. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
