google.com, github.com, wikipedia.org, cloudflare.com
Enter a domain and click Lookup to see IP addresses, DNS records and WHOIS information
In the early days of the ARPANET, the predecessor to the modern internet, hostnames and their corresponding addresses were managed through a single file called HOSTS.TXT. This file was maintained by the Stanford Research Institute's Network Information Center and distributed via FTP to all connected hosts. As the network grew, this centralized system became unsustainable due to increasing traffic, name collisions, and the administrative burden of keeping every host's copy of the file synchronized. [Wikipedia, Hosts File] [Wikipedia, DNS]
In 1983, Paul Mockapetris, working at the request of Jon Postel at the University of Southern California's Information Sciences Institute, designed and implemented the Domain Name System to solve the scaling problems of the HOSTS.TXT file. Mockapetris and Postel are jointly acknowledged as the inventors of DNS. Mockapetris authored RFC 882 and RFC 883, which introduced the concepts of domain names, name servers, and resource records. The DNS replaced the centralized model with a distributed, hierarchical database that delegated authority for different parts of the namespace to independent organizations. [Wikipedia, Paul Mockapetris] [IETF, RFC 882]
The first seven generic top-level domains (.com, .edu, .gov, .int, .mil, .net, and .org) were defined in RFC 920 in 1984 and implemented in the root zone in January 1985. That same year the first .com domain, symbolics.com, was registered. The original DNS implementation was refined through subsequent RFCs, including RFC 1034 and RFC 1035 in November 1987, which remain the foundational documents for DNS operation today. [IETF, RFC 920] [IETF, RFC 1035]
The 1990s saw explosive growth of DNS as the internet opened to commercial use. In 1998, the Internet Corporation for Assigned Names and Numbers was formed to coordinate DNS management, taking over responsibilities previously handled by the U.S. government under contract. ICANN introduced new generic top-level domains and established the Uniform Domain Name Dispute Resolution Policy to handle domain name conflicts. [Wikipedia, ICANN] [ICANN, History]
DNS Security Extensions were standardized in March 2005 through RFC 4033, RFC 4034, and RFC 4035, adding authentication and data integrity to DNS responses using public-key cryptography. These standards were driven in part by the discovery of increasingly practical cache poisoning techniques, culminating in Dan Kaminsky's landmark 2008 disclosure which showed that DNS resolver caches could be poisoned rapidly using the original DNS protocol. The root zone signing in July 2010 marked a major milestone in securing the DNS infrastructure by establishing a global chain of trust. DNS over TLS was standardized in RFC 7858 in May 2016 to encrypt DNS queries. DNS over HTTPS was standardized in RFC 8484 in October 2018, making queries indistinguishable from regular web traffic. [Wikipedia, DNSSEC] [Wikipedia, Kaminsky Attack] [RFC 7858, DNS over TLS] [RFC 8484, DNS over HTTPS]
DNS organizes domain names in a hierarchical tree structure. At the top are root name servers, represented by a dot. Below the root are top-level domains like .com, .org, and country-code domains like .uk and .jp. Under each top-level domain are second-level domains such as google.com and wikipedia.org. Additional subdomains can be created indefinitely, like mail.google.com or support.google.com. This hierarchy allows distributed management where each level delegates authority to the level below. [Wikipedia, DNS Structure]
When you type a domain name into your browser, your computer sends a query to a DNS resolver, typically provided by your internet service provider or a public service like Google DNS or Cloudflare. If the resolver does not have the answer cached, it begins a recursive query starting at the root servers. The root server responds with the address of the appropriate top-level domain nameserver. The resolver then queries the TLD server, which responds with the authoritative nameserver for the specific domain. Finally, the resolver queries the authoritative nameserver, which returns the requested record such as an IP address. [Cloudflare, DNS Explained]
There are 13 logical root name servers, identified by letters A through M. These are operated by 12 independent organizations distributed across more than 1,500 physical server instances worldwide using Anycast routing. The root servers contain the authoritative records for all top-level domains and are critical infrastructure for the internet. The root zone file, which lists all top-level domains and their authoritative nameservers, is managed by IANA (a function of ICANN), with Verisign handling the technical operation of publishing the signed root zone. [Wikipedia, Root Name Server] [ICANN, Root Server System]
To reduce load on authoritative nameservers and improve performance, DNS responses include a Time to Live value that indicates how long a resolver should cache a record. TTL values are specified in seconds, with common values ranging from 300 seconds for frequently changing records to 86400 seconds for stable records. Caching allows subsequent queries for the same domain to be answered immediately from the resolver's cache without traversing the hierarchy again. [RFC 1035, TTL Definition]
Address records are the most fundamental DNS records. A records map a domain name to an IPv4 address, a 32-bit number expressed as four decimal numbers separated by periods. AAAA records serve the same purpose for IPv6 addresses, which are 128 bits long and written in hexadecimal notation. Every domain that hosts a website must have at least one A or AAAA record pointing to a web server's IP address. [Wikipedia, DNS Record Types]
Canonical Name records create aliases that point one domain name to another. For example, www.example.com might be a CNAME pointing to example.com, which has the actual A record. CNAME records cannot coexist with other record types for the same name except for DNSSEC-related record types. They are commonly used to point subdomains to external services or to allow multiple domains to share the same IP address without duplicating A records. [RFC 2181, CNAME Clarification]
Mail Exchange records specify the mail servers responsible for accepting email on behalf of a domain. Each MX record includes a priority value, where lower numbers indicate higher preference. Mail delivery agents attempt to deliver to the lowest-numbered priority server first, and fall back to higher-numbered servers if the primary is unavailable. Multiple MX records allow for redundancy and load distribution across email servers. [Wikipedia, MX Record]
Text records store arbitrary text data associated with a domain. They serve multiple purposes including email authentication through SPF, DKIM, and DMARC policies, domain ownership verification for services like Google Search Console, and human-readable information about the domain. TXT records can contain multiple strings of text and are limited to 255 bytes per string, though multiple strings can be concatenated by resolvers to represent longer values. [Wikipedia, TXT Record]
Name Server records delegate authority for a domain to specific nameservers. They appear in both the parent zone pointing to child nameservers and in the authoritative zone itself. Start of Authority records contain administrative information about a domain including the primary nameserver, the responsible person's email address encoded as a domain name, the serial number used to signal zone changes for transfers, and timing parameters for refresh and retry intervals. Every DNS zone must have exactly one SOA record. [RFC 1035, SOA Definition]
PTR records provide reverse DNS lookup, mapping an IP address back to a domain name. SRV records specify servers for specific services, including port numbers and protocols, commonly used by VoIP and messaging applications. CAA records allow domain owners to specify which certificate authorities are authorized to issue TLS certificates for their domain. TLSA records support DANE (DNS-Based Authentication of Named Entities), which allows TLS certificates to be authenticated directly through DNS without relying solely on third-party certificate authorities. [IANA, DNS Parameters]
Original DNS specifications were designed for a trusted network environment and lacked security mechanisms. This exposes DNS to various attacks including cache poisoning, where attackers insert false records into a resolver's cache, redirecting users to malicious websites. Other attacks include DNS spoofing, man-in-the-middle interception, and DNS amplification attacks used for distributed denial of service. In 2008, security researcher Dan Kaminsky publicly disclosed a highly practical cache poisoning technique that could compromise most DNS resolvers within seconds, demonstrating the urgency of deploying DNSSEC. This disclosure is widely credited with accelerating real-world DNSSEC adoption. [Wikipedia, DNS Cache Poisoning] [Wikipedia, DNS Spoofing]
DNS Security Extensions add authentication and data integrity to DNS responses using public-key cryptography. DNSSEC allows resolvers to verify that responses came from the authoritative nameserver and were not modified in transit. The system uses a chain of trust starting from the root zone, which was cryptographically signed in July 2010. Each zone signs its records with a private key, and resolvers can verify the signature using the corresponding public key published in the parent zone. DNSSEC was standardized in March 2005 through RFC 4033, RFC 4034, and RFC 4035, though adoption has been slower than anticipated due to operational complexity. Notably, DNSSEC authenticates DNS data but does not encrypt DNS queries, meaning the domains being looked up remain visible on the network. [ICANN, DNSSEC] [Wikipedia, DNSSEC]
Traditional DNS queries are sent in plaintext over UDP or TCP, allowing anyone on the network path to see which domains are being queried. DNS over TLS (DoT), standardized in RFC 7858 in May 2016, encrypts DNS queries using a dedicated port 853 and is preferred by many enterprise and ISP networks. DNS over HTTPS (DoH), standardized in RFC 8484 in October 2018, uses standard HTTPS port 443, making queries indistinguishable from regular web traffic, which prevents blocking but has raised concerns about centralization. Major public DNS providers including Cloudflare, Google, and Quad9 support both standards. [RFC 8484, DNS over HTTPS] [RFC 7858, DNS over TLS]
Domain owners should implement DNSSEC signing for their zones, use registry locks to prevent unauthorized changes, monitor DNS traffic for anomalies, and minimize TTL values during planned infrastructure changes. Regular users can improve their DNS security by using public resolvers that support DNSSEC validation and encrypted transport, keeping systems updated to prevent local DNS hijacking, and being aware of certificate warnings which may indicate DNS-related attacks. [NIST, DNS Security Guidance]