Global DNS Checker

An A record maps a domain name to an IPv4 address. It is one of the most common DNS record types and is used when clients need to determine the IPv4 address of a host, such as a web server.

An NS record identifies the authoritative name servers for a DNS zone. These servers are responsible for providing authoritative answers for the zone and are essential to the DNS delegation process.

A CNAME record creates an alias from one DNS name to another canonical name. When a resolver encounters a CNAME, it continues the resolution process using the target name. A CNAME is useful for aliases, but it generally cannot coexist with other ordinary data at the same owner name, except where DNS standards explicitly allow related records.

An MX record identifies the mail servers responsible for accepting email for a domain. Each MX record has a preference value; lower preference values are preferred over higher ones. MX records point to hostnames rather than directly to IP addresses.

TXT records store one or more text strings associated with a DNS name. They are commonly used for service configuration and verification, including SPF policies, domain ownership verification, DKIM-related information, and other application-specific data. TXT is a general-purpose DNS record type and does not have a single predefined application.

A PTR record maps a DNS name to another domain name and is most commonly used for reverse DNS. For IPv4, reverse DNS names are normally found under in-addr.arpa; for IPv6, they are found under ip6.arpa. PTR records are commonly used for diagnostics and for services such as email systems that perform reverse-DNS checks.

An AAAA record maps a domain name to an IPv6 address. It serves the same basic purpose for IPv6 that an A record serves for IPv4, allowing clients to discover IPv6 addresses for a host.

ANY is a DNS query type, not a normal resource record stored in a zone. An ANY query requests information associated with a name without specifying one particular record type. Despite its historical use for obtaining multiple record sets at once, authoritative servers are allowed to return only a subset of the available data or otherwise minimize the response. ANY queries are also discouraged in many operational environments because of their potential for large responses and DNS amplification attacks.

A DNSKEY record contains a public key used by DNSSEC. DNSSEC uses these keys together with DS and RRSIG records to establish a chain of trust and to validate the authenticity and integrity of DNS data. A DNSKEY does not encrypt ordinary DNS traffic.

The SOA record marks the start of authority for a DNS zone and contains important zone-management information. It identifies the primary name server, the responsible-party mailbox, a serial number, and timing values used for zone transfers and negative caching.

WKS records were designed to describe well-known network services available at a particular IP address. They are obsolete in modern DNS and are rarely, if ever, used in current deployments.

HINFO records were designed to describe a host using information such as its CPU and operating system. They are rarely used today, partly because publishing detailed host information can disclose unnecessary technical information. HINFO may also appear in minimized responses to ANY queries as described by RFC 8482.

An RP record identifies the mailbox of the person responsible for a DNS name and can also reference a TXT record containing additional information. It provides a standardized way to publish responsible-party information, although it is uncommon in modern public DNS.

AFSDB records identify database servers associated with an Andrew File System (AFS) cell. They were designed for AFS and related distributed-file-system environments and are uncommon on today’s Internet.

An X25 record associates a DNS name with an X.25 Public Switched Data Network address. X.25 was an important packet-switched networking technology historically, but this DNS record type has little practical relevance in modern networks.

An ISDN record associates a DNS name with an Integrated Services Digital Network (ISDN) address and optional subaddress information. The record was designed for ISDN-based environments and is now largely historical.

An RT record identifies an intermediate host through which traffic for another host should be routed. It was designed for older networking and mail-routing scenarios and has very limited use in modern DNS deployments.

NSAP records were designed to store Network Service Access Point addresses used by OSI networking protocols. The record type is deprecated and is not part of normal modern Internet DNS deployments.

SIG was an early DNSSEC security record type used to carry cryptographic signatures. It was superseded by the more specific RRSIG record used by modern DNSSEC. SIG should therefore be regarded as a historical or obsolete DNSSEC record type.

KEY was an earlier DNS security record type intended to store cryptographic keys. Modern DNSSEC uses DNSKEY instead, making KEY primarily a historical record type.

PX records were designed to provide mappings between DNS names and X.400 mail or X.500 directory information. They belong to older messaging and directory technologies and are rarely encountered today.

A LOC record describes the geographical location of a DNS name, including latitude, longitude, altitude, and measurement precision. It can be used to publish geographic information about network resources, although it is not commonly used by ordinary websites.

EID was defined for the experimental Nimrod routing architecture. It was intended to identify endpoints independently from their network locators. Nimrod was never widely deployed, so EID has little practical relevance in today’s Internet.

NIMLOC was another record type associated with the experimental Nimrod routing architecture. It was intended to represent network locators for endpoints. Nimrod was not widely deployed, making NIMLOC primarily of historical interest.

An SRV record specifies where a particular network service is available. It identifies a target hostname, port, priority, and weight. SRV records are used by many protocols and applications, including SIP, XMPP, LDAP, and other service-discovery systems.

ATMA records were designed to associate DNS names with Asynchronous Transfer Mode (ATM) addresses. ATM was once used in high-performance networking and telecommunications, but this record type is now largely historical.

NAPTR records are used by the Dynamic Delegation Discovery System (DDDS) to apply ordered rewriting rules to domain names or other identifiers. They have been used by systems such as ENUM and certain service-discovery mechanisms that require structured, rule-based resolution.

A KX record identifies a host that acts as a key exchange agent for a domain. The record was designed for applications that require a separate key-management service. It is uncommon in modern DNS deployments.

A CERT record can associate a certificate or certificate-related data with a DNS name. It supports several certificate formats, including PKIX, SPKI, and OpenPGP-related data. In practice, other mechanisms are more commonly used for certificate distribution today.

A DNAME record aliases an entire subtree of the DNS namespace to another domain name. Unlike CNAME, which aliases a single DNS name, DNAME affects the name and its descendants. DNAME is useful when an entire branch of a namespace must be redirected.

OPT is an EDNS pseudo-record used to carry additional information in DNS messages, such as supported UDP payload size, EDNS version information, DNS cookies, and other protocol extensions. OPT records are not ordinary zone records and are not stored as part of a DNS zone.

An APL record represents a list of address prefixes. It can describe IPv4 or IPv6 address ranges associated with a DNS name and was designed for applications that need to publish structured address-prefix information. It is uncommon in general-purpose DNS deployments.

A DS record connects a child DNSSEC zone to its parent zone and forms an important part of the DNSSEC chain of trust. It contains a digest of a DNSKEY from the child zone. A validating resolver can use the DS record published by the parent to authenticate the child zone’s DNSKEY.

An SSHFP record publishes fingerprints of SSH public keys in DNS. SSH clients can use these fingerprints as an additional way to verify a server’s host key, particularly when the DNS information is DNSSEC-validated.

An IPSECKEY record publishes information that can help systems discover public keys and gateways used with IPsec. It was designed to support secure IP communications and related key-discovery mechanisms, although it is not widely used on the public Internet.

An RRSIG record contains a digital signature over a DNS resource record set (RRset). DNSSEC validators use the signature together with the appropriate DNSKEY to verify that the DNS data is authentic and has not been modified. RRSIG records are a fundamental part of modern DNSSEC.

An NSEC record provides authenticated proof that a DNS name or record type does not exist in a DNSSEC-signed zone. It links one existing DNS name to the next name in canonical DNS order. Because these links can reveal information about the contents of a zone, NSEC can make systematic zone enumeration possible.

A DHCID record stores an identifier used to associate dynamically managed DNS names with DHCP clients. It is primarily used in environments where DHCP servers update DNS automatically and helps prevent different clients from incorrectly claiming the same DNS name.

NSEC3 provides authenticated denial of existence for DNSSEC while using hashed owner names instead of exposing the names directly in the NSEC chain. This makes casual zone enumeration more difficult than with NSEC, although it does not make enumeration impossible. NSEC3 also supports parameters such as hashing iterations and salt.

NSEC3PARAM specifies the parameters used when generating NSEC3 records for a DNSSEC zone. These parameters include the hash algorithm, flags, iteration count, and salt. It is primarily relevant to authoritative DNS servers operating NSEC3-signed zones.

A TLSA record is used with DANE (DNS-based Authentication of Named Entities) to associate a TLS certificate or public-key information with a service. TLSA can allow a client to authenticate a TLS service using DNSSEC-validated DNS data. DANE therefore depends on DNSSEC for a trusted DNS-based authentication chain.

An SMIMEA record is designed to publish information about S/MIME certificates or public keys in DNS. It can be used with DANE to associate an email address with cryptographic credentials, allowing supporting mail systems to discover and authenticate S/MIME keys through DNSSEC-protected DNS data.

A HIP record contains information used by the Host Identity Protocol, which separates a host’s cryptographic identity from its network location. This separation can support mobility, multihoming, and other networking scenarios where an endpoint may change its IP address without changing its identity.

TALINK was designed to express a relationship between trust anchors in DNSSEC. It was intended to assist with trust-anchor management between zones but has seen little operational deployment.

A CDS record allows a child DNSSEC zone to publish information that can be used by its parent when creating or updating the child’s DS record. This supports automated DNSSEC delegation management and can simplify key rollover and initial DNSSEC deployment.

A CDNSKEY record allows a child zone to publish its DNSSEC public-key information in a form that a parent can use when managing the child’s delegation. It is primarily intended to support automated DNSSEC provisioning and key-management workflows.

An OPENPGPKEY record publishes an OpenPGP public key in DNS for an email address. It is intended to support automated discovery of OpenPGP keys, with DNSSEC providing a way to authenticate the DNS data.

A CSYNC record allows a child zone to signal that certain information should be synchronized with its parent zone. It can be used for changes involving NS records and DS-related delegation information and is intended to support more automated child-to-parent DNS management.

The SPF DNS record type was originally defined to publish Sender Policy Framework information directly as an SPF record. However, RFC 7208 deprecated the SPF record type for operational use. Modern SPF policies should be published as TXT records, and SPF-aware mail systems should not rely on the SPF RR type.

NID is part of the Identifier-Locator Network Protocol (ILNP) family. It is used to publish a node identifier that is separate from the node’s network locator, supporting architectures in which identity and location are handled independently.

An L32 record is associated with the Locator/ID Separation Protocol (LISP) and represents a 32-bit IPv4 routing locator. LISP separates endpoint identifiers from routing locators, allowing routing and endpoint identity to be handled independently.

An L64 record is associated with LISP and represents a 64-bit locator used in LISP-related mapping information. It supports the separation of endpoint identifiers from routing locators in LISP-based networking environments.

An LP record is associated with the LISP mapping system and points to another DNS name that contains locator information. It allows LISP mapping information to be organized through DNS names rather than placing all locator information directly at one name.

An EUI48 record stores an EUI-48 identifier, commonly represented as a 48-bit hardware or interface identifier. EUI-48 is historically associated with identifiers such as Ethernet MAC addresses. The record is specialized and uncommon in ordinary DNS deployments.

An EUI64 record stores an EUI-64 identifier. EUI-64 is a 64-bit identifier format used in several networking contexts. This DNS record type is specialized and is rarely encountered in normal public DNS configurations.

TKEY is a DNS protocol mechanism used to establish or delete shared secret keys between communicating DNS entities. These keys can subsequently be used by mechanisms such as TSIG to authenticate DNS messages. TKEY data is exchanged in DNS messages rather than being maintained as ordinary zone data.

TSIG provides message authentication and integrity protection for DNS communications using a shared secret. It is commonly used to authenticate zone transfers and dynamic DNS updates. TSIG information is not stored as ordinary DNS zone data; it is carried as part of DNS message processing.

A URI record associates a DNS name with a Uniform Resource Identifier. It can be used to publish a service endpoint or resource location, including URIs using schemes such as HTTP or HTTPS. URI records are specialized and are not commonly required by ordinary websites.

A CAA record allows a domain owner to specify which Certificate Authorities are authorized to issue certificates for the domain. CAA can also specify related certificate-issuance policies, such as reporting destinations. Certificate Authorities are required to check applicable CAA records before issuing certificates, subject to the rules defined by the relevant standards.

AVC was proposed as a DNS mechanism for publishing application visibility and control information. It has not achieved broad deployment and should be considered a specialized or experimental DNS record type rather than a common Internet DNS mechanism.

TA was proposed as a DNSSEC-related record type for publishing trust-anchor information. Trust anchors are the starting points from which DNSSEC validation chains are trusted. Modern DNSSEC deployments normally manage trust anchors outside ordinary authoritative zone data rather than relying on a TA record.

DLV was used by the DNSSEC Lookaside Validation system to provide an alternative way of obtaining DNSSEC trust information when a parent zone did not provide a DS record. The DLV service operated by ISC has been discontinued, and DLV is deprecated. Modern DNSSEC uses the normal DNSSEC chain of trust from the root through parent DS records.