Google Public DNS at 8.8.8.8 is one of the most reliable services on the internet, so when it looks down the problem is almost always somewhere between you and it - your local resolver, your router, or your ISP - not Google’s servers. You can prove exactly where the break is in about a minute with dig, ping, and a second resolver to compare against. Before you change anything, run those three checks: query 8.8.8.8 directly, test raw reachability, and try a different DNS server. That tells you whether to wait it out, restart your router, or switch resolvers - instead of guessing.
The instinct when the internet feels broken is to blame DNS, and the instinct when DNS feels broken is to blame Google. Both are usually wrong. Measure first.
Table of contents
- Check Google DNS directly with dig
- Separate reachability from resolution
- Compare against a second resolver
- Check whether it is really down for everyone
- The usual fixes, matched to the cause
- How this fits the rest of the stack
- FAQ
Check Google DNS directly with dig
The first question is whether 8.8.8.8 answers you at all. Ask it to resolve something and watch:
dig @8.8.8.8 example.com- You get an answer with an IP - 8.8.8.8 is working fine for you. Whatever is broken is elsewhere (your normal resolver, a specific site, or your app).
- It times out - your machine cannot reach 8.8.8.8, or 8.8.8.8 genuinely is not responding. The next checks tell you which.
On Windows, use nslookup example.com 8.8.8.8 for the same test. This one command settles the most important question: is Google DNS actually the thing failing, or is it fine and you are looking in the wrong place? Nine times out of ten it answers instantly and the investigation moves on.
Separate reachability from resolution
If dig timed out, find out whether you can even reach 8.8.8.8 at the network level:
ping 8.8.8.8Ping uses no DNS at all - it goes straight to the IP. So:
- Ping works but dig fails - the network path is fine and the DNS service is the issue (rare for Google, but possible during a genuine incident) or something is blocking port 53 specifically.
- Ping also fails - this is a network problem, not a DNS problem. Your router, your ISP, or your connection is down, and DNS is just the first thing you noticed. No resolver change will help.
This split - reachability versus resolution - is the single most useful diagnostic in networking. ping tests the road; dig tests the destination. Knowing which one failed points you at the right fix instead of the nearest one.
Compare against a second resolver
To confirm whether the fault is 8.8.8.8 or your setup, ask a different DNS server the same question:
dig @1.1.1.1 example.com1.1.1.1 is Cloudflare’s public resolver - an independent service on an independent network.
- 1.1.1.1 answers but 8.8.8.8 does not - the problem is specific to reaching Google’s resolver from your network. Switch to 1.1.1.1 and you are working again while you investigate.
- Neither answers, but ping works - something local is blocking DNS (port 53) for everyone: a firewall rule, a captive portal, misconfigured network settings.
- Both answer fine - DNS is not your problem at all; look at the specific application or record that sent you here.
Comparing two resolvers turns “is Google down” into a definite answer in one command.
Check whether it is really down for everyone
If your own tests are inconclusive, check whether the outage is global or just you. Google publishes a status dashboard for Public DNS, and outage-tracking sites aggregate user reports.
The reality check: 8.8.8.8 handles an enormous share of the world’s DNS queries and has redundancy most services can only dream of. A true, widespread 8.8.8.8 outage is rare and would be immediately visible everywhere - major sites reporting problems, the status page acknowledging it. If the wider internet looks normal and only your connection is affected, that asymmetry is your answer: it is you, not Google. Occasionally one of the pair (8.8.8.8 vs the secondary 8.8.4.4) has a blip while the other is fine - worth trying both before concluding anything.
The usual fixes, matched to the cause
Once you know where the break is, the fix follows directly:
- 8.8.8.8 unreachable, 1.1.1.1 fine - switch your resolver to 1.1.1.1 (or your ISP’s) in your OS or router network settings. Working immediately; investigate later.
- Both public resolvers fail, ping works - a local block on port 53. Check your firewall, disable any DNS-filtering software, or look for a captive portal you have not logged into.
- Ping fails too - it is your connection or router. Restart the router, check the physical link, or call the ISP. DNS was a symptom.
- Everything resolves but one site is broken - not a resolver problem at all; that site’s DNS record or the site itself is the issue.
Flush your local DNS cache after switching resolvers so old answers do not linger. The point is that each cause has a different fix, and the three commands above tell you which one you have before you touch a single setting.
How this fits the rest of the stack
Whatever you decide here, the cost of it eventually shows up as a bill. The RunxBuild hosting calculator is the right place to model that before committing: the compute, the database, the storage, the bandwidth, the worker - each one is a separate line item, and the real cost of a platform is the sum, not the headline number. The RunxBuild dashboard is where the team sees the actual usage once it is running.
Useful related references:
- AWS vs Azure vs Google Cloud: Pricing, Services, and the Right Defaults
- AWS vs Google Cloud for Startups: The Bill and the Boring Stuff
- AWS vs Google Cloud for Startups: A Friction-First Comparison
- Domains and DNS on RunxBuild
FAQ
Is Google DNS 8.8.8.8 down?
Almost never. 8.8.8.8 is one of the most reliable and redundant services on the internet, so if it looks down the cause is usually between you and it - your local resolver, router, or ISP. Test with dig @8.8.8.8 example.com; if it answers, Google DNS is fine and the problem is elsewhere.
How do I check if Google DNS is working?
Run dig @8.8.8.8 example.com (or nslookup example.com 8.8.8.8 on Windows). If you get an IP back, 8.8.8.8 is resolving for you. If it times out, run ping 8.8.8.8 to separate a network-reachability problem from a DNS-service problem.
Why can I ping 8.8.8.8 but DNS does not work?
Ping tests raw network reachability and uses no DNS, while dig tests the DNS service on port 53. If ping succeeds but dig fails, either the DNS service is genuinely failing (rare for Google) or something is blocking port 53 specifically - a firewall, DNS filtering, or a captive portal.
What is a good alternative to 8.8.8.8?
Cloudflare’s 1.1.1.1 is the most common alternative - an independent public resolver on a separate network. Testing dig @1.1.1.1 example.com also helps diagnose: if 1.1.1.1 answers and 8.8.8.8 does not, the problem is specific to reaching Google’s resolver from your network.
How do I fix DNS not resolving?
First find the cause: query 8.8.8.8 and 1.1.1.1 directly and ping 8.8.8.8. If a public resolver is unreachable, switch to a working one in your OS or router settings. If ping also fails, it is your connection or router - restart it. Flush your local DNS cache after any resolver change.