[dns-operations] PTR Records for Broadband Network?

[Joe Abley]

Hi Michele,

On Nov 23, 2022, at 07:46, Michele Neylon - Blacknight via dns-operations <dns-operations at dns-oarc.net> wrote:

> <mime-attachment>

Hmm :-)

> Many many moons ago we setup the PTR records for our network using a template that clearly flagged that the IPs were static and used for hosting.
>  
> The result was that the IP 185.97.239.13 would end up with a PTR record of 239-13.colo.sta.blacknight.ie
>  
> Fast forward to 2022 and we now offer broadband to both businesses and consumers, but unfortunately some streaming services and others are blocking access. So our users have issues with Disney+, All4, Netflix and Ticketmaster to name but a few examples. One of the issues appears to be the PTR records.

It might be worth reaching out to some of the people you know your customers are struggling with specifically and seeing what they are looking for. The presence and functional correctness of PTR records is known to be used as one heuristic for e-mail abuse ops; I hadn't heard of it for things like Netflix but what do I know?

I assume these PTR records you have made are correctly published. Have you checked that the PTR targets (the 239-13.colo.sta.blacknight.ie name and its friends) themselves resolve back to the right address?

Are the address ranges you are using for your customers tainted through some prior abuse, e.g. by some other organisation that used to use them? Do they appear on any of the usual blacklists?

I have seen informal guidance to access providers in the past on what naming conventions are useful. I can't seem to find any of them right now but your naming scheme does not seem ridiculous. I would be surprised if that's the problem.

You might want also to ask this question on the kind of more general lists that access and content providers hang out on.


Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20221123/7b8b2281/attachment.html>