Every device on the internet talks to other devices using numeric IP addresses such as 142.250.190.78 for one of Google’s frontends or 104.21.31.12 for a typical Cloudflare site. Humans, however, remember names like google.com or speedtester.pk. DNS is the translation layer that bridges those two worlds. When you type a domain into your browser, your operating system asks a resolver, “What is the address for this name?”, and the resolver chases the answer back through a global hierarchy until it finds an authoritative server that owns the record.

In Urdu we sometimes call it ‘انٹرنیٹ کی ٹیلی فون ڈائریکٹری’ — the internet’s telephone directory — and the analogy is almost perfect. You can dial a friend by name only because your phone has a contact list mapping that name to a real number. DNS is that contact list, only it is shared, distributed, and constantly updated by millions of administrators around the world. Without DNS the modern web simply would not work at human scale.

What makes DNS especially powerful — and occasionally frustrating — is that the answers are cached at every level. Your browser caches them. Your operating system caches them. Your home router caches them. Your ISP’s resolver in Lahore or Karachi caches them. Even Google’s 8.8.8.8 caches them. Each cache layer remembers the answer for a duration set by the domain owner, and that duration is the single most important number in DNS planning.

Before DNS existed, every computer on the early ARPANET shared a single file called HOSTS.TXT, manually maintained at SRI International. Every time a new machine joined, an administrator emailed an update and everyone downloaded a new copy. By the early 1980s the network had outgrown that approach — there were too many machines, too many changes, and too many time zones for a single file to stay accurate.

Paul Mockapetris designed DNS in 1983 (RFCs 882 and 883, later consolidated into RFCs 1034 and 1035) to replace HOSTS.TXT with a hierarchical, delegated, cached system. The genius of his design is that no single party has to know everything; instead, control is delegated downwards. The root knows where to find the .pk servers; the .pk servers know where to find the speedtester.pk servers; and the speedtester.pk servers know the actual address.

Forty-three years later, that same architecture handles trillions of queries per day. It survives DDoS attacks, undersea cable cuts, regional ISPs going dark, and entire data centres failing — because every layer is replicated and every answer can be cached. DNS is the most successful distributed database in history, and the propagation checker on this page lets you watch it in action across ten major resolvers worldwide.

When you load a page, eight or nine things happen before a single byte of HTML is fetched, and most of them are DNS-related. First, your browser checks its own in-memory cache. If the answer is there and not expired, the lookup ends in microseconds. If not, it asks the operating system, which checks its cache. If still no answer, the OS asks your configured resolver — typically your ISP’s box, or a public resolver like 1.1.1.1 if you changed your network settings.

The resolver itself usually has a cache, populated from previous queries by other users on the same network. If it has a fresh answer, it returns it immediately. If not, it begins a recursive chase: it asks the root servers (there are 13 logical roots, mirrored across hundreds of physical machines worldwide). The root tells it which TLD server to ask — for speedtester.pk that means a .pk server. The .pk server tells it which authoritative nameserver to ask for speedtester.pk specifically. That authoritative server finally returns the actual record.

The whole chase usually completes in 20–80 ms even from Pakistan, because every step is heavily replicated. Once your resolver has the answer, it caches it and serves it to the next user who asks, until the TTL expires.

An A record maps a hostname to a single IPv4 address. Example: speedtester.pk → 192.0.2.10. It is the most common record on the internet and the one you almost certainly need to set up first when you point a domain at new hosting. You can have multiple A records on the same name; the resolver will return all of them and the browser will try them in turn for redundancy.

An AAAA record (pronounced ‘quad-A’) is the same idea but for IPv6 addresses, which look like 2606:4700::6810:84e5. IPv6 adoption in Pakistan is still climbing — most major ISPs are dual-stack now, and serving AAAA alongside A is essential for mobile carriers like Jazz and Zong, where IPv6 traffic regularly exceeds 30%.

A CNAME (Canonical Name) record is an alias from one hostname to another hostname instead of to an IP. www.example.com CNAME → example.com is the textbook case. CNAMEs are extremely useful for CDNs and for keeping a single source of truth, but they cannot be used at the apex of a domain (the bare example.com). For that you need an A record, an AAAA record, or a provider-specific ALIAS / ANAME flattening trick.

MX (Mail Exchanger) records tell the world which servers accept email for your domain. Each MX has a preference number — lower is higher priority — so you can list a primary mail server and one or more failovers. If you do not set MX records, mail to user@yourdomain.pk simply bounces.

TXT records store free-form text. Originally meant for human notes, they have become the swiss army knife of modern DNS. SPF, DKIM and DMARC — the three pillars of email authentication — all live in TXT records. Domain ownership verification for Google Search Console, Microsoft 365, AWS, Mailchimp, and a hundred other services also lives there. SSL/TLS certificate validation via DNS-01 challenges does too.

SRV records are less famous but quietly power Microsoft Teams, SIP telephony, XMPP chat, and Active Directory discovery. They tell clients not only which host runs a service but also which port and what relative priority. CAA records control which Certificate Authorities are allowed to issue SSL certificates for your domain — a small but powerful security guard.

Every DNS record carries a TTL value — a number of seconds that tells caches how long they may keep the answer before re-asking. A TTL of 3600 means ‘this answer is good for one hour’. A TTL of 86400 means ‘this answer is good for a full day’. The longer the TTL, the cheaper and faster the lookups; the shorter the TTL, the faster you can change things.

When you plan a migration — moving hosting, switching email providers, changing your CDN — you want a short TTL well in advance, ideally 300 seconds (5 minutes). Twenty-four to forty-eight hours before the cutover, drop the TTL to 300. After the change, watch the propagation checker on this page. Once every resolver shows the new value, you can raise the TTL back to 3600 or 86400 to keep lookups cheap.

Forgetting to lower the TTL before a migration is the single most common cause of multi-day outages we see in Pakistan. A long TTL is not bad — it is great for stable records — but you must give yourself a runway.

Two completely different kinds of DNS server live in the wild. A recursive resolver is the one your device talks to: it does the legwork of chasing answers up and down the hierarchy, caches them, and returns them to you. Examples include 8.8.8.8 (Google), 1.1.1.1 (Cloudflare), 9.9.9.9 (Quad9), and your ISP’s in-house resolver — typically something like 203.135.0.1 for PTCL or 39.32.0.1 for Jazz mobile.

An authoritative server, on the other hand, is the source of truth for a specific zone. The authoritative servers for speedtester.pk only know about speedtester.pk; they do not chase queries for anyone else. When you buy a domain and configure DNS at your registrar, you are publishing records on a set of authoritative servers somewhere — usually two or four of them, geographically distributed.

The propagation checker on this page deliberately queries ten different recursive resolvers spread across continents. Why? Because if your authoritative servers have been updated but a particular ISP cache in Karachi has not refreshed yet, your visitors on that ISP will still see the old answer. The only way to verify true global propagation is to ask many resolvers in many regions, and that is exactly what the tool above does for you.

For years, most Pakistani users were stuck with whatever recursive resolver their ISP shipped. PTCL, Nayatel, StormFiber, Wateen, Optix, Jazz, Zong and Telenor all run their own. They work, but they vary wildly in cache freshness, latency, and how aggressively they enforce TTL. We have measured PTCL caches still serving pre-migration A records 18 hours after every other resolver in the world had updated.

Public resolvers fix that. Cloudflare’s 1.1.1.1 typically responds in 8–12 ms from major Pakistani cities. Google’s 8.8.8.8 usually adds 4–6 ms because of routing. Quad9 (9.9.9.9) sits in between and additionally blocks known malicious domains. OpenDNS (208.67.222.222) is great for parental controls. Switching to any of these in your router or device settings often produces a measurable improvement in time-to-first-byte for browsing and gaming.

Our DNS propagation checker queries all of the above plus regional resolvers in Singapore, Frankfurt, and the US, so you can see at a glance whether your records have actually reached the wider world or only your own ISP’s cache.

When you change a DNS record, the change is instant on your authoritative server. There is no global broadcast, no slow update wave rolling around the world. What is slow is every cache out there forgetting the old answer and re-asking for the new one. That cache expiration is what people loosely call ‘propagation’.

If a Karachi ISP cached your old A record one hour before you changed it, and the TTL was 24 hours, that ISP’s users will see the old address for another 23 hours regardless of how many times you re-save the record. Nothing on your authoritative server can shorten that — only the TTL on the record at the moment it was cached matters.

The propagation checker visualises this beautifully. You will often see most resolvers showing the new IP within seconds, while one or two stragglers are clearly still on the old answer. Those stragglers are not broken — they are simply honouring the TTL they were handed before your change. Patience, or a properly pre-lowered TTL, is the only fix.

A clean migration follows a predictable rhythm. Forty-eight hours before the move, drop every TTL you intend to change to 300 seconds. Twenty-four hours before, double-check using the checker on this page that all ten resolvers see the lowered TTL. On the day of the move, change the records on the authoritative server.

Within five to ten minutes most resolvers will show the new value. Confirm with the checker. Once every resolver agrees, raise the TTL back to 3600 or 86400. Keep both old and new servers responding for at least 24 hours — there will always be a long-tail cache somewhere holding on to the old address.

If your migration involves email (changing MX records), do the same dance for those, and additionally configure both old and new mail servers to accept inbound mail during the cut-over. Lost email during a migration is far more painful and far harder to recover from than a few seconds of webpage downtime.

Each resolver row in the checker shows one of four states. Green ‘Found’ means the resolver returned a value for your record, and the value is shown next to it. Red ‘NXDOMAIN’ means the resolver believes the domain or record type does not exist — most commonly seen on freshly-registered domains or on record types you never created. Orange ‘Error’ usually means the resolver answered with a SERVFAIL — a generic ‘something is wrong upstream’ signal. Grey ‘Timeout’ means the resolver did not respond within our limit.

When some resolvers are green and others are not, you are looking at propagation in progress. When all resolvers are green but show different values, you are looking at a split — typically a load-balanced setup where multiple A records exist and different resolvers cached different ones. When all resolvers are red, the record genuinely does not exist or your authoritative servers are unreachable.

The response-time number on the right is the resolver’s round-trip time from our query node, not from your home connection. It is useful for spotting overloaded or distant resolvers but it is not the same as the latency you will personally experience.

Email is the application most affected by DNS, because every receiving mail server checks several DNS-based authentication records before deciding whether your message is legitimate. SPF (Sender Policy Framework) is a TXT record listing which servers are allowed to send mail for your domain. If a message arrives from a server not on the list, SPF fails.

DKIM (DomainKeys Identified Mail) is a public-key signature system. Your sending server signs outgoing messages with a private key; receivers fetch the public key from a TXT record under your domain and verify the signature. DKIM proves the message was not tampered with in transit and was actually sent by your infrastructure.

DMARC ties SPF and DKIM together with a policy: ‘if both fail, here is what I want you to do — quarantine, reject, or just report.’ A correctly configured DMARC record published in DNS is the single biggest deliverability improvement most Pakistani businesses can make. It also stops attackers from spoofing your domain in phishing campaigns.

A Content Delivery Network puts copies of your site on edge servers around the world. From Pakistan, an uncached connection to a US origin can easily take 250 ms per round trip; a Cloudflare or Fastly edge in Karachi or Singapore typically responds in 15–40 ms. The trick that makes that work is DNS.

When you put a CDN in front of your site, you point your domain’s A or CNAME records at the CDN. The CDN runs an anycast network — the same IP address is announced from hundreds of locations, and BGP routing automatically delivers each query to the nearest edge. The DNS answer is the same everywhere; the network underneath does the geographic routing.

If you ever wonder why Cloudflare-fronted sites feel snappier in Lahore than the same site direct from a US data centre, that is exactly why. The DNS record looks identical; the underlying anycast and edge caching do the heavy lifting.

Plain DNS is a 1983 protocol with no built-in authentication or encryption. That is fine for most browsing, but it has two real risks: an attacker on the same network can see every domain you look up, and a sufficiently determined attacker can poison a resolver’s cache with fake answers.

DNSSEC fixes the second problem by cryptographically signing zone data. A DNSSEC-aware resolver verifies the signatures all the way back to the root, so a poisoned cache entry will fail validation. Adoption in Pakistan is still uneven — a minority of .pk domains are signed — but it is growing, and the propagation checker does not yet display DNSSEC status (a feature on our roadmap).

DNS over HTTPS (DoH) and DNS over TLS (DoT) fix the first problem by encrypting the channel between your device and the resolver. Cloudflare’s 1.1.1.1, Google’s 8.8.8.8, and Quad9 all support both. Modern Android, iOS, Windows 11, and Firefox can be configured to use them in a few clicks, and we strongly recommend it for any device that uses public Wi-Fi in Pakistan.

Pakistan’s DNS landscape has a few distinct flavours. PKNIC, the .pk registry, runs the authoritative servers for the country-code TLD. Lookups for .pk names route through their infrastructure, which is generally reliable but has had localised slowdowns during heavy DDoS events in past years. Caching at major Pakistani ISPs is unusually aggressive — we routinely see PTCL and StormFiber resolvers hold records for the full TTL even when the upstream changes.

Mobile carriers behave differently again. Jazz and Zong carrier-grade resolvers tend to respect TTL more strictly but introduce DNS hijacking on certain blocked domains, returning a sinkhole address rather than the real one. If you suspect this is happening to your domain, the propagation checker will show the discrepancy clearly.

Finally, residential users on PTCL DSL and FTTH frequently use the router’s built-in resolver, which is itself just a thin proxy in front of PTCL’s upstream caches. Bypassing it by configuring 1.1.1.1 or 8.8.8.8 directly in your device — not the router — almost always produces faster and more honest lookups.

Every uncached page load starts with at least one DNS lookup, often three or four (the main domain, a CDN, an analytics service, an ad network). On a desktop in Islamabad each of those can add 20–80 ms to the perceived time-to-first-byte. On a budget Android phone on Jazz 4G, the same lookups can add 200 ms or more, especially when the carrier’s resolver is overloaded during peak hours.

There are three lines of defence. First, use a fast public resolver like 1.1.1.1 instead of your carrier’s. Second, use HTTP/2 or HTTP/3, which can multiplex many requests over a single connection so subsequent lookups overlap with content download. Third, on your own site, set sensible TTLs — long enough to be cached, short enough to be flexible — and avoid pointless extra hostnames that each require their own DNS round trip.

If you are profiling a page in Chrome DevTools and you see a long ‘DNS Lookup’ block in the Waterfall view, that is exactly the latency we are talking about. Often it is invisible because the answer is already cached, but for first-time visitors it is the very first thing they wait for.

After thousands of support tickets we keep seeing the same eight failure modes. The fixes are simple once you know what to look for, and the propagation checker makes most of them obvious in seconds.

First, the missing apex A record after a CNAME-everywhere setup. Second, a TTL that was never lowered before a migration. Third, an SPF record that has accumulated too many lookups and silently exceeds the 10-lookup limit. Fourth, a DKIM key that was rotated on the sender but never published in DNS. Fifth, a stray trailing dot in a CNAME value that turns it into a different name. Sixth, IPv6 records pointing at a server that does not actually listen on IPv6. Seventh, MX records pointing to an IP address (illegal — they must point to hostnames). Eighth, glue records left behind from a previous registrar that still announce stale nameservers.

If you suspect any of these, run the checker against the affected record type, then walk through the list above. The combination of a global resolver view and a structured checklist will solve about 90% of real-world DNS incidents in under five minutes.

When you outgrow a web checker you reach for command-line tools. dig is the gold standard on Linux and macOS, with rich output and the ability to query specific resolvers (dig @1.1.1.1 example.com A). nslookup is the venerable Windows option, less rich but always available. host is dig’s simpler cousin for quick yes/no checks.

For programmatic use, our checker exposes a JSON API at /api/dns-check?domain=example.com&type=A. You can poll it from a deployment script to wait until the new value has propagated to all ten resolvers before declaring a release green. Combined with a CI system this turns ‘hope the DNS has propagated’ into a measurable, automatable gate.

Whichever tool you reach for, remember the golden rule: always specify which resolver you are asking. dig example.com A returns whatever your local resolver thinks; dig @8.8.8.8 example.com A returns the global answer. The difference between those two lines has solved more DNS mysteries than any other diagnostic technique.

Every domain you visit produces a DNS query, and unless you are using DoH or DoT that query travels in plain text over the network. Your ISP — and any actor on the same Wi-Fi — can build a near-complete browsing profile from those queries even when the underlying HTTPS traffic is fully encrypted. In Pakistan, where many cafés and offices share a single connection, this is a non-trivial concern.

There are three levels of defence. First, switch to an encrypted resolver: enable ‘Private DNS’ on Android and point it at one.one.one.one or dns.google, or enable DoH in Firefox and Chrome. Second, run your own caching resolver at home with Pi-hole or Unbound and point it upstream over DoT. Third, for the strongest privacy use a reputable VPN that itself uses encrypted DNS.

None of this is paranoia for ordinary users — it is the same posture banks, journalists, and government employees are increasingly required to adopt. The good news is that switching to encrypted DNS costs nothing, requires no special skills, and makes a real difference.

If you only remember a handful of things from this 6,000-word guide, make it these. Use a fast public resolver everywhere. Lower TTLs before any change and raise them after. Verify every change with the propagation checker on this page across all ten resolvers. Configure SPF, DKIM, and DMARC on every domain that ever sends email. Turn on DoH or DoT on every personal device. And document your DNS — a simple text file listing every record, its purpose, and its TTL is worth its weight in gold the next time something breaks at 2 a.m.

DNS is invisible when it works and catastrophic when it doesn’t. The good news is that almost every catastrophe is preventable with the small handful of habits above. Bookmark this page, run the checker before and after every change, and you will rarely be surprised.

If you want to go deeper, our other tools complement this one perfectly. The IP lookup confirms which address a hostname currently resolves to from your network. The ping test measures whether that address is actually reachable. The whois lookup verifies the registration details and authoritative nameservers. And the subdomain scanner enumerates the hostnames you might have forgotten about. Together they form the complete diagnostic stack we use ourselves.