{"id":36194,"date":"2019-10-31T22:10:13","date_gmt":"2019-10-31T19:10:13","guid":{"rendered":"https:\/\/prohoster.info\/blog\/reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020\/"},"modified":"2019-10-31T22:10:13","modified_gmt":"2019-10-31T19:10:13","slug":"reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/reliz-powerdns-recursor-4-2-i-initsiativa-dns-flag-day-2020","title":{"rendered":"Release of PowerDNS Recursor 4.2 and the DNS flag day initiative 2020","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

After a year and a half of development introduced<\/a><\/noindex> release of the caching DNS server PowerDNS Recursor 4.2<\/a><\/noindex>, responsible for recursive name resolution. PowerDNS Recursor is built on the same codebase as PowerDNS Authoritative Server, but the recursive and authoritative DNS servers of PowerDNS evolve within different development cycles and are released as separate products. The project code is distributed<\/a><\/noindex> is licensed under GPLv2. <\/p>\n

The new version addresses all issues related to processing DNS packets with EDNS flags. In older versions of PowerDNS Recursor prior to 2016, packets with unsupported EDNS flags were ignored without sending a response in the old format, discarding the EDNS flags as required by the specification. This non-standard behavior was previously supported in BIND as a workaround, but within the conducted<\/a><\/noindex> initiative in February DNS flag day<\/a><\/noindex>, DNS server developers have decided to abandon this hack. <\/p>\n

In PowerDNS, the main problems with processing packets with EDNS were resolved back in 2017 with the release of 4.1, while the 4.0 branch released in 2016 experienced some specific incompatibilities that arose under certain circumstances, but generally did not impede normal operations. In PowerDNS Recursor 4.2, as well as in BIND 9.14<\/a><\/noindex>, workarounds for supporting authoritative servers that incorrectly respond to requests with EDNS flags have been removed. Until now, if no response was received after sending an EDNS flag packet for a certain period, the DNS server assumed that the extended flags were unsupported and sent a repeat request without the EDNS flags. This behavior has now been disabled, as the presence of such code led to increased delays due to repeated packet sending, higher network load, and ambiguity in cases of no response due to network failures, as well as hindered the implementation of EDNS-based features such as the use of DNS Cookies for DDoS attack protection. <\/p>\n

Next year, an event is planned DNS flag day 2020<\/a><\/noindex>, aimed at focusing attention on addressing<\/a><\/noindex> issues<\/a><\/noindex> IP fragmentation when processing large DNS messages. Within the initiative, is planned<\/a><\/noindex> recommended buffer sizes for EDNS will be set to values around 1200 bytes, and additionally, the processing of requests over TCP will be transitioned to mandatory support on servers. Currently, processing requests over UDP is mandatory, while TCP is desirable but not obligatory for operation (the standard prescribes the option to disable TCP). It is proposed to remove the option to disable TCP from the standard and to standardize the transition from sending requests over UDP to using TCP in cases where the established EDNS buffer size is insufficient.<\/a><\/noindex> support for TCP request processing is mandatory on servers. Currently, support for UDP request processing is required, while TCP is desirable but not essential for operation (the standard allows for the option to disable TCP). It is proposed to remove the option to disable TCP from the standard and standardize the transition from sending requests via UDP to utilizing TCP in cases where the configured EDNS buffer size is insufficient.<\/p>\n

The proposed changes under this initiative will eliminate confusion over the choice of EDNS buffer size and address the issue of fragmentation of large UDP messages, which often leads to packet loss and timeouts on the client side. On the client side, the EDNS buffer size will be constant, and large responses will be immediately sent to the client via TCP. Excluding the sending of large messages over UDP will also allow for the blocking attacks<\/a><\/noindex> of DNS cache poisoning, based on manipulating fragmented UDP packets (when fragmented, the second fragment does not include the header with the identifier, so it can be forged as long as the checksum matches).<\/p>\n

PowerDNS Recursor 4.2 addresses problems with large UDP packets and transitions to using an EDNS buffer size (edns-outgoing-bufsize) of 1232 bytes, instead of the previously used limit of 1680 bytes, which should significantly reduce the likelihood of UDP packet loss. The value of 1232 was chosen as it is the maximum at which the DNS response size, considering IPv6, fits within the minimum MTU value (1280). The truncation-threshold parameter, responsible for truncating responses to the client, has also been reduced to 1232.<\/p>\n

Other changes in PowerDNS Recursor 4.2:<\/p>\n