PTR records for IPv6

[Erik Nygren]

Is it worth adding that convention (with some guidelines) to the wildcard
section of Lee Howard's isp-ip6rdns draft or to a follow-on to RFC 4472?

    https://datatracker.ietf.org/doc/draft-howard-isp-ip6rdns/

Given that this topic seems to be getting attention here, I'd encourage
people to provide feedback on that draft over on v6ops as I think it would
be valuable for that draft to get picked up and moved forwards...

Between mail reputation systems and ease-of-debugging, I think it would be
valuable for IPv6 PTR records to exist more consistently than they do
today.  (When I looked at observed client IPv6 addresses about a year or so
ago, only a tiny fraction of them had PTR records.)

         Erik



On Sun, Sep 1, 2013 at 9:14 PM, Lorenzo Colitti <lorenzo at google.com> wrote:

> On Mon, Sep 2, 2013 at 10:05 AM, Jason Fesler <jfesler at gigo.com> wrote:
>
>> On Sun, Sep 1, 2013 at 5:30 PM, Lorenzo Colitti <lorenzo at google.com>
>> wrote:
>> > What's wrong with wildcard PTRs?
>> >
>> > *.e.f.a.c.8.b.d.0.1.0.0.2 IN PTR customer-cafe.isp.net.
>>
>> And, customer-café.isp.net <http://xn--customer-caf-meb.isp.net> has
>> AAAA records to what exactly?
>>
>> It isn't just reverse DNS.  It is reverse + matching forward DNS.
>> Mismatches in the IPv4 world are greatly penalized both at SMTP time
>> and by SpamAssassin.
>>
>
> To 2001:db8:cafe::. Then we can modify SMTP servers and spam systems to
> look at only the first 64 bits and we sort of have parity to what we have
> today.
>
> Of course, if people put multiple customers on the same /64 then those
> customers can influence each other's reputations. But this is no different
> to what happens today to customers on the same public IPv4 address (e.g.,
> shared hosting, SMTP relay).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cluenet.de/pipermail/ipv6-ops/attachments/20130904/3cb51c75/attachment.html