I initially got a call from a client in Calgary complaining that she could not reach one of our web sites - rebekahcourt.com - unless she disconnected from her WiFi and tethered to her cellphone.
Turns out the servers she’s using at Shaw Cable in Alberta - 64.59.135.145 and 64.59.128.121 - won’t resolve that site or a new sister site, hannambnb.com. But while I was waiting for her to get me that info, I was fiddling with dig via digwebinterface dot com ('cause I’m a Windows guy, sorry, LOL)…
First thing I found was that Google, AT&T, Comodo, HiNet, OpenDNS, Securolytics, UUNET, Verisign and Yandex report back the A records correctly but Cloudflare and Quad9 do not, seeming to time-out.
After a little more fiddling what I began to notice was that my domains with DNS hosted at DirectNIC or CarrierZone (Fusion/Megapath, yech) were fine but that domains with their DNS records hosted on old Windows boxes under my desk (yes, static IPs, thanks) were a problem.
Maybe a coincidence, but I doubt it.
Frankly there’s no reason for me not to move all my DNS to DirectNIC at this point but just so this doesn’t bite me in the tush with other clients in the future, I’d really like to know why Cloudflare (and Quad9) don’t like my old Windows DNS servers, and maybe what the heck is going on with Shaw and whether or not there’s a connection. Any thoughts?
The issue has to do with missing responses from the server. Fix that and the issues will go away. Maybe purge them after the fix is done, https://1.1.1.1/purge-cache/.
The visualization takes a long time, I presume the Authoritative DNS server is slow to reply…?
Things are slightly inconsistent with Quad9. A recent try of rebekahcourt at digwebinterface got an A record back from there in 224ms. Another one, Quad9 said SERVFAIL after 2ms.
Missing responses, puzzling, when the responses are quick enough for 13 out of 15 servers tried. But yeah, Cloudflare gave up after four seconds and Quad9 after 1.6s. HiNet-TW didn’t mind waiting 3.8s in one instance and all the rest come back between under 30ms and as much as over 500ms.
I cleared the caches on the DNS box and at 1.1.1.1 without any consistent changes in behavior.
The DNS box isn’t exactly a hot rod but it’s not that slow.
Would the fact that I don’t support DNSSEC be the actual culprit here??
Or perhaps it’s some sort of comms issue getting from point A to point B and back? A tracert from my DNS to 1.1.1.1 and 9.9.9.9 seems relatively uneventful (request timeout between Charter in CO and Newark1.Level3) and not unusually circuitous. To 8.8.8.8 which never gives me issues isn’t all that different. My longest pings to 1.1.1.1 are under 30ms.
Oh, digwebinterface with the trace option on shows that the box running dig isn’t having any latency issues hitting the authoritative DNS. The .228 address is my ns2…
[email protected] (CloudFlare):
*dig +noadditional +noquestion +nocomments +nocmd +nostats +trace rebekahcourt.com. @1.1.1.1*
(...)
rebekahcourt.com. 3600 IN A 24.103.21.229
;; Received 50 bytes from 24.103.21.228#53(24.103.21.228) in 50 ms
I would suggest one thing at this point, maybe open a support ticket (you do have an account with Cloudflare after all, just e-mail them at support AT cloudflare DOT com) and let them check internall what happens.
In the mean time @cloonan and @cs-cf can take a look if they aren’t away for the holidays
Also, doing the trace command myself seems like your DNS server isn’t returning anything to them…
$ dig rebekahcourt.com @1.1.1.1 +trace
; <<>> DiG 9.10.6 <<>> rebekahcourt.com @1.1.1.1 +trace
;; global options: +cmd
. 7489 IN NS g.root-servers.net.
. 7489 IN NS h.root-servers.net.
. 7489 IN NS i.root-servers.net.
. 7489 IN NS j.root-servers.net.
. 7489 IN NS k.root-servers.net.
. 7489 IN NS l.root-servers.net.
. 7489 IN NS m.root-servers.net.
. 7489 IN NS a.root-servers.net.
. 7489 IN NS b.root-servers.net.
. 7489 IN NS c.root-servers.net.
. 7489 IN NS d.root-servers.net.
. 7489 IN NS e.root-servers.net.
. 7489 IN NS f.root-servers.net.
. 7489 IN RRSIG NS 8 0 518400 20200103170000 20191221160000 22545 . epgkhEUL7s4760l0aMGSfDcWD8z18BM/LjrFMFLffo8cnHWTRcdRchHr PdgOZrDMQsUnpzuf/D98BCh8H/xWLABBNV9g8iJwziB59WvGec+BN9of /sLuB+nxypKILpAoUV+OGgK62NWOdBCpl95um+uxZm0Ss8cXFYDMnXgV LYFA+fRN0SIWJNEq7IiehSej4sxAssWn+8iVhfyvVnG5C9wFTbnThhkQ RcGxscZnSdq+nSNGjNmR44hboPddaIDeNbye1bFke1kDJVUqfkRknW0u QilDsG0wcFsaaifiVml7r2ioDPMk0Bbf3jSIp9w5/OBycJI7x27Obxak pB2f/Q==
;; Received 717 bytes from 1.1.1.1#53(1.1.1.1) in 44 ms
com. 172800 IN NS a.gtld-servers.net.
com. 172800 IN NS b.gtld-servers.net.
com. 172800 IN NS c.gtld-servers.net.
com. 172800 IN NS d.gtld-servers.net.
com. 172800 IN NS e.gtld-servers.net.
com. 172800 IN NS f.gtld-servers.net.
com. 172800 IN NS g.gtld-servers.net.
com. 172800 IN NS h.gtld-servers.net.
com. 172800 IN NS i.gtld-servers.net.
com. 172800 IN NS j.gtld-servers.net.
com. 172800 IN NS k.gtld-servers.net.
com. 172800 IN NS l.gtld-servers.net.
com. 172800 IN NS m.gtld-servers.net.
com. 86400 IN DS 30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com. 86400 IN RRSIG DS 8 1 86400 20200103170000 20191221160000 22545 . PbApTIGSE03g7dx1f6K8xx7BeenJktWIWVF8ZeIDHXVtrin1lO4x2QDK UIWaWdw1qlAHDv1JmYrSjFZFTDzez5oIyeLzI7Q9fZ70uKGWhiNun4+g 1dS5IsqiD53ZxbkKHo5N4A/mmRhUg0lDURC8sGDBTcEmSuWtPRArUAV6 s+OLPyc6L8ZRBb0zo8B9ENp/BmPiBXiz2lQW49hkEF2tZ15w9feyOdB4 LhjJkF5tW6sV0E5Oih1HNNO2ku9LIR+sLbKPdB8EwQWo9QBkDTI31j3i t293aNti4reS64IcuWubr6JyLktyyH8fCfyvTKU/y6+i9kgvvF4BMtVG DTYgwA==
;; Received 1176 bytes from 199.7.83.42#53(l.root-servers.net) in 45 ms
rebekahcourt.com. 172800 IN NS ns1.bytebrothers.net.
rebekahcourt.com. 172800 IN NS ns2.bytebrothers.net.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20191225055021 20191218044021 12163 com. Okm0yKoeKjwyMPSHEJzaOdUJs22D32afLWS6hSJ6ercEFSEj0EdV858u wOTWthnTq5mTJRNe29xgT2w08GIwsJqV6BVCZZq1AD2UxUFeLBqMy7fm uGt1qUrWWGRDUBfE7zXpH5603yzZkLvOQuewRlZRo4UEJ2REatGQ24oZ XxcvesxIVEgWXjEjp+BZ90Fqm09xQ1Xpetr5WAigcR35QQ==
9C4M0EDKQ2CURC735886U0KCISQ5Q3G4.com. 86400 IN NSEC3 1 1 0 - 9C4N7USKJPGUFFB2QH1UG57IB1702GOE NS DS RRSIG
9C4M0EDKQ2CURC735886U0KCISQ5Q3G4.com. 86400 IN RRSIG NSEC3 8 2 86400 20191226053107 20191219042107 12163 com. dexVdchkpQnZlre8HcxZja6hnklxeKorBbnGSK5szceLjBFcfCdcqjl3 iEeR8t3enEUGcTRGDBdbuO2/pDgU7C9K5lSqEhwqMIJ0AYklv7tdpLGi BmHVldRo/JT1GhIWjhfRJGH1HJLkCt8+OsnFUCeRpNCvLpy0JAGSpQf1 9S5sTbFVwjr00pdOY50y0JfIZUAUIXIlue7Jef16hSSAag==
;; Received 646 bytes from 192.33.14.30#53(b.gtld-servers.net) in 141 ms
;; Received 45 bytes from 24.103.21.228#53(ns2.bytebrothers.net) in 169 ms
I also tried their test IP for the new version of the resolver, 1.0.0.2 (which is a beta they mention here on this forum), and that seems to work even though it’s slightly slow, but doesn’t support trace. @irtefa, any chance you can take a look?
Sitting here 6,867 miles (give or take a few meters, LOL) from my DNS server, NSLOOKUP works fine, so I can’t blame the ISP but blaming a POP or NAP somewhere still ain’t outta the question. Also gonna download BIND 9 and run DIG for myself in a little while.
