DNS Record Types Explained
What is DNS?
In the most simplest words, I can define DNS (Domain Name Server) as internet’s phone call log directory. For example humans like you and me may remember a website like “Bhupendra.com” but that’s not how computer machines remember those addresses. Instead, these machines talk using only IP addresses like 192.189.1.1 or more. Therefore, DNS translates the easy-to-remember domain name into the correct IP address so your browser can connect to the right server.
Steps in which a DNS works :
Basic steps:
You type a domain in your browser.
Your device asks a DNS resolver (often your ISP or a public service like 1.1.1.1/8.8.8.8) for the IP.
The resolver checks cached answers or queries authoritative DNS servers for that domain.
The resolver returns the IP to your device, and your browser connects to the server.
Key pieces:
Resolver: the helper that does the lookup work for you.
Authoritative DNS server: the source of truth for a domain’s records.
Records: the data stored in DNS, e.g., A/AAAA (map names to IPs), CNAME (alias), MX (mail), TXT (misc info).
Why it matters: DNS makes the web usable for humans, enables redundancy/load balancing (multiple IPs), and caches answers to speed things up.
What is NS Record?
An NS (Name Server) record tells the world which DNS servers are authoritative for a domain. In other words, it points to the servers that hold the “source of truth” DNS zone for that domain. When someone looks up “bhupendra.com”, resolvers first check the domain’s NS records (published at the parent zone, e.g., the TLD) to see which name servers to ask. Those authoritative servers then provide the actual DNS answers (A/AAAA, MX, etc.). So NS records define who is responsible for serving and maintaining the domain’s DNS data.
What is an A record?
An A record is the DNS entry that says, “This domain name should lead to this IPv4 address.” Think of it as the street address for a website on the IPv4 network.
How it works in practice
When you type bhupendra.com into a browser, your device asks DNS, “What’s the IP for this name?”
The authoritative DNS for the domain replies with the A record—e.g., bhupendra.com → 93.184.216.34 (replace that IP with your real server’s IPv4).
Your browser then connects to that IP and loads the site.
Key points and common patterns
It’s for IPv4 only: A = IPv4, AAAA = IPv6.
You can have multiple A records for one name (e.g., two server IPs). Resolvers typically round-robin through them, which can provide basic load spreading or redundancy.
Subdomains use A records too: api.bhupendra.com → 203.0.113.10, static.bhupendra.com → 203.0.113.11.
At the apex (root) of a zone (bhupendra.com), you usually use A/AAAA records rather than CNAMEs, because CNAMEs aren’t allowed at the root alongside other required records (like NS/SOA). Some DNS providers offer an “ALIAS”/“ANAME”/flattened record to mimic a CNAME at the apex, but under the hood they return A/AAAA answers.
TTL (time to live): Each A record has a TTL value that tells resolvers how long they can cache the IP before asking again. Lower TTLs make changes propagate faster but increase query load; higher TTLs reduce load but make changes slower to take effect.
If you change servers or IPs, you update the A record to point to the new IPv4 address. After caches expire (per the TTL), traffic flows to the new IP.
If you pair A records with health checks (some DNS providers support this), unhealthy IPs can be removed from responses, improving uptime.
A records are what ultimately let a human-friendly name become a routable IPv4 endpoint. Without them (or AAAA for IPv6), a domain name wouldn’t resolve to a server on the internet.
What is a AAAA record?
An AAAA record maps a domain name to an IPv6 address. Example: bhupendra.com → 2001:db8:1234:5678::1 (replace with your real IPv6).
It is specifically for IPv6; the A record handles IPv4.
When someone on an IPv6-capable network looks up bhupendra.com, DNS returns the AAAA answer and the browser connects to that IPv6 address.
You can publish multiple AAAA records for one name to provide basic load spreading or redundancy.
Subdomains use AAAA records too: api.bhupendra.com → 2001:db8:abcd:1::10, static.bhupendra.com → 2001:db8:abcd:1::11.
At the zone apex (bhupendra.com), you can have both A and AAAA records for dual-stack operation (IPv4 + IPv6).
Some DNS providers offer ALIAS/ANAME/flattened records to mimic a CNAME at the apex, but the answers they return are ultimately A/AAAA.
TTL controls how long resolvers cache the AAAA answer; lower TTLs speed up change propagation but increase query load, higher TTLs do the opposite.
If the server’s IPv6 changes, update the AAAA record; after caches expire per TTL, traffic flows to the new IPv6.
AAAA records, together with A records, make bhupendra.com reachable over both IPv6 and IPv4.
What is a CNAME record?
A CNAME record is a DNS entry that makes one name an alias of another name, rather than pointing directly to an IP address :
If you set www.bhupendra.com as a CNAME to app.hosting.net, a lookup for www.bhupendra.com returns app.hosting.net. The resolver then asks for app.hosting.net’s A or AAAA records to get the actual IP addresses.
CNAMEs link name-to-name; they do not directly return IPs. The final target must resolve to A or AAAA records.
They are commonly used on subdomains: api.bhupendra.com pointing to backend.example.net, cdn.bhupendra.com pointing to cdn.provider.com.
You cannot place a CNAME at the zone apex (the root) together with required records like NS and SOA, so you generally avoid bhupendra.com as a CNAME. Some DNS providers offer ALIAS, ANAME, or flattened records to mimic apex CNAME behaviour while ultimately returning A or AAAA answers.
CNAMEs simplify pointing multiple names to a single canonical host and make future target changes easier, since you update the destination in one place.
What are MX records?
An MX (Mail Exchanger) record tells the world which mail servers accept email for a domain and in what order to try them :
Purpose: It directs incoming email to the correct mail server(s) for bhupendra.com. Without an MX record, most servers won’t know where to deliver mail for the domain.
Format: Each MX record lists a mail host (a hostname) and a priority number (called “preference”). Lower numbers mean higher priority.
How delivery works:
A sending mail server looks up the MX records for bhupendra.com.
It sorts them by priority (lowest number first).
It tries the highest-priority MX host first; if that fails, it tries the next one, and so on.
Example setup:
Priority 10 → mx1.mailhost.net
Priority 20 → mx2.mailhost.net Here, email to user@bhupendra.com will be delivered to mx1.mailhost.net first; if unavailable, mx2.mailhost.net is tried.
MX targets must be hostnames, not IPs. Those hostnames then resolve via A/AAAA records to actual IP addresses.
Redundancy and load:
Multiple MX records with different priorities give failover.
Equal-priority MX records allow basic load spreading (servers pick one at random or round-robin).
Alignment with SPF/DMARC/DKIM:
SPF is often set on the domain to declare which hosts can send mail for bhupendra.com.
DKIM and DMARC help with authentication and policy. They’re separate DNS records but commonly configured alongside MX.
Common pitfalls:
Pointing an MX directly to an IP (invalid; must be a hostname).
Forgetting to create A/AAAA records for the MX hostnames.
Using a CNAME as the MX target (not allowed; MX must point to a canonical hostname).
What is a TXT record?
A TXT record lets you attach arbitrary text to a domain for things like verification, security, and configuration :
Purpose: Carries extra information in plain text. Common uses include domain ownership verification, email security, and service-specific settings.
Email security: SPF lives in a TXT record, declaring which servers may send mail for bhupendra.com. DMARC and DKIM also use TXT to publish policy and keys.
Verification: Many services (cloud providers, SaaS apps, certificate authorities) ask you to add a TXT record to prove you control bhupendra.com.
Flexibility: A domain can have multiple TXT records. Keep each value clearly separated; avoid cramming unrelated data into one record.
Format: It’s just text—no special structure required unless the service specifies one. You publish the exact string they give you.
TTL: Set the time-to-live based on how often you expect to change it; short TTLs help during setup and validation, longer TTLs reduce lookup load.
How different DNS records work together for one single website?
DNS records work together for a single site :
NS (Name Server) records — who’s authoritative
Point to the DNS servers that are the “source of truth” for bhupendra.com. Every lookup starts by finding these NS records at the parent zone (e.g., the TLD).SOA (Start of Authority) record — zone metadata
Lives at the apex (bhupendra.com) and defines the primary name server, contact email, serial number (for zone updates), and timers used by secondaries. It sets the coordination rules for the zone.A and AAAA records — name → IP
A maps bhupendra.com (or subdomains) to IPv4.
AAAA maps bhupendra.com (or subdomains) to IPv6.
These are what let browsers actually reach the server. Dual-stack sites publish both A and AAAA.
CNAME records — aliases to another name
For subdomains only (not the apex). Example: www.bhupendra.com can be a CNAME to app.hosting.net. The resolver follows the CNAME to that target name, then gets its A/AAAA to connect. CNAME simplifies pointing multiple labels to a single canonical host.MX records — where email is delivered
List mail hosts and priorities (lower number = higher priority). Example: priority 10 → mx1.mailhost.net, priority 20 → mx2.mailhost.net. Senders deliver mail for user@bhupendra.com to the highest-priority available MX.TXT records — extra info and verification
Carry text for SPF, DKIM, DMARC, and domain verification tokens. Example: SPF declares which servers can send mail for bhupendra.com; DKIM publishes public keys; DMARC sets policy; services add verification strings.How a web visit flows (bhupendra.com)
Client asks its resolver: “What’s bhupendra.com?”
Resolver finds the NS for bhupendra.com (from the parent), then queries those authoritative servers.
Authoritative servers return A/AAAA (and possibly CNAME chains) for bhupendra.com.
Client connects to the returned IP (IPv4 via A, IPv6 via AAAA). If www is a CNAME, the resolver follows that chain to get final A/AAAA.
How email delivery flows (user@bhupendra.com)
Sender looks up MX for bhupendra.com.
Sorts by priority; tries the lowest number first.
Each MX hostname must have A/AAAA.
SPF/DKIM/DMARC TXT records are checked by receivers to validate and apply policy.
TTL and caching — change speed vs. load
Every record has a TTL. Lower TTL = faster propagation of changes but more DNS queries; higher TTL = fewer queries but slower updates. Plan TTLs around expected change frequency.Redundancy and load spreading
Multiple A/AAAA entries: simple round-robin and resilience.
Multiple MX with different priorities: failover; equal priorities: basic load distribution.
Multiple NS: authoritative server redundancy.
Apex constraints
The root of the zone (bhupendra.com) cannot be a CNAME because it must coexist with NS/SOA. Use A/AAAA at the apex, or provider-specific ALIAS/ANAME/flattening that synthesise A/AAAA answers while mimicking CNAME behaviour.Putting it together
NS/SOA define authority and zone metadata. A/AAAA (and CNAMEs for subdomains) get users to the right IPs. MX directs email to the right mail hosts. TXT carries authentication/verification (SPF/DKIM/DMARC, service tokens). TTL and redundancy settings balance speed of change, load, and resilience.
