Free DNS Checker & Lookup

There's a running joke among engineers that whatever just broke, it's always DNS. It stuck around because it's usually right. DNS sits underneath everything — every page load, every email, every API call begins by turning a name into a number — so when it stumbles, the whole stack falls over and the cause is the last place anyone thinks to look.

Here's what really happens the instant you hit a domain. Your machine has no idea where example.com lives, so it asks a recursive resolver — a recursive DNS server run by your ISP, or something like 1.1.1.1. If that resolver hasn't seen the domain lately, it walks the chain: it asks a root server who runs .com, asks the .com servers who's authoritative for example.com, then asks that authoritative server for the actual record. Four hops, done in milliseconds, every single time you didn't notice.

That constant back-and-forth of queries and answers is what DNS traffic actually is, and almost all of it rides on a single port: the DNS port number is 53. A normal lookup is one small UDP packet on port 53 because that's fast and cheap; DNS only falls back to TCP on port 53 when the answer won't fit in one packet or the exchange has to be reliable — which is why you'll sometimes see DNS ports described in the plural. Either way, port 53 has to be open for name resolution to work at all: block it and a machine can't reach anything by name, even sitting on a perfectly healthy connection.

An A record and a CNAME both point a name somewhere, which is exactly why people confuse them — but they point at different kinds of things, and picking the wrong one breaks real setups. An A record maps a hostname straight to an IP address: example.com to 203.0.113.10. A CNAME record maps a hostname to another hostname — www.example.com to example.com — and lets DNS resolve the rest from there. The A record is the street address; the CNAME is a 'forward my mail to this other name' note.

The rule I'd give anyone: use an A record when you're holding an IP, and a CNAME when you're pointing at a name somebody else controls — a CDN, a hosting platform, a status page. That indirection is the whole point; it's what lets those providers move their servers around without you ever touching your DNS again.

Then comes the trap everyone hits once. You cannot put a CNAME on the root of your domain — the 'apex', the bare example.com with no www in front. The DNS spec won't let a CNAME sit next to the other records an apex is required to have, so your provider simply rejects it. That's why hosts invented workarounds:

This is the distinction that trips up almost everyone the first time, and it's worth nailing down. So what are nameservers, exactly? They decide who is in charge of your domain's DNS. Put another way, a nameserver is the server that answers for your domain and hands your records to the world. Your records — the A, the MX, the TXT — are the individual entries that whoever's in charge hands out. Change your nameservers and you're swapping which company answers for the domain entirely; edit a record and you're just tweaking one line at the company that already answers.

Why should you care? Because it's the single most common reason a change appears to do nothing. Say you bought the domain at GoDaddy but run your DNS at Cloudflare. Edit an A record in the GoDaddy panel while your nameservers point to Cloudflare and — nothing happens. You changed a copy nobody reads. The records that count are the ones sitting at whatever nameservers your NS record actually lists. So run the lookup above and read the NS records first: they tell you where your DNS truly lives, before you waste an afternoon hunting for a record in the wrong dashboard.

Make a DNS change and it almost never shows up everywhere at once. People call this 'propagation', as if your edit had to propagate across the internet one server at a time — but that picture is wrong. Nothing is spreading anywhere. The delay is DNS caching: resolvers all over the world saved your old record and keep handing it out until their copy expires.

How long they cling to it is entirely your call, set by a number called the TTL — time to live — attached to every record. A TTL of 3600 tells resolvers 'you may hold this for an hour.' So the honest answer to 'how long will my change take' is: up to the old record's TTL, and no longer. The move the pros make is to drop the TTL a day before a planned change — say to 300 seconds — so the world is only ever caching the old value for five minutes when you flip the switch. Flushing your own machine's DNS cache clears your local copy, but it can't reach the resolver caches sitting between you and the domain, which is exactly why a change can look live on your laptop and stale for a teammate across town.

Because DNS is the front door to everything, it's a favourite target for attackers — and a favourite spot for quiet mistakes. DNS attacks range from the blunt to the subtle: a hijack repoints your domain so visitors land on an attacker's server while the address bar still shows your name, and a 'dangling' record left aimed at a cloud host you gave up months ago can be claimed by a stranger — that's a subdomain takeover. Plenty of DNS outages aren't an attack at all, just a fat-fingered edit to the wrong record late on a Friday. (It's always DNS.)

What all of these share is timing: the lookup above reads perfectly fine right up until the moment it doesn't, and by then the damage is already live. A one-time check tells you what's true this second — it can't warn you when an A record quietly flips or an MX vanishes next week. That's the gap continuous DNS monitoring closes. Point Uptura at your domains and it re-runs this exact lookup on a schedule, keeps a baseline of every A, AAAA, CNAME, MX, TXT and NS record, and the second one changes it emails or Slacks you the precise before-and-after — so a hijack or a bad edit is something you catch in minutes, not something a customer reports days later.