Bulk DNS Lookup
What is DNS and what does it do?
The Domain Name System (DNS) is the distributed naming system that allows people and applications to use domain names instead of having to work directly with IP addresses.
When you enter a domain such as example.com into a browser, the browser and operating system need to determine which IP address is associated with that name. DNS provides that mapping. Depending on the service being requested, the result may be an IPv4 address, an IPv6 address, a mail server, another hostname, or other structured information.
DNS is much more than a simple "internet phone book". It is a distributed, hierarchical database made up of zones, authoritative name servers, recursive resolvers, and a wide variety of resource record types.
DNS does not only map names to IP addresses
A and AAAA records provide IP addresses, but DNS can also identify authoritative name servers, mail servers, service endpoints, cryptographic keys, certificate policies, reverse mappings, DNSSEC signatures, and many other kinds of information.
How DNS resolution works
A typical DNS lookup begins with a client such as a browser or operating system asking a recursive resolver for information. If the resolver does not already have a usable answer in its cache, it can follow the DNS hierarchy until it reaches an authoritative server capable of answering for the requested zone.
1. Client
Requests information for a DNS name.
2. Resolver
Checks its cache and performs resolution when necessary.
3. DNS Hierarchy
Root, TLD and authoritative servers may be consulted.
4. Response
The resolver returns the result to the client.
Strict Query Mode
Application-specific behavior
Strict Query Mode is not a standard DNS protocol feature. If this application provides a strict-query option, it should be understood as a policy applied by the application when interpreting DNS responses.
In a strict interpretation, the application can require the response to contain data associated directly with the queried name instead of following or accepting a CNAME alias. This can be useful for diagnostics, validation, or applications that specifically need an answer for the original owner name. Normal DNS resolution, however, is allowed to return CNAMEs and then continue resolution using the canonical target name.
DNS Recursion and the RD Bit
The DNS header contains a Recursion Desired (RD) flag. A client sets RD when it wants the queried server to perform recursive resolution on its behalf.
If the server supports recursion and accepts the request, it can follow referrals and query other DNS servers until it obtains an answer or determines that the requested information cannot be found. A recursive response is normally indicated by the RA (Recursion Available) flag in the response.
RD is not the same as "always recurse"
Setting RD requests recursion; it does not force a server to provide recursive service. An authoritative-only server can decline to recurse.
DNSSEC (Domain Name System Security Extensions)
DNSSEC adds cryptographic authentication to DNS data. It allows a validating resolver to determine whether DNS data originated from the expected DNSSEC-signed zone and whether the data was modified after it was signed.
DNSSEC uses public-key cryptography and several DNS record types, most importantly DNSKEY, DS, and RRSIG. The DNSSEC chain of trust normally starts at the DNS root and follows delegations through DS records to child zones.
DNSSEC does not provide encryption
DNSSEC provides data-origin authentication and integrity protection. It does not provide confidentiality, encryption, or access control for DNS queries and responses.
DNSSEC AD Flag AD
The Authenticated Data (AD) flag in a DNS response indicates that a validating resolver has successfully validated the DNSSEC-related data covered by the response according to the resolver's validation process.
A client should interpret AD in the context of a DNSSEC-aware validating resolver. The presence of the AD bit is not itself a cryptographic signature; it is an indication from the resolver that validation succeeded.
DNSSEC CD Flag CD
The Checking Disabled (CD) flag is set by a DNS client when it asks a resolver not to perform DNSSEC validation for that query. This is useful when a DNSSEC-aware client intends to perform validation itself or when troubleshooting DNSSEC behavior.
CD does not mean that DNSSEC data is removed from the response. Rather, it affects whether the resolver is expected to perform DNSSEC validation while processing the query.
DNS Record and Query Types
Record types vs. query/meta types
The list below contains several kinds of DNS protocol types. Most are ordinary resource records stored in zones, but some are historical record types, DNSSEC-related records, EDNS pseudo-records, or query/transaction mechanisms. They should not all be interpreted as records that can simply be added to a DNS zone file.
Available DNS Types
DNS Type Reference
A (Address Record) A
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.
NS (Name Server Record) NS
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.
CNAME (Canonical Name Record) CNAME
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.
MX (Mail Exchange Record) MX
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 (Text Record) TXT
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.
PTR (Pointer Record) PTR
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.
AAAA (IPv6 Address Record) AAAA
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 (QTYPE=ANY) ANY
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.
DNSKEY (DNS Key Record) DNSKEY
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.
SOA (Start of Authority Record) SOA
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 (Well Known Services Record) WKS
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 (Host Information Record) HINFO
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.
RP (Responsible Person Record) RP
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 (AFS Database Record) AFSDB
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.
X25 (X.25 Address Record) X25
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.
ISDN (ISDN Address Record) ISDN
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.
RT (Route Through Record) RT
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 (Network Service Access Point Record) NSAP
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 (Signature Record) SIG
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 (Security Key Record) KEY
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 (X.400 / X.500 Pointer Record) PX
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.
LOC (Location Record) LOC
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 (Endpoint Identifier Record) EID
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 (Nimrod Locator Record) NIMLOC
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.
SRV (Service Locator Record) SRV
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 (ATM Address Record) ATMA
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 (Naming Authority Pointer Record) NAPTR
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.
KX (Key Exchanger Record) KX
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.
CERT (Certificate Record) CERT
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.
DNAME (Delegation Name Record) DNAME
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 (EDNS Option Pseudo-Record) OPT
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.
APL (Address Prefix List Record) APL
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.
DS (Delegation Signer Record) DS
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.
SSHFP (SSH Fingerprint Record) SSHFP
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.
IPSECKEY (IPsec Key Record) IPSECKEY
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.
RRSIG (DNSSEC Signature Record) RRSIG
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.
NSEC (Next Secure Record) NSEC
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.
DHCID (DHCP Identifier Record) DHCID
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 (Next Secure Version 3 Record) NSEC3
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 (NSEC3 Parameters Record) NSEC3PARAM
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.
TLSA (TLS Authentication Record) TLSA
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.
SMIMEA (S/MIME Certificate Association Record) SMIMEA
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.
HIP (Host Identity Protocol Record) HIP
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 (Trust Anchor Link Record) TALINK
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.
CDS (Child DS Record) CDS
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.
CDNSKEY (Child DNSKEY Record) CDNSKEY
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.
OPENPGPKEY (OpenPGP Public Key Record) OPENPGPKEY
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.
CSYNC (Child-to-Parent Synchronization Record) CSYNC
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.
SPF (Sender Policy Framework Record) SPF
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 (Node Identifier Record) NID
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.
L32 (LISP IPv4 Locator Record) L32
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.
L64 (LISP IPv6 Locator Record) L64
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.
LP (LISP Locator Pointer Record) LP
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.
EUI48 (EUI-48 Identifier Record) EUI48
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.
EUI64 (EUI-64 Identifier Record) EUI64
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 (Transaction Key Mechanism) TKEY
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 (Transaction Signature Mechanism) TSIG
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.
URI (Uniform Resource Identifier Record) URI
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.
CAA (Certification Authority Authorization Record) CAA
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 (Application Visibility and Control Record) AVC
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 (Trust Anchor Record) TA
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 (DNSSEC Lookaside Validation Record) DLV
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.
Why are there so many DNS types?
DNS has evolved for decades and has been extended to support address resolution, mail delivery, service discovery, security, reverse lookups, networking protocols, cryptographic validation, and many specialized applications.
As a result, the DNS registry contains both widely deployed types such as A, AAAA, NS, MX, CNAME, TXT, and SRV, as well as historical, experimental, deprecated, or highly specialized types. A DNS server may recognize a type without that type being appropriate for normal public DNS configuration.
Which DNS records are commonly used?
Commonly Used
A— IPv4 addressesAAAA— IPv6 addressesNS— authoritative name serversCNAME— aliasesMX— mail deliveryTXT— service and verification dataSOA— zone authority informationPTR— reverse DNSSRV— service discoveryCAA— certificate issuance policy
Historical or Specialized
Several entries in the registry exist primarily because DNS has accumulated extensions over many years. Some are obsolete, deprecated, experimental, or intended for specialized networking technologies.
Their presence in a DNS implementation does not mean that they should be used in a normal website configuration.
Conclusion
DNS is one of the fundamental systems that makes the Internet usable. It provides a distributed way to associate human-readable names with addresses, services, mail systems, security information, and other application data.
Understanding DNS requires more than knowing that a domain name resolves to an IP address. Recursive resolution, authoritative servers, DNS record types, CNAME processing, DNSSEC validation, and DNS message flags all play different roles in the resolution process.
DNSSEC adds an important security layer by allowing resolvers to authenticate DNS data and detect unauthorized modification. The AD and CD flags provide mechanisms for communicating DNSSEC validation behavior between clients and resolvers, while the RD flag controls whether recursion is requested.
Finally, not every type in the DNS registry is a record that administrators will use in a zone file. The registry contains ordinary resource records, DNSSEC records, protocol extensions, pseudo-records, transaction mechanisms, and historical types. Understanding that distinction is essential when analyzing DNS traffic or configuring DNS infrastructure.
