When querying Cloudflare nameserver for IP of hosted sites, we get one IP (174.64.80.1) - regardless of the actual URL. URLs impacted are pdac[.]ca, bespokeav[.]ca, copyposse[.]com, cprs[.]ca, SABLEINDUSTRIESINC[.]COM, caufp[.]ca, pdffactory[.]com. see whatsmydns[.]net
Welcome to the Cloudflare Community. 
Those are hostnames not URLs, which is good since that is what you need for a DNS query.
None of those hostnames returned the 174.64.80.1 IP when I queried them. They all returned Cloudfare IP pairs which indicate they are 
Proxied.
Thank you for your kind reply.
I think they are domain names. I didn’t type the full URLs. You can assume http(s) for all of them.
Our experience is that some nameservers return the Cloudflare IP pairs and others don’t. Our service provider has two geographically dispersed data centres and they get different results when they make the query. We’ve been getting 174.64.80.1 from one machine / data centre for almost a week now so it probably isn’t a local cache issue.
If you look up [https:]//www[.]whatsmydns[.]net/#A/caufp[.]ca, you can see that MetroOptic in Montreal has the 174.64.80.1 address.
Unfortunately, the only Canadian location that is presented to me on the WhatsMyDNS site is St. John’s, Canada Memorial University of Newfoundland and it shows the Cloudflare IPs.
What resolvers are you using when you obtain the erroneous IP?
I can see the IP being returned there:
It also returns another single IPv6 ( 2606:4700:130:436c:6f75:6466:6c61:7265), alongside the IPv4 172.64.80.1.
Interesting that this has been reported on the forum before as well (
), but it doesn’t seem to cause any issues. Cloudflare does change their proxy IPs every so often as well.
Cloudflare does use the same IPs for multiple sites, they can tell which site the request is for based on the Server Name Identifier (SNI) and Host Header. The Proxy IPs - including that one, are Anycast, requests are routed to the closest Cloudflare location and load balanced across machines.
Is there a specific issue you were reporting with this?
If I force this IP via curl, it still returns a correct response:
curl -svo /dev/null https://caufp.ca --connect-to ::172.64.80.1
...
< HTTP/2 200
< date: Wed, 15 Mar 2023 01:36:22 GMT
< content-type: text/html; charset=UTF-8
< link: <https://caufp.ca/wp-json/>; rel="https://api.w.org/", <https://caufp.ca/wp-json/wp/v2/pages/29>; rel="alternate"; type="application/json", <https://caufp.ca/>; rel=shortlink
< cache-control: max-age=2592000
< expires: Fri, 14 Apr 2023 01:36:20 GMT
< vary: Accept-Encoding
< host-header: c2hhcmVkLmJsdWVob3N0LmNvbQ==
< x-endurance-cache-level: 2
< x-nginx-cache: WordPress
< cf-cache-status: DYNAMIC
...
< nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
< server: cloudflare
< cf-ray: 7a81065e4fc141a9-EWR
Edit: I realized the IP you originally reported it as, 174.64.80.1 (starting with 174) is different than the IP returned by the nameservers that I can see, which is 172.64.80.1 (starting with 172). Guessing that was just a typo?
That changes everything. I was operating on the impression that the problem was a Cox IP being returned when a Cloudflare IP was expected. If a different Cloudflare proxy IP is being returned that should not matter.
2 Likes
Is there a specific issue you were reporting with this?
CISCO Cloud Email Security looks up URL reputation based on IP address. When non-accurate IP is returned, non-accurate reputation is assigned and… email is blocked.
I realized the IP you originally reported it as,
174.64.80.1(starting with 174) is different than the IP returned by the nameservers that I can see, which is172.64.80.1(starting with 172). Guessing that was just a typo?
Yes. Sorry.
Sadly, I don’t control that. We’re using a hosted CISCO solution.
That sounds like something that only Cisco can fix. If what you describe is the cause of email being miscategorized, their process is damaged by design.
I’d agree with you however we have two deployments in geographically dispersed data centres and only one has this issue when it queries Cloudflare nameserver information. They query different systems for IPs of the sites (due to geography) - which returns different information (as shown in the whatsmydns queries - some locations share the 172.64.80.1 address that they get from Cloudflare and some have the actual IPs). This information is provided to the dns servers from Cloudflare.
All other queries are successful at both data centres. It’s just the one where requests for IP addresses for sites hosted by Cloudflare come back with the one IP.
I understand. The relevant aspect is that it is Cisco, not Cloudflare, that is making the problematic decision based on the iP address, which is clearly not going to always be the same across geographical locations. That means that only Cisco can fix their product’s defect.
I find it curious that their product is struggling with that IP when their own reputation platform. which sits behind the Cloudflare proxy, indicates no problems with it.
https://talosintelligence.com/reputation_center/lookup?search=172.64.80.1
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.