DNS Record Parser
Examples (click to load):
About This Tool
Understanding DNS Zone Files
DNS (Domain Name System) translates human-readable domain names into IP addresses and provides other routing information used by the internet. The configuration data for a DNS zone is stored in zone files using a standardized text format defined in RFC 1035. Every line in a zone file is either a comment (starting with a semicolon), a directive (starting with a dollar sign), or a resource record.
Resource records follow the format: name TTL class type rdata. The name identifies which domain the record applies to, TTL specifies how long resolvers may cache the record, the class is nearly always IN (Internet), the type specifies what kind of record it is, and rdata contains the type-specific data. This tool parses any resource record line and extracts each component into a structured, readable format.
Address Records: A and AAAA
A records map a domain name to an IPv4 address. They are the most fundamental DNS record type, enabling browsers and other clients to find the server for a domain. For example, example.com. 3600 IN A 192.168.1.1 means that example.com resolves to 192.168.1.1 and the result may be cached for 3600 seconds (one hour).
AAAA records serve the same purpose for IPv6 addresses. The name comes from the fact that an IPv6 address is four times as long as an IPv4 address (128 bits vs 32 bits). Example: example.com. 3600 IN AAAA 2001:db8::1. Most modern services have both A and AAAA records to support clients on both IPv4 and IPv6 networks. Clients with both connectivity types will prefer IPv6 through a mechanism called Happy Eyeballs.
Mail Records: MX
MX (Mail Exchange) records specify which servers handle email for a domain. An MX record contains a priority (lower numbers have higher priority) and the hostname of the mail server. When sending email to [email protected], the sender's mail server looks up the MX records for example.com and connects to the highest-priority mail server listed.
Multiple MX records with different priorities provide redundancy. If the primary mail server (lowest priority number) is unavailable, the sender tries the next priority. For example: example.com. IN MX 10 mail1.example.com. and example.com. IN MX 20 mail2.example.com. means mail1 is tried first and mail2 is the backup.
Text Records: TXT
TXT records store arbitrary text data associated with a domain. Originally intended for human-readable descriptions, TXT records are now widely used for machine-readable authentication and verification data. SPF (Sender Policy Framework) records use TXT to specify which mail servers are authorized to send email for a domain, reducing email spoofing. A typical SPF record looks like: example.com. IN TXT "v=spf1 include:_spf.google.com ~all".
Other common TXT record uses include DKIM public key publication, DMARC policy specifications, domain ownership verification for services like Google Search Console and certificate authorities, and Let's Encrypt ACME challenge tokens during certificate issuance. The TXT record type is flexible enough to support any future text-based DNS application without requiring a new record type.
Service Records: SRV
SRV (Service) records specify the location of specific network services within a domain. They combine service discovery with load balancing and failover into a single DNS record type. The record name uses the format _service._protocol.domain, and the rdata contains priority, weight, port, and target hostname. For example: _sip._tcp.example.com. IN SRV 10 5 5060 sip.example.com. specifies that the SIP service over TCP is available at sip.example.com on port 5060 with priority 10 and weight 5.
SRV records are used by many modern protocols including XMPP (instant messaging), SIP (VoIP), LDAP (directory services), and Kubernetes internal service discovery. They allow a single DNS lookup to discover the service port, reducing the need for hardcoded port numbers in client configurations. Weight values enable weighted round-robin load distribution among multiple servers with the same priority.
Name Server and Authority Records: NS and SOA
NS (Name Server) records identify the authoritative DNS servers for a zone. Every zone must have at least two NS records pointing to servers that hold the authoritative copy of the zone data. Registrars use these records to delegate DNS authority for a domain. When a resolver needs to find the authoritative servers for example.com, it looks up the NS records at the .com top-level domain and then queries those servers directly.
SOA (Start of Authority) records are required in every zone and contain administrative parameters. The serial number is incremented each time the zone is updated, which signals secondary servers to request a new copy. The refresh interval controls how often secondaries check for updates. The retry interval sets how long to wait before retrying a failed refresh. The expire value defines when a secondary stops serving the zone if it cannot contact the primary. The minimum TTL applies to negative responses (NXDOMAIN).
Security Records: CAA and DNSSEC
CAA (Certification Authority Authorization) records specify which certificate authorities are allowed to issue SSL/TLS certificates for a domain. For example, example.com. IN CAA 0 issue "letsencrypt.org" restricts certificate issuance to Let's Encrypt. CAs are required to check CAA records before issuing certificates, providing an additional layer of protection against certificate misissuance. The flags field (0 or 128) and tag field (issue, issuewild, iodef) control the behavior.
DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records to prevent tampering and spoofing. DNSKEY records publish the zone's public keys. DS (Delegation Signer) records in the parent zone authenticate the child zone's DNSKEY. RRSIG records contain the cryptographic signature for each signed record set. NSEC records provide authenticated denial of existence, proving that a queried name does not exist without allowing zone enumeration.
Practical Use Cases
Network engineers use DNS record parsing when auditing zone files, migrating DNS providers, or troubleshooting mail delivery problems. Understanding MX record priorities and SPF record syntax is essential for email deliverability. System administrators use the parser to verify that infrastructure automation tools generate correct zone file syntax before deploying changes.
Developers use DNS record parsing when building tooling around DNS management APIs, which often return raw resource record strings. DevOps engineers use it when working with Infrastructure as Code tools like Terraform or Ansible that manage DNS records as strings. Security engineers use it when reviewing DNSSEC configurations, CAA records, and SPF/DKIM/DMARC policies during security assessments.
Frequently Asked Questions
Yes, DNS Record Parser is totally free :)
Yes, you can install the webapp as PWA.
Yes, any data related to DNS Record Parser only stored in your browser (if storage required). You can simply clear browser cache to clear all the stored data. We do not store any data on server.
A DNS record parser reads raw DNS zone file entries or DNS record strings and extracts their structured components. It identifies the record name, TTL, class, type, and all type-specific fields. This helps network engineers, developers, and system administrators understand and validate DNS records without manually decoding the zone file syntax.
This tool parses A (IPv4 address), AAAA (IPv6 address), CNAME (canonical name alias), MX (mail exchange), TXT (text records including SPF), SRV (service location), NS (name server), PTR (reverse DNS), CAA (certificate authority authorization), SOA (start of authority), DNSKEY, DS, RRSIG, and NSEC (DNSSEC records).
The standard format is: name [ttl] [class] type rdata. The name identifies the domain or subdomain. TTL (time to live) is an optional numeric value in seconds. Class is typically IN (Internet) and is often omitted. Type is the record type such as A, MX, or TXT. Rdata is the type-specific data such as an IP address for A records or a priority and mail server for MX records.
TTL (Time To Live) is the number of seconds a resolver is allowed to cache the DNS record before it must query the authoritative name server again. A low TTL such as 300 (5 minutes) means changes propagate quickly but generate more queries. A high TTL such as 86400 (24 hours) reduces query load but means DNS changes take longer to propagate globally.
An SOA (Start of Authority) record is required in every DNS zone and contains administrative information about the zone. It specifies the primary name server, the responsible administrator's email address (with @ replaced by a dot), a serial number for tracking zone changes, and timing parameters: refresh interval (how often secondary servers check for updates), retry interval, expire time, and the minimum TTL for negative responses.
DNS zone files allow long records to span multiple lines by enclosing extra lines in parentheses. SOA records commonly use this format. This tool automatically joins parenthesized multi-line records into a single record before parsing, so you can paste entire zone file sections directly without manual reformatting. Comment lines beginning with semicolons are also stripped.