When a client computer sends a request to a Domain Name System DNS server what type of packet is sent?

The Domain Network System (DNS) protocol helps Internet users and network devices discover websites using human-readable hostnames, instead of numeric IP addresses.

The DNS process, simplified, works as follows:

  1. A browser, application or device called the DNS client, issues a DNS request or DNS address lookup, providing a hostname such as “example.com”.
  2. The request is received by a DNS resolver, which is responsible for finding the correct IP address for that hostname. The DNS resolver looks for a DNS name server that holds the IP address for the hostname in the DNS request.
  3. The resolver starts from the Internet’s root DNS server, moving down the hierarchy to Top Level Domain (TLD) DNS servers (“.com” in this case), down to the name server responsible for the specific domain “example.com”.
  4. When the resolver reaches the authoritative DNS name server for “example.com”, it receives the IP address and other relevant details, and returns it to the DNS client. The DNS request is now resolved.
  5. The DNS client device can connect to the server directly using the correct IP address.

History of DNS

The idea of mapping human-readable hostnames to numerical addresses originated in the 1970s, with ARPANET, the predecessor of the modern internet. The Stanford Research Institute (SRI) was responsible for maintaining a text file called hosts.txt that mapped hostnames to computer addresses on ARPANET. To add an entry to the hosts file, users would call SRI staff during business hours, and they would add the host and its associated numeric address manually to the file.

In the 1980s it was understood that a centralized, manually updated host file was not a scalable approach. John Postel of the University of Southern California, whose team was responsible for the ARPANET Assigned Numbers List, assigned the task of creating an automated naming system to Paul Mockapetris. Mockapetris was supposed to find a compromise between five competing technical solutions, but instead he created his own solution, the Domain Name System.

In 1984, four UC Berkeley students wrote the first DNS name server implementation for unix, and named it BIND. In the 1990s BIND was ported to Windows NT. To date, it is the world’s most widely used DNS software.

In 1987 DNS was formalized in RFC 1035.

DNS Protocol Specification

The Domain Namespace

The DNS namespace governs public hostnames used on the Internet. The namespace is a tree structure, with each node in the tree having a textual label and zero or more DNS resource records (RR) describing the domain.

The domain name consists of the label, together with the label of its parent nodes, separated by a dot (as in “example.com”). The domain namespace is divided into zones, and each zone is delegated to a specific legal entity for administration and management.

Domain Name Syntax and Format

A domain name consists of one or more parts called labels, which are separated by dots. A label may contain up to 63 characters. The label at the extreme right is the top-level domain (TLD), and the next labels from right to left are lower down in the namespace hierarchy. Each label is known as a subdomain of the label above it. DNS allows up to 127 hierarchical levels.

For example, “forum.support.example.com” represents a subdomain “forum” under the subdomain “support”, under the domain “example”, under the top level domain “.com”.

Architecture of DNS Resolver and Name Server

There are two key components that resolve DNS requests by clients: a DNS resolver and a DNS name server.

DNS Resolver

Also called a recursive resolver, this is a server designed to receive DNS queries from web browsers and other applications or network devices. It receives a hostname, and is responsible for tracking down the IP address for that hostname:

  1. The resolver looks for the required DNS resource record in its local cache or that of the operating system on the local device.
  2. If not found, it looks for a direct reference to the authoritative name server of the domain’s DNS zone.
  3. Failing that, it performs a recursive query - the resolver contacts a DNS Root Server and receives details of a TLD Name Server for relevant TLD, e.g. “.com”.
  4. Via the TLD Name Server, it receives details of the Authoritative Name Server, and asks it for the IP that matches the requested hostname.

In reality, resolvers do not go through this entire process for every recursive query, because part of the journey, including DNS server addresses, may already be stored in local cache.

Authoritative Name Server

The authoritative name server is the last stop in a DNS query. It holds the DNS Master File for the DNS zone it manages, which contains the trusted, correct resource records for all domains in the zone.

In some cases, the authoritative name server routes the DNS resolver to another name server that contains specific records for a subdomain, for example, support.example.com. If a CNAME or ALIAS record is used, the name server redirects the DNS resolver to another hostname, for which the requested hostname is an alias, and the DNS resolution process starts over.

DNS Message Format

DNS communication occurs via two types of messages: queries and replies. Both DNS query format and reply format consist of the following sections:

  • The header section contains Identification; Flags; Number of questions; Number of answers; Number of authority resource records (RRs); and Number of additional resource records.
  • The flag field contains sections of one or four bits, indicating type of message, whether the name server is authoritative; whether the query is recursive or not, whether request was truncated, and status.
  • The question section contains the domain name and type of record (A, AAAA, MX, TXT, etc.) being resolved. Each label in the domain name is prefixed by its length.
  • The answer section has the resource records of the queried name.

DNS Transport Protocol

DNS uses the User Datagram Protocol (UDP) on port 53 to serve DNS queries. UDP is preferred because it is fast and has low overhead. A DNS query is a single UDP request from the DNS client followed by a single UDP reply from the server.

If a DNS response is larger than 512 bytes, or if a DNS server is managing tasks like zone transfers (transferring DNS records from primary to secondary DNS server), the Transmission Control Protocol (TCP) is used instead of UDP, to enable data integrity checks.

DNS Master Files (Zone Files)

A DNS Master File is a text file stored on a DNS name server, which defines the DNS information for a single DNS zone. The file contains the following data:

  • Global Time to Live (TTL) - how long records should be kept in local DNS cache.
  • Start of Authority (SOA) record—primary authoritative name server for the zone.
  • One or more resource records - see more details below.

DNS Resource Records

Resource Records are used to store hostnames, IP addresses and other information in DNS name servers. A record is made up of the following fields:

name

ttl

record class

record type

record data

  • Name is an alphanumeric identifier of the DNS record
  • TTL (time to live) specifies how long the record should be kept in local cache
  • Record class indicates the namespace—typically IN, the Internet namespace
  • Record type is the DNS record type—for example an A, CNAME, MX
  • Record data contains the DNS values, for example the IP address for a hostname

The most common DNS record types supported by the DNS protocol:

  • Name Server records (NS)—specifies the authoritative name server for a DNS zone
  • IPv4 Address Mapping records (A)—a hostname and its IPv4 address
  • IPv6 Address records (AAAA)—a hostname and its IPv6 address
  • Canonical Name records (CNAME)—points a hostname to an alias
  • Mail eXchanger record (MX)—specifies an SMTP email server for the domain

Next-Generation DNS

DNS can be more than just a routing mechanism connecting hostnames with IPs. Advanced DNS solutions leverage the DNS infrastructure for new use cases:

  • Multi CDN - dynamically selecting one of several CDNs to give each user and optimal experience
  • Global server load balancing (GSLB) - routing connections intelligently between data centers distributed around the world
  • Geographical routing - routing users to the network resource that is physically nearest to them
  • Cloud migration - integrating between on-premise data centers and the cloud and copying or synchronizing data at large scale
  • Internet traffic management - routing traffic intelligently using information about resource readiness, load and network conditions, to dramatically improve performance

These capabilities are made possible by next-generation managed DNS servers that are able to intelligently route and filter traffic. Learn more about NS1’s intelligent DNS platform and take DNS to the next level.