Re: [dns-operations] cloudflare-dns.com doesn't have reverse DNS

2023-09-23 Thread Mark Andrews
CNAMES return the canonical name.  Add that in the PTR.   Really that is the 
name you need when you have operational problems.

-- 
Mark Andrews

> On 24 Sep 2023, at 04:38, Joe Abley  wrote:
> 
> Op 23 sep 2023 om 19:48 heeft Fred Morris  het volgende 
> geschreven:
> 
>> I think what's happening with cloudflare-dns reflects my working hypothesis, 
>> which is that infrastructury stuff has a higher likelihood of having reverse 
>> DNS attended to and cloudy, direct to consumer stuff has a lower likelihood.
> 
> I guess, maybe, depending on what you mean by infrastructury and consumer, 
> which are pretty broad categories :-)
> 
>> The question in my mind is how often the same entity controls the forward 
>> domains and the relevant reverse domains, because there is little to no 
>> technical impediment in that case for generating and publishing a 
>> notional-as-to-intent reverse DNS entry from their own forward emissions.
> 
> Using Cloudflare's customers as an example, some people bring their own 
> addresses for a variety of reasons and others use Cloudflare addresses.
> 
> In both cases it is possible for there to be a one to one, static mapping 
> between a single name and a single address, but the more common situation by 
> far is for there to be many (sometimes very, very many) names associated with 
> a single address, and for the mapping to be dynamic and to change often. What 
> reverse DNS strategy makes sense in that scenario? The strategy of not 
> provisioning reverse DNS at all in those cases does not seem ridiculous. 
> 
> In the case where a one to one mapping does exist between a customer address 
> and a customer name, my observation is that people don't bother to make 
> reverse DNS available even though it is quite easy to do so. This seems to 
> support the apparent consensus that there's no compelling operational reason 
> to bother.
> 
> 
> Joe
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations


Re: [dns-operations] cloudflare-dns.com doesn't have reverse DNS

2023-09-23 Thread Joe Abley
Op 23 sep 2023 om 19:48 heeft Fred Morris  het volgende 
geschreven:

> I think what's happening with cloudflare-dns reflects my working hypothesis, 
> which is that infrastructury stuff has a higher likelihood of having reverse 
> DNS attended to and cloudy, direct to consumer stuff has a lower likelihood.

I guess, maybe, depending on what you mean by infrastructury and consumer, 
which are pretty broad categories :-)

> The question in my mind is how often the same entity controls the forward 
> domains and the relevant reverse domains, because there is little to no 
> technical impediment in that case for generating and publishing a 
> notional-as-to-intent reverse DNS entry from their own forward emissions.

Using Cloudflare's customers as an example, some people bring their own 
addresses for a variety of reasons and others use Cloudflare addresses.

In both cases it is possible for there to be a one to one, static mapping 
between a single name and a single address, but the more common situation by 
far is for there to be many (sometimes very, very many) names associated with a 
single address, and for the mapping to be dynamic and to change often. What 
reverse DNS strategy makes sense in that scenario? The strategy of not 
provisioning reverse DNS at all in those cases does not seem ridiculous. 

In the case where a one to one mapping does exist between a customer address 
and a customer name, my observation is that people don't bother to make reverse 
DNS available even though it is quite easy to do so. This seems to support the 
apparent consensus that there's no compelling operational reason to bother.


Joe
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations


Re: [dns-operations] cloudflare-dns.com doesn't have reverse DNS

2023-09-23 Thread Fred Morris

On Fri, 22 Sep 2023, Joe Abley wrote:



Op 22 sep 2023 om 16:26 heeft Grant Taylor  het 
volgende geschreven:

I have long viewed operational, or better accurate, reverse DNS as an 
indication that a network cares enough to set up lesser valued 
services.


Me too, actually. I don't personally think it's the only such 
indication, or a particularly strong one, even, but I agree with you.


So, mail sending, traceroute and marketing to niche technical audiences? 
:-)


I think what's happening with cloudflare-dns reflects my working 
hypothesis, which is that infrastructury stuff has a higher likelihood of 
having reverse DNS attended to and cloudy, direct to consumer stuff has a 
lower likelihood.


In some cases CNAME chains obviously make the commonly understood meaning 
of reverse DNS "operational but not accurate", but not the intent in my 
opinion. In other cases (looking at you, Fastly) you just get back 
NXDOMAIN.


In the field, I seldom see a single address serving content across 
multiple entities of control (businesses) at a given point in time, what I 
see is more along the lines of e.g. cdn.technologynetworks.com and 
www.technologynetworks.com both resolve to the same address, and one is 
probably queried more than the other.


The question in my mind is how often the same entity controls the forward 
domains and the relevant reverse domains, because there is little to no 
technical impediment in that case for generating and publishing a 
notional-as-to-intent reverse DNS entry from their own forward emissions. 
I give away software on GitHub to do that for consumer/client networks 
today (pay particular attention to the heuristic for choosing which option 
of many to generate the record for, so there is a single record best 
reflecting intent).


--

Fred Morris___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations