IP addresses (especially IPv6 addresses) are cumbersome for humans to use and remember, so the Internet supports the use of host names to identify hosts, both clients and servers.

In order to be used by protocols such as TCP and IP, host names are converted into IP addresses using a process known as name resolution.

There are different forms of name resolution in the Internet, but the most prevalent and important one uses a distributed database system known as the Domain Name System (DNS) .

DNS is a distributed client/server networked database that is used by TCP/IP applications to map between host names and IP addresses (and vice versa).

  • DNS runs as an application on the Internet, using IPv4 or IPv6 (or both).

  • For scalability, DNS names are hierarchical, as are the servers that support name resolution.

From an application’s point of view, access to the DNS is through an application library called a resolver.

  • In general, an application must convert a host name to an IPv4 and/or IPv6 address before it can ask TCP to open a connection or send a unicast datagram using UDP.

  • The TCP and IP protocol implementations know nothing about the DNS; they operate only with the addresses.

1. The DNS Name Space

The set of all names used with DNS constitutes the DNS name space. This space is partitioned hierarchically and is case insensitive, similar to computer file system folders (directories) and files.

The current DNS name space is a tree of domains with an unnamed root at the top. The top echelons of the tree are the so-called top-level domains (TLDs), which include

  • generic TLDs (gTLDs),

  • country-code TLDs (ccTLDs),

  • and internationalized country-code TLDs (IDN ccTLDs), plus a special infrastructure TLD called,

  • for historical reasons, ARPA [RFC3172].

DNS Name Space
Figure 1. The DNS name space forms a hierarchy with an unnamed root at the top. The top-level domains (TLDs) include generic TLDs (gTLDs), country-code TLDs (ccTLDs), internationalized TLDs (IDN ccTLDs), and a special infrastructure TLD called ARPA.
Table 1. Special-use domain name
Domain Purpose Reference


Used for Private/internal DNS Namespaces

RFC 6762 (Appendix G)







Used for Multicast DNS as link-local host names

RFC 6762 (Section 3)


Reserved to avoid conflict with the traditional use of localhost as a hostname

RFC 6761


Anonymous onion service

RFC 7686

  • RFC 6762 reserves the use of .local for link-local host names that can be resolved via the Multicast DNS name resolution protocol.

  • RFC 7686 reserves the use of .onion for the self-authenticating names of Tor onion services.

1.1. DNS Naming Syntax

The names below a TLD in the DNS name tree are further partitioned into groups known as subdomains. This is very common practice, especially for the ccTLDs.

For example, the site www.ci.manhattan-beach.ca.us is the site of Manhattan Beach, California’s, city government in the United States, also known as fully qualified domain names (FQDNs).

  • FQDNs are sometimes written more formally with a trailing period (e.g., mit.edu.).

  • The trailing period indicates that the name is complete; no additional information should be added to the name when performing a name resolution.

In contrast to the FQDN, an unqualified domain name, which is used in combination with a default domain or domain search list set during system configuration, has one or more strings appended to the end.

  • When a system is configured, it is typically assigned a default domain extension and search list using DHCP (or, less commonly, the RDNSS and DNSSL RA options).

    For example, the default domain cs.berkeley.edu might be configured in systems at the computer science department at UC Berkeley.

    If a user on one of these machines types in the name vangogh, the local resolver software converts this name to the FQDN vangogh.cs.berkeley.edu. before invoking a resolver to determine vangogh’s IP address.

A domain name consists of a sequence of labels separated by periods.

  • The name represents a location in the name hierarchy, where the period is the hierarchy delimiter and descending down the tree takes place from right to left in the name.

  • Each label can be up to 63 characters long, and an entire FQDN is limited to at most 255 (1-byte) characters.

The hierarchical structure of the DNS name space allows different administrative authorities to manage different parts of the name space. For example,

  • creating a new DNS name of the form elevator.cs.berkeley.edu would likely require dealing with the owner of the cs.berkeley.edu subdomain only.

  • The berkeley .edu and edu portions of the name space would not require alteration, so the owners of those would not need to be bothered.

  • This feature of DNS is one key aspect of its scalability.

2. Name Servers and Zones

Management responsibility for portions of the DNS name space is assigned to individuals or organizations.

  • The active DNS name space (domains) is supposed to arrange for at least two name servers or DNS servers to hold information about the name space so that users of the Internet can perform queries on the names.

  • The collection of servers forms the DNS (service) itself, a distributed system whose primary job is to provide name-to-address mappings.

The unit of administrative delegation, in the language of DNS servers, is called a zone.

  • A zone is a subtree of the DNS name space that can be administered separately from other zones.

  • Every domain name exists within some zone, even the TLDs that exist in the root zone.

  • Whenever a new record is added to a zone, the DNS administrator for the zone allocates a name and additional information (usually an IP address) for the new entry and enters these into the name server’s database.

A DNS server can contain information for more than one zone.

  • At any hierarchical change point in a domain name (i.e., wherever a period appears), a different zone and containing server may be accessed to provide information for the name. This is called a delegation.

  • Each zone has a designated owner or responsible party who is given authority to manage the names, addresses, and subordinate zones, also the name servers that contain the zone’s database(s) within the zone.

Zone information is supposed to exist in at least two places, implying that there should be at least two servers containing information for each zone.

  • This is for redundancy; if one server is not functioning properly, at least one other server is available.

  • All of these servers contain identical information about a zone.

  • Typically, among the servers, a primary server contains the zone database in a disk file, and one or more secondary servers obtain copies of the database in its entirety from the primary using a process called a zone transfer.

3. Caching

Name servers contain information such as name-to-IP-address mappings that may be obtained from three sources.

  • The name server obtains the information directly from the zone database,

    The server is said to contain authoritative information about the zone and may be called an authoritative server for the zone. Such servers are identified by name within the zone information.

  • as the result of a zone transfer (e.g., for a slave server),

  • or from another server in the course of processing a resolution.

Most name servers (except some of the root and TLD servers) also cache zone information they learn, up to a time limit called the time to live (TTL). They use this cached information to answer queries.

  • Doing so can greatly decrease the amount of DNS message traffic that would otherwise be carried on the Internet.

  • When answering a query, a server indicates whether the information it is returning has been derived from its cache or from its authoritative copy of the zone.

  • When cached information is returned, it is common for a server to also include the domain names of the name servers that can be contacted to retrieve authoritative information about the corresponding zone.

It is worth mentioning that caching is applied both for successful resolutions and for unsuccessful resolutions (called negative caching).

  • If a request for a particular domain name fails to return a record, this fact is also cached.

  • Doing so can help to reduce Internet traffic when errant applications repeatedly make requests for names that do not exist.

  • Negative caching was changed from optional to mandatory by [RFC2308].

In some network configurations (e.g., those using older UNIX-compatible systems), the cache is maintained in a nearby name server, not in the resolvers resident in the clients.

  • Placing the cache in the server allows any hosts on the LAN that use the nearby server to benefit from the server’s cache but implies a small delay in accessing the cache over the local network.

  • In Windows and more recent systems (e.g., Linux), the client can maintain a cache, and it is made available to all applications running on the same system.

    In Windows, this happens by default, and in Linux, it is a service that can be enabled or disabled.

  • On Windows, the local system’s cache parameters may be modified by editing the following registry entry:


    The DWORD value MaxNegativeCacheTtl gives the maximum number of seconds that a negative DNS result remains in the resolver cache.

    The DWORD value MaxCacheTtl gives the maximum number of seconds that a DNS record may remain in the resolver cache.

    If this value is less than the TTL of a received DNS record, the lesser value controls how long the record remains in cache.

    These two registry keys do not exist by default, so they must be created in order to be used.

  • In Linux and other systems that support it, the Name Service Caching Daemon (NSCD) provides a client-side caching capability.

    It is controlled by the /etc/nscd.conf file that can indicate which types of resolutions (for DNS and some other services) are cached, along with some cache parameters such as TTL settings.

    In addition, the file /etc/nsswitch.conf controls how name resolution for applications takes place. Among other things, it can control whether local files, the DNS protocol, and/or NSCD is employed for mappings.

4. The DNS Protocol

The DNS protocol consists of two main parts:

  • a query/response protocol used for performing queries against the DNS for particular names,

  • and another protocol for name servers to exchange database records (zone transfers).

  • It also has a way to notify secondary servers that the zone database has evolved and a zone transfer is necessary (DNS Notify), and a way to dynamically update the zone (dynamic updates).

DNS query/response operations are supported over the distributed DNS infrastructure consisting of

  • servers deployed locally at each site or ISP,

  • and a special set of root servers,

  • also a special set of generic top-level domain servers used for scaling some of the larger gTLDs.

DNS resurcive query
Figure 2. A typical recursive DNS query for EXAMPLE.COM from A.HOME involves up to ten messages. The local recursive server (GW.HOME here) uses a DNS server provided by its ISP. That server, in turn, uses an Internet root name server and a gTLD server (for COM and NET TLDs) to find the name server for the EXAMPLE.COM domain. That name server (A.IANA-SERVERS.NET here) provides the required IP address for the host EXAMPLE.COM. All of the recursive servers cache any information learned for later use.

Here, we have a laptop called A.HOME residing nearby the DNS server GW.HOME. The domain HOME is private, so it is not known to the Internet—only locally at the user’s residence.

When A.HOME wishes to connect to the host EXAMPLE.COM, it must determine the IP address of EXAMPLE.COM.

  1. Assuming it does not know this address already, the resolver software on A.HOME first makes a request to its local name server, GW.HOME, to convert the name EXAMPLE.COM into an address and constitutes message 1.

  2. If GW.HOME does not already know the IP address for EXAMPLE.COM or the name servers for either the EXAMPLE.COM domain or the COM TLD, it forwards the request to another DNS server (called recursion). In this case, a request (message 2) goes to an ISP-provided DNS server.

  3. Assuming that this server also does not know the required address or other information, it contacts one of the root name servers (message 3).

  4. The root servers are not recursive, so they do not process the request further but instead return the information required to contact a name server for the COM TLD.

    For example, it might return the name A.GTLD-SERVERS.NET and one or more of its IP addresses (message 4).

  5. With this information, the ISP-provided server contacts the gTLD server (message 5) and discovers the name and IP addresses of the name servers for the domain EXAMPLE.COM (message 6). In this case, one of the servers is A.IANA-SERVERS.NET.

  6. Given the correct server for the domain, the ISP-provided server contacts the appropriate server (message 7), which responds with the requested IP address (message 8).

  7. At this point, the ISP-provided server can respond to GW.HOME with the required information (message 9).

  8. GW.HOME is now able to complete the initial query and responds to the client with the desired IPv4 and/or IPv6 address(es) (message 10).

From the perspective of A.HOME, the local name server was able to perform the request.

However, what really happened is a recursive query, where the GW.HOME and ISP-provided servers in turn made additional DNS requests to satisfy A.HOME's query.

  • In general, most name servers perform recursive queries such as this.

  • The notable exceptions are the root servers and other TLD servers that do not perform recursive queries.

4.1. DNS Message Format

There is one basic DNS message format [RFC6195] used for all DNS operations (queries, responses, zone transfers, notifications, and dynamic updates).

The basic DNS message begins with a fixed 12-byte header followed by four variable-length sections:

  • questions (or queries),

  • answers,

  • authority records,

  • and additional records.

All but the first section contain one or more resource records (RRs). The question section contains a data item that is very close in structure to an RR. RRs can be cached; questions are not.

DNS Message format
Figure 3. The DNS message format has a fixed 12-byte header. The entire message is usually carried in a UDP/IPv4 datagram and limited to 512 bytes. DNS UPDATE (DNS with dynamic updates) uses the field names ZOCOUNT, PRCOUNT, UPCOUNT, and ADCOUNT. A special extension format (called EDNS0) allows messages to be larger than 512 bytes, which is required for DNSSEC.

In the fixed-length header, the Transaction ID field is set by the client and returned by the server. It lets the client match responses to requests.

The second 16-bit word includes a number of flags and other subfields.

  • Beginning from the left-most bit, QR is a 1-bit field: 0 means the message is a query; 1 means it is a response.

  • The next is the OpCode, a 4-bit field.

    The normal value is 0 (a standard query) for requests and responses.

    Other values are: 4 (notify), and 5 (update).

    Other values (1–3) are deprecated or never seen in operational use.

  • Next is the AA bit field that indicates an "authoritative answer" (as opposed to a cached answer).

  • TC is a 1-bit field that means "truncated."

    With UDP, this flag being set means that the total size of the reply exceeded 512 bytes, and only the first 512 bytes of the reply were returned.

  • RD is a bit field that means "recursion desired."

    It can be set in a query and is then returned in the response. It tells the server to perform a recursive query.

    If the bit is not set, and the requested name server does not have an authoritative answer, the requested name server returns a list of other name servers to contact for the answer. At this point, the overall query may be continued by contacting the list of other name servers. This is called an iterative query.

  • RA is a bit field that means "recursion available."

    This bit is set in the response if the server supports recursion.

    Root servers generally do not support recursion, thereby forcing clients to perform iterative queries to complete name resolution.

  • The Z bit field must be 0 for now but is reserved for future use.

  • The AD bit field is set to true if the contained information is authenticated, and the CD bit is set to true if security checking is disabled.

  • The Response Code (or RCODE) field is a 4-bit field with the return code whose possible values are given in [DNSPARAM].

    The common values include 0 (no error) and 3 (name error or "nonexistent domain", written as NXDOMAIN).

    A name error is returned only from an authoritative name server and means that the domain name specified in the query does not exist.

  • The next four fields are 16 bits in size and specify the number of entries in the question, answer, authority, and additional information sections that complete the DNS message.

    For a query, the number of questions is normally 1 and the other three counts are 0. For a reply, the number of answers is at least 1. Questions have a name, type, and class.

    All of the other sections contain zero or more RRs. RRs contain a name, type, and class information, but also the TTL value that controls how long the data can be cached.

x@node-0:~$ dig @ +nocmd +trace +question cs.berkeley.edu A
;.				IN	NS
.			12283	IN	NS	g.root-servers.net.
.			12283	IN	NS	j.root-servers.net.
.			12283	IN	NS	e.root-servers.net.
.			12283	IN	NS	l.root-servers.net.
.			12283	IN	NS	d.root-servers.net.
.			12283	IN	NS	a.root-servers.net.
.			12283	IN	NS	b.root-servers.net.
.			12283	IN	NS	i.root-servers.net.
.			12283	IN	NS	m.root-servers.net.
.			12283	IN	NS	h.root-servers.net.
.			12283	IN	NS	c.root-servers.net.
.			12283	IN	NS	k.root-servers.net.
.			12283	IN	NS	f.root-servers.net.
.			12283	IN	RRSIG	NS 8 0 518400 20221223170000 20221210160000 18733 . RKkv+/2Kd7pxDEzR/ZHRsgPe+YM/M3BYXrU/WwOaco4UT9Wc3A2CF+Bd rBlNbvi8fS7MXDeQPZfRPrVn1yLVNTNVJJVCDzge5QKVhumVM6zfB60e aI0a0mojthg7cKS9mZa29cvoITNW41MTk4dilaDKl4uvLfjnfvZ59ZBS BgDHvd8e0VC53v7Dz8fnoo+climQvU51Xq6haB/v3/m8RXCm6Yvu2qg5 xLdZaRHrnFqKFur7+7UE7zMqWVA1rmwozEi/mgfK0JczDk9LJ2xyEgRH Cq+wKVAZEVU48Yoe1Vemh2PwTZqBLnXpKHooMQ4tNNAkAYKMnP5Na8oW 2U/Y7A==
;; Received 525 bytes from in 39 ms

;cs.berkeley.edu.		IN	A
edu.			172800	IN	NS	a.edu-servers.net.
edu.			172800	IN	NS	h.edu-servers.net.
edu.			172800	IN	NS	b.edu-servers.net.
edu.			172800	IN	NS	d.edu-servers.net.
edu.			172800	IN	NS	c.edu-servers.net.
edu.			172800	IN	NS	l.edu-servers.net.
edu.			172800	IN	NS	f.edu-servers.net.
edu.			172800	IN	NS	e.edu-servers.net.
edu.			172800	IN	NS	i.edu-servers.net.
edu.			172800	IN	NS	g.edu-servers.net.
edu.			172800	IN	NS	k.edu-servers.net.
edu.			172800	IN	NS	j.edu-servers.net.
edu.			172800	IN	NS	m.edu-servers.net.
edu.			86400	IN	DS	28065 8 2 4172496CDE85534E51129040355BD04B1FCFEBAE996DFDDE652006F6 F8B2CE76
edu.			86400	IN	RRSIG	DS 8 1 86400 20221224170000 20221211160000 18733 . p7OvKwfjcx6Iveh7NZ0huq24niVZINxiqttjuDxDJD3wNwVdmgvxzBrw +VzP+5p6JJ63okmvaqlJYlZJNX85n7vweab/LAPFFtT2kHs77Zc/MY1a k/k/E/mZstyAkoS3JwXoDvStoCdAUU/8eH32DFROPpZsKjoeiejcWOWb 86yBU7QKjPlsu5BJO74qlyDP7yLlEBum5YbcMDGoaV3RPozrTCz7r1+V KItG7ObBnw9Vjchv6gG3Q7wyTw2uXWMfGBgAS6P8VGN/GgqS7Bct9y+v 1cc75EY7YM0pqtzu230m1DFnBUWG1pcU4+fS5kPmUBpyBxpMFO99q48q IJyk2A==
;; Received 1205 bytes from in 55 ms

;cs.berkeley.edu.		IN	A
berkeley.edu.		172800	IN	NS	adns1.berkeley.edu.
berkeley.edu.		172800	IN	NS	adns2.berkeley.edu.
berkeley.edu.		172800	IN	NS	adns3.berkeley.edu.
berkeley.edu.		86400	IN	DS	38028 10 2 A37654ABBF41A2F3D7DC8D4B2E77A70E9B1AF6A670101FF8AEF4F36E FB7CA323
berkeley.edu.		86400	IN	DS	20949 10 2 448D22499ED0D3098E2BC186F5D5F5091055C5BECDF3BD82632855D2 1CD493C4
berkeley.edu.		86400	IN	RRSIG	DS 8 2 86400 20221216073252 20221209062252 28775 edu. ym6j4W1W9h8oaqJMFu1kZ/eTHWiRh94zTP33PU81PCP2JGjiKxXNC27D oPU96kj6hWv9jYCLKFqtjcMjdFb/KJL3JmJNBl4QTf9RNHfXyxEsd7zm RgVJkgk5XBaCebMzZsJWz6godVrxGtLC8EcRCg+Y3IQeDLmS5T+zUtaZ GR8kYgN9L+mW23jrKTVh2rOD+v1AZu0fbitcfj/3Q25odQ==
;; Received 471 bytes from in 79 ms

;cs.berkeley.edu.		IN	A
cs.berkeley.edu.	86400	IN	A
;; Received 88 bytes from in 223 ms
x@node-0:~$ sudo tcpdump -tnv udp and port 53
IP (tos 0x0, ttl 64, id 2498, offset 0, flags [none], proto UDP (17), length 68) > 30713+ [1au] NS? . (40)
IP (tos 0x0, ttl 128, id 2372, offset 0, flags [none], proto UDP (17), length 553) > 30713$ 14/0/1 . NS a.root-servers.net., . NS b.root-servers.net., . NS c.root-servers.net., . NS d.root-servers.net., . NS e.root-servers.net., . NS f.root-servers.net., . NS g.root-servers.net., . NS h.root-servers.net., . NS i.root-servers.net., . NS j.root-servers.net., . NS k.root-servers.net., . NS l.root-servers.net., . NS m.root-servers.net., . RRSIG (525)

IP (tos 0x0, ttl 64, id 1382, offset 0, flags [DF], proto UDP (17), length 64) > 64354+ A? a.root-servers.net. (36)
IP (tos 0x0, ttl 64, id 1383, offset 0, flags [DF], proto UDP (17), length 64) > 43153+ AAAA? a.root-servers.net. (36)
IP (tos 0x0, ttl 128, id 2373, offset 0, flags [none], proto UDP (17), length 80) > 64354 1/0/0 a.root-servers.net. A (52)
IP (tos 0x0, ttl 128, id 2374, offset 0, flags [none], proto UDP (17), length 92) > 43153 1/0/0 a.root-servers.net. AAAA 2001:503:ba3e::2:30 (64)
IP (tos 0x0, ttl 128, id 2397, offset 0, flags [none], proto UDP (17), length 80) > 10021 1/0/0 m.root-servers.net. A (52)
IP (tos 0x0, ttl 128, id 2398, offset 0, flags [none], proto UDP (17), length 92) > 22347 1/0/0 m.root-servers.net. AAAA 2001:dc3::35 (64)

IP (tos 0x0, ttl 64, id 49461, offset 0, flags [none], proto UDP (17), length 84) > 53008 [1au] A? cs.berkeley.edu. (56)
IP (tos 0x0, ttl 128, id 2399, offset 0, flags [none], proto UDP (17), length 1202) > 53008- 0/15/27 (1174)

IP (tos 0x0, ttl 64, id 43388, offset 0, flags [DF], proto UDP (17), length 63) > 35146+ A? a.edu-servers.net. (35)
IP (tos 0x0, ttl 64, id 43389, offset 0, flags [DF], proto UDP (17), length 63) > 21077+ AAAA? a.edu-servers.net. (35)
IP (tos 0x0, ttl 128, id 2400, offset 0, flags [none], proto UDP (17), length 79) > 35146 1/0/0 a.edu-servers.net. A (51)
IP (tos 0x0, ttl 128, id 2401, offset 0, flags [none], proto UDP (17), length 91) > 21077 1/0/0 a.edu-servers.net. AAAA 2001:503:a83e::2:30 (63)
IP (tos 0x0, ttl 128, id 2424, offset 0, flags [none], proto UDP (17), length 91) > 60038 1/0/0 m.edu-servers.net. AAAA 2001:501:b1f9::30 (63)
IP (tos 0x0, ttl 128, id 2425, offset 0, flags [none], proto UDP (17), length 79) > 900 1/0/0 m.edu-servers.net. A (51)

IP (tos 0x0, ttl 64, id 37599, offset 0, flags [none], proto UDP (17), length 84) > 47106 [1au] A? cs.berkeley.edu. (56)
IP (tos 0x0, ttl 128, id 2426, offset 0, flags [none], proto UDP (17), length 499) > 47106- 0/6/5 (471)

IP (tos 0x0, ttl 64, id 38284, offset 0, flags [DF], proto UDP (17), length 64) > 55216+ A? adns1.berkeley.edu. (36)
IP (tos 0x0, ttl 64, id 38285, offset 0, flags [DF], proto UDP (17), length 64) > 17843+ AAAA? adns1.berkeley.edu. (36)
IP (tos 0x0, ttl 128, id 2427, offset 0, flags [none], proto UDP (17), length 80) > 55216 1/0/0 adns1.berkeley.edu. A (52)
IP (tos 0x0, ttl 128, id 2428, offset 0, flags [none], proto UDP (17), length 92) > 17843 1/0/0 adns1.berkeley.edu. AAAA 2607:f140:ffff:fffe::3 (64)
IP (tos 0x0, ttl 128, id 2431, offset 0, flags [none], proto UDP (17), length 80) > 62215 1/0/0 adns3.berkeley.edu. A (52)
IP (tos 0x0, ttl 128, id 2432, offset 0, flags [none], proto UDP (17), length 92) > 41239 1/0/0 adns3.berkeley.edu. AAAA 2607:f140:a000:d::abc (64)

IP (tos 0x0, ttl 64, id 47471, offset 0, flags [none], proto UDP (17), length 84) > 8354 [1au] A? cs.berkeley.edu. (56)
IP (tos 0x0, ttl 128, id 2433, offset 0, flags [none], proto UDP (17), length 116) > 8354*- 1/0/1 cs.berkeley.edu. A (88)

4.2. UDP or TCP

The well-known port number for DNS is 53, for both UDP and TCP. The most common format uses the UDP/IPv4 datagram structure.

DNS UDP/IPv4 Message
Figure 4. DNS messages are typically encapsulated in a UDP/IPv4 datagram and are limited to 512 bytes in size unless TCP and/or EDNS0 is used. Each section (except the question section) contains a set of resource records.

When a resolver issues a query and the response comes back with the TC bit field set ("truncated"), the size of the true response exceeded 512 bytes, so only the first 512 bytes are returned by the server.

  • The resolver may issue the request again, using TCP, which now must be a supported configuration [RFC5966].

  • This allows more than 512 bytes to be returned because TCP breaks up large messages into multiple segments.

When a secondary name server for a zone starts up, it normally performs a zone transfer from the primary name server for the zone.

  • Zone transfers can also be initiated by a timer or as a result of a DNS NOTIFY message.

  • Full zone transfers use TCP as they can be large.

  • Incremental zone transfers, where only the updated entries are transferred, may use UDP at first but switch to TCP if the response is too large, just like a conventional query.

When UDP is used, both the resolver and the server application software must perform their own timeout and retransmission.

  • A recommendation for how to do this is given in [RFC1536].

  • It suggests starting with a timeout of at least 4s, and that subsequent timeouts result in an exponential increase of the timeout (a bit like TCP’s algorithms).

  • Linux and UNIX-like systems allow a change to be made to the retransmission timeout parameters by altering the contents of the /etc/resolv.conf file (by setting the timeout and attempts options).

x@node-0:~$ dig +short +tcp @ cs.berkeley.edu A
x@node-0:~$ sudo tcpdump -tnv \(tcp or udp\) and port 53

IP (tos 0x0, ttl 64, id 30721, offset 0, flags [none], proto TCP (6), length 60) > Flags [S], cksum 0xbe79 (correct), seq 1999751284, win 64240, options [mss 1460,sackOK,TS val 3664026097 ecr 0,nop,wscale 7], length 0
IP (tos 0x0, ttl 128, id 5910, offset 0, flags [none], proto TCP (6), length 44) > Flags [S.], cksum 0x18e7 (correct), seq 1120675634, ack 1999751285, win 64240, options [mss 1460], length 0
IP (tos 0x0, ttl 64, id 30722, offset 0, flags [none], proto TCP (6), length 40) > Flags [.], cksum 0x30a4 (correct), ack 1, win 64240, length 0
IP (tos 0x0, ttl 64, id 30723, offset 0, flags [none], proto TCP (6), length 98) > Flags [P.], cksum 0xfd6a (correct), seq 1:59, ack 1, win 64240, length 58 32781+ [1au] A? cs.berkeley.edu. (56)
IP (tos 0x0, ttl 128, id 5911, offset 0, flags [none], proto TCP (6), length 40) > Flags [.], cksum 0x306a (correct), ack 59, win 64240, length 0
IP (tos 0x0, ttl 128, id 5912, offset 0, flags [none], proto TCP (6), length 102) > Flags [P.], cksum 0x8005 (correct), seq 1:63, ack 59, win 64240, length 62 32781 1/0/1 cs.berkeley.edu. A (60)
IP (tos 0x0, ttl 64, id 30724, offset 0, flags [none], proto TCP (6), length 40) > Flags [.], cksum 0x306a (correct), ack 63, win 64178, length 0
IP (tos 0x0, ttl 64, id 30725, offset 0, flags [none], proto TCP (6), length 40) > Flags [F.], cksum 0x3069 (correct), seq 59, ack 63, win 64178, length 0
IP (tos 0x0, ttl 128, id 5913, offset 0, flags [none], proto TCP (6), length 40) > Flags [.], cksum 0x302c (correct), ack 60, win 64239, length 0
IP (tos 0x0, ttl 128, id 5914, offset 0, flags [none], proto TCP (6), length 40) > Flags [FP.], cksum 0x3023 (correct), seq 63, ack 60, win 64239, length 0
IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 40) > Flags [.], cksum 0x3068 (correct), ack 64, win 64178, length 0

4.3. Question (Query) and Zone Section Format

The question or query section of a DNS message lists the question(s) being referenced. The same structure is also used for the zone section in dynamic updates, but with different names.

DNS query(question) message
Figure 5. The query (or question) section of a DNS message does not contain a TTL because it is not cached.
  • The Query Name is the domain name being looked up, using the encoding for labels.

  • Each question has a Query Type and Query Class.

    The class value is 1, 254, or 255, indicating the Internet class, no class, or all classes, respectively, for all cases in which we are interested (other values are not typically used for TCP/IP networks).

    The Query Type field holds a value indicating the type of query being performed.

    • The most common query type is A (or AAAA if IPv6 DNS resolution is enabled), which means that an IP address is desired for the query name.

    • It is also possible to create a query of type ANY, which returns all RRs of any type in the same class that match the query name.

4.4. Answer, Authority, and Additional Information Section Formats

The final three sections in the DNS message, the answer, authority, and additional information sections, contain sets of RRs.

DNS RR message
Figure 6. The format of a DNS resource record. For DNS in the Internet, the Class field always contains the value 1. The TTL field gives the maximum amount of time the RR can be cached (in seconds).
  • The Name field (sometimes called the "owning name", "owner", or "record owner’s name") is the domain name to which the following resource data corresponds.

  • The Type field specifies one of the RR type codes.

  • The Class field is 1 for Internet data.

  • The TTL field is the number of seconds for which the RR can be cached.

  • The Resource Data Length (RDLENGTH) field specifies the number of bytes contained in the Resource Data (RDATA) field.

4.5. Resource Record Types

Although DNS is most commonly used to determine the IP address(es) that correspond to a particular name, it can also be used for the opposite purpose and for a number of other things. The wide range of capabilities provided by DNS is largely attributable to its ability to have different types of resource records.

Table 2. The popular resource record and query types used in DNS protocol messages. Additional records (not shown) are used when DNS security (DNSSEC) is employed.
Value RR Type Reference Description and Purpose




Address record for IPv4 (32-bit IPv4 address)




Name server; provides name of authoritative name server for zone




Canonical name; maps one name to another (to provide a form of name aliasing)




Start of authority; provides authoritative information for the zone (name servers, e-mail address of contact, serial number, zone transfer timers)




Pointer; provides address to (canonical) name mapping; used with in-addr.arpa and ip6.arpa domains for IPv4 and IPv6 reverse queries




Mail exchanger; provides name of e-mail handling host for a domain



[RFC1035] [RFC1464]

Text; provides a variety of information (e.g., used with SPF anti-spam scheme to identify authorized e-mail servers)




Address record for IPv6 (128-bit IPv6 address)




Server selection; transport endpoints of a generic service




Name authority pointer; supports alternative name spaces




Pseudo-RR; supports larger datagrams, labels, return codes in EDNS0




Incremental zone transfer



[RFC1035] [RFC5936]

Full zone transfer; carried over TCP




Request for all (any) records

Resource records are used for many purposes but can be divided into three broad categories: data types, query types, and meta types.

  • Data types are used to convey information stored in the DNS such as IP addresses and the names of authoritative name servers.

  • Query types use the same values as data types, with a few additional values (e.g., AXFR, IXFR, and *).

  • Meta types designate transient data associated with a particular single DNS message.

4.5.1. Authority (SOA) Records

In DNS, each zone has an authority record, using an RR type called start of authority (SOA). These records provide authoritative links between portions of the DNS name space and the servers that provide the zone information allowing various queries to be performed for addresses and other information.

The SOA RR is used to identify the name of the host providing the official permanent database,

  • the responsible party’s e-mail address (where "." is used instead of @),

  • zone update parameters,

  • and the default TTL.

The default TTL is applied to RRs in the zone that are not otherwise assigned an explicit per-RR TTL.

The zone update parameters include a serial number, refresh time, retry time, and expire time.

  • The serial number is increased (by at least 1), usually by the network administrator, anytime there is a change to the zone contents.

    It is used by secondary servers to determine if they should initiate a zone transfer (when they do not have a copy of the zone contents with largest serial number).

  • The refresh time tells secondary servers how long to wait before checking the SOA record from the primary and its version number to determine if a zone transfer is required.

  • The retry and expire times are used in the case of zone transfer failure.

    The retry value gives the time (in seconds) a secondary will wait before retrying.

    The expire time is an upper bound (in seconds) that a secondary server will keep retrying zone transfers before giving up. If it gives up, such a server ceases to respond to queries for the zone.

In general, a zone can contain a mix of IPv4 and IPv6 data and can be accessed using either version of IP.

Default Server:  DC01.fosun.com

> set type=soa
> codefarm.me
Server:  DC01.fosun.com

Non-authoritative answer:
        primary name server = ns01.domaincontrol.com
        responsible mail addr = dns.jomax.net
        serial  = 2022120700
        refresh = 28800 (8 hours)
        retry   = 7200 (2 hours)
        expire  = 604800 (7 days)
        default TTL = 600 (10 mins)

ns01.domaincontrol.com  internet address =
ns01.domaincontrol.com  AAAA IPv6 address = 2603:5:2140::1

4.5.2. Mail Exchanger (MX) Records

An MX record provides the name of a mail exchanger—a host willing to engage in the Simple Mail Transfer Protocol (SMTP) [RFC5321] to receive incoming e-mail on behalf of users associated with a domain name.

MX records include a preference value, so that more than one MX record may be present for a particular domain name, which allows a sending agent to sort the hosts in preference order (smaller is more preferable) in deciding which host to use as an e-mail destination.

x@node-0:~$ nslookup
> set type=mx
> server ns3.dns.ucla.edu
Default server: ns3.dns.ucla.edu
Default server: ns3.dns.ucla.edu
Address: 2600:1f18:21d4:e000::53#53
> cs.ucla.edu
Server:		ns3.dns.ucla.edu

CS.UCLA.EDU	mail exchanger = 13 Mailman.CS.UCLA.EDU.
CS.UCLA.EDU	mail exchanger = 3 Pelican.CS.UCLA.EDU.

4.5.3. Fighting Spam: The Sender Policy Framework (SPF) and Text (TXT) Records

For outgoing e-mail, MX records allow the DNS to help determine the names of mail relays and servers for a domain. More recently, the DNS has been leveraged by receiving mail agents to determine which relaying or sending mail servers are authorized to send mail from a particular domain name. This is used to help combat spam (unwanted e-mail) that is sent by a rogue mail agent pretending to be an authorized mail sender.

E-mail received by a mail server is rejected, stored, or forwarded to another mail server.

  • Rejection can happen for a number of reasons, such as a protocol error or lack of available storage space at the receiver.

  • It can also be rejected because the sending mail client does not appear to be the proper one for sending e-mail.

    This capability is supported by the Sender Policy Framework (SPF) and documented in [RFC4408], an experimental RFC.

    There is another framework known as Sender ID [RFC4406] that incorporates SPF’s functions. It is also experimental but less widely deployed.

Version 1 of SPF uses DNS TXT or SPF (type 99) resource records.

  • Records are set up and published in the DNS by a domain’s owner to indicate which servers are authorized to send mail originating from the domain.

  • The text contains the matching criteria (called mechanisms) and other information (called modifiers).

  • Preceding each mechanism is a qualifier that determines the consequence of a matching mechanism.

Any mechanism missing a qualifier is assumed to have the + qualifier.

  • The + qualifier indicates that a match results in a Pass indication.

  • Other possible qualifiers include - (Fail), ~ (Soft Fail), and ? (Neutral).

If none of the matching mechanisms produces a Pass result, the final mechanism (all) matches any condition.

  • The tilde character (~) before the all criterion indicates that a Soft Fail return should be generated if all is the only matching mechanism.

    The exact way a soft failure is handled is dependent on the receiving e-mail software.

x@node-0:~$ dig +tcp +nocmd +nostats txt outlook.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18595
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4000
;outlook.com.			IN	TXT

outlook.com.		349	IN	TXT	"v=spf1 include:spf-a.outlook.com include:spf-b.outlook.com ip4: include:spf.protection.outlook.com include:spf-a.hotmail.com include:_spf-ssg-b.microsoft.com include:_spf-ssg-c.microsoft.com ~all"
outlook.com.		349	IN	TXT	"google-site-verification=0iLWhIMhXEkeWwWfFU4ursTn-_OvoOjaA0Lr7Pg1sEM"
outlook.com.		349	IN	TXT	"google-site-verification=DC2uC-T8kD33lINhNzfo0bNBrw-vrCXs5BPF5BXY56g"

x@node-0:~$ dig +tcp +nocmd +nostats txt spf-a.outlook.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1423
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4000
;spf-a.outlook.com.		IN	TXT

spf-a.outlook.com.	380	IN	TXT	"v=spf1 ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: ip4: -all"

Reading from left to right in the above example,

  • the string v=spf1 is a modifier indicating that the SPF version is 1.

  • The ip4 mechanism specifies that the SMTP sender has an IPv4 address with the prefix.

  • The ip6 mechanism specifies any sending host with IPv6 address prefix.

  • Finally, the include mechanism incorporates, by reference, the TXT records with recursive SPF resource records.

4.6. Zone Transfers and DNS NOTIFY

A zone transfer is used to copy a set of RRs for a zone from one server to another (generally from the master server to slave servers). The purpose of doing so is to keep multiple servers in sync with respect to a zone’s contents.

  • Multiple servers provide resiliency to failure, in case a server should go down.

  • Performance can also be improved as multiple servers can be used to share the processing load for incoming queries.

  • Finally, the latency of a DNS query/response can potentially be reduced if servers are placed in locations close to clients (i.e., where the network latency between resolver and server is small).

As originally specified, zone transfers are initiated after polling, where slaves periodically contact masters to see if a zone transfer is necessary by comparing the zones' version numbers.

A later method says if a zone transfer needs to be initiated using an asynchronous update mechanism when the zone contents change, called DNS NOTIFY.

Once a zone transfer is initiated, either the entire zone is transferred (using DNS AXFR messages) [RFC5936], or an incremental zone transfer option may be used (using DNS IXFR messages) [RFC1995].

DNS zone transfer
Figure 7. A DNS zone transfer copies the contents of zones between servers. An optional notification can cause a slave to request a full or incremental zone transfer.

5. Sort Lists, Round-Robin, and Split DNS

A DNS server could return all matching data to any client in whatever order the server finds most convenient.

However, special configuration options and behaviors are available in most DNS server software to achieve certain operational, privacy, or performance goals.

Small enterprise topology
Figure 8. In a small enterprise topology, DNS may be configured to return different addresses depending on the requesting IP address. There is a private network and a public network including a DNS server. In addition, there is a pair of hosts on the DMZ (A and B), one on the internal network © and one on the Internet ®. A multihomed host (M) spans the DMZ and internal networks. M therefore has two IP addresses drawn from two different network prefixes.

A host wishing to contact M performs a DNS lookup that returns two addresses—one associated with the internal network and one with the DMZ.

Naturally, it would be more efficient if A, B, and R reached M via the DMZ and C reached M via the internal network.

  • This generally happens if the DNS server orders its returned address records based on the source IP address of the request.

  • It could also use the destination IP address, especially if M uses multiple IP addresses from different subnets on the same network interface.

To achieve load balancing, the DNS server may be configured to use DNS round-robin, which means that the server permutes the order of the returned address records. While this helps to balance load, it is far from perfect.

  • When records are cached, the desired effect may not occur because of reuse of existing cached address records.

  • In addition, this scheme may balance the number of connections well across servers, but not the load.

    Different connections can have radically different processing requirements, so the true processing load is likely to remain unbalanced unless the particular service always has the same processing requirements.

In split DNS, the set of resource records returned in response to a query is dependent on the identity of the client and possibly query destination address. With split DNS, we could arrange for

  • any host in the enterprise (i.e., those sharing a set of prefixes) to be provided with the entire DNS database,

  • whereas those outside are given visibility only to A and B, where the main Web service is offered.

6. Open DNS Servers and DynDNS

Many home users are assigned a single IPv4 address by their ISP, and this address may change over time as the user’s computer or home gateway connects, disconnects, and reconnects to the Internet.

Consequently, it is often difficult for the user to establish a DNS entry that allows for running services that are visible from the Internet.

A number of so-called open Dynamic DNS (DDNS) servers are available that support a special update protocol called the DNS Update API, whereby a user may update an entry in a provider’s DNS server given a preregistration or account.

7. LLMNR and mDNS

The ordinary DNS system requires a set of DNS servers to be configured to provide mappings between names and addresses, and possibly other information.

Sometimes this is too much overhead when only a few local hosts wish to communicate.

In cases where a DNS server is not available (e.g., a quickly formed ad hoc network of clients that connect only to each other), a special local version of DNS called Link-Local Multicast Name Resolution (LLMRR) [RFC4795] may be available.

  • It is a (nonstandard) protocol based on DNS developed by Microsoft and used in local environments to help discover devices on a local area network, such as printers and file servers.

  • It is supported in Windows Vista, Server 2008, and 7.

  • It uses UDP port 5355 with the IPv4 multicast address and IPv6 address ff02::1:3.

  • The servers also use TCP on port 5355 from whatever unicast IP address they respond from.

Multicast DNS (mDNS) [IDMDNS] is another form of local DNS-like capability developed by Apple.

  • When it is combined with the DNS Service Discovery protocol, Apple calls the resulting framework Bonjour.

  • mDNS uses DNS messages carried over local multicast addresses.

    • It uses UDP with port 5353.

    • It specifies that the special TLD .local is to be treated with special semantics. The .local TLD is link-local in scope.

    • Any DNS queries for domain names in this TLD are sent to the mDNS IPv4 address or the IPv6 address ff02::fb.

    • Queries for other domains may optionally be sent to these multicast addresses.

Multicast DNS: From Wikipedia, the free encyclopedia

In computer networking, the multicast DNS (mDNS) protocol resolves hostnames to IP addresses within small networks that do not include a local name server.

  • It is a zero-configuration service, using essentially the same programming interfaces, packet formats and operating semantics as unicast Domain Name Service (DNS).

  • It was designed to work as either a stand-alone protocol or compatibly with standard DNS servers.

  • It uses IP multicast User Datagram Protocol (UDP) packets, and is implemented by the Apple Bonjour and open source Avahi software packages, included in most Linux distributions.

  • Although the Windows 10 implementation was limited to discovering networked printers, subsequent releases resolved hostnames as well.

  • mDNS can work in conjunction with DNS Service Discovery (DNS-SD), a companion zero-configuration networking technique specified separately in RFC 6763.

Multicast DNS was first proposed by Bill Woodcock and Bill Manning in the IETF in 2000, and was eventually published as standards-track IETF RFC 6762 by Stuart Cheshire and Marc Krochmal thirteen years later.

When an mDNS client needs to resolve a hostname,

  • it sends an IP multicast query message that asks the host having that name to identify itself.

  • That target machine then multicasts a message that includes its IP address.

  • All machines in that subnet can then use that information to update their mDNS caches.

  • Any host can relinquish its claim to a name by sending a response packet with a time to live (TTL) equal to zero.

By default, mDNS exclusively resolves hostnames ending with the .local top-level domain.

An mDNS message is a multicast UDP packet sent using the following addressing:

  • IPv4 address or IPv6 address ff02::fb and UDP port 5353

  • When using Ethernet frames, the standard IP multicast MAC address 01:00:5E:00:00:FB (for IPv4) or 33:33:00:00:00:FB (for IPv6)

  • The payload structure is based on the unicast DNS packet format.

    x@node-0:~$ avahi-resolve-host-name node-1.local
    node-1.local	fe80::20c:29ff:fe85:2607
    x@node-0:~$ sudo tcpdump -tnvvv port 5353
    IP6 (flowlabel 0x83068, hlim 255, next-header UDP (17) payload length: 44) fe80::20c:29ff:fe8c:df3f.5353 > ff02::fb.5353: [bad udp cksum 0x0894 -> 0xc569!] 0 [2q] A (QM)? node-1.local. AAAA (QM)? node-1.local. (36)
    IP (tos 0x0, ttl 255, id 63528, offset 0, flags [DF], proto UDP (17), length 64) > [bad udp cksum 0xfd67 -> 0xd095!] 0 [2q] A (QM)? node-1.local. AAAA (QM)? node-1.local. (36)
    IP6 (flowlabel 0xac503, hlim 255, next-header UDP (17) payload length: 60) fe80::20c:29ff:fe85:2607.5353 > ff02::fb.5353: [udp sum ok] 0*- [0q] 1/0/0 node-1.local. (Cache flush) [2m] AAAA fe80::20c:29ff:fe85:2607 (52)
    IP (tos 0x0, ttl 255, id 13910, offset 0, flags [DF], proto UDP (17), length 112) > [udp sum ok] 0*- [0q] 3/0/0 node-1.local. (Cache flush) [2m] AAAA fe80::20c:29ff:fe85:2607, node-1.local. (Cache flush) [2m] A, node-1.local. (Cache flush) [2m] A (84)
    x@node-0:~$ dig +search +nocmd +nostats -p 5353 @ node-1.local A
    ;; Got answer:
    ;; WARNING: .local is reserved for Multicast DNS
    ;; You are currently testing what happens when an mDNS query is leaked to DNS
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15791
    ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
    ;node-1.local.			IN	A
    node-1.local.		10	IN	A
    node-1.local.		10	IN	A
    x@node-0:~$ dig +search +nocmd +nostats -p 5353 @ node-1.local AAAA
    ;; Got answer:
    ;; WARNING: .local is reserved for Multicast DNS
    ;; You are currently testing what happens when an mDNS query is leaked to DNS
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61682
    ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
    ;node-1.local.			IN	AAAA
    node-1.local.		10	IN	AAAA	fe80::20c:29ff:fe85:2607
    x@node-0:~$ sudo tcpdump -tnv port 53 or port 5353
    tcpdump: listening on ens32, link-type EN10MB (Ethernet), snapshot length 262144 bytes
    IP (tos 0x0, ttl 1, id 36980, offset 0, flags [none], proto UDP (17), length 81) > 15791+ [1au] A (QM)? node-1.local. (53)
    IP (tos 0x0, ttl 255, id 45595, offset 0, flags [DF], proto UDP (17), length 90) > 15791*- 2/0/0 node-1.local. A, node-1.local. A (62)
    IP (tos 0x0, ttl 1, id 39442, offset 0, flags [none], proto UDP (17), length 81) > 61682+ [1au] AAAA (QM)? node-1.local. (53)
    IP (tos 0x0, ttl 255, id 47214, offset 0, flags [DF], proto UDP (17), length 86) > 61682*- 1/0/0 node-1.local. AAAA fe80::20c:29ff:fe85:2607 (58)
x@node-0:~$ systemctl status avahi-daemon.service
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
     Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2022-12-14 11:53:34 CST; 5min ago
TriggeredBy: ● avahi-daemon.socket
   Main PID: 1864 (avahi-daemon)
     Status: "avahi-daemon 0.8 starting up."
      Tasks: 2 (limit: 4633)
     Memory: 784.0K
        CPU: 23ms
     CGroup: /system.slice/avahi-daemon.service
             ├─1864 avahi-daemon: running [node-0.local]
             └─1865 avahi-daemon: chroot helper

x@node-0:~$ sudo systemctl restart avahi-daemon.service

x@node-0:~$ cat /etc/resolv.conf
domain localdomain
search localdomain

x@node-0:~$ ping -c 1 node-1
PING node-1.localdomain ( 56(84) bytes of data.
64 bytes from ( icmp_seq=1 ttl=64 time=0.216 ms

--- node-1.localdomain ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.216/0.216/0.216/0.000 ms
x@node-0:~$ sudo tcpdump -tnv port 53 or port 5353
tcpdump: listening on ens32, link-type EN10MB (Ethernet), snapshot length 262144 bytes
IP (tos 0x0, ttl 64, id 22416, offset 0, flags [DF], proto UDP (17), length 64) > 43159+ A? node-1.localdomain. (36)
IP (tos 0x0, ttl 64, id 22417, offset 0, flags [DF], proto UDP (17), length 64) > 16776+ AAAA? node-1.localdomain. (36)
IP (tos 0x0, ttl 128, id 17525, offset 0, flags [none], proto UDP (17), length 136) > 16776 NXDomain 0/1/0 (108)
IP (tos 0x0, ttl 1, id 50969, offset 0, flags [none], proto UDP (17), length 58) > 0 A (QM)? node-1.local. (30)
IP (tos 0x0, ttl 255, id 5793, offset 0, flags [DF], proto UDP (17), length 84) > 0*- [0q] 2/0/0 node-1.local. (Cache flush) A, node-1.local. (Cache flush) A (56)
IP6 (flowlabel 0xfc266, hlim 1, next-header UDP (17) payload length: 38) fe80::50c2:d6ef:87fb:1b7b.5353 > ff02::fb.5353: [udp sum ok] 0 A (QM)? node-1.local. (30)
IP (tos 0x0, ttl 128, id 17526, offset 0, flags [none], proto UDP (17), length 80) > 43159*- 1/0/0 node-1.localdomain. A (52)


  • [1] Kevin Fall, W. Stevens TCP/IP Illustrated: The Protocols, Volume 1. 2nd edition, Addison-Wesley Professional, 2011