After a year and a half of development release of the caching DNS server , 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 licensed under GPLv2.
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 initiative in February , DNS server developers have decided to abandon this hack.
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 , 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.
Next year, an event is planned , aimed at focusing attention on IP fragmentation when processing large DNS messages. Within the initiative, recommended buffer sizes for EDNS will be set to values around 1200 bytes, and additionally, 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.
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 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).
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.
Other changes in PowerDNS Recursor 4.2:
- Support for the mechanism (X-Proxied-For), which is equivalent to the HTTP header X-Forwarded-For for DNS, allowing the transmission of information about the IP address and port number of the original request initiator, redirected through intermediary proxies and load balancers (e.g., dnsdist). Options for enabling XPF include" and "«;
- Enhanced support for the EDNS extension (ECS), which allows passing information about the subnet from which the original request was sent in DNS queries to the authoritative DNS server (data about the client's original subnet is necessary for effective content delivery networks). The new release adds settings for selective control over the application of EDNS Client Subnet:with a list of network masks for which the IP will be used in ECS in outbound requests. For addresses that do not fall under the specified masks, a common address specified in the directive. Through the directiveYou can define subnets, incoming requests with filled ECS values that will not be replaced;
- For servers handling a large number of requests per second (more than 100,000), the directive "" is proposed, which defines the number of threads for receiving incoming requests and distributing them among worker threads (meaningful only when using the mode "«).
- A setting has been added to define your own file with of domains in which users can register their subdomains, instead of the built-in list in PowerDNS Recursor.
The PowerDNS project has also announced a switch to a six-month development cycle, according to which the next significant release of PowerDNS Recursor 4.3 is expected in January 2020. Updates for significant releases will be developed throughout the year, after which there will be another six months of vulnerability fixes. Thus, support for the PowerDNS Recursor 4.2 branch will last until January 2021. Similar changes in the development cycle are adopted for the PowerDNS Authoritative Server product, with release 4.2 expected soon.
Key features of PowerDNS Recursor:
- Tools for remote statistics collection;
- Instant restart;
- Built-in engine for connecting handlers in Lua;
- Full support for DNSSEC and ;
- Support for RPZ (Response Policy Zones) and the ability to define blacklists;
- Mechanisms to combat spoofing;
- The ability to log resolution results as BIND zone files.
- To ensure high performance, modern connection multiplexing mechanisms are used in FreeBSD, Linux, and Solaris (kqueue, epoll, /dev/poll), as well as a high-performance DNS packet parser capable of handling tens of thousands of parallel requests.
Source: opennet.ru
