DNS (Domain Name System) is the silent workhorse that makes the internet usable. Every time you open a website, send an email, or connect an app to a server, DNS is running in the background, turning readable names like aeserver.com into the numeric IP addresses that machines actually use to talk to each other. If DNS stops working, the internet stops working for you, even if your connection is fine.
This guide covers everything you need to understand and manage DNS in practice: how the lookup process works, every record type you will encounter, how to fix the most common DNS problems on Windows, macOS, Linux, iOS, and Android, how to check records with real command-line tools, and what DNS security features actually protect you from. Examples use real values you can copy, including the MX records for Google Workspace and Microsoft 365 that most UAE businesses need when setting up email on a .ae domain.
DNS is the internet’s address book. Computers identify each other by IP addresses, which look like 172.217.22.14 for IPv4 or 2a00:1450:4001:830::200e for IPv6. Humans cannot memorize those. DNS lets you type google.com instead, and translates that name into the correct IP address behind the scenes.
Without DNS, three things that you probably use every day would stop working:
DNS also powers several features you rely on without noticing: load balancing (one hostname pointing to many servers for high traffic), failover (automatic switch to a backup server when the primary is down), content delivery networks (sending you to the nearest CDN edge for faster loading), and security filtering (blocking malicious domains at the DNS level before your browser ever connects).
When you type a domain into your browser, a chain of servers cooperates to find the answer. Here is what actually happens in the milliseconds before the page loads.
Your browser keeps a short-term cache of recent DNS lookups. If you visited aeserver.com a minute ago, the browser already knows the IP and skips the rest of this process. This is why a site loads faster the second time you open it.
If the browser does not have the record, it asks the operating system, which has its own DNS cache. Windows, macOS, and Linux all keep one. You can clear it when records change, as shown in the troubleshooting section.
If nothing is cached locally, the OS sends the query to a recursive resolver. This is usually your ISP’s DNS server, or a public one like Google (8.8.8.8), Cloudflare (1.1.1.1), or Quad9 (9.9.9.9). The resolver’s job is to chase down the answer on your behalf.
The resolver contacts one of the 13 logical root server clusters (named A through M). Despite the “13 servers” myth, each letter is backed by hundreds of physical servers worldwide via anycast routing, so there is always one geographically close. The root server does not know the IP of aeserver.com, but it knows who handles .com.
The root server points the resolver to the .com TLD (Top-Level Domain) server. For a .ae domain, the resolver would be pointed to the .ae TLD server, operated by the UAE registry. The TLD server knows which authoritative nameserver holds the records for the specific domain.
The authoritative nameserver is the final source of truth for the domain. It holds all the DNS records (A, MX, TXT, etc.) that the domain owner configured. It returns the IP address to the resolver.
The resolver sends the IP back to your operating system, which sends it to your browser, which finally opens the connection to the website. The resolver also caches the answer for the duration of the record’s TTL (Time To Live), so the next user who asks gets an instant reply without repeating the whole chain.
1.1.1.1) or Google (8.8.8.8) often makes a noticeable difference, especially on mobile networks.
A DNS record is a line in a domain’s zone file that tells the world something specific about the domain: where its website lives, where its email should go, which services are authorized to send on its behalf, and so on. Here are the record types you will actually use.
The A record maps a hostname to an IPv4 address. The AAAA record does the same for IPv6. These are the records that make a website reachable at a browsable URL.
; A record (IPv4) aeserver.com. 3600 IN A 192.0.2.10 ; AAAA record (IPv6) aeserver.com. 3600 IN AAAA 2001:db8::10
The number 3600 is the TTL in seconds (one hour), which tells resolvers how long to cache the answer. We cover TTL in detail in the propagation section.
A CNAME (Canonical Name) record is an alias. Instead of pointing to an IP directly, it points one hostname to another hostname. Useful when you want www.example.com and shop.example.com to always match wherever example.com lives, so you only update one record when the server changes.
www.aeserver.com. 3600 IN CNAME aeserver.com. shop.aeserver.com. 3600 IN CNAME aeserver.com.
example.com without www). CNAMEs only work on subdomains. Some DNS providers offer workarounds called “ALIAS” or “ANAME” records that behave like a CNAME at the apex.
MX records tell the world where to deliver email for a domain. Without them, email simply does not arrive. Every MX record has two components: a priority (lower number = higher priority) and a mail server hostname.
If a domain has multiple MX records, mail servers try the lowest-priority value first. If that server is unreachable, they fall back to the next one. This is how redundant email infrastructure works.
Real MX records for the most common email providers:
| Provider | Priority | Mail Server |
|---|---|---|
| Google Workspace | 1 | smtp.google.com |
| Microsoft 365 | 0 | yourdomain-com.mail.protection.outlook.com |
| AEserver Email | 10 | mail.yourdomain.com |
Replace yourdomain-com with your actual domain (with dots replaced by hyphens for Microsoft 365), and replace yourdomain.com with your real domain for AEserver Email. The exact values are always shown in your email provider’s setup panel.
Here is how a full MX record set looks in a zone file for a domain using Google Workspace:
aeserver.com. 3600 IN MX 1 smtp.google.com.
And here is how a domain with a primary and a backup mail server would be configured:
example.com. 3600 IN MX 10 mail.example.com. example.com. 3600 IN MX 20 backup-mail.example.com.
Setting up email for a .ae domain or any other domain works the same way. You add MX records in your DNS panel and point them to your email provider. See our guides on Google Workspace, Microsoft 365, or AEserver Business Email for provider-specific values.
TXT records hold arbitrary text. In practice, they are almost always used for email authentication and domain verification. The three big TXT record uses are SPF, DKIM, and DMARC, which together prevent other people from sending fake emails that look like they came from your domain.
SPF (Sender Policy Framework) lists which servers are allowed to send email for your domain:
example.com. 3600 IN TXT "v=spf1 include:_spf.google.com ~all"
This example says “Google Workspace is allowed to send email for example.com, and anyone else should be treated with suspicion” (~all = soft fail).
DKIM (DomainKeys Identified Mail) publishes a public key that receiving servers use to verify that an email was really signed by your mail server. The record lives at a selector subdomain:
default._domainkey.example.com. 3600 IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."
DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving servers what to do with email that fails SPF or DKIM checks, and where to send reports:
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; pct=100"
The p=quarantine part means “if authentication fails, put the message in the recipient’s spam folder.” Other options are p=none (monitor only) and p=reject (bounce the email).
NS (Nameserver) records tell the world which servers are authoritative for a domain. When you register a domain and point it to AEserver, you are setting NS records at the registry level:
aeserver.com. 86400 IN NS ns1.aeserver.com. aeserver.com. 86400 IN NS ns2.aeserver.com.
SOA (Start of Authority) is a single record per zone that holds administrative metadata: the primary nameserver, the admin email (with @ replaced by .), the serial number (incremented on every change), and timers for secondary servers:
aeserver.com. 3600 IN SOA ns1.aeserver.com. hostmaster.aeserver.com. (
2026042101 ; serial
3600 ; refresh
1800 ; retry
1209600 ; expire
86400 ) ; minimum TTL
These are less common but worth knowing:
The word “DNS server” is used loosely and actually refers to three very different things depending on context. Understanding the difference clears up a lot of confusion.
This is what your computer talks to. It receives your query, runs around the internet asking root, TLD, and authoritative servers, and returns the final answer. Public resolvers include Google (8.8.8.8 / 8.8.4.4), Cloudflare (1.1.1.1 / 1.0.0.1), and Quad9 (9.9.9.9). Your ISP also runs one, which your router uses by default.
This is the final source of truth for a domain. It holds the actual zone file with all the A, MX, TXT, and other records the domain owner configured. When you sign up with AEserver and host your domain’s DNS here, you are putting your records on our authoritative nameservers.
Root servers (13 logical clusters, hundreds of physical instances worldwide) sit at the top of the DNS hierarchy. They know where to find every TLD server. TLD servers know where to find the authoritative nameserver for every domain under their TLD. For .ae domains, the .ae TLD servers are run by the UAE registry, which sits under the TDRA (Telecommunications and Digital Government Regulatory Authority).
A primary nameserver holds the master copy of the zone file. Secondary nameservers pull copies from the primary and serve the same answers. If the primary goes down, the secondary keeps answering queries. Every domain should have at least two nameservers (NS records), and most registries require it. AEserver provides multiple redundant nameservers by default.
DNS issues are among the most frequent internet problems, and most of them are fixable in under five minutes. Here are the ones you will actually run into.
This Windows error means your computer cannot reach its configured DNS resolver. Causes and fixes, in order of likelihood:
Unplug the router from power, wait 30 seconds, plug it back in. Waits for a full cold boot (60 to 90 seconds) before testing. This fixes the majority of “DNS server not responding” errors, because the router’s own DNS cache gets corrupted surprisingly often.
Your ISP’s DNS may be down or slow. Switch to Google or Cloudflare. On Windows, open Settings, Network & Internet, your connection, and find DNS server assignment. Set primary and secondary manually:
Google DNS Primary: 8.8.8.8 Secondary: 8.8.4.4 Cloudflare DNS Primary: 1.1.1.1 Secondary: 1.0.0.1
On macOS, go to System Settings, Network, click your connection, Details, DNS tab, and add the servers. On a router, you can set these for the whole household at once in the router admin panel.
VPN clients often push their own DNS servers. If the VPN’s DNS is broken, you get “DNS server not responding” even though your connection is fine. Disconnect the VPN and retry.
Some antivirus suites (Avast, Kaspersky, Norton) intercept DNS queries and can block them after an update. Temporarily disable the antivirus’s web shield or firewall module and retest. If it works, add an exception rather than leaving the shield off.
Open Run (Win+R), type services.msc, find “DNS Client”, right-click and choose Restart. This clears any stuck state in the Windows DNS resolver.
When you change a DNS record (for example, moving a website to a new host), your computer keeps serving the old cached answer until the TTL expires. Flushing the cache forces an immediate fresh lookup.
Windows (all versions from 7 to 11):
ipconfig /flushdns
Run in Command Prompt as Administrator. Success message:
Successfully flushed the DNS Resolver Cache.
macOS (modern versions: Ventura, Sonoma, Sequoia, and newer):
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder
Run in Terminal. Enter your admin password when prompted. There is no success message, silence means it worked.
Linux (systemd-resolved, the default on Ubuntu 18.04+):
sudo resolvectl flush-caches
Linux (older systems using nscd):
sudo systemctl restart nscd
iOS (iPhone and iPad): there is no command-line flush. The fastest way is to toggle Airplane Mode on for 10 seconds and then off again. This flushes the DNS cache. A full device restart also works.
Android: same approach, toggle Airplane Mode or restart. On newer Android versions, you can also go to Settings, Apps, Chrome (or your browser), Storage, Clear Cache.
Chrome browser cache (independent of OS): Chrome keeps its own internal DNS cache. Open this URL in Chrome:
chrome://net-internals/#dns
Click “Clear host cache”. Then open chrome://net-internals/#sockets and click “Flush socket pools” to close any open connections using the old IP.
If you want better speed and privacy than your ISP’s default DNS, switch to a public resolver. The change applies system-wide, so every app benefits.
Recommended public DNS resolvers:
| Provider | Primary | Secondary |
|---|---|---|
| Cloudflare (fastest globally) | 1.1.1.1 | 1.0.0.1 |
| 8.8.8.8 | 8.8.4.4 | |
| Quad9 (blocks malicious domains) | 9.9.9.9 | 149.112.112.112 |
| OpenDNS (Cisco) | 208.67.222.222 | 208.67.220.220 |
From the UAE, Cloudflare usually wins on latency thanks to its Dubai presence, but test both: on some ISPs Google is slightly faster.
When you want to verify that a DNS record is correct or diagnose why email is not arriving, command-line tools beat web-based checkers every time. They show you exactly what the resolver sees.
dig is the standard DNS query tool. Basic usage:
dig aeserver.com
Returns the A records. To query a specific record type:
dig aeserver.com MX dig aeserver.com TXT dig aeserver.com NS dig _dmarc.aeserver.com TXT
To trace the full resolution chain from root servers down (excellent for debugging):
dig +trace aeserver.com
To query a specific resolver instead of your default one:
dig @1.1.1.1 aeserver.com dig @8.8.8.8 aeserver.com MX
Querying multiple resolvers is useful when you are checking DNS propagation: if Cloudflare sees the new record but your ISP’s resolver still shows the old one, that tells you the issue is local caching rather than a broken record.
On Windows, dig is not installed by default, so nslookup is your go-to. Usage:
nslookup aeserver.com nslookup -type=MX aeserver.com nslookup -type=TXT aeserver.com
To query a specific server:
nslookup aeserver.com 1.1.1.1
host is the simplest of the three, with shorter output:
host aeserver.com host -t MX aeserver.com host -t NS aeserver.com
When you need to see how your DNS records look from multiple countries at once (handy for checking propagation after a change), online tools are useful. Popular ones include DNSChecker.org, MXToolbox, and intoDNS. For WHOIS information on a domain (registration date, registrant, nameservers), use our own WHOIS Lookup tool.
“DNS propagation” is the time it takes for a DNS change to become visible to everyone on the internet. This is the single most misunderstood thing in DNS, and it causes more support tickets than almost any other issue.
Every DNS record has a TTL (Time To Live) value in seconds. When a resolver caches the answer, it keeps it for exactly that long before asking the authoritative server again. Common TTL values:
| TTL Value | In Plain English | When to Use |
|---|---|---|
| 300 | 5 minutes | Before a planned migration, for fast rollback |
| 3600 | 1 hour | Default for most records, good balance |
| 86400 | 24 hours | Stable records (NS, MX) that rarely change |
| 604800 | 1 week | SOA expire timer, not for individual records |
If the old TTL was 3600 (1 hour), a DNS change will be visible to everyone within 1 hour at most, usually much sooner. If the old TTL was 86400 (24 hours), you may have to wait a full day for the slowest resolvers to clear their cache.
The practical rule: lower your TTL to 300 seconds 24 to 48 hours BEFORE you plan to make a change. That way, when you flip the switch, every resolver picks up the new value within 5 minutes. After the migration is stable, raise the TTL back to 3600 or higher to reduce the load on your nameservers.
DNS was designed in the 1980s without security in mind. Over decades, several extensions have been added to close the most serious holes. Here are the threats you should know about and the features that mitigate them.
An attacker injects a fake DNS answer into a resolver’s cache. Users asking for yourbank.com get the attacker’s IP and land on a phishing site that looks identical to the real one. Defense: DNSSEC, which cryptographically signs DNS records so resolvers can verify they are authentic.
An attacker gains access to your domain registrar account and changes your nameservers or records, redirecting your entire domain to their infrastructure. Defense: enable two-factor authentication on your registrar account, use registrar-level domain lock, and monitor for unauthorized changes. AEserver offers registrar lock by default on all domains.
Attackers flood your nameservers with junk queries, overwhelming them so legitimate users cannot resolve your domain. When your DNS goes down, your entire business goes dark: website, email, apps, everything. Defense: use an anycast DNS network with capacity far above normal traffic, so any single attack is absorbed across hundreds of points of presence.
DNSSEC adds cryptographic signatures to DNS records. When a resolver receives a signed answer, it can verify that the answer was not tampered with in transit. DNSSEC does not encrypt DNS traffic, it only authenticates it. Most modern TLDs support DNSSEC, including .ae. To enable it, you publish a DS (Delegation Signer) record at the registry level, and your authoritative nameserver signs your zone.
These are encryption protocols for DNS queries. Normal DNS traffic is in cleartext, so anyone on the path (your ISP, public Wi-Fi operators, governments) can see which sites you are looking up. DoH wraps DNS in HTTPS (port 443, indistinguishable from regular web traffic). DoT wraps it in TLS on a dedicated port (853). Modern browsers (Firefox, Chrome, Edge) support DoH natively. iOS and Android 9+ support DoT at the OS level.
A few things are worth knowing specifically if you are running a business in the UAE.
.ae domains are managed by the UAE registry under TDRA oversight. Registrations require a valid UAE contact, and the registry runs DNSSEC-capable TLD nameservers. See our .ae domain registration page for details and pricing.
Hosting DNS in the UAE vs abroad. For pure resolution speed, anycast networks with a Dubai or Fujairah point of presence (like Cloudflare and AWS Route 53) are as fast as any local provider. The real benefit of a UAE-based DNS provider like AEserver is local support, AED billing, regulatory compliance, and integrated bundles with UAE hosting and .ae domain management in one account.
Email deliverability for UAE senders. If you send marketing emails or transactional mail from a .ae domain to Gulf region recipients, configure SPF, DKIM, and DMARC from day one. Gulf ISPs are particularly aggressive with spam filtering. Our DMARC Force service can configure and monitor all three automatically.
SSL and DNS together. When issuing an SSL certificate with automated validation (Let’s Encrypt, or any CA using ACME), the certificate authority verifies that you control the domain by asking you to publish a specific DNS TXT record or HTTP file. If your DNS is slow or broken, SSL issuance fails. A stable DNS setup is a prerequisite for stable HTTPS.
Before DNS, every computer on the early internet (then called ARPANET) kept a single file called HOSTS.TXT, maintained by Stanford Research Institute. Whenever a new machine joined the network, every other machine had to download an updated copy. By the early 1980s, this obviously did not scale.
In 1983, Paul Mockapetris proposed a distributed hierarchical naming system. The original specifications were published as RFC 882 and RFC 883 the same year, later obsoleted by RFC 1034 and RFC 1035 in 1987. Those two RFCs are still the foundational standards for DNS.
The system has been extended many times since: DNSSEC was introduced in stages starting with RFC 2535 in 1999 and deployed at the root zone in July 2010. IDNs (Internationalized Domain Names, for Arabic and other non-ASCII scripts) were standardized in 2003. DNS over HTTPS was published as RFC 8484 in 2018. Despite 40+ years of additions, the core lookup mechanism Mockapetris designed is still what runs every query you make today.
On Windows, open Command Prompt and run ipconfig /all, look for “DNS Servers”. On macOS, open Terminal and run scutil --dns | grep nameserver. On Linux, check /etc/resolv.conf or run resolvectl status.
“DNS” refers to the whole system of name resolution. A “nameserver” is one specific server that participates in it. Your domain’s “nameservers” (set as NS records at the registry) are the authoritative servers that hold your zone file.
Yes. Registration (who owns the domain) and DNS hosting (who answers queries about it) are separate services. You can register a domain with one provider and point its NS records to nameservers at another provider. Many businesses register with a local registrar and host DNS on a specialized provider for redundancy.
Almost always, it is local DNS caching. Flush your DNS cache (see commands above), try from a different network (mobile data), or use a tool like DNSChecker to verify that the new record is live globally. If the record is live everywhere except your machine, the problem is your cache, not the DNS.
For a personal blog, probably not. For a business handling customer data, financial transactions, or email under a .ae domain, yes. DNSSEC prevents an entire class of attacks (cache poisoning) that can redirect your customers to phishing sites. Most modern DNS providers, including AEserver, enable it with one click.
From a terminal, run dig yourdomain.com MX or nslookup -type=MX yourdomain.com. Compare the output with the values your email provider gave you. For a more thorough check including reverse DNS and SPF/DKIM/DMARC, use MXToolbox.
For most UAE ISPs, Cloudflare (1.1.1.1) gives the lowest latency due to its Dubai point of presence. Google (8.8.8.8) is a close second. You can measure yourself with tools like DNSPerf or the open-source namebench utility.
ipconfig /flushdns (Windows) or sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder (macOS), and the issue usually goes away.1.1.1.1) or Google (8.8.8.8) for better speed and reliability than most ISP defaults.dig or nslookup to verify records yourself instead of guessing. Command-line tools are faster and more accurate than web interfaces.If you need help configuring DNS for your .ae domain, setting up business email with correct MX records, or securing your email with DMARC, the AEserver team is available 24/7 via live chat and WhatsApp.