knowing its not the root issue, I would like to remind people the RIR system for rDNS delegation is almost entirely automatic from our various portals, and WHOIS based nserver mechanisms. Its not hard to do the top part. We're not roadblocking.
We don't have any failure to delegate the parent blocks facing down: Its people's willingness to invest energy on the various different approaches to the sub-delegation engines inside your own block management, be it embedded in the NMS or some kind of customer facing provisioning web portal or whatever. What we don't do, (noting 6to4 reverse as a very specific counter-case) is permit 'hop over' in the delegation chain because its got issues regarding 'who said you could do that' we don't want to prod. The delegation sequence really has to be top down if you have sub-delegation state. Personally, and it is only my personal view, I like some of the older ideas for semi-machine generated and wildcarded reverse I saw presented at the RIPE ROME meeting. And I see some value in sign-on-the-fly work. I think rDNS remains potential for big value. I can't verbalize it well, but it has qualities about trust which for me could be useful. Its volountarist nature is a huge counter argument as you've all exposed here: can't depend on it. coverage is low. -G On Sun, Nov 2, 2014 at 7:20 PM, Paul Ebersman <list-dn...@dragon.net> wrote: > > ebersman> So your grand scheme is > > vixie> decorum? > > No objections here if you succeed. :) > > ebersman> ... to limit who can get v6 PTRs and that will be the new > ebersman> standard of whether or now you're tall enough to send email > ebersman> with the big boys? > > vixie> yes. > > Well, for my $DAYJOB, that's certainly something we support. As someone > who runs my own mail server and knows other small businesses who do as > well, I'm still hoping we can come up with a better system that lets > some of the smaller players in too. > > ebersman> How about we admit that PTRs as a measure of trust and > ebersman> reputation is broken to begin with and won't scale or > ebersman> magically work better for v6 than v4? Let's come up with a > ebersman> better solution(s). > > vixie> i think we're on the same page, actually. where we're still far > vixie> apart is in our understandings of how things work today, in other > vixie> words, what status quo are we living with; and also, whether and > vixie> in what direction we can change it. > > I'm happy to be educated or corrected by hard facts. And I agree we > probably ultimately want the same thing: email that is more signal than > noise to mail servers. > > Getting back to this draft, I think there is enough value in enumerating > the challenges and tradeoffs of doing some kind of v6 PTRs to try to get > the draft out soon. Plenty of folks (including $DAYJOB) want something > short term that doesn't break anything and looks/smells somewhat like > what we already have in v4. No argument that a better solution here long > term would be welcome too; I just don't want folks to have another > excuse not to roll out v6 now. > > As for a grander scheme to clean up the PTR space, do you agree that > breaking that out into a separate draft is more productive? > > It does seem to make sense to mention that folks doing the $GENERATE > equiv will get the same short shrift from the anti-spam folks that the > v4 PTRs get currently. > > Any other comments/additions to this draft? > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
