After a year and a half of development caching DNS server release , which is responsible for recursive name resolution. PowerDNS Recursor is built on the same codebase as PowerDNS Authoritative Server, but PowerDNS recursive and authoritative DNS servers are developed through different development cycles and are released as separate products. Project code licensed under GPLv2.
The new version eliminates all issues related to the processing of DNS packets with EDNS flags. In older versions of PowerDNS Recursor before 2016, it was practiced to ignore packets with unsupported EDNS flags, without sending a response in the old format, discarding EDNS flags, as required by the specification. Previously, such non-standard behavior was supported in BIND in the form of a workaround, but within the framework of February initiatives , the developers of DNS servers decided to abandon this hack.
In PowerDNS, the main problems in processing packets with EDNS were fixed back in 2017 in release 4.1, and in the 2016 branch released in 4.0, individual incompatibilities emerged that occurred under a certain set of circumstances and generally did not interfere with normal operation. In PowerDNS Recursor 4.2, as in , removed workarounds to support authoritative servers incorrectly responding to queries with EDNS flags. Until now, if there was no response after a certain period of time after sending a request with EDNS flags, the DNS server considered that the extended flags were not supported and sent a second request without EDNS flags. This behavior has now been disabled, as having such code resulted in increased delays due to resending packets, increased network load and ambiguity in the absence of a response due to network failures, and also interfered with the implementation of EDNS-based features such as the use of DNS Cookies to protect against DDoS attacks.
The next year it was decided to hold an event designed to focus on with IP fragmentation when processing large DNS messages. As part of the initiative fix the recommended buffer sizes for EDNS to 1200 bytes, and processing requests over TCP in the category necessarily supported on servers. Now support for processing requests over UDP is required, and TCP is desirable, but not required for operation (the standard prescribes the ability to disable TCP). It is proposed to remove the option to disable TCP from the standard and standardize the transition from sending requests over UDP to using TCP in cases where the set EDNS buffer size is not enough.
The changes proposed by the initiative will eliminate confusion about the choice of EDNS buffer size and solve the problem of fragmentation of large UDP messages, the processing of 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 immediately be sent to the client over TCP. Avoiding sending large messages over UDP will also block on DNS cache poisoning, based on the manipulation of fragmented UDP packets (when split into fragments, the second fragment does not include a header with an identifier, so it can be forged, for which it is enough just to match the checksum).
PowerDNS Recursor 4.2 addressed issues with large UDP packets and moved to use an EDNS buffer size (edns-outgoing-bufsize) of 1232 bytes instead of the previously used limit of 1680 bytes, which should significantly reduce the chance of lost UDP packets. The value 1232 is chosen because it is the maximum at which the DNS response size, taking into account IPv6, fits into the minimum MTU value (1280). The value of the truncation-threshold parameter, which is responsible for truncating responses to the client, has also been reduced to 1232.
Other changes in PowerDNS Recursor 4.2:
- Added mechanism support (X-Proxied-For), which is the DNS equivalent of the X-Forwarded-For HTTP header, which allows you to pass information about the IP address and port number of the original requester, forwarded through intermediate proxies and load balancers (for example, dnsdist). To enable XPF, the options "" and "β;
- Improved support for EDNS extension (ECS), which allows information about the subnet from which the original query was poisoned in a DNS request to an authoritative DNS server (data about the client's source subnet is necessary for the effective operation of content delivery networks). The new release adds settings for selective control over the use of EDNS Client Subnet: «» with a list of netmasks for which IP will be used in ECS in outgoing requests. For addresses that do not match the specified masks, the generic address specified in the "". Through the directiveΒ» you can define subnets, incoming requests with filled ECS values ββfrom which will not be replaced;
- For servers that process a large number of requests per second (more than 100 thousand), the directive "", which determines the number of threads to receive incoming requests and distribute them among worker threads (only makes sense when using the "").
- Added setting to define your own file with domains where users can register their subdomains instead of the built-in PowerDNS Recursor list.
The PowerDNS project also announced a six-month development cycle, with the next major release of PowerDNS Recursor 4.3 expected in January 2020. Updates for major releases will be rolled out over the course of a year, followed by another six months for vulnerability fixes. Thus, support for the PowerDNS Recursor 4.2 branch will last until January 2021. Similar development cycle changes have been adopted for the PowerDNS Authoritative Server product, which is expected to release 4.2 soon.
Key features of PowerDNS Recursor:
- Tools for remote collection of statistics;
- Instant restart;
- Built-in engine for connecting handlers in the Lua language;
- Full support for DNSSEC and ;
- Support for RPZ (Response Policy Zones) and the ability to define blacklists;
- Anti-spoofing mechanisms;
- Ability to write resolving results as BIND zone files.
- To ensure high performance, modern connection multiplexing mechanisms in FreeBSD, Linux and Solaris (kqueue, epoll, /dev/poll) are used, as well as a high-performance DNS packet parser capable of processing tens of thousands of parallel queries.
Source: opennet.ru