Extension Mechanisms for DNS

Last updated

Extension Mechanisms for DNS (EDNS) is a specification for expanding the size of several parameters of the Domain Name System (DNS) protocol which had size restrictions that the Internet engineering community deemed too limited for increasing functionality of the protocol. The first set of extensions was published in 1999 by the Internet Engineering Task Force as RFC   2671, also known as EDNS0 [1] which was updated by RFC   6891 in 2013 changing abbreviation slightly to EDNS(0). [2]

Contents

Motivation

The Domain Name System was first developed in the early 1980s. Since then, it has been progressively enhanced with new features, while maintaining compatibility with earlier versions of the protocol.

The restrictions in the size of several flags fields, return codes and label types available in the basic DNS protocol prevented the support of some desirable features. Moreover, DNS messages carried by UDP were restricted to 512 bytes, not considering the Internet Protocol (IP) and transport layer headers. [3] Resorting to a virtual circuit transport, using the Transmission Control Protocol (TCP), would greatly increase overhead. This presented a major obstacle to adding new features to DNS. In 1999, Paul Vixie proposed extending DNS to allow for new flags and response codes and to provide support for longer responses in a framework that is backwards compatible with previous implementations.

Mechanism

Since no new flags could be added in the DNS header, EDNS adds information to DNS messages in the form of pseudo-Resource Records ("pseudo-RR"s) included in the "additional data" section of a DNS message. Note that this section exists in both requests and responses.

EDNS introduces a single pseudo-RR type: OPT.

As pseudo-RRs, OPT type RRs never appear in any zone file; they exist only in messages, fabricated by the DNS participants.

The mechanism is backward compatible, because older DNS responders ignore any RR of the unknown OPT type in a request and a newer DNS responder never includes an OPT in a response unless there was one in the request. The presence of the OPT in the request signifies a newer requester that knows what to do with an OPT in the response.

The OPT pseudo-record provides space for up to 16 flags and it extends the space for the response code. The overall size of the UDP packet and the version number (at present 0) are contained in the OPT record. A variable length data field allows further information to be registered in future versions of the protocol. The original DNS protocol provided two label types, which are defined by the first two bits in the length octet of a label (RFC 1035): 00 (standard label) and 11 (compressed label). EDNS introduces the label type 01 as extended label. The lower 6 bits of the first byte may be used to define up to 63 new extended labels.

Example

An example of an OPT pseudo-record, as displayed by the dig command :

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096

The result of "EDNS: version: 0" indicates full conformance with EDNS0. [4] The result "flags: do" indicates that "DNSSEC OK" is set. [5]

Applications

DNSSEC

EDNS is essential for the implementation of DNS Security Extensions (DNSSEC). [6]

EDNS Padding

There are standards for using EDNS to set how much padding should be around a DNS message. [7] [8] Padding is essential when encrypting DNS, because without padding it may be possible to determine the queried domain name from the encrypted size of the query.

EDNS Keepalive

EDNS is used for indicating how long a TCP connection should be kept alive. [9]

EDNS Client Subnet (ECS)

EDNS is also used for sending general information from resolvers to name servers about clients' geographic location in the form of the EDNS Client Subnet (ECS) option. [10]

Issues

In practice, difficulties can arise when using EDNS traversing firewalls, since some firewalls assume a maximum DNS message length of 512 bytes and block longer DNS packets.

The introduction of EDNS made feasible the DNS amplification attack, a type of reflected denial-of-service attack, since EDNS facilitates very large response packets compared to relatively small request packets.

The IETF DNS Extensions working group (dnsext) has finished work on a refinement of EDNS0, which has been published as RFC 6891.

Related Research Articles

The Domain Name System (DNS) is a hierarchical and distributed naming system for computers, services, and other resources in the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. The Domain Name System has been an essential component of the functionality of the Internet since 1985.

The Dynamic Host Configuration Protocol (DHCP) is a network management protocol used on Internet Protocol (IP) networks for automatically assigning IP addresses and other communication parameters to devices connected to the network using a client–server architecture.

The Internet Control Message Protocol (ICMP) is a supporting protocol in the Internet protocol suite. It is used by network devices, including routers, to send error messages and operational information indicating success or failure when communicating with another IP address, for example, an error is indicated when a requested service is not available or that a host or router could not be reached. ICMP differs from transport protocols such as TCP and UDP in that it is not typically used to exchange data between systems, nor is it regularly employed by end-user network applications.

<span class="mw-page-title-main">IPv6</span> Version 6 of the Internet Protocol

Internet Protocol version 6 (IPv6) is the most recent version of the Internet Protocol (IP), the communications protocol that provides an identification and location system for computers on networks and routes traffic across the Internet. IPv6 was developed by the Internet Engineering Task Force (IETF) to deal with the long-anticipated problem of IPv4 address exhaustion, and was intended to replace IPv4. In December 1998, IPv6 became a Draft Standard for the IETF, which subsequently ratified it as an Internet Standard on 14 July 2017.

<span class="mw-page-title-main">Network address translation</span> Protocol facilitating connection of one IP address space to another

Network address translation (NAT) is a method of mapping an IP address space into another by modifying network address information in the IP header of packets while they are in transit across a traffic routing device. The technique was originally used to bypass the need to assign a new address to every host when a network was moved, or when the upstream Internet service provider was replaced, but could not route the network's address space. It has become a popular and essential tool in conserving global address space in the face of IPv4 address exhaustion. One Internet-routable IP address of a NAT gateway can be used for an entire private network.

The Bootstrap Protocol (BOOTP) is a computer networking protocol used in Internet Protocol networks to automatically assign an IP address to network devices from a configuration server. The BOOTP was originally defined in RFC 951 published in 1985.

Zero-configuration networking (zeroconf) is a set of technologies that automatically creates a usable computer network based on the Internet Protocol Suite (TCP/IP) when computers or network peripherals are interconnected. It does not require manual operator intervention or special configuration servers. Without zeroconf, a network administrator must set up network services, such as Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS), or configure each computer's network settings manually.

The Domain Name System Security Extensions (DNSSEC) are a suite of extension specifications by the Internet Engineering Task Force (IETF) for securing data exchanged in the Domain Name System (DNS) in Internet Protocol (IP) networks. The protocol provides cryptographic authentication of data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

In computer networking, Layer 2 Tunneling Protocol (L2TP) is a tunneling protocol used to support virtual private networks (VPNs) or as part of the delivery of services by ISPs. It uses encryption ('hiding') only for its own control messages, and does not provide any encryption or confidentiality of content by itself. Rather, it provides a tunnel for Layer 2, and the tunnel itself may be passed over a Layer 3 encryption protocol such as IPsec.

STUN is a standardized set of methods, including a network protocol, for traversal of network address translator (NAT) gateways in applications of real-time voice, video, messaging, and other interactive communications.

DNS zone transfer, also sometimes known by the inducing DNS query type AXFR, is a type of DNS transaction. It is one of the many mechanisms available for administrators to replicate DNS databases across a set of DNS servers.

The Neighbor Discovery Protocol (NDP), or simply Neighbor Discovery (ND), is a protocol of the Internet protocol suite used with Internet Protocol Version 6 (IPv6). It operates at the internet layer of the Internet model, and is responsible for gathering various information required for network communication, including the configuration of local connections and the domain name servers and gateways.

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 System (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.

An IPv6 transition mechanism is a technology that facilitates the transitioning of the Internet from the Internet Protocol version 4 (IPv4) infrastructure in use since 1983 to the successor addressing and routing system of Internet Protocol Version 6 (IPv6). As IPv4 and IPv6 networks are not directly interoperable, transition technologies are designed to permit hosts on either network type to communicate with any other host.

Google Public DNS is a Domain Name System (DNS) service offered to Internet users worldwide by Google. It functions as a recursive name server. Google Public DNS was announced on December 3, 2009, in an effort described as "making the web faster and more secure." As of 2018, it is the largest public DNS service in the world, handling over a trillion queries per day. Google Public DNS is not related to Google Cloud DNS, which is a DNS hosting service.

TCP Cookie Transactions (TCPCT) is specified in RFC 6013 as an extension of Transmission Control Protocol (TCP) intended to secure it against denial-of-service attacks, such as resource exhaustion by SYN flooding and malicious connection termination by third parties. Unlike the original SYN cookies approach, TCPCT does not conflict with other TCP extensions, but requires TCPCT support in the client (initiator) as well as the server (responder) TCP stack.

The Stream Control Transmission Protocol (SCTP) is a computer networking communications protocol in the transport layer of the Internet protocol suite. Originally intended for Signaling System 7 (SS7) message transport in telecommunication, the protocol provides the message-oriented feature of the User Datagram Protocol (UDP), while ensuring reliable, in-sequence transport of messages with congestion control like the Transmission Control Protocol (TCP). Unlike UDP and TCP, the protocol supports multihoming and redundant paths to increase resilience and reliability.

DNSCrypt is a network protocol that authenticates and encrypts Domain Name System (DNS) traffic between the user's computer and recursive name servers. DNSCrypt wraps unmodified DNS traffic between a client and a DNS resolver in a cryptographic construction, preventing eavesdropping and forgery by a man-in-the-middle.

EDNS Client Subnet (ECS) is an option in the Extension Mechanisms for DNS that allows a recursive DNS resolver to specify the subnetwork for the host or client on whose behalf it is making a DNS query. This is generally intended to help speed up the delivery of data from content delivery networks (CDN), by allowing better use of DNS-based load balancing to select a service address near the client when the client computer is not necessarily near the recursive resolver.

References

  1. ↑ RFC   2671, Extension Mechanisms for DNS (EDNS0), P. Vixie, The Internet Society (August 1999)
  2. ↑ RFC   6891, Extension Mechanisms for DNS (EDNS(0)), J. Damas, M. Graff, P. Vixie, (April 2013)
  3. ↑ RFC 1035, Domain Names - Implementation and Specification, P. Mockapetris (November 1987)
  4. ↑ Network Working Group of the IETF, August 1999, RFC 2671: Extension Mechanisms for DNS (EDNS0), page 3, Full conformance with this specification is indicated by version "0."
  5. ↑ Network Working Group of the IETF, December 2001, RFC 3225: Indicating Resolver Support of DNSSEC, page 3, The mechanism chosen for the explicit notification of the ability of the client to accept (if not understand) DNSSEC security RRs is using the most significant bit of the Z field on the EDNS0 OPT header in the query. This bit is referred to as the "DNSSEC OK" (DO) bit.
  6. ↑ RFC 4035, Protocol Modifications for the DNS Security Extensions, R. Arends, Telematica Instituut, 2005. Section 4.1 EDNS Support
  7. ↑ Mayrhofer, Alexander (May 2016). "RFC 7830: The EDNS(0) Padding Option". tools.ietf.org. Retrieved 2018-02-02.
  8. ↑ Mayrhofer, Alexander (October 2018). "RFC 8467: Padding Policies for Extension Mechanisms for DNS (EDNS(0))". tools.ietf.org. Retrieved 2018-10-01.
  9. ↑ Wouters, Paul (April 2016). "RFC 7828: The edns-tcp-keepalive EDNS0 Option". tools.ietf.org. Retrieved 2018-02-02.
  10. ↑ Contavalli, Carlo (May 2016). "RFC 7871: Client Subnet in DNS Queries". tools.ietf.org. Retrieved 2018-02-02.

See also

This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.