PTR records for IPv6
erik at nygren.org
Wed Sep 4 15:26:35 CEST 2013
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?
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.)
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>
>> > 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
> 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...
More information about the ipv6-ops