DNS

• DNS lookup A, AAAA, MX, TXT, NS, CAA and more for any domain.
• MX lookup Mail exchanger records and their priorities for a domain.
• Reverse DNS (PTR) Resolve an IP address back to its hostname.
• Whois / RDAP Registrar, registration dates, status and nameservers for a domain or IP.
• DNS resolver / leak test See which DNS resolver your connection is actually using. Coming with the API.

• A record — An A record is the basic DNS record type that maps a hostname to an IPv4 address, defined in RFC 1035 alongside the rest of the core DNS record set. When a resolver looks up a domain's A record, it gets back one or more 32-bit IPv4 addresses a client can connect to directly; a domain can publish several A records for the same name to spread traffic across multiple servers, a simple form of load distribution usually called round-robin DNS. The IPv6 counterpart, the AAAA record (RFC 3596), serves the same purpose for 128-bit addresses, and a dual-stack domain typically publishes both for the same hostname. AdminKit's DNS lookup tool queries a domain's A records alongside AAAA, MX, TXT, NS and CAA in a single lookup, making it easy to confirm which IPv4 address visitors will actually reach.
• AAAA record — An AAAA record maps a hostname to an IPv6 address, the same job an A record does for IPv4, just for a 128-bit address instead of a 32-bit one. RFC 3596 defines the AAAA record type specifically for this purpose, as part of the broader set of DNS extensions written to support IPv6 alongside the existing IPv4-oriented record types. A dual-stack domain typically publishes both an A and an AAAA record for the same hostname, letting a connecting client's resolver choose whichever address family it and the network path actually support; a domain with only an A record is IPv4-only regardless of whether the server itself supports IPv6. AdminKit's DNS lookup tool queries AAAA records alongside A, MX, TXT, NS and CAA for any domain, so a missing AAAA record is easy to spot when auditing a domain's IPv6 readiness.
• Authoritative nameserver — An authoritative nameserver is the server that holds the actual source-of-truth records for a DNS zone and is designated, via NS records at both the registrar and the zone itself, to answer queries about that domain directly -- as opposed to a recursive resolver, which only caches and forwards answers it looked up elsewhere. When a recursive resolver doesn't have a cached answer, it eventually queries one of the domain's authoritative nameservers to get the current, canonical record. Changing DNS providers means updating which servers are authoritative for a domain at the registrar, and until every resolver's cached copy of the old NS records expires, some queries may still reach the old servers. Confirming which nameservers are actually authoritative for a domain, and that they match what was intentionally configured, is a basic check against DNS hijacking or an unnoticed registrar change.
• CAA record — A CAA (Certification Authority Authorization) record is a DNS entry that specifies which certificate authorities are permitted to issue TLS/SSL certificates for a domain. Without one, any publicly trusted CA can issue a certificate for the domain if it passes that CA's own validation; with a CAA record in place, CAs are required by the CA/Browser Forum baseline requirements to check it and refuse to issue a certificate if they aren't on the allowed list. It's a defense-in-depth control against a certificate being mistakenly or maliciously issued by an unintended CA, and it costs nothing to add beyond a single DNS record.
• CNAME record — A CNAME (Canonical Name) record is a DNS entry that makes one domain name an alias for another, telling resolvers to look up the other name instead of returning an address directly. Defined in RFC 1035, it's the standard way to point a subdomain at a service you don't control the IP address for -- a custom domain pointed at a CDN, a SaaS vendor's hosting, or an email-marketing platform's tracking domain are common examples -- since the target's own address can change without the CNAME needing to be updated. RFC 1035 also means a CNAME record cannot coexist with any other record type on the same name, and most DNS providers don't allow a domain's root/apex record to be a CNAME at all, which is why services needing root-domain aliasing use provider-specific ALIAS or ANAME records instead.
• DNS — DNS (the Domain Name System) is the internet's directory service, translating human-readable domain names like adminkit.net into the numeric IP addresses computers actually use to route traffic. A DNS lookup walks a hierarchy of servers -- root, top-level-domain, and authoritative nameservers for the specific domain -- to resolve a name to its records, which can include an A/AAAA record (the IP address), an MX record (mail server), a TXT record (often used for SPF/DMARC or domain verification), and more. Every authentication mechanism email relies on, and most of the web's addressing, sits on top of DNS working correctly and resolving quickly.
• DNS cookies — DNS cookies (RFC 7873) are an optional EDNS0 extension that lets a DNS client and server exchange a pair of opaque tokens -- a client cookie and a server cookie -- attached to plain UDP queries and responses. Once a server has issued a client a server cookie, it can reject or deprioritize any later query claiming to be from that client but presenting the wrong cookie, giving lightweight protection against off-path attackers who spoof a query's source address to poison a cache or trigger a reflected denial-of-service response, without the overhead of switching every query to TCP. Support is optional and not universal: a resolver or authoritative server that doesn't implement DNS cookies simply ignores the extension and falls back to ordinary unauthenticated UDP behavior.
• DNS forwarder — A DNS forwarder is a nameserver that resolves queries by handing them to another nameserver instead of walking the authoritative chain itself, defined in RFC 8499's DNS terminology as sending a query with the RD (recursion desired) bit set rather than iterating through root, TLD and authoritative servers directly. Home routers and small-office DNS servers commonly run as forwarders, sitting between a device's stub resolver and an upstream recursive resolver -- often the ISP's, or a public one like 1.1.1.1 or 8.8.8.8 -- so the forwarder itself does little more than cache answers and pass queries on. Because a forwarder decides which upstream resolver every device on its network actually uses, a router quietly reconfigured to forward to an attacker-controlled resolver -- without ever changing any individual device's own DNS settings -- is a common, easy-to-miss form of DNS hijacking.
• DNS propagation / TTL — TTL (Time To Live) is a value attached to every DNS record that tells resolvers how many seconds they're allowed to cache an answer before checking again. "DNS propagation" describes the real-world delay after a DNS change before every resolver worldwide that cached the old answer has that cache expire and fetch the new one -- it isn't instant, and the wait is bounded mainly by whatever TTL was set on the old record, not by the change itself. A short TTL (like 300 seconds) set in advance of a planned change, such as a server migration, lets the old answer expire quickly once the real change happens; a long-standing TTL of 86400 seconds or more means stragglers can take a full day or more to catch up.
• DNSBL — A DNSBL (DNS-based Blackhole List, also called an RBL) is a blocklist of IP addresses -- typically ones observed sending spam, running open relays, or otherwise associated with abuse -- published in a format mail servers can query using ordinary DNS lookups for speed. A mail server checks the sending IP against one or more DNSBLs in real time before accepting a message; a listing on a widely trusted DNSBL like Spamhaus can cause legitimate mail from that IP to be rejected or sent to spam, even for senders who did nothing wrong, which is especially common behind shared or CGNAT addresses.
• DNSKEY record — A DNSKEY record publishes the public key a zone uses to sign its own DNS records under DNSSEC, defined alongside the rest of the DNSSEC record set in RFC 4034. A zone's authoritative servers hold the matching private key and use it to generate RRSIG records -- the actual signatures over other record sets -- while a validating resolver fetches the DNSKEY record to verify those signatures, and separately checks a DS record at the parent zone to confirm the DNSKEY itself hasn't been substituted by an attacker. A zone typically publishes two: a Zone Signing Key used for day-to-day signing, and a Key Signing Key that signs the DNSKEY record set itself and is the one hashed into the parent's DS record. Losing track of a key rollover here is a common way a signed zone goes dark for validating resolvers.
• DNSSEC — DNSSEC (Domain Name System Security Extensions) adds cryptographic signatures to DNS records so a validating resolver can confirm a response actually came from a domain's authoritative owner and wasn't forged or altered in transit. It works by chaining trust from the DNS root down through each parent zone to the domain's own signed records (RRSIG, DNSKEY, and DS records tie the chain together), so a resolver can verify authenticity without a prior trust relationship with that domain. Plain DNS has no such protection, which is what makes cache-poisoning and spoofing attacks possible -- DNSSEC closes that gap, though it guarantees authenticity, not confidentiality, since responses are still sent in the clear. Adoption needs both the domain's DNS provider to sign the zone and the client's resolver to actually validate signatures, so a signed domain can still get unvalidated answers from a resolver that ignores DNSSEC.
• DoH — DoH (DNS over HTTPS) sends DNS queries and responses inside an encrypted HTTPS connection instead of the traditional unencrypted UDP/TCP port 53 traffic, so an observer on the network -- an ISP, a public Wi-Fi operator, or an attacker -- can't read or tamper with which domains are being looked up. Many modern browsers now enable DoH by default to a chosen resolver, which can bypass network-level DNS filtering or parental controls configured elsewhere on the network, a tradeoff worth knowing about if a device seems to ignore DNS-based blocking. DoH is defined in RFC 8484.
• DoT — DoT (DNS over TLS) encrypts DNS queries and responses using TLS over a dedicated port, 853, separate from ordinary DNS traffic on port 53. It serves the same privacy and integrity goal as DoH -- preventing on-path observation or tampering with DNS lookups -- but keeps DNS traffic on its own recognizable port rather than blending it into regular HTTPS traffic, which makes it easier for network administrators to identify and manage deliberately, at the cost of being easier to block outright. DoT is defined in RFC 7858 and is commonly supported by operating-system DNS settings and some router firmware.
• DS record — A DS (Delegation Signer) record is a DNSSEC record published in a parent zone that holds a cryptographic hash of a child zone's DNSKEY, letting a validating resolver confirm the child's signing key is the one the parent actually delegated to, without needing any prior trust relationship with the child zone itself. It is the link that turns a chain of individually signed zones into a single chain of trust running from the DNS root down to a specific domain, defined alongside the rest of DNSSEC in RFC 4034 and RFC 4035. A domain adds DNSSEC by signing its own zone and then asking its registrar to publish a matching DS record at the parent; skipping that second step leaves the zone signed but unverifiable, since resolvers have no way to confirm the child's key is genuine.
• EDNS0 (Extension Mechanism for DNS) — EDNS0 (RFC 6891) extends the original DNS message format with an optional pseudo-record, OPT, that lets a resolver advertise capabilities the 1987-era protocol never anticipated. Its most immediate job is signaling a larger UDP payload size than the original 512-byte limit, which is what lets DNS carry the bigger answers DNSSEC-signed zones produce without falling back to TCP for every query. EDNS0's extensible options field is also how later additions, like the DNSSEC OK (DO) bit and DNS Cookies (RFC 7873), attach to a query without changing the core wire format again. A resolver or server that doesn't understand EDNS0 simply ignores the OPT record and responds as if it weren't there, which is why support rolled out gradually without breaking older infrastructure. AdminKit's DNS lookup tool sends EDNS0-aware queries so it can retrieve full DNSSEC and large-answer responses correctly.
• Extended DNS Error (EDE) — Extended DNS Error (EDE) is an EDNS0 option, defined in RFC 8914, that lets a DNS server attach a machine-readable numeric code and short text to a response explaining why it answered the way it did, rather than leaving a client to guess from a bare SERVFAIL or NXDOMAIN. Codes distinguish causes that previously all looked identical from outside -- a DNSSEC signature that's expired (code 6), a name blocked by local policy (code 15), or a forwarder unable to reach its own upstream (code 22) -- so a filtering or validating resolver can report the actual reason instead of an opaque failure. This matters most for resolvers that intentionally withhold an answer, such as a DNSSEC-validating resolver rejecting a forged response or a protective DNS service blocking a known-malicious domain, where EDE turns a bare failure into a reason an administrator can actually act on.
• FQDN — A fully qualified domain name (FQDN) specifies a host's exact, complete position in the DNS hierarchy -- for example www.example.com -- rather than a partial or relative name a local resolver would need to guess a suffix for. DNS names are defined by RFC 1035, which specifies how a name is built from labels separated by dots, read right to left from the root down to the specific host; an FQDN includes every label needed to resolve unambiguously from the root, conventionally written with a trailing dot to make that explicit, though most software omits it. Entering anything less than a full FQDN into a DNS tool -- just "example" instead of "example.com" -- either fails outright or resolves against a local search-domain suffix that has nothing to do with the intended target. AdminKit's DNS lookup tool validates the FQDN you enter before forwarding the query to its upstream resolver.
• Glue record — A glue record is an A or AAAA record a parent zone publishes alongside an NS delegation, giving the IP address of a nameserver directly instead of making a resolver look it up separately. It's needed specifically when a domain's nameserver is itself a subdomain of the domain it serves (for example, `ns1.example.com` acting as a nameserver for `example.com`), since otherwise resolving that nameserver's address would require already knowing it -- a circular dependency. Without the correct glue record at the registrar, a domain using in-domain nameservers can become unresolvable even though its own DNS zone is configured correctly, because resolvers never get far enough to ask it anything. Glue records live at the registrar/parent-zone level, not inside the domain's own zone file, which is why confirming them means checking what the registrar actually publishes, not just the domain's own DNS records.
• mDNS — mDNS (Multicast DNS) lets devices on a local network resolve each other's names, typically ending in .local, without a central DNS server. A device announces its own name over multicast UDP on port 5353, and any other device on the same network segment can ask "who has this name" and get a direct reply, which is how Apple's Bonjour/AirPrint and many smart-home and IoT devices find printers, speakers, and cameras nearby. Because mDNS queries and replies are multicast and unauthenticated, the main risk is scope: it is meant to stay inside a single local network, but misconfigured routers or VPNs that bridge mDNS across network boundaries can leak device names and services to networks that shouldn't see them, and devices that answer mDNS queries from the public internet become a reflection target for abuse.
• MX record — An MX (Mail Exchange) record is a DNS entry that tells other mail servers which server is responsible for receiving email on behalf of a domain. Each MX record has a priority value -- lower numbers are tried first -- so a domain can list a primary mail server and one or more backups. Without a correct MX record, incoming mail to that domain has nowhere valid to go and will bounce or queue indefinitely. MX records point to a hostname, not an IP address directly, so that hostname's own A/AAAA record also has to resolve correctly for mail delivery to actually complete.
• Negative caching — Negative caching is a resolver's practice of remembering that a DNS query returned no answer -- either NXDOMAIN (the name doesn't exist) or NOERROR with an empty answer (the name exists but not for the requested record type) -- so it can return that same negative result without re-querying authoritative servers. RFC 2308 defines how long a negative answer may be cached: the TTL comes from the minimum value in the zone's SOA record, not the TTL of the (nonexistent) record itself. This matters in practice because a misconfigured or not-yet-propagated DNS record can keep failing for resolvers that cached the earlier NXDOMAIN, even after the correct record is published, until that negative-cache TTL expires.
• NS record — An NS (Nameserver) record identifies which servers are authoritative for a domain -- the servers that hold the actual DNS records and answer queries about that domain, as opposed to servers that merely cache or forward answers. NS records exist both at the domain's registrar (delegating the domain to its DNS provider) and within the DNS zone itself, and the two sets should match; a mismatch can cause intermittent resolution failures. Changing DNS providers means updating NS records at the registrar, and because of DNS caching and TTLs, that change can take time to propagate fully across resolvers worldwide rather than applying instantly.
• NSEC3 record — NSEC3 is a DNSSEC record type, defined in RFC 5155, that lets a resolver cryptographically confirm a queried name genuinely doesn't exist in a signed zone -- authenticated denial of existence -- without the zone publishing every name it contains in a walkable, plaintext order. The original NSEC record proves non-existence the same way, but does so using the zone's real owner names arranged sequentially, which lets anyone walk the chain and enumerate every name in the zone, even ones never otherwise published. NSEC3 replaces those owner names with a salted cryptographic hash of each one, so proving a gap between two hashed values no longer reveals the names that would fall inside it. It also supports an Opt-Out flag, letting a zone with many unsigned delegated subdomains skip signing each one without weakening validation for the names that are signed.
• NXDOMAIN — NXDOMAIN is the DNS response code (RFC 1035) a server returns when a queried domain name does not exist at all, as distinct from NOERROR with an empty answer, which means the name exists but has no record of the requested type. A resolver that receives NXDOMAIN for a name can cache that negative result for a TTL set by the queried zone's SOA record (RFC 2308), so repeated queries for a nonexistent name don't keep hitting authoritative servers. This caching is why a newly registered domain, or a typo'd one a registrar hasn't delegated yet, can keep returning NXDOMAIN for a while even after the correct delegation is published, and why some ISPs and public Wi-Fi networks intercept NXDOMAIN responses to redirect users to a search or ad page instead of returning the honest "this name doesn't exist" answer.
• PTR record — A PTR (Pointer) record is the reverse of an ordinary DNS lookup: instead of resolving a name to an IP address, it resolves an IP address back to a hostname, stored in the special in-addr.arpa (IPv4) or ip6.arpa (IPv6) DNS zones. Mail servers commonly check that an incoming connection's IP has a PTR record, and that the PTR's hostname in turn resolves forward back to the same IP (forward-confirmed reverse DNS) -- a mismatch or missing PTR record is a common reason legitimate mail gets flagged as spam. Residential and dynamic IP ranges often have generic, ISP-assigned PTR records rather than ones controlled by the account holder.
• Punycode (internationalized domain names) — Punycode (RFC 3492) is the encoding that lets internationalized domain names (IDNs) containing non-ASCII characters -- Cyrillic, Chinese, Arabic script, accented Latin letters -- work inside the DNS, which only ever transmits ASCII labels on the wire. An IDN label is converted to an ASCII-Compatible Encoding (ACE) form prefixed with xn--, so a label like café.example becomes xn--caf-dma.example internally, as specified by the IDNA2008 standard (RFC 5890-5894) governing which characters are valid. Browsers and other clients convert back and forth automatically, displaying the readable Unicode form while the DNS and WHOIS/RDAP records underneath use the xn-- form. The same mechanism is also a known phishing vector: visually similar characters from different scripts (homoglyphs) can form lookalike domains that render identically to a legitimate one. AdminKit's WHOIS tool resolves both the Unicode and xn-- forms of a domain when looking up registration data.
• QNAME minimization — QNAME minimization (RFC 7816) is a privacy technique for recursive DNS resolvers that limits how much of a query name (the QNAME) gets sent to each server consulted while resolving it. Without it, resolving www.example.com by asking the root server, then the .com server, then example.com's nameserver, traditionally sent the full name www.example.com to all three, even though the root server only needed to know about .com. With QNAME minimization, each server in the chain is asked only the minimum label needed to get the next referral, so the root server sees just a query related to .com rather than the full name, reducing how much of a user's browsing or lookup activity any single server along the path can observe.
• RDAP — RDAP (Registration Data Access Protocol) is the IETF-standardized successor to WHOIS for looking up who registered a domain or IP address block. Unlike WHOIS's loosely defined, plain-text, per-registry output formats, RDAP returns structured JSON over HTTPS with a consistent schema across registries, making it far easier for software to parse reliably and supporting features WHOIS lacked, like internationalization and differentiated access levels for redacted personal data under privacy rules like GDPR. Most domain and IP registries now run RDAP services alongside legacy WHOIS, and RDAP is gradually becoming the primary lookup method as WHOIS is phased down.
• Recursive resolver — A recursive resolver is the DNS server a client -- a computer, phone, router, or application -- actually asks when it looks up a domain. Rather than knowing the answer itself, it tracks the answer down on the client's behalf by querying the root servers, then the relevant top-level-domain servers, then the domain's authoritative nameservers, following the referral chain until it gets a final answer, which it then caches and returns. Most users never choose a recursive resolver explicitly: their ISP or router assigns one automatically, often with no filtering or logging transparency, and it can be silently overridden by malware or a compromised router. Confirming which recursive resolver a device is actually using, as opposed to the one configured, is the first step in diagnosing a DNS hijack or an unexpected forwarding override.
• RRSIG record — An RRSIG record carries the digital signature DNSSEC attaches to a specific set of DNS records -- all the A records for a name, for instance -- so a validating resolver can confirm that set hasn't been altered or forged since the zone's owner signed it. It is defined, like the rest of the DNSSEC record types, in RFC 4034, and a resolver verifies it using the public key published in the zone's DNSKEY record, which it has in turn confirmed is genuine through a DS record at the parent zone. Each RRSIG carries an explicit validity window, and a signature that has expired without being re-signed causes every validating resolver to treat the covered records as unverifiable, taking the zone offline for DNSSEC-aware resolvers even though the underlying records themselves never changed -- a common cause of a signed domain breaking unexpectedly.
• SOA record — An SOA (Start of Authority) record is the first record in every DNS zone, naming the zone's primary authoritative nameserver and administrator contact, plus a set of timing values -- serial number, refresh, retry, expire, and minimum/negative-cache TTL -- that control how secondary nameservers replicate the zone and how long a negative answer (a domain or record that doesn't exist) can be cached. The serial number is incremented on every zone change so secondaries know to pull an update; a serial that doesn't increase after an edit is a common, easy-to-miss cause of changes that silently fail to replicate to secondary nameservers. Unlike most record types, there is exactly one SOA record per zone, and it's typically surfaced alongside a domain's other records rather than looked up on its own, since it describes the zone itself rather than resolving to an address.
• SRV record — An SRV record publishes the hostname and port a specific service is reachable on for a domain, in the format `_service._proto.name`, letting a client look up where to connect for something like SIP or XMPP without a single fixed port the way HTTP uses port 80. It carries priority and weight values so multiple servers can share load or fail over, similar in spirit to how MX records route mail to multiple servers by priority. The same host-and-port advertisement pattern appears in DNS-SD (RFC 6763), which layers SRV, PTR, and TXT records on top of multicast DNS so devices on a local network can discover services like printers or media servers automatically -- the same mDNS-based discovery mechanism covered in AdminKit's LAN discovery guide, where the convenience of automatic discovery comes with broadcasting device and service details to anything listening on the same network segment.
• Stub resolver — A stub resolver is the lightweight DNS client built into an operating system or application that forwards every lookup straight to a recursive resolver, rather than walking the DNS hierarchy itself. RFC 1123 explicitly names this pattern, describing most end-host resolvers as minimal stub resolvers that depend on a nearby recursive resolver to do the iterative lookups RFC 1034 defines. Most operating systems ship a stub resolver pointed at whatever resolver address DHCP, a router, or an ISP supplies, though it can be repointed at a different one, including a Protective DNS or DNS-over-HTTPS resolver, to change what queries see and get filtered. A stub resolver does no caching or validation on its own, so behavior like DNSSEC validation or content filtering depends entirely on the recursive resolver it's configured to use. AdminKit's DNS resolver test tool checks which resolver a device is actually using and how it answers.
• SVCB/HTTPS record — SVCB and HTTPS are DNS record types, both defined in RFC 9460, that let a zone publish service-connection hints -- such as which ALPN protocols a server supports (h2, h3) or a non-default port -- in the same DNS answer as the service's address, rather than leaving a client to discover them during the connection itself. HTTPS is a fixed specialization of the general-purpose SVCB record for web traffic specifically; a browser that resolves an HTTPS record for a domain can open a QUIC/HTTP-3 connection directly, skipping the extra round trip of first connecting over TCP and negotiating ALPN during the TLS handshake. Because the record is new relative to the rest of DNS, a resolver or client that doesn't understand it simply ignores it and falls back to ordinary A/AAAA resolution, so publishing one is additive rather than something that can break older clients.
• TLD (top-level domain) — A top-level domain (TLD) is the last label in a domain name, the part after the final dot, such as .com, .net, or a two-letter country code like .uk; the authoritative list of all TLDs is published by IANA as the DNS root zone. TLDs fall into a few categories: generic TLDs (gTLDs) like .com and .org, country-code TLDs (ccTLDs) like .de or .jp, and newer generic TLDs delegated under ICANN's expansion program since 2012, such as .app or .shop. Each TLD is operated by a registry under contract with ICANN -- a delegation model originally described in RFC 1591 -- which accredits the registrars that sell domain names under it. A domain's registration details, including its registry, registrar, and expiry date, are published through WHOIS or the newer RDAP protocol. AdminKit's WHOIS tool looks up this registration data for any domain, regardless of which TLD it's registered under.
• TSIG (Transaction Signature) — TSIG (Transaction Signature) is a mechanism, defined in RFC 8945, for authenticating a DNS message using a secret key shared between two servers, rather than trusting the message based on where it came from. Each signed message carries a keyed-hash (HMAC) computed over its contents plus a timestamp, so the receiving server can confirm both that the sender holds the shared secret and that the message hasn't been replayed or altered in transit. It is most commonly used to control zone transfers (AXFR) and dynamic DNS updates: instead of, or alongside, restricting those operations to an allow-list of IP addresses, a server can require a valid TSIG signature, which still works correctly even if the requesting server's IP address changes. Because the secret is shared out of band and never sent in the DNS message itself, TSIG is vulnerable only if that secret leaks, not to IP spoofing.
• TXT record — A TXT record is a DNS entry that holds arbitrary text, originally meant for human-readable notes (RFC 1035) but now used almost entirely to carry machine-readable policy strings that other systems parse automatically. SPF policies, DKIM public keys, DMARC policies, and one-off domain-ownership verification strings for services like a cloud provider or SSL certificate issuer are all published as TXT records on specific names, and a domain can publish multiple unrelated TXT records at once since each is just a line of text with no structure the DNS protocol itself enforces. Because TXT records have no type-specific syntax validation at the DNS layer, a malformed SPF or DKIM TXT record can be published without any error, only surfacing as a mail-authentication failure once a receiving server actually tries to parse it.
• WHOIS — WHOIS is a simple TCP-based query/response protocol, defined in RFC 3912, for looking up who registered a domain name or IP address block. A client opens a connection to port 43 of the responsible WHOIS server, sends the name being queried, and the server replies with a block of human-readable text before closing the connection -- there's no authentication, and RFC 3912 deliberately leaves the response's structure undefined, acknowledging the protocol "lacks many of the protocol design attributes" expected of a modern IETF standard, kept this way for historic compatibility rather than reformed. Because each registry formats, labels and discloses fields differently, and redacting data for privacy rules like GDPR is inconsistent across that unstructured text, RDAP -- a newer, JSON-based, schema-consistent protocol -- is gradually replacing it as the standard way to query registration data.
• Wildcard DNS record — A wildcard DNS record uses an asterisk label, such as *.example.com, to answer queries for any subdomain without its own explicit record, a mechanism first described in RFC 1034 and later clarified in RFC 4592. It's commonly used to point every subdomain of a domain at the same server, for example routing arbitrary customer subdomains on a SaaS platform to one load balancer without adding a DNS record per customer. The tradeoff is that a wildcard can silently resolve typos and never-registered subdomains, which helps attackers probing for subdomain takeovers and can mask the fact that a subdomain was never actually provisioned. A wildcard only applies when no more specific record exists for the queried name; an explicit record for a subdomain always takes precedence. AdminKit's DNS lookup tool shows exactly which record answered a query, making wildcard coverage easy to confirm.
• Zone transfer (AXFR) — A zone transfer (AXFR), defined in RFC 5936, is the DNS mechanism a secondary nameserver uses to copy an entire zone's records in one bulk request from the primary authoritative server, rather than querying one record at a time the way ordinary resolution works. It exists for legitimate nameserver replication, but an authoritative server misconfigured to answer AXFR requests from any client, not just its designated secondaries, hands an attacker the domain's complete record set in a single query -- every subdomain, mail server, and internal-sounding hostname at once, information otherwise only discoverable by guessing. Modern DNS providers restrict AXFR to an explicit allow-list of secondary IPs by default; a domain owner can confirm their own setup doesn't permit open transfers rather than assuming it's locked down.

No solutions in this cluster yet — see the full solutions list.