Loading network utility...
Loading network utility...
The Domain Name System (DNS) functions as the decentralized distributed database of the internet. Every domain name maps to resource records (RRs) defined in RFC 1034 and RFC 1035 that govern host routing, corporate mail delivery, SSL issuance authentication, and cryptographically verified domain ownership.
Run live checks and calculations directly on LotsofNetwork.
Every entry in an authoritative DNS zone file is structured as a Resource Record (RR). Regardless of the specific record type, each entry adheres to a standardized format composed of five fundamental fields: Owner Name, Time to Live (TTL), Class, Type, and Type-Specific Resource Data (RDATA).
Owner Name specifies the fully qualified domain name (FQDN) or relative subdomain identifier. In BIND zone files, the '@' symbol represents the current origin or zone apex (e.g., example.com).
TTL specifies the duration in seconds that recursive caching resolvers (such as 1.1.1.1 or 8.8.8.8) are permitted to store the record before querying authoritative servers again.
Class designates the networking protocol suite. Across virtually all modern public internet configurations, the class is strictly 'IN' (Internet), established by RFC 1035.
Type designates the 16-bit integer identifier representing the record function (such as Type 1 for 'A', Type 28 for 'AAAA', or Type 15 for 'MX').
; Canonical RFC 1035 BIND Zone Syntax: ; [Owner] [TTL] [Class] [Type] [RDATA / Destination Value] @ 3600 IN A 198.51.100.25 api 300 IN A 198.51.100.26 @ 3600 IN AAAA 2001:db8:85a3::8a2e:370:7334 www 1800 IN CNAME @ @ 3600 IN MX 10 mail.example.com. @ 3600 IN TXT "v=spf1 include:_spf.google.com ~all" @ 86400 IN CAA 0 issue "letsencrypt.org"
Understanding when to deploy specific record types is critical for systems architecture, email deliverability, and avoiding circular resolution loops.
| Record Type | RFC Standard | Primary Role | Apex Allowed? | Typical TTL Scope |
|---|---|---|---|---|
| A | RFC 1035 | Maps hostname to 32-bit IPv4 address | Yes | 300 - 3600s |
| AAAA | RFC 3596 | Maps hostname to 128-bit IPv6 address | Yes | 300 - 3600s |
| CNAME | RFC 1034 | Canonical alias pointing to target hostname | No (RFC restriction) | 1800 - 86400s |
| MX | RFC 5321 | Routes inbound mail with numeric priority | Yes | 3600 - 86400s |
| TXT | RFC 1464 | Arbitrary text strings for SPF, DKIM, and site verification | Yes | 300 - 3600s |
| NS | RFC 1035 | Delegates zone authority to nameserver clusters | Yes (Mandatory) | 86400s (24h) |
| SOA | RFC 1035 | Administrative master, serial number, and zone sync timers | Yes (Root only) | 86400s |
| PTR | RFC 1035 | Reverse DNS mapping IP address to reverse hostname | N/A (ARPA zone) | 3600 - 86400s |
| CAA | RFC 6844 | Whitelists authorized SSL/TLS certificate issuers | Yes | 86400s |
| SRV | RFC 2782 | Service discovery specifying port, protocol, weight, priority | Yes (Subdomains) | 3600s |
The 'A' (Address) record is the foundational cornerstone of IPv4 internet navigation, translating human-friendly names into 32-bit dotted-decimal IP addresses. With global IPv4 exhaustion, the 'AAAA' (Quad-A) record serves the identical role for 128-bit IPv6 hexadecimal addresses.
CNAME (Canonical Name) records create an alias from one label to another. However, a major architectural rule in RFC 1034 Section 3.6.2 dictates: 'If a CNAME RR is present at a node, no other data should be present'. Because a zone apex (example.com) must always possess SOA and NS records, placing a standard CNAME at the apex violates RFC specifications and breaks inbound mail (MX) routing.
To overcome this limitation without violating RFCs, modern cloud DNS providers (such as Cloudflare, AWS Route 53, and NS1) implement proprietary synthetic record types known as ALIAS, ANAME, or CNAME Flattening. These engines dynamically resolve the target CNAME at the edge and serve synthetic A and AAAA records directly to querying clients.
Never attempt to point your naked root apex domain (example.com) to an external SaaS provider (like Shopify, Vercel, or Heroku) using a raw CNAME record unless your DNS provider supports automated CNAME Flattening / ALIAS records, or you will completely drop inbound MX emails.
Email deliverability relies on a coordinated cluster of DNS records to establish sender identity and block spam, spoofing, and phishing campaigns:
1. MX (Mail Exchange) Records: Dictate which Mail Transfer Agents (MTAs) accept incoming mail for the domain. MX records contain a priority preference integer (e.g., 10, 20, 30). Sending MTAs always attempt connection to the lowest priority number first, falling back to higher values only during network timeouts.
2. SPF (Sender Policy Framework - RFC 7208): Published as a TXT record at the root apex. It enumerates all IP addresses, CIDR subnets, and third-party relay services (e.g., Google Workspace, SendGrid) authorized to transmit outbound mail from your domain.
3. DKIM (DomainKeys Identified Mail - RFC 6376): Uses TXT records published at selector subdomains (e.g., google._domainkey.example.com) containing a 2048-bit RSA public key. Receiving mail servers use this key to cryptographically verify that the email header and body were not tampered with in transit.
4. DMARC (RFC 7489): Published at _dmarc.example.com. It tells receiving servers whether to monitor (p=none), quarantine (p=quarantine), or reject (p=reject) incoming messages that fail SPF or DKIM alignment checks.
NS (Nameserver) records delegate control of your DNS zone to authoritative servers across globally distributed geographic locations. For redundancy, RFC standards mandate a minimum of two distinct authoritative nameservers hosted across separate Autonomous System Numbers (ASNs) and network backbones.
SOA (Start of Authority) records supply the master zone configuration. Crucially, the SOA Serial Number tracks changes. Under RFC 1912 best practices, network administrators format the serial number as YYYYMMDDNN (Year, Month, Day, Revision). Secondary nameservers periodically query the SOA serial; when the serial increases, secondaries trigger an automated zone transfer (AXFR / IXFR) to synchronize records.
; Sample RFC 1035 SOA Record Structure
@ IN SOA ns1.example.com. admin.example.com. (
2026100401 ; Serial: YYYYMMDDNN
7200 ; Refresh: 2 hours (secondary checks master)
3600 ; Retry: 1 hour (retry if master unreachable)
1209600 ; Expire: 2 weeks (secondary discards zone if unreachable)
300 ; Negative Cache TTL: 5 minutes (RFC 2308 NXDOMAIN cache)
)Sysadmins and DevOps engineers diagnose record propagation and delegation issues using standard command-line tools. Below are the most effective terminal recipes for verifying active zone records:
# Query all active A records for a domain directly from Cloudflare Public DNS dig @1.1.1.1 example.com A +short # Query MX records with priority ranking and trace full authoritative delegation dig example.com MX +noall +answer # Query TXT records to audit active SPF, DKIM, and DMARC enforcement dig example.com TXT +short dig _dmarc.example.com TXT +short # Inspect authoritative SOA record serial and timers dig example.com SOA +multiline # Windows PowerShell equivalent using Resolve-DnsName Resolve-DnsName -Name example.com -Type MX
AI Mobile App Developer & Full-Stack Systems Engineer•Dhaka, Bangladesh
Bayajit Islam is an AI Mobile App Developer and Full-Stack Systems Engineer based in Dhaka, Bangladesh. With 2+ years of hands-on production experience building cross-platform apps for iOS, Android & Desktop with Flutter & Dart, asynchronous backends with FastAPI & Python, and modern web applications with Next.js, TypeScript, and Docker, he engineered LotsofNetwork as a zero-latency, privacy-first diagnostic platform for developers and network administrators.
Quick answers to common questions on this topic.
High-speed, zero-cost engineering tools built for network diagnostics and developer workflows.
Detect IP, GeoIP, ISP, ASN & PTR
Reverse IP to PTR hostname & verify FCrDNS
Domain registrar & expiry info
Audit SPF, DKIM & DMARC records
Check global DNS record propagation across Anycast resolvers
Calculate CIDR, masks & host ranges