Bulk DNS Lookup

Paste anyting. We will catch the first 500 valid domains.
max 20MB
must be ipv4

Hide “name”, “rdata”, “type”, “ttl”, “rdlength” and “class” in results.

strict query mode means that if the hostname that was looked up isn’t actually in the answer section of the response, script will return an empty answer section, instead of an answer section that could contain CNAME records.

if we should set the recursion desired bit to 1 or 0.

request DNSSEC values, by setting the DO flag to 1; this actually makes the resolver add a OPT RR to the additional section, and sets the DO flag in this RR to 1.

set the DNSSEC AD (Authentic Data) bit on/off.

set the DNSSEC CD (Checking Disabled) bit on/off

What is DNS and what does it do?

DNS, or the Domain Name System, is the internet's equivalent of a phone book. It maintains a directory of domain names and translates them to IP addresses. This is necessary because, although domain names are easy for people to remember, computers access websites based on IP addresses. When you type a website's name into your browser, DNS servers take that domain name and translate it into the IP address for that website so your browser can load the page.

Strict Query Mode

Strict Query Mode is an operational setting in DNS query handling whereby the response must directly address the queried hostname. Under this mode, if a DNS resolver receives a query for a specific hostname, the answer section of the DNS response must contain that exact hostname. If the hostname is not found, the answer section is returned empty.

This mode contrasts with typical DNS resolution where, if the exact hostname is not found, the response can include a CNAME (Canonical Name) record, pointing to another hostname as an alias. Strict Query Mode is particularly useful for security or diagnostic purposes, ensuring that responses are explicitly addressing the query without redirection or aliasing.

DNS Recurse Bit

The recurse bit in a DNS query is a flag set by the client, indicating whether recursive querying should be used. When this bit is set, the DNS resolver will query other DNS servers on behalf of the client until it finds the definitive answer or exhausts the query path. If the recurse bit is not set, the server will respond with whatever information it immediately has, which could be incomplete if it doesn't have records for the queried domain.

DNSSEC (Domain Name System Security Extensions)

DNSSEC adds a layer of security to the DNS to protect it against certain types of attacks such as cache poisoning, where false DNS data is introduced into a resolver's cache. DNSSEC provides authentication and integrity but not confidentiality. It works by digitally signing records for DNS lookup using public key cryptography. This ensures that the received DNS responses are authentic and have not been tampered with.

DNSSEC AD Flag (Authenticated Data Flag)

The Authenticated Data (AD) flag in a DNS reply, when set, signifies that the DNS resolver has checked and verified the digital signatures on the records, confirming they are secure and have not been tampered with. This flag is only meaningful in responses from resolvers that support DNSSEC and is used to indicate that the included data can be trusted as verified by DNSSEC.

DNSSEC CD Flag (Checking Disabled Flag)

The Checking Disabled (CD) flag is used by a DNS client to indicate that the resolver should not attempt to validate the DNSSEC signatures. This is useful for debugging purposes or for DNSSEC-aware resolvers that want to perform validation themselves. When set, the resolver passes the DNSSEC data along without verification, leaving it up to the client to perform the security checks.

List of DNS Query Types

DNS Query Types

A (Address Record)

The A record is one of the most fundamental DNS record types, mapping a domain name to its corresponding IPv4 address. This allows internet users to access websites using human-readable names rather than numeric IP addresses.

NS (Name Server Record)

NS records specify the DNS servers responsible for a particular domain or subdomain. This tells the global DNS system which servers to consult to find out the IP addresses of domains within that zone.

CNAME (Canonical Name Record)

CNAME records allow a domain to be aliased to another domain. Whenever a DNS lookup is performed on a domain with a CNAME record, the lookup will continue by querying the domain the CNAME points to. This is useful for aliasing multiple domain names to a single host.

MX (Mail Exchange Record)

MX records define the mail servers responsible for accepting email on behalf of a domain and establish their priority. This ensures that emails sent to your domain are directed to the correct mail server.

TXT (Text Record)

TXT records hold free-form text of any type. They are often used to store descriptive text or data for various services, such as SPF records (for email sender verification), domain ownership verification codes, and other DNS-based validation mechanisms.

PTR (Pointer Record)

PTR records, used in reverse DNS lookups, map an IP address back to a domain name. They are the opposite of A or AAAA records and are primarily used for validation purposes, such as verifying that an IP address matches the domain it claims to be sending from, a common check in email spam prevention.

AAAA (IPv6 Address Record)

The AAAA record is similar to the A record but for IPv6 addresses. It maps a domain name to its corresponding IPv6 address, enabling devices to connect to resources over IPv6, the latest Internet Protocol version.

ANY (All cached records)

ANY queries were designed to request all available DNS records for a domain at once. However, due to security concerns and potential misuse in DDoS amplification attacks, the use of ANY queries has been discouraged or restricted on many DNS servers.

DNSKEY (DNS Key Record)

DNSKEY records are part of DNSSEC (DNS Security Extensions), which add a layer of security to the DNS. These records contain the public keys that are used to digitally sign a zone, enabling the validation of the authenticity and integrity of DNS data.

SOA (Start of Authority Record)

The SOA record contains essential information about a domain and its DNS configuration, including the primary DNS server, the email of the domain administrator, and various timers and counters related to zone refresh rates and retries.

WKS (Well Known Services Record)

WKS records map an IP address to a list of well-known services (such as HTTP, FTP, or SMTP) that are available on that address. They are rarely used today due to their static nature and the advent of more dynamic service discovery methods.

HINFO (Host Information Record)

HINFO records provide basic information about a host, specifically the CPU type and operating system. Due to privacy and security considerations, their use is now generally avoided.

RP (Responsible Person Record)

RP records identify the mailbox for the person responsible for a domain. This can be used for administrative contact information but is not widely utilized.

AFSDB (AFS Database Record)

AFSDB records are used to specify servers for the Andrew File System (AFS) and other distributed file systems that use the same model. They help in locating database servers of an AFS cell.


The X25 DNS record type maps a domain name to an X.25 address. Although X.25 is an older packet-switching network technology, this record type provided integration between DNS and X.25 networks.


ISDN records map a domain name to an ISDN address, which is a set of communication standards for simultaneous digital transmission of voice, video, data, and other network services. This record type facilitated the use of DNS within ISDN environments.

RT (Route Through)

RT records specify intermediate hosts that act as routers for the host specified in the record. They are associated with the X.400 mail routing and rarely used in modern internet infrastructure.


NSAP records are intended for storing NSAP addresses, used in OSI (Open Systems Interconnection) networking. These addresses are part of a system that predates the widespread adoption of the Internet Protocol but provided a way to integrate OSI networking into the DNS system.

SIG (Signature)

The SIG record was originally used in DNSSEC (DNS Security Extensions) to provide a cryptographic signature for a set of DNS records, ensuring their authenticity and integrity. However, SIG records have been superseded by RRSIG records in modern DNSSEC specifications, although the concept remains central to DNSSEC's operation.


The KEY record was used to store a public key associated with a DNS name for DNSSEC. The purpose was to enable cryptographic verification of DNS data. Like SIG, KEY records have been largely replaced by more specific DNSSEC records, such as DNSKEY, which is now used for this purpose.

PX (Pointer to X.400/X.500)

PX records are used in conjunction with the X.400 and X.500 directory services, mapping domain names to X.400 mail and X.500 directory services. While these services are less commonly used today, PX records provided a bridge between DNS domain names and these older directory and messaging systems.

LOC (Location)

LOC records provide geographical location information for a domain, specifying latitude, longitude, altitude, and precision. This can be used for various applications, including location-based services or for informational purposes to locate the physical presence of network resources.

EID (Endpoint Identifier)

Part of the Nimrod routing architecture, the EID record was intended to support highly dynamic routing environments. Nimrod is an experimental protocol, and the use of EID records is not widespread in current internet infrastructure.

NIMLOC (Nimrod Locator)

Similar to EID, NIMLOC records were designed for use with the Nimrod routing protocol, specifying locators for endpoints. Like EID, NIMLOC's practical application is limited due to the experimental nature of Nimrod.

SRV (Service Locator)

SRV records are used to specify the location of servers or services for a domain, including the hostname, port, and protocol for services such as SIP (Session Initiation Protocol) or XMPP (Extensible Messaging and Presence Protocol). SRV records are crucial for enabling services that require specific ports and protocols to operate under a domain.

ATMA (Asynchronous Transfer Mode Address)

ATMA records were designed for specifying ATM (Asynchronous Transfer Mode) addresses within DNS. ATM is a networking technology that supports high-throughput data transfer, but the use of ATMA records is rare as ATM technology has become less common in favor of newer networking standards.

NAPTR (Naming Authority Pointer)

NAPTR records are used in the Dynamic Delegation Discovery System (DDDS) to support regular expression-based rewriting of domain names. This can be used for a variety of applications, including ENUM (Telephone Number Mapping) and other services that require complex redirection or rules-based handling of domain names.

KX (Key Exchanger)

KX records specify a key management agent for a domain, used primarily in secure email exchange protocols. They point to a domain that holds a public key, which can then be used to encrypt communications or establish secure connections.

CERT (Certificate)

CERT records are used to store public key certificates and related information, such as PGP/GPG keys or X.509 certificates. This enables the association of cryptographic certificates with DNS names for secure communication and authentication purposes.

DNAME (Delegation Name)

DNAME records provide a way to redirect an entire subtree of the DNS namespace to another domain. Unlike CNAME records, which alias a single name, DNAME redirects all requests for a specified domain and all its subdomains to another domain.

OPT (Option)

OPT records are used in EDNS (Extended DNS) to provide additional capabilities not available in standard DNS, such as larger message sizes and the ability to carry additional information in DNS packets. OPT records are crucial for DNSSEC and other extensions to the basic DNS protocol.

APL (Address Prefix List)

APL records specify lists of IP address ranges in DNS, allowing for more granular control over which IP addresses are authorized for certain DNS operations. This can be used for various policy and security applications within DNS.

DS (Delegation Signer)

DS records are used in DNSSEC as a way to link a child zone to a parent zone securely, facilitating the chain of trust in DNSSEC. DS records contain a hash of a DNSKEY record from the child zone, which the parent zone publishes to establish trust for the child's DNSSEC keys.

SSHFP (SSH Public Key Fingerprint)

SSHFP records are used to store SSH public key fingerprints in DNS, allowing clients to verify the authenticity of an SSH server based on DNS and potentially using DNSSEC for additional security. This can prevent man-in-the-middle attacks during SSH authentication.


IPSECKEY records are used to store keys for IPsec (Internet Protocol Security), enabling secure IP communications by specifying cryptographic keys in DNS. This can be used for secure VPN connections and other IPsec-based communications.

RRSIG (DNSSEC Signature)

RRSIG records are used in DNSSEC to provide cryptographic signatures for a set of DNS records, ensuring their authenticity and integrity. Each RRSIG is associated with a DNSKEY record that can be used to verify the signature, forming a critical component of DNSSEC's security model.


The NSEC (Next SECure) record is part of DNSSEC (DNS Security Extensions), which adds security measures to the DNS to protect against certain types of attacks. NSEC records provide proof of non-existence of a DNS name within a zone. When a DNS resolver queries a name that doesn't exist, an NSEC record is returned, showing the next valid domain name in the DNS zone. This proves that the name queried doesn't exist, but it also allows for zone walking, where an attacker can enumerate all the domain names in a zone.


The DHCID (DHCP Identifier) record is used in conjunction with DHCP (Dynamic Host Configuration Protocol) to associate a domain name with a specific client identifier. It's primarily used to prevent conflicts when dynamically updating DNS records in environments where both DHCP and DNS are used for network management.


NSEC3 records are an enhancement over NSEC records used in DNSSEC. NSEC3 addresses the zone walking vulnerability of NSEC records by hashing the domain names before they are stored in the DNS. This makes it much harder for an attacker to enumerate all the domain names in a zone. NSEC3 records still provide proof of non-existence but in a way that protects the zone's contents from easy discovery.


The NSEC3PARAM record specifies the parameters (such as the hash algorithm, flags, iterations, and salt) used for NSEC3 records in a zone. This record allows DNS resolvers to understand how to interpret NSEC3 records they receive.


The TLSA record is used for DANE (DNS-based Authentication of Named Entities). TLSA records enable a DNS zone to specify cryptographic certificates associated with a domain, directly in the DNS, which can be used to authenticate TLS (Transport Layer Security) connections. This is particularly useful for securing HTTPS connections or email servers.


Similar to TLSA, the SMIMEA record supports the DANE protocol but is specifically used for S/MIME (Secure/Multipurpose Internet Mail Extensions) certificate validation. SMIMEA records enable the publication of S/MIME certificates in DNS, allowing senders to encrypt email content in a way that can only be decrypted by the intended recipient.


The HIP (Host Identity Protocol) record facilitates the separation of the endpoint identifier and locator roles of IP addresses, improving the mobility and multi-homing capabilities of hosts. HIP records are used to associate a host identity (a public key) with one or more IP addresses that serve as network locators for that host.


The CDS (Child DS) record is used in DNSSEC for a child zone to signal DS (Delegation Signer) record information to its parent zone. This facilitates the automated management of DNSSEC trust anchors, especially for rolling over keys.


The CDNSKEY (Child DNSKEY) record is similar to the CDS record but for DNSKEY information. It allows a child zone to publish its DNSKEY records in a way that can be retrieved by the parent zone, supporting automated DNSSEC key management.


The OPENPGPKEY record allows for the publication of OpenPGP public keys in DNS. This enables users to retrieve the PGP key for an email address directly via DNS, facilitating encrypted email exchanges.


The CSYNC (Child-To-Parent Synchronization) record is used in DNS to signal changes in a child zone to its parent. This includes updates to NS (Name Server) records or the introduction/removal of DS records. It supports the coherent operation of DNSSEC by ensuring that parent zones are kept up to date with changes in child zones.


The SPF (Sender Policy Framework) record was used to specify which mail servers are authorized to send email on behalf of a domain, aiming to reduce email spam and spoofing. However, SPF records have been largely superseded by TXT records for specifying SPF information, though SPF records are still seen in use.


The NID (Node ID) record, part of the ILNP (Identifier-Locator Network Protocol) suite, is used to specify a node identifier in the DNS. This supports advanced networking scenarios where separating identifiers from locators can improve network resilience and flexibility.


The L32 record is used with the Locator/ID Separation Protocol (LISP), mapping a 32-bit IPv4 locator to an Endpoint Identifier (EID). LISP separates IP addresses into EIDs (used by end hosts) and Routing Locators (RLOCs, used by network devices for traffic forwarding), improving routing efficiency and scalability.


Similar to the L32 record, the L64 record is used in the LISP system but for mapping a 64-bit IPv6 locator to an EID. This supports the LISP protocol's operation in IPv6 networks, facilitating the same separation of endpoint identities from their routing locators.


The LP record, another component of the LISP system, links a DNS name to an EID, allowing for the resolution of EIDs similarly to how A or AAAA records resolve to IP addresses. This helps integrate LISP with the DNS infrastructure, enabling easier use and deployment of LISP.


EUI48 and EUI64 records are used for storing MAC addresses in DNS. EUI-48 and EUI-64 are standards for MAC addresses, commonly used for network interface identification. EUI48 records are for 48-bit MAC addresses, while EUI64 records accommodate 64-bit MAC addresses. These records can be used for various purposes, including mapping physical hardware addresses to domain names for network management and configuration tasks.


EUI48 and EUI64 records are used for storing MAC addresses in DNS. EUI-48 and EUI-64 are standards for MAC addresses, commonly used for network interface identification. EUI48 records are for 48-bit MAC addresses, while EUI64 records accommodate 64-bit MAC addresses. These records can be used for various purposes, including mapping physical hardware addresses to domain names for network management and configuration tasks.


The TKEY (Transaction Key) record is used for establishing a shared secret between two entities that are communicating using DNS. This secret can then be used to authenticate DNS messages and ensure their integrity, supporting secure dynamic updates and other DNS transactions that require authentication.


TSIG (Transaction Signature) records are not actually stored in DNS but are used to provide a way to authenticate DNS messages. A TSIG applies a cryptographic signature to DNS communication, ensuring authenticity and integrity of the message between the DNS client and server. It's commonly used for secure zone transfers (AXFR/IXFR) and dynamic updates.


The URI (Uniform Resource Identifier) record provides a way to associate a DNS name with a URI. This is useful for services that need to direct clients not just to a server, but to a specific resource or service identified by a URI, such as HTTP(S) URLs or other services within the URI scheme.


CAA (Certification Authority Authorization) records allow domain owners to specify which Certificate Authorities (CAs) are authorized to issue certificates for their domain. This enhances security by preventing unauthorized issuance of certificates, helping to mitigate certain types of man-in-the-middle attacks.


The AVC (Application Visibility and Control) record was proposed for use in expressing application visibility and control preferences directly within DNS. It's aimed at allowing domain owners to communicate policies regarding the handling of their traffic by networks, although its implementation and usage are not widely adopted or standardized.


The TA (Trust Anchor) record is related to DNSSEC, serving as a way to specify a trust anchor for a zone. Trust anchors are used to verify the DNSSEC chain of trust, starting from a known, trusted public key. This is essential for validating the authenticity of DNS data.


DLV (DNSSEC Lookaside Validation) records were part of an alternative mechanism for validating DNSSEC-signed data without requiring the presence of DNSSEC in the parent zone. The DLV system was hosted by ISC (Internet Systems Consortium) and allowed for DNSSEC validation through a lookaside repository. However, the use of DLV has been deprecated in favor of more direct DNSSEC deployment methods.

Each DNS record type serves a specific purpose, from basic domain name resolution to security-related functions. The diversity of DNS record types illustrates the flexibility and complexity of the Domain Name System, a critical component of the internet's infrastructure.


DNS plays a critical role in the functioning of the internet by resolving domain names into IP addresses. Understanding its features like Strict Query Mode, the recurse bit, and DNSSEC, along with the AD and CD flags, is crucial for network administrators, security professionals, and anyone interested in the infrastructure of the internet. These mechanisms enhance the reliability, security, and accuracy of DNS services, forming an essential component of cyber defense strategies.