DNS Flag Day 2020

Authors: Yazid Akanho, Malick Alassane, Mike Houngbadji and Amreesh Phokeer

The Domain Name System (DNS) is one of the most critical services for the daily functioning of the Internet. It allows names to be resolved into IP addresses and vice versa through a hierarchical system of distributed servers. As a prelude to the DNS Flag day 2020, a study was conducted to assess the EDNS and TCP readiness level of authoritative DNS servers (Name Server - NS) on reverse zones of IP addresses allocated by AFRINIC to its members and authoritative servers of African ccTLD domains. Such a study makes it possible to assess the level of DNS compliance in Africa with good practices related to EDNS, but also to highlight various related aspects of good practices and DNS standards such as location, geographic distribution, resilience, and IPv6 accessibility or reachability of these authoritative servers.

The DNS Flag Day is an initiative born out of the joint desire of DNS providers and operators to make DNS more reliable, resilient and scalable. The first DNS Flag Day took place on February 1, 2019, and was dedicated to studying the configuration level of the EDNS extension on authoritative DNS servers around the world.

For 2020, the DNS Flag Day plans to verify two elements: on one hand, the size of the EDNS buffer (which must not exceed 1232 bytes to avoid the fragmentation of DNS responses in UDP), and on the other hand, the possibility of communicating in TCP mode between client and DNS server.

EDNS, short for Extension Mechanisms for DNS, is defined in RFC 6891, as an extension of the DNS protocol, for the exchange of information between clients (resolvers) and servers. While EDNS has various functions, its primary focus was originally to enable support for DNSSEC, which provides cryptographic security for the DNS infrastructure. 

EDNS was intended to be backwards compatible, meaning that it should not impact the performance of older servers not supporting EDNS. In practice, however, many servers were found to be incompatible with EDNS, which compelled resolver developers to add all kinds of workarounds to their code to allow clients and servers to continue exchange DNS traffic without breaking. An EDNS compatible server is, therefore, a server which supports the EDNS extension or is able to ignore it according to the specification.

In order to assess the global EDNS compatibility of an authoritative server, the latter must be subjected to several tests described in detail here. The Internet System Consortium (ISC) has also developed and published a series of DNS Compliance Testing tools allowing, among other things, registries and registrars to verify the compliance of the DNS protocol running on the servers to which they delegate zones. 

As of June 15, 2020, there were 38,945 IPv4 reverse zones and 348 IPv6 reverse zones known to AFRINIC. These zones are defined by members who have received IP prefixes from the registry. A total of 3604 (unique) authoritative name servers (NS) provide reverse resolution for the global IP addressing zone (v4 and v6) administered by AFRINIC: 3224 NS manage the IPv4 space, while 61 NS manage the IPv6 space and 319 NS provide reverse resolution for both v4 and v6 blocks of the Regional Internet Registry.

Regarding the overall EDNS compatibility of the servers tested, only 1.78% are rigorously compatible on all the EDNS parameters tested for the NS of the AFRINIC reverse zones, i.e. all the tests return exactly the expected responses and the EDNS cache size is between 512 and 1232 bytes. Actually, there is no fixed value retained for the configuration of the EDNS buffer. RFC6891 defines a maximum size of 4096 bytes. However, to avoid fragmentation of DNS responses, a value between 1220 and 1232 bytes is recommended; the main reason being that the MTU on an Ethernet link is 1500 bytes. The organisers of DNS Flag Day 2020 recommend 1,232 bytes.

However, this must be put into perspective because around 75% of the servers tested for reverse zones support EDNS0 with a buffer between 512 and 4096 bytes, which is already very encouraging. We found that out of 3604 NS, 872 (25.4%) returned an error with status: REFUSED.

Figure 1. Distribution of buffer sizes for AFRINIC Reverse DNS

As of June 15, 2020, 54 ccTLDs served by 225 unique NS are counted on the African continent. Only one of the NS of the ccTLD .cm (benoue.camnet.cm.) did not have a type A or AAAA record. 81 NS were IPv4 only and 143 were dual-stacked.

We could not retrieve the EDNS buffer sizes for 53.8% of NS in African ccTLDs either because of a network or timeout issue, which was quite surprising. The results for the rest of the distribution are as follows: 82 (36.4%) 4096, 16 (7.1%) 512, 5 (2.2%) 1680 and 1 (0.4%) 512 bytes.

Figure 2. Distribution of buffer sizes for ccTLDs

When it comes to TCP compliance for African ccTLD, It is quite difficult to accurately evaluate the real number of authoritative name servers that can respond to DNS requests using TCP. However, we received answers from 43.55% of those servers using TCP.

Another important element of DNS is that name servers must be able to process DNS queries in TCP mode. RFC1035 specifies that a DNS name server must be able to handle DNS queries using TCP or UDP on port 53. However, the UDP protocol has historically been predominantly used for its simplicity and speed.

With the introduction of DNSSEC in particular, the need to communicate over TCP has become necessary because DNS responses can now be larger than 512 bytes. In total, we found that 71.7% of AFRINIC reverse zone name servers resolve requests sent over TCP. However, it is difficult to clarify whether it is the server that is not configured to respond to TCP requests or if a firewall located between the client and the server that rejects this type of traffic (unfortunately, several network administrators still consider that DNS must only work over UDP).

To summarise, in the reverse zone NS group, 25.4% of servers do not support the EDNS extension. On the ccTLD side, the percentage is double, around 54%. In both cases, these are servers running with an outdated software version or because the EDNS setting is disabled in their configuration, which is not recommended. In total, we found that 71.7% of AFRINIC reverse zone name servers resolve requests sent over TCP compared to 43.55% in the case of ccTLDs. This study made it possible to obtain relevant results and to have better visibility on the level of implementation of several recommendations and current good practices in Domain Name System on the African continent such as EDNS and TCP support among others.

The following report was generated at a specific point in time and it aims at providing a general overview of the compliance with EDNS in Africa. Results depend on DNS server reachability. Network issues at the time of the experiment might have introduced some false positives.

This study was sponsored by AFRINIC under the 2019 AFRINIC Research Collaboration (ARC) programme.

We would like to thank Amreesh Phokeer, Research Manager at AFRINIC, for his support and guidance in this project.