When I trace the DOS it comes back to my own IP Provider (AT&T) and then I do a little more investigation to find that it is blocking both 1.1.1.1 and 1.0.0.1
https://news.ycombinator.com/item?id=16980292
The link above explains it better than I can.
Here’s the cf CEO tweeting about it: https://twitter.com/eastdakota/status/991718955021623296
Is there a workaround to this?
Without the cooperation of your ISP generally not.
It also depends on whether the address is misrouted on your own router or on an ISP level. I remember a thread from a couple of months ago where an AT&T user reported the same or similar problem. In this case his own AT&T router blocked it but there was a firmware update available which fixed that.
Whether this is something that applies in your case too, is something I cannot say I am afraid.
I think it’s due to the webpages I have compiling the issues of that AT&T mandated modem. Hey Sandro, if you find time will you tell me your take on this telephone recording? In the beginning are the allegations of the previous internet provider (spectrum) and at the end of the recording is arris.
Any insightful comments would be much appreciated. I have a few webpages but am wondering if the main audio recording is understandable or if it needs to be cut more.
Are you able to test with IPv6? If IPv6 works but IPv4 doesn’t, it’s most likely a bug, rather than something intentional. There seems to be some contention in that Hacker News thread over whether the IPv6 endpoints are accessible via AT&T.
If you want a quick and dirty workaround, look up the IP addresses for cloudflare-dns.com, then use those in place of 1.1.1.1 and 1.0.0.1. They’re liable to change without notice, but they’re a lot less likely to be blocked or interfered with by router bugs. The caveat is that I’m fairly sure this isn’t a supported configuration and is likely to break eventually.
I did test IPV6 and only allow access to the site using 443. I also have this listed in the iptables to allow access only through cf:
-A INPUT -p tcp -m tcp --dport 80 -j DROP
-A INPUT -m state --state INVALID -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -s 173.245.48.0/20 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 103.21.244.0/22 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 103.22.200.0/22 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 103.31.4.0/22 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 141.101.64.0/18 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 108.162.192.0/18 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 190.93.240.0/20 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 188.114.96.0/20 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 197.234.240.0/22 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 198.41.128.0/17 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 162.158.0.0/15 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 104.16.0.0/12 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 172.64.0.0/13 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j DROP
-A INPUT -p tcp --dport http -j DROP
Not sure if the entries above are properly ordered in an optimized fashion, but the initial effect was a reduced number or attacks getting through (setting in cf firewall is on HIGH).
Here’s one of the notices I receive:
No. Don’t mix 1.1.1.1 and any web services running behind Cloudflare and your router. ATT did block Cloudflare’s DNS (1.1.1.) ‘accidentially’ which could be solved with a firmware update.
The iptables rules are correct (your websites are working. ).
Run a traceroute and post the results please.
About your screenshot:
Where does this come from? 104.28.4.102 cannot redirect to your domain because it’s a shared IP address from Cloudflare. Direct access via IP is not possible.
Any website really is not involved here. Either you can connect to 1.1.1.1 or you cant. In your ISP’s case it seems certain hardware prevents that. At least this was the case a while ago, maybe now they block this on a network level, but this is difficult to tell for someone on an AT&T network, let alone for someone who is not.
In short, you best clarify this with your ISP and - if the issue is with the router - ask for a firmware update.
Below is the traceroute you requested. When you say don’t mix 1.1.1.1, I am confused.
What I did was choose the network connection and selected for ADDRESS ONLY and instead of the IP Provider’s ipv4 dns I put 1.1.1.1 and 1.0.0.1, for the ipv6 i put : 2606:4700:4700::1111, 2606:4700:4700::1001
Is this what I shouldn’t do?
Why would you run a traceroute to your domain if you are asking about the DNS service?
Not sure (*why did i?) LOL In case I was supposed to traceroute 1.1.1.1 it appears to be working (now): 
Me neither.
Your question is about the DNS service, not anything web or your site related, correct?
In that case, my two initial comments basically summarise it. If your ISP blocks anything, only they can unblock it.
If it would be working, 1.1.1.1 (one.one.one.one) would be the last HOP in that list. It isn’t. I don’t even see that the traffic is leaving GTT’s network. to Either the trace was incomplete or the tool you used is…
You are running a Linux system. Open a terminal and type
traceroute 1.1.1.1
If traceroute is not available on your system install is with APT or yum or whatever the package manager is.
Smart thinking. Not sure why the results are different, I suspect you are right about the tools used. This is using your method:
1 192.168.1.254 (192.168.1.254) 0.699 ms 0.702 ms 0.726 ms
2 76-243-32-1.lightspeed.cntmoh.sbcglobal.net (76.243.32.1) 21.465 ms 21.729 ms 21.900 ms
3 75.14.96.61 (75.14.96.61) 22.401 ms 22.963 ms 23.059 ms
4 12.123.159.246 (12.123.159.246) 32.971 ms 32.980 ms 32.971 ms
5 cgcil403igs.ip.att.net (12.122.133.33) 33.210 ms 33.227 ms 34.182 ms
6 ae16.cr7-chi1.ip4.gtt.net (173.241.128.29) 31.580 ms 44.799 ms 30.343 ms
7 et-1-0-1.cr9-chi1.ip4.gtt.net (141.136.108.221) 31.314 ms 31.302 ms 31.299 ms
8 ip4.gtt.net (208.116.131.178) 63.155 ms 63.190 ms 63.093 ms
9 one.one.one.one (1.1.1.1) 31.177 ms 30.417 ms 30.336 ms
From that traceroute you seem to be able to reach the machine, unless they hijacked the address and respond on their own.
Can you actually use the service? What was the motivation for your posting in the first place?
Sandro if I had to summarize it would be futile. So I sufficed to focus just on what I thought was a problem because the site that tested my site said it was an issue (attachment).
How is this related to Cloudflare’s DNS service?
Which site tested your site? Can you provide an actual link?
It is related to the proxy address and am not sure but somewhere along this thread dns was mentioned (probably my alter ego). I’ll go dig up the ip address of the service in history (have to check three browsers)…brb
You might want to clarify this with him 
If the issue is not clear, there is no way to say anything and guessing shouldnt be part of the game
We agree. This is the url and the results. The areas I became alerted were the sudden items in red and then of course the statement that the ip does not correlate to my website…so I was hoping that maybe that was the cause for the sudden drops by google (and twitter and facebook simply suspending me without notice (again for both of them)… So that’s when I started looking into dns and other possible causes for strange extremes every other week.
That is a completely different issue.
That simply checks if you have a dedicated IP address and if that address redirects to your domain. This never will be the case in Cloudflare’s case.
Not related to the DNS service and only very superficially related to the core web service.
In short, no issue here.
