2020-2021 IETF DNS Technology Hotspot Analysis
Domain Name System (DNS) is the basic service and protocol of the Internet, which is the connection and conversion between the two identifier systems of Internet service and resource names (domain names) and IP addresses and provides Internet scalability, application deployment flexibility, and business security. Stability provides basic capabilities. Entering the era of mobile Internet and cloud platforms, the status of DNS as the core network infrastructure is being increasingly recognized. The IETF is an authoritative standards organization for Internet technology, and it is also the main position for customizing DNS technology standards. This article will give an overview of the DNS technology hotspots in the IETF in the past two years (2020-2021), including the technical issues, innovative ideas, topic trends, and directions currently discussed by the DNS technology community.
IETF DNS Technology :Introduction to DNS Domain Name System:
IETF DNS Technology :Introduction to DNS Domain Name System:
Overview of IETF DNS-related Working Groups
The DNSOP working group is responsible for most of the DNS-related work of the IETF. Although DNSOP is a working group in the field of IETF operation management (OPS), the expansion and innovation of the new DNS protocol are also done in this working group. DNSOP is a very busy working group. In the past two years (2020-2021), the DNSOP working group has published 13 RFCs, 10 working group drafts and 19 individual drafts are still active in the queue.
In 2014, the IETF established the DRIVE working group, which mainly focused on the standards and related technical discussions related to DNS privacy protection, and developed a number of DNS encrypted transmission protocols on it, including DoH, DoT, DADT , including the popular DNS over QUIC. The workgroup works from the user side to the recursive encrypted transmission, to the recursive to the authoritative encrypted transmission. In the past two years (2020-2021), the DRIVE working group has published a total of 3 RFCs, 2 working group drafts, and 5 individual drafts that are still active in the queue.
In the past two years, due to the rise of application-layer DNS, especially encrypted DNS, in order to better focus on DNS clients, discovery and selection of DNS resolvers in various network environments, including public networks, private networks, and VPN, encrypted and non-encrypted DNS are supported. Encrypted resolvers, 2020 the IETF established the ADD working group to develop client-side DNS service discovery and configuration protocols. The ADD working group has just been established and has not yet published an RFC, but the popularity has not diminished in the past two years. There are 4 working group drafts and 8 individual drafts active in the queue.
Main directions and hot work
If the standards, proposals, and technical topics of the IETF DNSOP, DRIVE, and ADD working groups are classified, there are four main directions:
1. DNS configuration and deployment (Provisioning & Deployment)
The main focus of this direction is to better deploy and run DNS services by developing new DNS protocols and services, such as defining new RRs, EDNS0 extensions, and new DNS operating mechanisms. Below are some feature discussions and technical drafts.
Today uses multiple DNS providers to host authoritative DNS services and requires intelligent responses based on different links. If the zone of the enterprise needs to support DNSSEC (Online Signature Mode), it needs to support the management of multiple signers and multiple keys. RFC 8901 introduces a new DNSSEC signature mode that allows multiple signers (Multi-Signer) to sign independently or share a partial key. Following the publication of RFC8901, the draft dnssec-automation proposes an algorithm and protocol to automate DNSSEC schemas for multiple signers.
In the operation of DNS service, it is often encountered that the authoritative server does not respond or responds incorrectly. RFC 8906 proposes a best practice, introduces various abnormal response scenarios and problems, and gives the authoritative server test for these response exceptions. and assessment methods, and recommendations for DNS users and service operators
In the field of network management and configuration data modeling, IETF has a type of work to define the corresponding YANG data models for various protocols, so as to facilitate the management and configuration of network devices through the NETCONF protocol. RFC 9108 defines some new YANG types and standard terms for DNS Class and Resource Record data that can be used for network modeling. For the YANG data model, please refer to the related introductions of NETCONF and YANG.
The synchronization of the zone file configuration of the master and slave servers is an operation and maintenance issue that needs to be considered. The general practice is that administrators manually configure additions and deletions, or use external control programs to automate this operation. In order to achieve master-slave server configuration synchronization within DNS, the working group draft catalog zones introduce a "catalog zone" that records information about the zone list of authoritative servers. The master server can keep the zone configuration information synchronized with the slave server through the catalog zone, reducing the risk of manual or external application synchronization configuration files.
The glue record of the In-domain in the DNS response data will be placed in the Additional Section, and it is not necessary to carry the information. If the size of the packet exceeds the Bufsize, the glue record will only retain part of it (Note: Glue is the address record of the NS record). The working group draft glue-is-not-optional modifies this behavior and requires that the in-domain glue address record cannot be completely placed in the additional section due to the packet size limit. This new working group draft requires the server to set TC=1, The client needs to re-initiate the TCP DNS query.
The answer to "who answers my query?" is often required in DNS troubleshooting. Because many zones are hosted on multiple authoritative server clusters and deployed using Anycast, different servers may have inconsistent zone versions, resulting in parsing errors using stale data. The working group draft RRSERIAL EDNS option proposes a DNS protocol extension that carries the version number of the zone (SOA serial number) in the response data, which is used to check which version of the zone file is served by the source server of the response.
Hot discussion In addition to providing domain name and address resolution functions, DNS can also be used in service discovery and protocol configuration scenarios. In order to better enhance the security, privacy, and performance improvement of DNS and applications deployed in the cloud, ADD has a working group draft svc-HTTPS-RR by introducing new resources SVCB and HTTPS two new types of records, allowing clients to connect before connecting Initialize through a DNS query to obtain more endpoint service and parameter information, such as port number/IP parameters for HTTPS connections, ESNI/ECH public key information, CNAME records for zone top names, etc.
This direction mainly focuses on how to ensure the stable operation of DNS and high availability of services in various complex and risky Internet scenarios, such as dealing with DDoS risks, reducing external network dependencies, failure avoidance, recovery, etc.
For a long time, there have been some disputes over the DNS root server at home and abroad. The actual situation is that there are 13 root servers and thousands of mirrors in the world, operated by 12 organizations. ICANN and VeriSign edit and sign the root zone respectively. China does not have root server operation rights, but there are 20+ root mirrors. In order to reduce the dependence of root zone access on external root servers, and to reduce the risk of information leakage when DNS accesses the root zone, RFC7706 proposes the idea of running a copy of the root zone locally to reduce the root zone resolution delay and reduce DNS information leakage. This standard is also regarded as a root server resolution scheme that achieves "decentralization" through local root zone resolution. RFC 8806 is an update to RFC7706, which relaxes some restrictions on local deployment, supports more flexible software deployment, and increases The ability to switch to global root resolution after local root resolution fails, updated the online root zone copy download link.
When the recursive cache data timeout cannot update the data, SERVFAIL will be returned. However, in a "loosely" coordinated distributed data system such as DNS, "stale data is better than nothing". So to improve DNS resiliency, RFC 8767 defines a way for recursive servers to answer queries with stale data. This method is mainly to deal with scenarios where the recursive server cannot refresh the cached data, for example, the authoritative server is attacked and cannot respond. The standard recommends that stale data can be used for up to 7 days. This method also makes some attacks targeting authoritative servers unattractive.
DNS RCODE has only limited types of exceptions, such as NXDOMAIN, NODATA, SERVFAIL, REFUSED, etc. Relative to the various abnormal situations of DNS, it cannot be accurately described. Therefore, RFC 8914 introduces a new DNS protocol extension Extended DNS Error (ENE) function to support the DNS server to return richer Error information to the user. For example, the method of RFC8767 is used recursively to reply with stale data. The reply can be combined with the RCODE of SERVFAIL and then returns EDE Code 3, which means that the query reply timed out, but the reply provides stale data. This standard also defines several types of ENE Codes that "do not respond", which are differentiated due to policy review (censored), security blacklist (Blocked), or user blacklist (Filtered), with specific reference to the standard text.
IP fragmentation can cause various network problems ( RFC8900 ), and DNS is one of the affected protocols, causing packet loss and DNS service timeouts. In order to reduce DNS packet fragmentation, a working group draft draft-IETF-drop-avoid-fragmentation suggests setting a reasonable DNS packet size parameter to avoid IP fragmentation during DNS transmission. The draft also proposes to reduce the corresponding packet size by reducing the number of NS and A/AAAA in a zone and using ECDSA/ EdDSA instead of RSA.
There may be DNS loops in the DNS resolution process. For example, the A and B zones create resolution loops through CNAME or NS settings, consuming DNS technical resources. negative-cache-loop This document updates the method for detecting DNS loops in recursive resolver algorithms, requiring recursive resolvers to detect loops and reduce resolve loops by implementing Negative Caching (caching of negative or nonexistent records).
3. DNS Security and Privacy
This part mainly involves the security reinforcement and privacy of DNS services, such as DNSSEC data signature and authentication, DNS data digest, DNS encrypted transmission, DNS privacy protocol, etc. In particular, DNS privacy security has been a continuous hot work of the IETF in the past 5~6 years.
RFC 9076 DNS Privacy Consideration released in 2021 is an update and reprint of RFC7626 six years ago, enriching and improving the DNS privacy risks in the three main aspects of DNS, data, transmission, and server, and increasing the practice and operation of DNS privacy in recent years. Experience and research results, a standard texts that must be read in the field of DNS privacy.
In the field of DNS encrypted transmission, the IETF has done a lot of standard work, from DoH, DoT, DADT to the popular DNS over QUIC ( dnsoquic ) in the past two years. On the premise of ensuring privacy encryption, the latest transmission protocol QUIC is used to transmit DNS. From the perspective of encrypted transmission scenarios, the standard work is from users to recursive encrypted transmission scenarios, and gradually turns to recursive to authoritative encrypted transmission scenarios, and discusses two methods of non- authentication ( unauth-to-authoritative ) and authentication ( adot-auth ).
Hot discussion] Due to the centralized trend of DNS traffic, the DNS query information of users who use DoH /DoT will also be concentrated in the hands of a few DNS operators, such as Google's 22.214.171.124 and Cloudflare's 126.96.36.199. In order to reduce the privacy problems caused by DNS centralization, ODoH ( oblivious-doh ) was proposed by Cloudflare and APPLE. Its idea is to access recursive DNS by accessing a DNS Proxy, separate DNS QNAME information from user source addresses, and provide The ultimate anonymity and privacy protection technology, so ODoH is also called anonymous DNS. However, due to the reduced parsing performance (increased latency, affected scheduling accuracy), increased system complexity, and ODoH proponents say that it has been widely deployed and are reluctant to accept changes from the IETF, ODoH as a standard class draft does Not adopt by the working group, but an independently submitted ISE experimental draft (Experimental).
DNS Cookies ( RFC7873 ) is a lightweight DNS transaction security mechanism that provides protection for DNS servers and clients by creating cookies, preventing various denial of service amplification, forgery or cache poisoning attacks of forged addresses. RFC 9018 This paper introduces a method for creating DNS cookies, which supports the interconnection of different types of DNS servers in the Anycast scenario, and can better protect user privacy.
RFC 8976 introduces a new DNS resource record, ZONEMD RR, which is similar to the MD information carried after many software installation images are released. ZONEMD is a message digest for the entire zone data to ensure the data integrity and authenticity of the zone file after transmission. It is conducive to the transmission, copying, and storage of DNS zone files on the Internet. From the perspective of computational overhead, ZONEMD records are particularly suitable for infrequent updates and relatively small zones, such as the root zone. Therefore, the ICANN Root Zone Evolution Review Committee (RZERC) recommends that the root zone consider adding ZONEMD records.
Remarks: The author believes that ZONEMD will be used in more scenarios under the premise of increasing emphasis on local closed-loop analysis and not relying on external infrastructures, such as RPZ zone files, centralized zone file data services, etc. Because DNS zone files are often transmitted, copied, and stored over the Internet, message digesting them is a necessary function, and ZONEMD will cover content that is not covered by DNSSEC, such as authoritative NS records.
Since the adoption of DoH /DoT may destroy the network security policy of the local network, such as bypassing local DNS resolution and firewalls, in the field of DNS security and network management, there is a category of how to discover and authenticate DNS encryption services or intranet DNS services to support local DNS configuration resolution for namespaces ( split-dns ), these technical standards are mainly discussed in the ADD working group. In 2021, there are three main areas of work for ADD: using Dynamic Host Configuration Protocol (DHCP) to specify which resolvers are available on the network, a protocol to help discover resolvers not present in DHCP , and carrying information about resolvers in DNS. The format of the information. Interested readers can follow the ADD documentation page to find related drafts.
In addition to DNS privacy and security, DNSSEC has always been a hot spot in the IETF DNS field, and new proposals are constantly being put forward. Due to space limitations, this article will not be expanded. Readers who are interested in DNSSEC can visit the DNSOP documentation page to find DNSSEC/NSEC related technical drafts Documentation
4. DNS Operational Guidelines and Requirements
Some of the IETF technical standard drafts focus on early operation guidelines and technical requirements for reference by DNS operators. Some drafts may not eventually become standard RFCs, but they are also summaries of experience and research conclusions, which are of reference significance.
From 2020 to 2021, there are several drafts that introduce DNSSEC resolver operation recommendations, large authoritative DNS operator recommendations, NSEC3 operation guidelines , and DNS TCP technical requirements . Among them, the draft proposal for large DNS operators deserves the attention of DNS operators. It sorts out the measurement research and suggestions of the academic community on Anycast-based DNS services, and it is worth reading.
Sort out the technical discussions of IETF DNS, mainly in terms of DNS security, privacy, and high availability. Recently, encrypted DNS (Encrypted DNS) and DNS service discovery configuration have become hotspots, which fully shows that the network connection-centric DNS is constantly changing to application-centric. It uses UDP/53 instead of HTTPS/QUIC, etc., which can reuse the web application infrastructure to improve the operation efficiency of encrypted and connected DNS, allowing smart terminals and applications to connect to cloud resources faster; Applications and services can actively announce and push configurations to smart terminals and applications through DNS, allowing applications to sink and integrate with DNS. The representative standard work is svcb-https-RR , and large-scale deployment and application have not yet been formulated. stand up.
The IETF is not only an international standards organization for Internet protocols but also a platform for technical exchanges between Internet/network engineers. In the DNS working group, many European and American mainstream Internet companies, network operators and engineers from national network centers are active. Paying attention to the technical discussions and topic trends of IETF DNS is helpful to our own technology research and development, architecture design, and business operations.
Attachment: Introduction to Alibaba Cloud DNS
Cloud DNS (Domain Name Service ) is a leading international DNS service provider, providing a full range of one-stop domain name resolution service products, covering public domain name resolution, intranet domain name resolution, global traffic scheduling, mobile resolution, and proprietary cloud domain name resolution scenarios. Alibaba Cloud DNS is the first in the industry to propose cloud-integrated technology and product architecture, helping enterprises achieve digital transformation for diverse connection scenarios on and off the cloud, and providing secure and stable connections for mobile apps, smart terminals/IoT, and home/enterprise networks and intelligent dispatching services, the current average daily analysis service volume of the platform has exceeded one trillion.
Knowledge Base Team
Knowledge Base Team
Knowledge Base Team
Knowledge Base Team
Explore More Special Offers
50,000 email package starts as low as USD 1.99, 120 short messages start at only USD 1.00