Domain Name System

80 languages

Tools

From Wikipedia, the free encyclopedia

(Redirected from

)

"DNS" redirects here. For other uses, see

Domain Name System

Abbreviation

DNS

Purpose

To identify resources on networks

Developer(s)

Introduction

November 1983

; 42 years ago

(

)

(

)

(

)

The

Domain Name System

(

DNS

) is a hierarchical and distributed

that provides a naming system for

, services, and other

resources on the Internet or other

(IP) networks. It

associates various information with

(

)

assigned to each of the associated entities. Most prominently, it

translates readily memorized domain names to the numerical

needed for locating and identifying computer services and devices with the

underlying

The Domain Name System has been an

essential component of the functionality of the Internet since 1985.

The Domain Name System delegates the responsibility of assigning domain

names and mapping those names to Internet resources by designating

for each domain. Network administrators may delegate

authority over

of their allocated name space to other name servers.

This mechanism provides distributed and

service and was designed to

avoid a single large central database. In addition, the DNS specifies the

technical functionality of the

service that is at its core. It defines

the DNS protocol, a detailed specification of the data structures and

exchanges used in the DNS, as part of the

The Internet maintains two principal

, the domain name hierarchy and the

The Domain Name System maintains the domain name hierarchy

and provides translation services between it and the address spaces. Internet name

servers and a

implement the Domain Name System. A DNS name

server is a server that stores the DNS records for a domain; a DNS name server

responds with answers to queries against its database.

The most common types of records stored in the DNS database are for start of

authority (

), IP addresses (

and

(MX), name servers

(NS), pointers for

(PTR), and

(CNAME).

Although not intended to be a general-purpose database, DNS has been expanded over time to store records for other types of

data for either automatic lookups, such as

records, or for human queries such as

responsible person

(RP) records. As

a general-purpose database, the DNS has also been used in combating

(spam) by storing

. The DNS

database is conventionally stored in a structured text file, the

, but other database systems are common.

The Domain Name System originally used the

(UDP) as transport over IP. Reliability, security, and

privacy concerns spawned the use of the

(TCP) as well as numerous other protocol

developments.

Function

[

]

An often-used analogy to explain the DNS is that it serves as the

for the Internet by translating human-friendly

computer

into IP addresses. For example, the hostname

www.example.com

within the domain name

translates to the addresses

93.184.216.34

(

) and

2606:2800:220:1:248:1893:25c8:1946

(

). The DNS can be quickly and

transparently updated, allowing a service's location on the network to change without affecting the end users, who continue

to use the same hostname. Users take advantage of this when they use meaningful Uniform Resource Locators (

) and

without having to know how the computer actually locates the services.

An important and

function of the DNS is its central role in distributed Internet services such as

and

When a user accesses a distributed Internet service using a URL, the domain name of the

is translated to the IP address of a server that is proximal to the user.

The key functionality of the DNS exploited

here is that different users can

simultaneously

receive different translations for the

same

domain name, a key point of

divergence from a traditional phone-book view of the DNS. This process of using the DNS to assign proximal servers to users

is key to providing faster and more reliable responses on the Internet and is widely used by most major Internet

services.

The DNS reflects the structure of administrative responsibility on the Internet.

Each subdomain is a

administrative autonomy delegated to a manager. For zones operated by a

, administrative information is often

complemented by the registry's

and

services.

That data can be used to gain insight on, and track responsibility

for, a given host on the Internet.

History

[

]

Using a simpler, more memorable name in place of a host's numerical address dates back to the

era. The Stanford

Research Institute (now

) maintained a text file named

that mapped host names to the numerical

addresses of computers on the ARPANET.

developed and maintained the first ARPANET directory.

Maintenance of numerical addresses, called the Assigned Numbers List, was handled by

at the

(ISI), whose team worked closely with SRI.

Addresses were assigned manually. Computers, including their hostnames and addresses, were added to the primary file by

contacting the SRI

(NIC), directed by Feinler, via

during business hours.

Later,

Feinler set up a

directory on a server in the NIC for retrieval of information about resources, contacts, and

entities.

She and her team developed the concept of domains.

Feinler suggested that domains should be based on the

location of the physical address of the computer.

Computers at educational institutions would have the domain

, for

example.

She and her team managed the Host Naming Registry from 1972 to 1989.

By the early 1980s, maintaining a single, centralized host table had become slow and unwieldy and the emerging network

required an automated naming system to address technical and personnel issues. Postel directed the task of forging a

compromise between five competing proposals of solutions to

. Mockapetris instead created the Domain Name

System in 1983 while at the

The

published the original specifications in RFC 882 and RFC 883 in November 1983.

These were updated in RFC 973 in January 1986.

In 1984, four

students, Douglas Terry, Mark Painter, David Riggle, and Songnian Zhou, wrote the first

implementation for the Berkeley Internet Name Domain, commonly referred to as

In 1985, Kevin Dunlap of

substantially revised the DNS implementation.

, Phil Almquist, and

then took over BIND maintenance.

was founded in 1994 by

, and

, expressly to provide a home

for BIND development and maintenance. BIND versions from 4.9.3 onward were developed and maintained by ISC, with support

provided by ISC's sponsors. As co-architects/programmers, Bob Halley and Paul Vixie released the first production-ready

version of BIND version 8 in May 1997. Since 2000, over 43 different core developers have worked on BIND.

In November 1987, RFC 1034

and RFC 1035

superseded the 1983 DNS specifications. Several additional

have proposed extensions to the core DNS protocols.

Structure

[

]

Domain name space

[

]

The domain name space consists of a

. Each node or leaf in the tree has a

label

and zero or more

resource records

(RR), which hold information associated with the domain name.

The domain name itself consists of the

label, concatenated with the name of its parent node on the right, separated by a dot.

: §3.1

The tree sub-divides into

zones

beginning at the

may consist of as many domains and subdomains as the

zone manager chooses.

DNS can also be partitioned according to

class

where the separate classes can be thought of as an

array of parallel namespace trees.

: §4.2

The hierarchical Domain Name System for class

Internet

, organized into zones, each served by a name

server

Administrative responsibility for any zone may be divided by creating

additional zones. Authority over the new zone is said to be

delegated

to a designated name server. The parent zone ceases to be

authoritative for the new zone.

: §4.2

Domain name syntax, internationalization

[

]

The definitive descriptions of the rules for forming domain names

appear in RFC 1035, RFC 1123, RFC 2181, and RFC 5892.

consists of one or more parts, technically called

labels

, that are

conventionally

, and delimited by dots, such as

example.com.

The right-most label conveys the

; for example, the

domain name www.example.com belongs to the top-level domain

com

The hierarchy of domains descends from right to left; each label to

the left specifies a subdivision, or

of the domain to the

right. For example, the label

example

specifies a subdomain of the

com

domain, and

www

is a subdomain of example.com. This tree of subdivisions may have up to 127 levels.

A label may contain zero to 63 characters, because the length is only allowed to take 6 bits. The null label of length zero

is reserved for the root zone. The full domain name may not exceed the length of 253 characters in its textual

representation (or 254 with the trailing dot).

In the internal binary representation of the DNS this maximum length of

253 requires 255 octets of storage, as it also stores the length of the first of many labels and adds last null byte.

255

length is only achieved with at least 6 labels (counting the last null label).

Although no technical limitation exists to prevent domain name labels from using any character that is representable by an

octet, hostnames use a preferred format and character set. The characters allowed in labels are a subset of the

character set, consisting of characters

through

, digits

through

, and hyphen. This rule is known as the

LDH rule

(letters, digits, hyphen). Domain names are interpreted in a case-independent manner.

Labels may not start or

end with a hyphen.

An additional rule requires that top-level domain names should not be all-numeric.

The limited set of ASCII characters permitted in the DNS prevented the representation of names and words of many languages

in their native alphabets or scripts. To make this possible,

approved the

(IDNA) system, by which user applications, such as web browsers, map

strings into the valid DNS

character set using

. In 2009, ICANN approved the installation of internationalized domain name

. In addition, many

of the existing top-level domain names (

) have adopted the IDNA

system, guided by RFC 5890, RFC 5891, RFC 5892, RFC 5893.

Name servers

[

]

The Domain Name System is maintained by a

system, which uses the

. The nodes of

this database are the

. Each domain has at least one authoritative DNS server that publishes information about

that domain and the name servers of any domains subordinate to it. The top of the hierarchy is served by the

, the servers to query when looking up (

resolving

) a

Authoritative name server

[

]

authoritative

name server is a name server that only gives

to DNS queries from data that have been configured by

an original source, for example, the domain administrator or by dynamic DNS methods, in contrast to answers obtained via a

query to another name server that only maintains a cache of data.

An authoritative name server can either be a

primary

server or a

secondary

server. Historically the terms

and

primary/secondary

were sometimes used interchangeably

but the current practice is to use the latter form. A primary

server is a server that stores the original copies of all zone records. A secondary server uses a special

in the DNS protocol in communication with its primary to maintain an identical copy of the primary

records.

Every DNS zone must be assigned a set of authoritative name servers. This set of servers is stored in the parent domain

zone with name server (NS) records.

An authoritative server indicates its status of supplying definitive answers, deemed

authoritative

, by setting a protocol

flag, called the "

Authoritative Answer

" (

)

in its responses.

This flag is usually reproduced prominently in the

output of DNS administration query tools, such as

, to indicate

that the responding name server is an authority for the

domain name in question.

When a name server is designated as the authoritative server for a domain name for which it does not have authoritative

data, it presents a type of error called a "lame delegation" or "lame response".

Operation

[

]

Address resolution mechanism

[

]

Domain name resolvers determine the domain name servers responsible for the domain name in question by a sequence of

queries starting with the right-most (top-level) domain label.

A DNS resolver that implements the iterative approach

mandated by RFC 1034; in this case, the resolver

consults three name servers to resolve the

"www.wikipedia.org".

For proper operation of its domain name resolver, a network host is

configured with an initial cache (

hints

) of the known addresses of

the root name servers. The hints are updated periodically by an

administrator by retrieving a dataset from a reliable source.

Assuming the resolver has no cached records to accelerate the

process, the resolution process starts with a query to one of the root

servers.

In typical operation, the root servers do not answer

directly, but respond with a referral to more authoritative servers,

e.g., a query for "www.wikipedia.org" is referred to the

org

servers.

The resolver now queries the servers referred to, and iteratively

repeats this process until it receives an authoritative answer. The

diagram illustrates this process for the host that is named by the

"www.wikipedia.org".

This mechanism would place a large traffic burden on the root servers, if every resolution on the Internet required

starting at the root. In practice

is used in DNS servers to off-load the root servers, and as a result, root name

servers actually are involved in only a relatively small fraction of all requests.

Recursive and caching name server

[

]

In theory, authoritative name servers are sufficient for the operation of the Internet. However, with only authoritative

name servers operating, every DNS query must start with recursive queries at the

of the Domain Name System and

each user system would have to implement resolver software capable of recursive operation.

To improve efficiency, reduce DNS traffic across the Internet, and increase performance in end-user applications, the

Domain Name System supports DNS cache servers which store DNS query results for a period of time determined in the

configuration (

) of the domain name record in question. Typically, such caching DNS servers also implement the

recursive algorithm necessary to resolve a given name starting with the DNS root through to the authoritative name servers

of the queried domain. With this function implemented in the name server, user applications gain efficiency in design and

operation.

The combination of DNS caching and recursive functions in a name server is not mandatory; the functions can be implemented

independently in servers for special purposes.

(ISP) typically provide recursive and caching name servers for their customers. In addition,

many home networking routers implement DNS caches and recursion to improve efficiency in the local network.

DNS resolvers

[

]

The

of the DNS is called a DNS resolver. A resolver is responsible for initiating and sequencing the queries

that ultimately lead to a full resolution (translation) of the resource sought, e.g., translation of a domain name into an

IP address. DNS resolvers are classified by a variety of query methods, such as

recursive

non-recursive

, and

iterative

. A

resolution process may use a combination of these methods.

In a

non-recursive query

, a DNS resolver queries a DNS server that provides a record either for which the server is

authoritative, or it provides a partial result without querying other servers. In case of a

, the non-

recursive query of its local

delivers a result and reduces the load on upstream DNS servers by caching DNS

resource records for a period of time after an initial response from upstream DNS servers.

In a

recursive query

, a DNS resolver queries a single DNS server, which may in turn query other DNS servers on behalf of the

requester. For example, a simple stub resolver running on a

typically makes a recursive query to the DNS server

run by the user's ISP. A recursive query is one for which the DNS server answers the query completely by querying other

name servers as needed. In typical operation, a client issues a recursive query to a caching recursive DNS server, which

subsequently issues non-recursive queries to determine the answer and send a single answer back to the client. The

resolver, or another DNS server acting recursively on behalf of the resolver, negotiates use of recursive service using

bits in the query headers. DNS servers are not required to support recursive queries.

The

iterative query

procedure is a process in which a DNS resolver queries a chain of one or more DNS servers. Each server

refers the client to the next server in the chain, until the current server can fully resolve the request. For example, a

possible resolution of www.example.com would query a global root server, then a "com" server, and finally an "example.com"

server.

Circular dependencies and glue records

[

]

Name servers in delegations are identified by name, rather than by IP address. This means that a resolving name server must

issue another DNS request to find out the IP address of the server to which it has been referred. If the name given in the

delegation is a subdomain of the domain for which the delegation is being provided, there is a

In this case, the name server providing the delegation must also provide one or more IP addresses for the

mentioned in the delegation. This information is called

glue

The delegating name server provides this glue in

the form of records in the

additional section

of the DNS response, and provides the delegation in the

authority section

the response. A glue record is a combination of the name server and IP address.

For example, if the

for example.org is ns1.example.org, a computer trying to resolve

www.example.org first resolves ns1.example.org. As ns1 is contained in example.org, this requires resolving example.org

first, which presents a circular dependency. To break the dependency, the name server for the

org

includes glue along with the delegation for example.org.

The glue records are address records that provide IP addresses for

ns1.example.org. The resolver uses one or more of these IP addresses to query one of the domain's authoritative servers,

which allows it to complete the DNS query.

Record caching

[

]

A common approach to reduce the query load on DNS servers is to cache the results of name resolution locally or on

intermediary resolver hosts. Each DNS query result comes with a time to live (TTL), which indicates how long the

information remains valid before it needs to be discarded or refreshed. This TTL is determined by the administrator of the

authoritative DNS server and can range from a few seconds to several days or even weeks.

As a result of this distributed caching architecture, changes to DNS records do not propagate throughout the network

immediately, but require all caches to expire and to be refreshed after the TTL. RFC 1912 conveys basic rules for

determining appropriate TTL values.

Some resolvers may override TTL values, as the protocol supports caching for up to sixty-eight years or no caching at all.

, i.e. the caching of the fact of non-existence of a record, is determined by name servers authoritative

for a zone which must include the

(SOA) record when reporting no data of the requested type exists. The

value of the

minimum

field of the SOA record and the TTL of the SOA itself is used to establish the TTL for the negative

answer.

Reverse lookup

[

]

is a query of the DNS for domain names when the IP address is known. Multiple domain names may be

associated with an IP address. The DNS stores IP addresses in the form of domain names as specially formatted names in

pointer (PTR) records within the infrastructure top-level domain

. For IPv4, the domain is in-addr.arpa.

For IPv6, the

reverse lookup domain is ip6.arpa. The IP address is represented as a name in reverse-ordered octet representation for

IPv4, and reverse-ordered nibble representation for IPv6.

When performing a reverse lookup, the DNS client converts the address into these formats before querying the name for a PTR

record following the delegation chain as for any DNS query. For example, assuming the IPv4 address 208.80.152.2 is assigned

to Wikimedia, it is represented as a DNS name in reverse order: 2.152.80.208.in-addr.arpa. When the DNS resolver gets a

pointer (PTR) request, it begins by querying the root servers, which point to the servers of

(ARIN) for the 208.in-addr.arpa zone. ARIN's servers delegate 152.80.208.in-addr.arpa to Wikimedia to which the

resolver sends another query for 2.152.80.208.in-addr.arpa, which results in an authoritative response.

Client lookup

[

]

DNS resolution sequence

Users generally do not communicate directly with a DNS resolver.

Instead DNS resolution takes place transparently in applications such

, and other Internet applications.

When an application makes a request that requires a domain name

lookup, such programs send a resolution request to the

the local operating system, which in turn handles the communications

required.

The DNS resolver will almost invariably have a cache (see above)

containing recent lookups. If the cache can provide the answer to the

request, the resolver will return the value in the cache to the program that made the request. If the cache does not

contain the answer, the resolver will send the request to one or more designated DNS servers. In the case of most home

users, the ISP to which the machine connects will usually supply this DNS server: such a user will either have configured

that server's address manually or allowed

to set it; however, where systems administrators have configured systems to

use their own DNS servers, their DNS resolvers point to separately maintained name servers of the organization. In any

event, the name server thus queried will follow the process outlined

, until it either successfully finds a result or

does not. It then returns its results to the DNS resolver; assuming it has found a result, the resolver duly caches that

result for future use, and hands the result back to the software which initiated the request.

Broken resolvers

[

]

Some large ISPs have configured their DNS servers to violate rules, such as by disobeying TTLs, or by indicating that a

domain name does not exist just because one of its name servers does not respond.

Some applications such as web browsers maintain an internal DNS cache to avoid repeated lookups via the network. This

practice can add extra difficulty when debugging DNS issues as it obscures the history of such data. These caches typically

use very short caching times on the order of one minute.

represents a notable exception: versions up to IE 3.x cache DNS records for 24 hours by default. Internet

Explorer 4.x and later versions (up to IE 8) decrease the default timeout value to half an hour, which may be changed by

modifying the default configuration.

When

detects issues with the DNS server it displays a specific error message.

Other applications

[

]

The Domain Name System includes several other functions and features.

Hostnames and IP addresses are not required to match in a one-to-one relationship. Multiple hostnames may correspond to a

single IP address, which is useful in

, in which many web sites are served from a single host.

Alternatively, a single hostname may resolve to many IP addresses to facilitate

and

multiple server instances across an enterprise or the global Internet.

DNS serves other purposes in addition to translating names to IP addresses. For instance,

use DNS to

find the best mail server to deliver

: An

provides a mapping between a domain and a mail exchanger; this

can provide an additional layer of fault tolerance and load distribution.

The DNS is used for efficient storage and distribution of IP addresses of block-listed email hosts. A common method is to

place the IP address of the subject host into the sub-domain of a higher level domain name, and to resolve that name to a

record that indicates a positive or a negative indication.

For example:

The address

203.0.113.5

is block-listed. It points to

5.113.0.203.blocklist.example

, which resolves to

127.0.0.1

The address

203.0.113.6

is not block-listed and points to

6.113.0.203.blocklist.example

. This hostname is either not

configured, or resolves to

127.0.0.2

E-mail servers can query blocklist.example to find out if a specific host connecting to them is in the block list. Many

such block lists, either subscription-based or free of cost, are available for use by email administrators and anti-spam

software.

To provide resilience in the event of computer or network failure, multiple DNS servers are usually provided for coverage

of each domain. At the top level of global DNS, thirteen groups of

exist, with additional "copies" of

them distributed worldwide via

addressing.

(DDNS) updates a DNS server with a client IP address on-the-fly, for example, when moving between ISPs or

mobile

, or when the IP address changes administratively.

DNS message format

[

]

The DNS protocol uses two types of DNS messages, queries and responses; both have the same format. Each message consists of

a header and four sections: question, answer, authority, and an additional space. A header field (

flags

) controls the

content of these four sections.

The header section consists of the following fields:

Identification

Flags

Number of questions

Number of answers

Number

of authority resource records

(RRs), and

Number of additional RRs

. Each field is 16 bits long, and appears in the order

given. The identification field is used to match responses with queries. After the flags word, the header ends with four

16-bit integers which contain the number of records in each of the sections that follow, in the same order.

DNS Header

Offset

Octet

Transaction ID

OPCODE

RCODE

Number of Questions

Number of Answers

Number of Authority RRs

Number of additional RRs

Transaction ID: 16 bits

Transaction ID

Flags: 16 bits

The flag field consists of sub-fields as follows:

QR: 1 bit

Indicates if the message is a query (0) or a reply (1).

OPCODE: 4 bits

The type can be QUERY (standard query, 0), IQUERY (inverse query, 1), or STATUS (server status request, 2).

AA: 1 bit

Authoritative Answer, in a response, indicates if the DNS server is authoritative for the queried hostname.

TC: 1 bit

TrunCation, indicates that this message was truncated due to excessive length.

RD: 1 bit

Recursion Desired, indicates if the client means a recursive query.

RA: 1 bit

Recursion Available, in a response, indicates if the replying DNS server supports recursion.

Z: 1 bit; (Z) == 0

Zero, reserved for future use.

AD: 1 bit

Authentic Data, in a response, indicates if the replying DNS server verified the data.

CD: 1 bit

Checking Disabled, in a query, indicates that non-verified data is acceptable in a response.

RCODE: 4 bits

Response code, can be NOERROR (0), FORMERR (1, Format error), SERVFAIL (2), NXDOMAIN (3, Nonexistent domain), etc.

Number of Questions: 16 bits

Number of Questions.

Number of Answers: 16 bits

Number of Answers.

Number of Authority RRs: 16 bits

Number of Authority Resource Records.

Number of Additional RRs: 16 bits

Number of Additional Resource Records.

Question section

[

]

The question section has a simpler format than the resource record format used in the other sections.

Each question record

(there is usually just one in the section) contains the following fields:

Resource record (RR) fields

Field

Description

Length (

)

NAME

Name of the requested resource

Variable

TYPE

Type of RR (A, AAAA, MX, TXT, etc.)

CLASS

Class code

The domain name is broken into discrete labels which are concatenated; each label is prefixed by the length of that

label.

Resource records

[

]

The Domain Name System specifies a database of information elements for network resources. The types of information

elements are categorized and organized with a

, the resource records (RRs). Each record has a type

(name and number), an expiration time (

), a class, and type-specific data. Resource records of the same type

are described as a

resource record set

(RRset), having no special ordering. DNS resolvers return the entire set upon query,

but servers may implement

to achieve

. In contrast, the

(DNSSEC) work on the complete set of resource record in canonical order.

When sent over an

network, all records (answer, authority, and additional sections) use the common format

specified in RFC 1035:

: §3

Resource record (RR) fields

Field

Description

Length (

)

NAME

Name of the node to which this record pertains

Variable

TYPE

Type of RR in numeric form (e.g., 15 for MX RRs)

CLASS

Class code

Count of seconds that the RR stays valid (The maximum is 2

−1, which is about 68

years)

RDLENGTH

Length of RDATA field (specified in octets)

RDATA

Additional RR-specific data

Variable, as per

RDLENGTH

NAME

is the fully qualified domain name of the node in the tree.

[

]

On the wire, the name may be shortened

using label compression where ends of domain names mentioned earlier in the packet can be substituted for the end of the

current domain name.

TYPE

is the record type. It indicates the format of the data and it gives a hint of its intended use. For example, the

record is used to translate from a domain name to an

, the

record lists which name servers can answer

lookups on a

, and the

record specifies the mail server used to handle mail for

a domain specified in an e-mail

address.

RDATA

is data of type-specific relevance, such as the IP address for address records, or the priority and hostname for MX

records. Well known record types may use label compression in the RDATA field, but "unknown" record types must not (RFC

3597).

The

CLASS

of a record is set to IN (for

Internet

) for common DNS records involving Internet hostnames, servers, or IP

addresses. In addition, the classes

(CH) and

(HS) exist.

: 11

Each class is an independent name space with

potentially different delegations of DNS zones.

In addition to resource records defined in a

, the domain name system also defines several request types that are

used only in communication with other DNS nodes (

on the wire

), such as when performing zone transfers (AXFR/IXFR) or for

(OPT).

Wildcard records

[

]

The domain name system supports

which specify names that start with the

asterisk label

*

, e.g.,

*.example

DNS records belonging to wildcard domain names specify rules for generating resource records within a

single DNS zone by substituting whole labels with matching components of the query name, including any specified

descendants. For example, in the following configuration, the DNS zone

x.example

specifies that all subdomains, including

subdomains of subdomains, of

x.example

use the mail exchanger (MX)

a.x.example

. The AAAA record for

a.x.example

is needed

to specify the mail exchanger IP address. As this has the result of excluding this domain name and its subdomains from the

wildcard matches, an additional MX record for the subdomain

a.x.example

, as well as a wildcarded MX record for all of its

subdomains, must also be defined in the DNS zone.

x.example.

MX

10

a.x.example.

*.x.example.

MX

10

a.x.example.

a.x.example.

MX

10

a.x.example.

*.a.x.example.

MX

10

a.x.example.

a.x.example.

AAAA

2001:db8::1

The role of wildcard records was refined in

, because the original definition in

was incomplete and

resulted in misinterpretations by implementers.

Protocol extensions

[

]

The original DNS protocol had limited provisions for extension with new features. In 1999, Paul Vixie published in RFC 2671

(superseded by RFC 6891) an extension mechanism, called

(EDNS) that introduced optional

protocol elements without increasing overhead when not in use. This was accomplished through the OPT pseudo-resource record

that only exists in wire transmissions of the protocol, but not in any zone files. Initial extensions were also suggested

(EDNS0), such as increasing the DNS message size in UDP datagrams.

Dynamic zone updates

[

]

use the UPDATE DNS opcode to add or remove resource records dynamically from a zone database

maintained on an authoritative DNS server.

This facility is useful to register network clients into the DNS when they

boot or become otherwise available on the network. As a booting client may be assigned a different IP address each time

from a

server, it is not possible to provide static DNS assignments for such clients.

Transport protocols

[

]

From the time of its origin in 1983 the DNS has used the

(UDP) for transport over IP. Its

limitations have motivated numerous protocol developments for reliability, security, privacy, and other criteria, in the

following decades.

Conventional: DNS over UDP and TCP port 53 (Do53)

[

]

UDP reserves port number 53 for servers listening to queries.

Such a query consists of a clear-text request sent in a

single UDP packet from the client, responded to with a clear-text reply sent in a single UDP packet from the server. When

the length of the answer exceeds 512 bytes and both client and server support

(EDNS), larger

UDP packets may be used.

Use of DNS over UDP is limited by, among other things, its lack of transport-layer encryption,

authentication, reliable delivery, and message length. In 1989, RFC 1123 specified optional

(TCP) transport for DNS queries, replies and, particularly,

. Via fragmentation of long replies, TCP allows

longer responses, reliable delivery, and re-use of long-lived connections between clients and servers. For larger

responses, the server refers the client to TCP transport.

DNS over TLS (DoT)

[

]

Main article:

emerged as an IETF standard for encrypted DNS in 2016, utilizing Transport Layer Security (TLS) to protect the

entire connection, rather than just the DNS payload. DoT servers listen on TCP port 853.

specifies that

opportunistic encryption and authenticated encryption may be supported, but did not make either server or client

authentication mandatory.

DNS over HTTPS (DoH)

[

]

Main article:

was developed as a competing standard for DNS query transport in 2018, tunneling DNS query data over HTTPS,

which transports HTTP over TLS. DoH was promoted as a more web-friendly alternative to DNS since, like DNSCrypt, it uses

TCP port 443, and thus looks similar to web traffic, though they are easily differentiable in practice without proper

padding.

DNS over QUIC (DoQ)

[

]

RFC 9250, published in 2022 by the

, describes DNS over

. It has "privacy properties

similar to DNS over TLS (DoT) [...], and latency characteristics similar to classic DNS over UDP". This method is not the

same as DNS over

Oblivious DoH (ODoH) and predecessor Oblivious DNS (ODNS)

[

]

Main article:

Oblivious DNS (ODNS) was invented and implemented by researchers at

and the

an extension to unencrypted DNS,

before DoH was standardized and widely deployed. Apple and Cloudflare subsequently

deployed the technology in the context of DoH, as

(ODoH).

ODoH combines ingress/egress separation

(invented in ODNS) with DoH's HTTPS tunneling and TLS transport-layer encryption in a single protocol.

DNS over Tor

[

]

DNS may be run over

(VPNs) and

. The privacy gains of Oblivious DNS can be

garnered through the use of the preexisting

network of ingress and egress nodes, paired with the transport-layer

encryption provided by TLS.

DNSCrypt

[

]

Main article:

The

protocol, which was developed in 2011 outside the

standards framework, introduced DNS encryption on the

downstream side of recursive resolvers, wherein clients encrypt query payloads using servers' public keys, which are

published in the DNS (rather than relying upon third-party certificate authorities) and which may in turn be protected by

signatures.

DNSCrypt uses either TCP port 443, the same port as

encrypted web traffic, or UDP port 443.

This introduced not only privacy regarding the content of the query, but also a significant measure of firewall-traversal

capability. In 2019, DNSCrypt was further extended to support an "anonymized" mode, similar to the proposed "Oblivious

DNS", in which an ingress node receives a query which has been encrypted with the public key of a different server, and

relays it to that server, which acts as an egress node, performing the recursive resolution.

Privacy of user/query pairs

is created, since the ingress node does not know the content of the query, while the egress node does not know the identity

of the client. DNSCrypt was first implemented in production by

in December 2011. There are several free and open

source software implementations that additionally integrate ODoH.

It is available for a variety of operating systems,

including Unix, Apple iOS, Linux, Android, and Windows.

Security issues

[

]

Originally, security concerns were not major design considerations for DNS software or any software for deployment on the

early Internet, as the network was not open for participation by the general public. However, the expansion of the Internet

into the commercial sector in the 1990s changed the requirements for security measures to protect

and user

Several vulnerability issues were discovered and exploited by malicious users. One such issue is

, in

which data is distributed to caching resolvers under the pretense of being an authoritative origin server, thereby

polluting the data store with potentially false information and long expiration times (time-to-live). Subsequently,

legitimate application requests may be redirected to network hosts operated with malicious intent.

DNS responses traditionally do not have a

, leading to many attack possibilities; the

(DNSSEC) modify DNS to add support for cryptographically signed responses.

has been

proposed as an alternative to DNSSEC. Other extensions, such as

, add support for cryptographic authentication between

trusted peers and are commonly used to authorize zone transfer or dynamic update operations.

Techniques such as

can also be used to help validate DNS results.

DNS can also "leak" from otherwise secure or private connections, if attention is not paid to their configuration, and at

times DNS has been used to bypass firewalls by malicious persons, and

data, since it is often seen as innocuous.

DNS spoofing

[

]

Some domain names may be used to achieve spoofing effects. For example,

paypal.com

and

paypa1.com

are different names, yet

users may be unable to distinguish them in a graphical user interface depending on the user's chosen

. In many

fonts the letter

and the numeral

look very similar or even identical. This problem, known as the

is acute in systems that support

, as many character codes in

may appear identical

on typical computer screens. This vulnerability is occasionally exploited in

DNSMessenger

[

]

DNSMessenger

is a type of cyber attack technique that uses the

DNS to communicate and control malware

remotely without relying on conventional protocols that might raise red flags. The DNSMessenger attack is covert because

DNS is primarily used for domain name resolution and is often not closely monitored by network security tools, making it

an effective channel for attackers to exploit.

This technique involves the use of DNS TXT records to send commands to infected systems. Once malware has been

surreptitiously installed on a victim's machine, it reaches out to a controlled domain to retrieve commands encoded in DNS

text records. This form of malware communication is stealthy, as DNS requests are usually allowed through firewalls, and

because DNS traffic is often seen as benign, these communications can bypass many network security defenses.

DNSMessenger attacks can enable a wide array of malicious activities, from data exfiltration to the delivery of additional

payloads, all while remaining under the radar of traditional network security measures. Understanding and defending against

such methods are crucial for maintaining robust cybersecurity.

Privacy and tracking issues

[

]

Originally designed as a public, hierarchical, distributed and heavily cached database, the DNS protocol has no

confidentiality controls. User queries and nameserver responses are sent unencrypted, enabling

and

. This deficiency is commonly used by cybercriminals and

network operators for marketing purposes, user authentication on

and

User privacy is further exposed by proposals for increasing the level of client IP information in DNS queries (RFC 7871)

for the benefit of

The main approaches that are in use to counter privacy issues with DNS include:

, which move DNS resolution to the VPN operator and hide user traffic from the local ISP.

, which replaces traditional DNS resolution with anonymous

domains, hiding both name resolution and user

traffic behind

counter-surveillance.

and public DNS servers, which move the actual DNS resolution to a trusted third-party provider.

Some public DNS servers may support security extensions such as

and

Solutions preventing DNS inspection by the local network operator have been criticized for thwarting corporate network

security policies and Internet censorship. Public DNS servers are also criticized for contributing to the centralization of

the Internet by placing control over DNS resolution in the hands of the few large companies which can afford to run public

resolvers.

Google is the dominant provider of the platform in

, the browser in Chrome, and the DNS resolver in the

8.8.8.8 service. Would this scenario be a case of a single corporate entity being in a position of overarching

control of

the

entire

namespace

the

Internet?

already

fielded

app that used its own DNS resolution

mechanism independent of the platform upon which the app was running. What if the

app included DoH? What

used a DoH-resolution mechanism to bypass local DNS resolution and steer all DNS queries from

Apple's platforms to a set of Apple-operated name resolvers?

— DNS Privacy and the IETF

Domain name registration

[

]

The right to use a domain name is delegated by

which are accredited by the

(ICANN) or other organizations such as

, that are charged with overseeing the name and

number systems of the Internet. In addition to ICANN, each top-level domain (TLD) is maintained and serviced technically by

an administrative organization, operating a registry. A

registry

is responsible for operating the database of names within

its authoritative zone, although the term is most often used for TLDs.

registrant

is a person or organization who asked

for domain registration.

The registry receives registration information from each domain name

registrar

, which is

authorized (accredited) to assign names in the corresponding zone and publishes the information using the

protocol.

As of 2015, usage of

is being considered.

ICANN publishes the complete list of TLDs, TLD registries, and domain name registrars. Registrant information associated

with domain names is maintained in an online database accessible with the WHOIS service. For most of the more than 290

(ccTLDs), the domain registries maintain the WHOIS (Registrant, name servers, expiration

dates, etc.) information. For instance,

, Germany NIC, holds the DE domain data. From about 2001, most

(gTLD) registries have adopted this so-called

thick

registry approach, i.e. keeping the WHOIS data in central

registries instead of registrar databases.

For top-level domains on COM and NET, a

thin

registry model is used. The domain registry (

, etc.) holds basic WHOIS data (i.e., registrar and name servers, etc.). On the other hand, organizations, i.e.,

registrants using ORG, are on the

exclusively.

Some domain name registries, often called

network information centers

(NIC), also function as registrars to end-users, in

addition to providing access to the WHOIS datasets. The top-level domain registries, such as for the domains COM, NET, and

ORG use a registry-registrar model consisting of many domain name registrars.

In this method of management, the

registry only manages the domain name database and the relationship with the registrars. The

registrants

(users of a domain

name) are customers of the registrar, in some cases through additional subcontracting of resellers.