ebersman> My concern is random folks who currently accept any v4 PTR
ebersman> regardless of format (but caring if there is no PTR at all)
ebersman> will do something equally bad in v6. i.e. NYT web content and
ebersman> similar pointless cruft. Putting in an auto-gen'ed v6 PTR
ebersman> would satisfy that level of check.

TLemon> The status quo is that the ISP doesn't add a PTR record for a
TLemon> customer IPv6 address, nor delegate the zone.   Lots of IPv6
TLemon> users are getting by just fine right this very moment (including
TLemon> me) without this.  So I think it's safe to say that we do not
TLemon> need to solve this problem: if there is damage, it has already
TLemon> been routed around.

This is a lovely thought. And I really hope it's true. I've thought
since the early 90s that most things we did with PTRs other than network
interfaces were questionable usefulness for pain that we're still
dealing with supporting.

However, I'm concerned that this (v6 working fine without already) is
just as much an unsupported assumption as that we must support PTRs for
content with no good data (other than various anecdotal stories) and no
idea of what would break if we didn't do them.

IPv6 is still in early adoption for broad general use and we don't know
what plans folks have for requiring PTRs.

TLemon> So really all we need to talk about is whether there are
TLemon> features to add, not whether we need to fix something right now.
TLemon> It's already too late for that.

I would still like to see:

  - actual data on how/where PTRs are being used and abused now (beyond
    the known mail filtering) to see if any of those folks are planning
    on continuing the bad idea into v6

  - suggestions on how/if we can clean PTR usage, v4 and v6

I'm not expecting anything I'll be able to use to clean up current v4
usage, but I'd love to be pleasantly surprised. If someone does come up
with a solid performance/efficiency improvement or a biz case for
keeping better track and use, I'd certainly take that to my mgmt.

As for the current draft, if it doesn't happen, I'll still need to cope
with customer breakage and vendors will produce solutions that customers
like me pay for. I'd much rather have a consistent approach across
vendors and guidance in the IETF I can point to but I will probably have
to do something about PTRs in the next year or two. And it will probably
be something icky but less icky than screaming customers...

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to