By Hugo Salgado, Research and Development Engineer at NIC Chile
Technical and Operational Agreement
The DNS protocol consists of information packets that allow clients to receive answers to their queries, such as: “What is the IPv6 address of www.example.com?” or “Where do you receive mail sent to @gmail.com?”.
DNS success and ubiquity make it appealing for much more than just asking about IP addresses. Indeed, mail configuration data, SSH connection keys, digital certificates for websites, etc. are also stored in the DNS. In addition, there are records that allow DNS to function internally, such as delegations to sub-domains, cryptographic signatures, cache information, etc.
The increased use of the DNS protocol and the expected upgrade in its operation compel the industry to make joint efforts to push for changes that will allow the DNS to grow. As we know, everything on the Internet works thanks to agreements and consensus. There is no Internet government or police force to punish those who do not comply with the protocols. However, there is a technical and operational agreement to follow and adapt to the standards.
Since the origin of the DNS dates back to the beginnings of the Internet, it is difficult to make coordinated changes on a global scale. Moreover, given that it is a critical and fundamental system, great care must be taken. Therefore, any deployment of new DNS features is measured in years −if not decades− and DNS software developers must consider many edge cases to ensure interoperability with hundreds of implementations and infrastructures.
In 2019, a consortium was organized among the most important organizations that develop software and provide DNS services. This consortium agreed on certain steps to finally drop out-of-standard behavior in order to build a unified effort to punish those who do things incorrectly. Some of the organizations that participate in this project are the ISC firm (creator of the BIND software, the most widely used on the Internet), Infoblox, Bluecat, PowerDNS; and providers such as Google DNS, Quad9, etc.
First DNS Flag Day campaign
This consortium conducted the first “DNS Flag Day” campaign on February 1, 2019. At that time, they tackled the various “patches” that had been built up over time in DNS software in an attempt to respond to implementations that were outside the standard of the extension mechanisms for DNS (EDNS).
DNS software developers always find themselves in the dilemma of knowing how far one can be permissive with certain deviations from the standards because they understand that by being very strict, they can also affect the universality and adaptation to different operational realities. In addition, they must take into account the creation of perverse incentives: once a popular implementation deviates from the standard, the others are compelled to follow it and do not cause comparisons in the operation between different tools. For this reason, DNS Flag Day 2019 was a joint agreement to stop supporting these patches and to punish bad implementations with an operating error that would finally force everyone to respect the standard.
The campaign was a success. Indeed, several measurements have shown that today the DNS is a much better space than it was. An un-patched DNS is simpler, sleeker, easier to maintain, and enables further growth.
It is now time to take the next step and tackle the next problem.
DNS Flag Day 2020
DNS Flag Day 2020 addresses message size in the DNS. Initially, messages had to fit within 512 bytes, which was enough at the time. However, this size is now falling short. For more than 15 years, there has been a DNS negotiation mechanism that allows messages to grow to much larger sizes (in theory, up to 65,536 bytes) and thus carry much more information than in the past.
However, there are certain limitations in the most widely used DNS transport layer (the UDP layer) that make this size negotiation complex, and which do not rely on information from either end of the communication. In addition, several measurements have shown that the technique used to separate a message into “fragments” −a mechanism that has always been available for Internet communication− is not working properly and actually poses significant security risks. For this reason, it has been agreed that DNS Flag Day 2020 will define a default operating size of 1,232 bytes in the communication −which can also be negotiable upwards or downwards at both ends− and will prohibit the fragmentation of these packets if problems are detected along the way. If there is a need to send more data than defined by this negotiation, you should switch to the TCP transport protocol (the same used for the web), which despite being less efficient than the UDP protocol, has no size limit.
In other words, DNS Flag Day 2020 will be held on October 1, 2020, and will have two objectives:
- define a default DNS packet size of 1,232 bytes to prevent fragmentation; and
- force the switch to TCP transport when more information needs to be sent.
To this end, the DNS software developers consortium will start publishing new versions of their systems that include these two behaviors. As each Internet player begins to install and update their DNS services, this behavior will spread throughout the network.
What should DNS operators be mindful of?
First, DNS service operators must keep their software up to date. This is very important not only because of these changes, but because older software is affected by performance, operation and even security issues.
In addition, you must be careful not to have firewalls or filtering devices in your network that prevent this new behavior. In this regard, it is worth emphasizing the importance of allowing TCP communication in the DNS. Some system administrators still believe that the DNS protocol works only in UDP and that it is better to block TCP for security reasons. This belief, in fact, was a historical misunderstanding because the protocol, since its inception, allowed the use of both transports. In any case, standards have been updated to make this behavior clearer and to make the use of TCP absolutely mandatory for any participant in the DNS.
The consortium itself has created tools that allow direct testing of authoritative DNS servers, as well as resolvers that allow client browsing. It is important that you review your infrastructure and, if necessary, make adjustments in a timely manner. Maintaining an incorrect operation will cause more problems in the long term and may even lead to the interruption of communication in the near future.
It is everyone’s task to keep the Internet safe and up-to-date.
Research and Development, NIC Chile