Final draft of RIPE DNS Resolver Best Common Practices
Fellow Task Force members, I have updated the document based on the feedback and text from Farzaneh and John. If you spot anything at this point, please let me know. I plan on turning the document over to the RIPE NCC for editing on 2024-03-29 (29 March 2024). I know that it is not perfect, but I'd like to get it published at some point. ð I included all changes except for the cache flushing suggestion: * Added description of the problems with ANY replies. * Added a section about name server identification. * Added the proposal to document as much about blocklists as possible, even if source of the blocklists themselves cannot be published. * Added a section about NTA transparency. Again, thank you all for the work you've put in. Cheers, -- Shane # DNS Resolver Recommendations About the DNS Resolver Best Common Practice Task Force https://www.ripe.net/participate/ripe/tf/dns-resolver-best-common-practice-t... ## Terminology * Open Resolver: A DNS resolver that accepts queries from any client. Often the result of misconfiguration. * Public Resolver: A resolver intentionally configured to be an open resolver. ## Introduction ### What Is This Document? Who Is It For? This document presents recommendations and best current practices for operating DNS resolvers, both public and non-public ones. It covers technical aspects of operations and provides best practice recommendations for data management, with a particular focus on user privacy, security, and resilience. The document serves as guidance for the wider Internet community, offering input to: * Those running public DNS resolver services, and * Those who want to make informed choices between such services. Its purpose is to provide clear guidance and promote effective practices in DNS resolver operation. The intended audience is not the entire DNS community. Advice here is probably not useful for operators of authoritative servers, domain registrars, and so on. It is also not meant to be an introductory or educational document. There are many documents which cover the basics of DNS and the roles of organizations in it; a good overview is: Addressing the challenges of modern DNS - a comprehensive tutorial by van der Toorn et al. https://ris.utwente.nl/ws/files/282427879/1_s2.0_S1574013722000132_main.pdf The document does not consider how to measure adherence to these recommendations. So it is not intended to be used for certification, although certification created based on the principles here is possible. ### How Is This Document Organized? This document has a number of sections, and specific recommendations in each section. The intent is for each recommendations to have clear guidance at the top, and then background and discussion related to the recommendation afterwards. Each recommendation indicates whether it is mostly for operators of public resolvers or for operators of any resolver. ### About Recomendation Text This is not a standards document, and does not propose any way to measure compliance or interoperability. It does use words like "should" or "may be" throughout. These are meant to be interpreted in the usual English sense, and not as IETF-style RFC 2119 jargon. ## System and Network Hardening ### Infrastructure considerations Running any Internet service requires attention to the infrastructure used to operate it. This section discusses various approaches that can be used to run a DNS resolver. Everything applies to both public and non-public DNS resolvers. #### Bare metal or public cloud All DNS resolver software can run either on dedicated servers (rented or colocated), or in virtualized clouds, or in a combination of those. Every approach has pros and cons. Most of these are not specific to running DNS resolvers, however, some of them are. **Running DNS resolver instances as OS level daemons on bare metal hosts:** Pros: - Performance: Bare metal servers have direct access to the underlying hardware, and can offer superior performance/cost balance by avoiding the overhead associated with virtualization. Moreover, you have full control over the server's configurations, down to the hardware level, which can be beneficial for performance and cost optimization once you get the understanding of your typical work load during peak hours. - Data Security: Since you are in control of the physical servers, there is no risk of data leakage that can occur due to vulnerabilities in multi-tenant virtualization platforms, including CPU cache-based side-channel vulnerabilities. It could be argued that attacks targeting such issues are rare, and their impact on a DNS resolver service is low, but potential breaches may have significant privacy impact. It is advised to evaluate this against your organisation's risk model, or to discuss this with your information security compliance experts. - Predictability: Because there is no virtualization layer and no "noisy neighbours" on the host, the performance of your servers is more predictable. Cons: - Cost of failure: If you pick hardware configuration that is not optimal for the workload of your DNS resolver, you may need to upgrade and replace hardware components afterwards. Ways to reduce this risk include renting servers instead of buying them, carrying load testing with data similar to production workloads, and providing limited beta access to the service before it fully enters the production phase. - Scalability: Scaling up with physical servers means acquiring or renting, installing, and configuring new hardware, which will take more time than provisioning new virtual servers in a cloud environment. Moreover, most cloud environments will provide you with cluster autoscaling features, which could barely be achieved in bare metal. - Maintenance: You will be responsible for all server maintenance tasks, including hardware issues, which can require significant effort and specific expertise. - Redundancy: Setting up high availability and disaster recovery strategies can be more complex and time consuming compared to the cloud, where these features are often provided as value added products. See the Redundancy section for more details. **Running DNS resolver instances in containers in a public cloud:** Pros: - Scalability: Clouds excel at scaling applications. You can scale up and down rapidly based on load, which is important for a DNS resolver that needs to handle variable query loads. In case of regional or geographically distributed resolvers, in every region where the resolver would be deployed, daily periodicity is likely to be observed, for example peak hour is likely to occur around 19:00 local time, and off-peak hours may begin at around 01:00-03:00. In a situation like that, using cluster autoscaling features and tools, you can run less instances in the night and more instances throughout the day, which may help to optimize your cloud hosting costs. - Fault Tolerance and High Availability: Most clouds have built-in strategies, features, and products for handling node failures, which can increase your service's availability. - Deployment and Management: Cloud providers offer built-in methods to deploy and manage applications, which can simplify operations and reduce the likelihood of human errors if your infrastructure management department is already familiar with these tools. - Cost: While this largely depends on your specific usage, cloud services can sometimes be more cost-effective than managing your own physical servers, especially when you consider the total cost of ownership, including power, cooling, and maintenance. Cons: - Performance: The virtualization layer of public clouds can impact performance. While this certainly could be mitigated through scaling the number of virtual hosts, the cost would also increase accordingly. - Complexity: Advanced cloud technologies are complex systems which come with a steep learning curve. Without prior experience, properly configuring and managing a cloud-based compute cluster can be challenging. - Cost Variability: While the cloud can be cheaper, it can also be more expensive if not properly managed. Costs can rise unexpectedly based on traffic. Make sure to always set some limits on how much may be spent on hosting in the cloud control panel, and to set up notifications to be sent to you when these thresholds are about to be triggered. - Multi-tenancy Risks: In a public cloud environment, the "noisy neighbour" problem could potentially affect your service's performance. Additionally, even though cloud providers take steps to isolate tenant environments, vulnerabilities could potentially expose sensitive data (see the previous section for a detailed explanation). **Additional considerations** - In today's environments, Kubernetes and Terraform are sometimes used as a substitute for cloud APIs when it comes to production services' management. When running a DNS resolver in a Kubernetes cluster on top of a public cloud environment, all the pros and cons of the public cloud apply; basically, Kubernetes becomes your public cloud provider. If you have significant prior experience running services in Kubernetes in production, you may successfully replicate your experience with the DNS resolver software. Otherwise, we would advise against Kubernetes in this case. - The only reason we may find to run a DNS resolver in a Kubernetes cluster on top of self-hosted dedicated servers is when you have significant hands-on experience with Kubernetes and it is natural for you to manage applications this way. Otherwise, running DNS resolver daemons in containers brings little, if any, benefit. Autoscaling features are not available to you in this case, and neither horizontal nor vertical pod autoscaling is of any use, because DNS resolver software typically scales in-host by itself just fine. - When designing a cluster of resolvers for autoscaling, keep in mind that newly spawned resolver machines would need to populate resolver cache first before they are fully useful. Your DNS resolver software may provide cache replication mechanisms. Otherwise, it is safe to overprovision clusters somewhat under heavy load, and discarding excessive instances once all the caches are populated and the average load of a compute instance decreases. In addition, it may be worthwhile to consider sharing cache data between instances. - It is always advised to prefer environments your infrastructure management team is familiar with. ### Software considerations #### Open Source **Recommendation**: Choose any well-maintained DNS software you are comfortable using. Regardless of which software you choose, ensure you have somewhere to go for support. In the case of open source software, consider providing financial support to ensure continued development. Some open source maintainers take donations, while others offer support contracts. There are both open source and proprietary implementations of DNS resolver software. Mixing these is also possible, for example, by using proprietary extensions with open source software or deploying open source software modified in-house. General observations: - Software licensing is orthogonal to software security. Neither is proprietary software less secure on principle nor are contributions by "unknown" developers more of a risk in open source. Benefits of open source: - Open source allows for inspection, independent auditing, and troubleshooting. - Open source can avoid vendor lock-in. - Open source can aid internet standards development. Widely-deployed open source implementations allow proponents of standards drafts to contribute proof of concept implementations without permission or cooperation of vendors. Drawbacks of open source - Both open source and proprietary software require skilled maintenance, which has costs. Proprietary licensed software or appliances typically come with license fees to cover these. In contrast, open source licenses decouple usage by operators from monetary compensation to developers. It is up to operators to consider the financial sustainability of continued maintenance of the open source DNS software they depend upon. Please also consider deploying different software implementations to ensure diversity, as discussed in the diversity section below. ### Networking considerations #### IPv4 and IPv6 **If available, both IPv4 and IPv6 must be deployed.** Large parts of the authoritative DNS are only accessible via IPv4, so the resolver must be able to originate IPv4 queries. Authoritative DNS that is only accessible via IPv6 is very rare. Depending on the connectivity of clients, a resolver may be IPv4-only, IPv6-only, or support IPv4 and IPv6. #### Addressing **Using multiple IP addresses for the service address should be considered.** Using 2 or more IPv4 addresses and 2 or more IPv6 addresses from different RIR will allow resilience in failure at an RIR, either governance, security, or technical. Note that support for multiple addresses for recursive resolvers varies and some clients perform poorly if any address does not respond normally. There is no need to pick an IPv4 address with all octets the same, like 2.2.2.2 or 11.11.11.11. **Publishing a list of back-end addresses used for resolving should be considered.** Publishing a list of back-end addresses used for resolving can be useful for other network & DNS operators (for example, geo-IP location, making sure data is getting to correct places, and so on). #### High Availability This can be considered in terms of local and global scope. ##### Local scope Inside a single location/region, such as an office, campus, or small ISP network, the main availability concern is that a resolver is always reachable. Client systems can be configured with multiple resolver addresses, but the failover behaviour of stub resolvers to a second address can be painful. Ideally the primary address is highly available and such fallback rarely required. How much effort is put into ensuring this is true should probably scale in line with the number of users, or sensitivity of the clients using that resolver to delayed resolution. There are several ways to promote high availability of an individual resolver address, such as dedicated load balancing equipment, or network techniques like VRRP, or IP anycast. These generally have in common a pool of recursive servers and the means to direct queries to them when a health check has determined them to be capable of answering those queries. Dedicated free or commercially produced, hardware or software load balancing solutions are available. These typically own the resolver IP address and forward queries to the currently available instances of a pool of recursive servers. VRRP enables a technique to make the resolver IP address available on multiple servers, often used to provide automatic failover between two. A pool of recursive servers using this technique must reside in the same broadcast domain. IP anycast in the local scope typically involves a pool of recursive servers advertising a route to a shared resolver IP address into a routing protocol. This can be configured in failover or load-sharing configurations. A load sharing configuration typically requires network equipment able to balance traffic to a destination over equal cost paths (ECMP). A pool of recursive servers using this technique can be distributed in different parts of the network. ##### Global scope The same concerns as for local service availability are present in the global scope, with the added issue that DNS resolution over long distances may be slow. Practically speaking, only multiple resolver addresses, or IP anycast are useful strategies here. The motivations for finding better failover solutions than multiple resolver addresses have been covered above. IP anycast in the global scope means routing the same IP prefix to more than one location. This can provide effective solutions for failover and, when optimally configured for routing client queries to the topologically least distant recursive server location. IP anycast in the global scope requires the use of globally routable prefixes. If a separate prefix is to be used for anycasting, usually this means a /24 in IPv4 and a /48 in IPv6, as those are the smallest sizes that will be widely propagated in BGP. A common practice is to use a covering prefix (/23 in IPv4 or /47 in IPv6) for fallback, and a more-specific prefix (/24 or /48) for the traffic. The more-specific prefix can then be withdrawn to send traffic to a backup site; this will happen automatically if the site is disconnected from routing. [RFC7094](https://www.rfc-editor.org/rfc/rfc7094.html) discusses anycast architecture in detail, including references to various other RFC which discuss anycast in general and to DNS in particular. [RFC4786](https://datatracker.ietf.org/doc/html/rfc4786) discuses operation of anycast services. ##### Generally Operators of a globally scoped recursive service are encouraged to also adopt the local scope recommendations in each of the locations where the service is provisioned. Though the above deals with the shortcomings of reliance on stub resolver failover between a list of addresses those recommendations shouldnât be seen as an exclusive alternative. Multiple resolver addresses, where each is provisioned using differing failover strategies, can provide a resolver of last resort and further improved resilience. #### Ingress Filtering **Ingress Filtering to follow BCP 38 should be deployed.** DNS normally uses UDP traffic, which makes it a common vector of both [reflection](https://en.wikipedia.org/wiki/Reflection_attack) and [amplification](https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-a...) attacks. To minimize the amount of spoofed traffic that a resolver responds to, the network should be configured as recommended in [BCP 38](https://www.rfc-editor.org/rfc/rfc2827.html). #### RPKI Sign Advertised Routes **Route Advertisements should be signed using RPKI** Using RPKI to sign any route advertisements - either toward authoritative servers or toward DNS clients - is straightforward to do and will reduce the impact of BGP misconfigurations and some BGP hijacking attempts. RPKI validation is also possible, although the effort is greater. It is possible that the hosting provider or the transit provider for your service validates BGP; asking and making this part of your selection criteria is reasonable. #### (D)DoS measures Denial-of-Service (DoS) attacks, both distributed (DDoS) and not are a threat to any Internet service. Network operators for a service providing any DNS service must be prepared for large amounts of attack traffic. In addition to attacks on the service itself, a resolver may be used both as an attack reflector and as an attack amplifier. Active monitoring of network and service usage, careful logging, and a security team that is able to respond to problem reports is necessary. Mitigation techniques will include filtering or rate-limiting traffic, both on the authoritative and client side of the resolver. ### Capacity planning #### Server capacity If using a model that is easy to scale (cloud based, or Kubernetes based, or similar), then getting server capacity correct is largely a question of budgeting. If using a less-flexible model (bare metal for example), then under-estimating will mean problems delivering service. Hardware performance varies widely, as does operating system and resolver performance. Some lab testing will be necessary to estimate the number of systems needed. #### Network capacity Since DNS is mostly UDP-based, it is often easy to generate large amounts of spoofed traffic to and from DNS servers. DNS traffic is small compared to application traffic (videos and other content), but still significant. Authoritative server operators often build their networks and servers to handle 10 times their normal load. Recursive server operators may need to do the same, although the service only accepts traffic from IP addresses that cannot be spoofed (for example users within a network that operated by the same company) then this can be reduced, for example to 3 times normal load. To estimate expected load, the best approach is to examine historical usage for the actual expected users of the system. ### Resilience #### System Diversity In addition to the software considerations above, operators should consider whether to use different server implementations to provide service. This allows continued operation if a critical vulnerability is found in one implementation, by shifting traffic to other implementations. Placing resolvers and control systems in different physical locations will allow continued operation in the event of a disaster or other problem that impacts a single location. In addition, ensuring diverse connectivity to other networks will prevent single points of failure on the network side. Ensuring network diversity may take some care, as it is not always obvious what fate is shared between any given path; this may be physical, virtual, or organizational, and my sometimes be hidden. #### Security In addition to the DNS-specific security considerations, normal security best practices for any Internet service should be followed, including updating software updated regularly, patching software as soon as possible for any known security vulnerabilities, following CERT announcements and so on. #### Certification It may be useful or required for an organization to follow specific certifications, such as ISO or ITIL. These can be government-defined or industry-defined. For end users there is typically not much direct value, but business customers will often look for services that are operated by organizations meeting such standards. ## DNS configuration knobs The DNS is an old protocol that has a lot of settings that can be tweaked. This section reviews these and provides recommendations on which should be used for a resolver. ### DNSSEC validation **DNSSEC validation should be enabled.** For: All DNS resolver operators. DNSSEC validation is the best way to ensure that the answers from the owner of domain name being queried are returned. The root KSK must be updated when it changes. While [RFC5011](https://www.rfc-editor.org/rfc/rfc5011.html) defines an automated way to do this, a resolver operator will probably either manage this trust anchor directly or have it updated via OS updates. [RFC9364](https://www.rfc-editor.org/rfc/rfc9364.html) provides a lot of useful information, and links to further documents about DNSSEC. However, operators usually do not need to know the details, and can simply ensure that DNSSEC validation is enabled in their software. Resolver software that does not support DNSSEC validation should be avoided. ### DNS Transport Protocols **UDP and TCP must be supported.** For: All DNS resolver operators. UDP is what most clients use, and TCP is necessary for DNS answers that are too large for a single UDP packet. [RFC7766](https://www.rfc-editor.org/rfc/rfc7766.html) explains why TCP is necessary in more detail. ### Packet Fragmentation Avoidance **Servers should be configured to avoid fragmentation.** For: ALL DNS resolver operators. Packet fragmentation can cause issues with DNS over UDP, especially over IPv6. These issues can be minimized by choosing implementations that set IP options to avoid this, and by taking care with EDNS0 message sizes. Recommendations are available in [draft-ietf-dnsop-avoid-fragmentation](https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/). ### Encrypted DNS **At least one of DNS-over-TLS (DoT), DNS-over-HTTPS (DoH), and DNS-over-QUIC (DoQ) should be supported.** For: All DNS resolver operators. DoT, DoH, and DoQ are different technologies that all provide an encrypted channel between the resolver and the authoritative server. DoT is the oldest, and provides encrypted DNS using TLS. DoH uses HTTP over TLS as a way to transmit queries and answers, and is widely supported by web browsers. DoQ is the newest, and provides advanced features such as separate streams for each query, avoiding the "head of line" blocking problem common with all protocols layered on top of TCP (such as DoT and DoH). - DoT - [RFC7858](https://www.rfc-editor.org/rfc/rfc7858.html) - DoH - [RFC8484](https://www.rfc-editor.org/rfc/rfc8484.html) - DoQ - [RFC9250](https://www.rfc-editor.org/rfc/rfc9250.html) **Discovery of DNS Designated Resolvers** There are new mechanisms that allow DNS clients to use DNS records to discover encrypted DNS configurations. Resolvers should publish DNS records to assist clients finding encrypted resolvers. - Discovery of Designated Resolvers - [RFC9462](https://www.rfc-editor.org/rfc/rfc9462.html) QUESTION: Do we need to publish certificate in other ways that via the DDR mechanisms? ### QNAME Minimization **QNAME minimization should be enabled.** For: All DNS resolver operators. Using QNAME minimization, a resolver does not send the full name that it is trying to resolver to authoritative servers higher in the DNS hierarchy. So, for example, when querying "atlas.ripe.net" the servers for ".net" would only be asked for "ripe.net". This improves privacy for the end user querying the name. [RFC7816](https://www.rfc-editor.org/rfc/rfc7816.html) covers QNAME minimization. ### Aggressive NSEC caching **Aggressive NSEC caching may be enabled.** For: Public resolver operators. "Aggressive NSEC caching", meaning negative caching based on NSEC and NSEC3 values, can reduce traffic greatly. It is important to protect against random subdomain attacks. This style of caching takes advantage of the way that NSEC and NSEC3 records cover a range of names in a zone. A resolver can know that a query falls within such a range without sending any further queries, by remembering the NSEC or NSEC3 redords that is has seen as answers to earlier queries. Aggressive NSEC caching is almost always a good idea. However enabling this is less important for DNS resolver operators who have a close relationship with users, since they can stop attacks by blocking users or otherwise directly dealing with the source of abusive queries. [RFC8189](https://www.rfc-editor.org/rfc/rfc8189.html) describes negative caching in detail. ### ANY Queries **ANY queries responses should be limited.*** For: All resolver operators. Public or large-scale resolvers should be exceptionally careful with queries of type ANY, which return all all records at a given name. If a resolver replies with all of the records cached for a given type, the response can be much larger than for a single record type. Strict limits should be enforced on volumes of such queries to prevent amplification abuse, or truncation should be applied to prevent spoofed redirections. [RFC8482](https://www.rfc-editor.org/rfc/rfc8482.html) describes several approaches to limiting ANY responses. ### Local Root **Local root should be used.** For: Public resolver operators. Running a local root has several benefits, but it is an additional component to maintain. For public resolver operators this is definitely worth the cost, but other resolver operators may choose to simply send all queries to the well-distributed root name servers. [RFC8806](https://www.rfc-editor.org/rfc/rfc8806.html) describes local root, including several example configurations. In the future it will be possible to use ZONEMD to validate the copy of the root zone obtained before using it. This is currently available for the root zone. [RFC8976](https://www.rfc-editor.org/rfc/rfc8976.html) describes ZONEMD. ### DNS Cookies **Interoperable DNS Cookies may be supported.** For: Public resolver operators. DNS cookies provide some improved security over plain UDP, and are designed to be more lightweight than TCP. If more than one server is responding for a given IP address, then the Server Secret must be shared by all servers, and the answer must be constructed in a consistent manner by all server implementations. Since client-side support for DNS cookies is not very widespread, and since managing server-side secrets involves some work, the costs may outweigh the benefits for some non-public resolver operators. [RFC7873](https://www.rfc-editor.org/rfc/rfc7873.html) describes DNS cookies, and [RFC9018](https://www.rfc-editor.org/rfc/rfc9018.html) standardizes shared DNS cookies. ### TTL Recommendations **TTL limits may be adjusted.** For: All DNS resolver operators. Software typically defaults to a maximum stored TTL of 1 or 2 days. A lower TTL will mean removing rarely-used records that have long TTL, and should not have much operational impact from a CPU or network point of view. It is possible to set a minimum TTL in many implementations. This is a violation of the DNS protocol, although may be useful to reduce load from records with very low TTL (less than 5 seconds). Note that software may set different maximum and minimum TTL independent of the results that the resolver returns. That may have a significant impact on queries as well, but resolver operators cannot influence that. ### TTL-based Record Pre-Fetch **TTL record pre-fetch should be enabled when available.** For: All DNS resolver operators. Some resolvers have the ability to look up a record before it has expired from cache, in order to refresh the value and extend the TTL. This way there is never a time when the records are missing from the cache. This is not currently standardized, but a form of this was proposed in the IETF as [DNS Hammer](https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-hammer-03). We recommend turning this feature on if available. ### EDNS Client Subnet (ECS) **ECS may be enabled.** For: All DNS resolver operators. EDNS Client Subnet (ECS) allows the resolver to include information about the IP address of the client querying it when sending messages to authoritative servers. This may allow authoritative servers to provide different answers which are more appropriate for the client. However, ECS will increase the amount of cache space required by resolvers, may reduce DNS performance, and may have privacy implications. A resolver operator that has clients that are limited to a specific region may see no benefit. A resolver operator that has a widely distributed anycast network may not have much benefit from ECS, since the locations that initiate the query will be close to the client. But a resolver operator that answers client queries only from a few locations, and expects clients to come from a wide area, may provide better service for end-users by supporting ECS. EDNS client subnet is described in [RFC7871](https://www.rfc-editor.org/rfc/rfc7871.html), an informational RFC. ### Extended DNS Errors **Extended DNS errors should be enabled.** For: All DNS resolver operators. DNS traditionally provides very broad error reporting, SERVFAIL being the most common. This makes diagnosing and fixing problems difficult. Extended DNS errors provide extra information about failures, for example expired DNSSEC signatures. They also allow resolver operators to report administrative reasons for DNS failures, such as blocks due to legal requirements. [RFC8914](https://www.rfc-editor.org/rfc/rfc8914.html) defines extended DNS errors. ### Negative Trust Anchors **Negative trust anchors may be deployed.** For: All DNS resolver operators. Negative trust anchors (NTA) allow a resolver operator to handle a case where an authoritative server has a DNSSEC problem and becomes inaccessible. They basically disable DNSSEC checking for a domain. When this is warranted is difficult to know with certainty, and will usually requires some manual checking. Since DNSSEC validation is now widespread, DNSSEC failures on the authoritative side will impact many resolvers. Because of these reasons this document does not recommend NTA, but also does not recommend that a deployment avoid NTA if it makes sense for that environment. Negative trust anchors are documented in [RFC7646](https://www.rfc-editor.org/rfc/rfc7646.html). ### DNS Error Reporting **DNS error reporting may be enabled.** For: All DNS resolver operators. DNS error reporting is a way for resolver operators to let authoritative operators know about problems in authoritative servers or zones. It provides little direct value for the resolver operators, but over time should improve the overall quality of the DNS ecosystem. It is neither widely deployed nor standardized, but hopefully will be both soon. Resolver operators are encouraged to enable DNS error reporting when it is available. DNS error reporting is proposed in [draft-ietf-dnsop-dns-error-reporting](https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting). ### Trust Anchor Reporting **Trust anchor reporting should be enabled.** For: All DNS resolver operators. Trust anchor reporting is a way for resolver operators to convey their DNSSEC trust anchor configuration to the operator of the zone that it is for. For most resolvers this is only the root zone. This information is intended to be used during a root KSK rollover to ensure that it is safe to proceed. In the future ICANN is planning an algorithm roll for the root KSK, and this information could be helpful. Resolver operators are encouraged to enable trust anchor reporting. [RFC8145](https://www.rfc-editor.org/rfc/rfc8145.html) covers trust anchor reporting, in both possibilities available. ### Name Server Identification **Servers should be configured to identify themselves.** For: All DNS resolver operators. Large resolver operations, especially publicly available resolvers, should support an in-band method of discovery that is obvious to permit users to discover what node has answered their query. This improves troubleshooting significantly, and may be useful for research and testing purposes. NSID (Name Server Identifier) is ideal for this, though also âCH TXT id.serverâ support is also reasonable. Geographic hints should be provided in this data, though specific host data is optional for arrays of servers in clusters. IATA codes have traditionally been used for naming points-of-presence, though this is at the discretion of the operator. [RFC5001](https://www.rfc-editor.org/rfc/rfc5001.html) describes NSID. [RFC4892](https://www.rfc-editor.org/rfc/rfc4892.html) describes name server identification in general, and documents the pre-NSID approaches. ## Privacy, Filtering, Transparency ### Privacy & anonymity Operators are advised to apply [RFC8932](https://www.rfc-editor.org/rfc/rfc8932.html) "Recommendations for DNS Privacy Service Operators" as follows: 1. its operational and policy guidance related to DNS encrypted transports and data handling, by applying all "Threat mitigations" (thereby by meeting its level of "minimally compliant") and additionally by applying the "Optimizations" on EDNS Client Subnet listed in section 5.3.1. 2. its framework on a Recursive operator Privacy Statement, by publishing a privacy statement on their website that is compliant with Section 6. #### Logging considerations 1. Public privacy policy: DNS resolvers are recommended to publish their privacy policies transparently on their website. It can be a brief privacy commitment as well or be more elaborate on how the privacy policy was made. (See for example [Cloudflare's statement](https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver) or [Quad9's privacy page](https://www.quad9.net/service/privacy/).) Such policies should explicitly mention the sampling rate of DNS queries/responses that are kept, and whether these are anonymized. 2. Third party access to personal data: it seems that the only critical personal data that DNS resolvers collect are IP addresses and the queries that are resolved. The other meta data collected can be used to have an understanding of for example which user accessed which website which can reveal information about a personâs health, lifestyle and other personal preferences (we call this profiling). For example, resolving the website for alcoholics anonymous may tell you something about the health of a person behind an IP address. IP addresses are personally identifiable information. Follow the applicable privacy laws or privacy principles when receiving third party requests to access. Resolvers should only comply with such requests when balancing legitimate third party interest with other fundamental rights. 3. Access to data for researchers: how it is done, who has access and who can request access, how the resolver makes a decision to give access (validated and credible researchers, what they can access and other issues) 4. Data minimization: do not collect personal information not needed for critical operations. Only retain or use what is being asked (the query). If collecting data to make the service more private and secure, explain the rationale for each piece of data (data collection purpose) 5. Encryption: If data is encrypted, explain how it has been encrypted (DoH, DoT, or so on). 6. Data security and retention: when to delete the data and how it is stored #### Advertisement Policy If there is any advertising from the service, the policy should be published as well as how it can potentially affect the users' privacy. ### Filtering and blocking #### Block Lists Resolvers can be directed to block or modify answers in various ways. Blocklists may be provided by governments, communities, or other parties (for example security firms). Response Policy Zone (RPZ) allows a way to both document specific modifications that resolvers will make to DNS answers, and send the rules to resolvers. This allows updates to occur very quickly. If RPZ or some other high-speed blocking technology is used, the parties supplying these sources must be highly trusted, as changes to blocklists will usually immediately impact user queries. RPZ is not standardized, but there is an IETF draft, [draft-vixie-dnsop-dns-rpz](https://datatracker.ietf.org/doc/draft-vixie-dnsop-dns-rpz/00/). #### Legal blocking **Legal requests and blocking and filtering laws:** DNS resolvers should not filter content and block access to web-services. When the local law requires blocking, and the law applies to the resolver, the resolver should transparently disclose a list of blocked websites and services, when possible (disclosing such a list may not be allowed by law or regulation). Similarly, the resolver should disclose the source of such block lists, when possible. If it is not possible to disclose the source of blocklists, operators should try to be as transparent as possible about how they receive those blocklists, based on what criteria, and how they mitigate errors and false positives. Disclosing which organizations operators interact with, how they liase, and so on, can help users understand the impact on the service provided. If possible, resolvers should provide information about blocked responses via the Extended DNS Error with the Blocked, Censored, Filtered, or Prohibited code - whichever applies best - along with a text why the response was blocked, censored, filtered, or prohibited. [RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html#section-4.16) provides information about the meanings of the different codes. **Community governance of blocklists:** blocklists, if mandatory, have to be audited and assessed by third parties and there should be a right to appeal for those blocked. The Internet community can vet the blocklists from time to time to avoid blocking access to websites that are mistakenly blocked. During crisis - when mistakes can have drastic effects on accessing a critical service - preferably filtering and blocking should not be used. #### Opt-in/Opt-out Mechanisms End users may choose to use a DNS resolver that filters specific kinds of traffic. For example, they may wish to avoid potential malware web sites. Or resolver operators may be required to default to filtering but allowed for to provide an unfiltered DNS resolver service. Depending on the specific requirements, a resolver service may publish different IP addresses and what type of filtering applies to each address. It is also possible to perform client authentication and authorization, using IP-based authentication, TSIG keys, or client-side TLS certificates. ### Transparency DNS resolvers usually provide transparency reports once a year. The reports inform the public about disclosure of user information and removal of content required by law enforcement and other government agencies. Transparency reports should (to the extent that the law allows) indicate which government agencies and law enforcement agencies request access on what basis. It should also be clear from the transparency reports what kind of data has been requested and if content removal and content blocking have been requested. Categories of data include: Content Data, Basic Subscriber Data, Other Non-Content Data and Content Blocking. #### Voluntary certificates and standards Some DNS resolvers opt for obtaining certificates in security and privacy. Some also undertake audits on their privacy practices. See for example:https://www.cloudflare.com/trust-hub/compliance-resources/ #### Negative Trust Anchor reporting Negative Trust Anchors (NTA) are discussed in the previous section on DNS configurations. If NTAs are present in the resolver, they should be published with as much detail as possible about them. This includes reasons for insertion, dates of activation and expected removal dates, or a published review date or cycle for when NTAs should be actively examined for deletion if such fine-grained information cannot be shared. NTAs are equivalent to a security fault, and may even be more significant than a block event as they remove expected trust behavior with limited signal of that trust downgrade ("limited" because few if any clients care about those response bits changing.). #### Human rights considerations DNS resolvers can opt for declaring their understanding of their responsibilities regarding human rights from the Universal Declaration of Human Rights. Specifically, Quad9 mentions rights to freedoms without distinction made on the basis of country, no interference with privacy, the right to freedom of opinion and expression, the right to peaceful assembly, and the right to freely participate in the cultural life of the community. See [Quad9's Human Rights Considerations](https://www.quad9.net/privacy/human-rights-considerations/) for the full statement. It also invokes other human rights related solutions other than [UDHR](https://www.un.org/en/universal-declaration-human-rights/) such as Articles 8 and 9 of Resolution 42/15 of the United Nations Human Rights Council on the right to privacy in the digital age of 26 September 2019 more directly define the responsibilities of the private sector toward the furtherance of human rights in modern terms. They also follow the Guidelines for Human Rights Protocol and Architecture Consideration of the Human Rights Protocol Considerations Research Group at Internet Research Task Force. The latest version of the IRTF [Guidelines for HRPC](https://tools.ietf.org/html/draft-irtf-hrpc-guidelines) may be considered for all network operators. ## Appendix A: Why Did RIPE Write This Document? There is increasing concern that large open DNS resolvers will become centralised points of DNS operations on the Internet. In order to address this, the European Commission issued the [DNS4EU](https://hadea.ec.europa.eu/calls-proposals/equipping-backbone-networks-high-...) proposal. However, such an initiative could lead to centralised guidance or regulation which might interfere with the decentralised way the Internet infrastructure works - including the DNS. See for reference the [RIPE NCC Open House discussion](https://labs.ripe.net/author/chrisb/dns4eu-ripe-ncc-open-house-discussion/) on this topic. Rather than attempting to respond to the EC proposal or organize specific DNS resolver deployments, the RIPE community has decided that it is best able to provide advice and guidance. The RIPE Community is well positioned to provide a set of Best Current Practices that operators of Open DNS Resolvers will be encouraged to subscribe to.
Many thanks for putting this together, Shane and thanks to all of you for contributing to this document! I am looking forward to seeing this published as a RIPE Document so it can become a useful source of knowledge for DNS resolver operators. Kind regards, Mirjam On 17/03/2024 17:09, Shane Kerr wrote:
Fellow Task Force members,
I have updated the document based on the feedback and text from Farzaneh and John.
If you spot anything at this point, please let me know. I plan on turning the document over to the RIPE NCC for editing on 2024-03-29 (29 March 2024). I know that it is not perfect, but I'd like to get it published at some point. ð
I included all changes except for the cache flushing suggestion:
* Added description of the problems with ANY replies.
* Added a section about name server identification.
* Added the proposal to document as much about blocklists as possible, even if source of the blocklists themselves cannot be published.
* Added a section about NTA transparency.
Again, thank you all for the work you've put in.
Cheers,
-- Shane
[..]
hi Shane, Farzaneh, tf, Thanks for doing all this work to get this work wrapped up. Apologies for missing the last meeting. On Sun Mar 17, 2024 at 17:09 CET, Shane Kerr wrote:
If you spot anything at this point, please let me know.
I took the time to read through once more. The first part is nits mostly. I have more substantial comments on the privacy content that I helped write myself, which is a bit awkward at this point in time, but I'd rather get them addressed before we go to publication. They are mostly editorial in nature and do not change the substance of what was shared with the community. @Farzaneh, can you have a look? I'd like to hear what you think. kind regards, Maarten
# DNS Resolver Recommendations
About the DNS Resolver Best Common Practice Task Force
https://www.ripe.net/participate/ripe/tf/dns-resolver-best-common-practice-t...
## Terminology
* Open Resolver: A DNS resolver that accepts queries from any client. Often the result of misconfiguration.
* Public Resolver: A resolver intentionally configured to be an open resolver.
## Introduction
### What Is This Document? Who Is It For?
This document presents recommendations and best current practices for operating DNS resolvers, both public and non-public ones. It covers technical aspects of operations and provides best practice recommendations for data management, with a particular focus on user privacy, security, and resilience.
The document serves as guidance for the wider Internet community, offering input to:
* Those running public DNS resolver services, and
Should we remove "public" here?
* Those who want to make informed choices between such services.
Its purpose is to provide clear guidance and promote effective practices in DNS resolver operation.
The intended audience is not the entire DNS community. Advice here is probably not useful for operators of authoritative servers, domain registrars, and so on. It is also not meant to be an introductory or educational document. There are many documents which cover the basics of DNS and the roles of organizations in it; a good overview is:
Addressing the challenges of modern DNS - a comprehensive tutorial by van der Toorn et al.
https://ris.utwente.nl/ws/files/282427879/1_s2.0_S1574013722000132_main.pdf
The document does not consider how to measure adherence to these recommendations. So it is not intended to be used for certification, although certification created based on the principles here is possible.
### How Is This Document Organized?
This document has a number of sections, and specific recommendations in each section. The intent is for each recommendations to have clear guidance at the top, and then background and discussion related to the recommendation afterwards. Each recommendation indicates whether it is mostly for operators of public resolvers or for operators of any resolver.
### About Recomendation Text
This is not a standards document, and does not propose any way to measure compliance or interoperability. It does use words like "should" or "may be" throughout. These are meant to be interpreted in the usual English sense, and not as IETF-style RFC 2119 jargon.
## System and Network Hardening
### Infrastructure considerations
Running any Internet service requires attention to the infrastructure used to operate it. This section discusses various approaches that can be used to run a DNS resolver. Everything applies to both public and non-public DNS resolvers.
#### Bare metal or public cloud
All DNS resolver software can run either on dedicated servers (rented or colocated), or in virtualized clouds, or in a combination of those. Every approach has pros and cons. Most of these are not specific to running DNS resolvers, however, some of them are.
**Running DNS resolver instances as OS level daemons on bare metal hosts:**
Pros:
- Performance: Bare metal servers have direct access to the underlying hardware, and can offer superior performance/cost balance by avoiding the overhead associated with virtualization. Moreover, you have full control over the server's configurations, down to the hardware level, which can be beneficial for performance and cost optimization once you get the understanding of your typical work load during peak hours.
- Data Security: Since you are in control of the physical servers, there is no risk of data leakage that can occur due to vulnerabilities in multi-tenant virtualization platforms, including CPU cache-based side-channel vulnerabilities. It could be argued that attacks targeting such issues are rare, and their impact on a DNS resolver service is low, but potential breaches may have significant privacy impact. It is advised to evaluate this against your organisation's risk model, or to discuss this with your information security compliance experts.
The ", or [..]" This feels a bit wordy; we don't suggest who to talk to for all the other recommendations either.
- Predictability: Because there is no virtualization layer and no "noisy neighbours" on the host, the performance of your servers is more predictable.
Cons:
- Cost of failure: If you pick hardware configuration that is not optimal for the workload of your DNS resolver, you may need to upgrade and replace hardware components afterwards. Ways to reduce this risk include renting servers instead of buying them, carrying load testing with data similar to production workloads, and providing limited beta access to the service before it fully enters the production phase.
- Scalability: Scaling up with physical servers means acquiring or renting, installing, and configuring new hardware, which will take more time than provisioning new virtual servers in a cloud environment. Moreover, most cloud environments will provide you with cluster autoscaling features, which could barely be achieved in bare metal.
- Maintenance: You will be responsible for all server maintenance tasks, including hardware issues, which can require significant effort and specific expertise.
- Redundancy: Setting up high availability and disaster recovery strategies can be more complex and time consuming compared to the cloud, where these features are often provided as value added products. See the Redundancy section for more details.
**Running DNS resolver instances in containers in a public cloud:**
Pros:
- Scalability: Clouds excel at scaling applications. You can scale up and down rapidly based on load, which is important for a DNS resolver that needs to handle variable query loads. In case of regional or geographically distributed resolvers, in every region where the resolver would be deployed, daily periodicity is likely to be observed, for example peak hour is likely to occur around 19:00 local time, and off-peak hours may begin at around 01:00-03:00. In a situation like that, using cluster autoscaling features and tools, you can run less instances in the night and more instances throughout the day, which may help to optimize your cloud hosting costs.
- Fault Tolerance and High Availability: Most clouds have built-in strategies, features, and products for handling node failures, which can increase your service's availability.
- Deployment and Management: Cloud providers offer built-in methods to deploy and manage applications, which can simplify operations and reduce the likelihood of human errors if your infrastructure management department is already familiar with these tools.
- Cost: While this largely depends on your specific usage, cloud services can sometimes be more cost-effective than managing your own physical servers, especially when you consider the total cost of ownership, including power, cooling, and maintenance.
Cons:
- Performance: The virtualization layer of public clouds can impact performance. While this certainly could be mitigated through scaling the number of virtual hosts, the cost would also increase accordingly.
- Complexity: Advanced cloud technologies are complex systems which come with a steep learning curve. Without prior experience, properly configuring and managing a cloud-based compute cluster can be challenging.
- Cost Variability: While the cloud can be cheaper, it can also be more expensive if not properly managed. Costs can rise unexpectedly based on traffic. Make sure to always set some limits on how much may be spent on hosting in the cloud control panel, and to set up notifications to be sent to you when these thresholds are about to be triggered.
- Multi-tenancy Risks: In a public cloud environment, the "noisy neighbour" problem could potentially affect your service's performance. Additionally, even though cloud providers take steps to isolate tenant environments, vulnerabilities could potentially expose sensitive data (see the previous section for a detailed explanation).
**Additional considerations**
- In today's environments, Kubernetes and Terraform are sometimes used as a substitute for cloud APIs when it comes to production services' management. When running a DNS resolver in a Kubernetes cluster on top of a public cloud environment, all the pros and cons of the public cloud apply; basically, Kubernetes becomes your public cloud provider. If you have significant prior experience running services in Kubernetes in production, you may successfully replicate your experience with the DNS resolver software. Otherwise, we would advise against Kubernetes in this case.
- The only reason we may find to run a DNS resolver in a Kubernetes cluster on top of self-hosted dedicated servers is when you have significant hands-on experience with Kubernetes and it is natural for you to manage applications this way. Otherwise, running DNS resolver daemons in containers brings little, if any, benefit. Autoscaling features are not available to you in this case, and neither horizontal nor vertical pod autoscaling is of any use, because DNS resolver software typically scales in-host by itself just fine.
- When designing a cluster of resolvers for autoscaling, keep in mind that newly spawned resolver machines would need to populate resolver cache first before they are fully useful. Your DNS resolver software may provide cache replication mechanisms. Otherwise, it is safe to overprovision clusters somewhat under heavy load, and discarding excessive instances once all the caches are populated and the average load of a compute instance decreases. In addition, it may be worthwhile to consider sharing cache data between instances.
- It is always advised to prefer environments your infrastructure management team is familiar with.
### Software considerations
#### Open Source
**Recommendation**: Choose any well-maintained DNS software you are comfortable using. Regardless of which software you choose, ensure you have somewhere to go for support. In the case of open source software, consider providing financial support to ensure continued development. Some open source maintainers take donations, while others offer support contracts.
There are both open source and proprietary implementations of DNS resolver software. Mixing these is also possible, for example, by using proprietary extensions with open source software or deploying open source software modified in-house.
General observations: - Software licensing is orthogonal to software security. Neither is proprietary software less secure on principle nor are contributions by "unknown" developers more of a risk in open source.
Benefits of open source: - Open source allows for inspection, independent auditing, and troubleshooting. - Open source can avoid vendor lock-in. - Open source can aid internet standards development. Widely-deployed open source implementations allow proponents of standards drafts to contribute proof of concept implementations without permission or cooperation of vendors.
Drawbacks of open source - Both open source and proprietary software require skilled maintenance, which has costs. Proprietary licensed software or appliances typically come with license fees to cover these. In contrast, open source licenses decouple usage by operators from monetary compensation to developers. It is up to operators to consider the financial sustainability of continued maintenance of the open source DNS software they depend upon.
Please also consider deploying different software implementations to ensure diversity, as discussed in the diversity section below.
### Networking considerations
#### IPv4 and IPv6
**If available, both IPv4 and IPv6 must be deployed.**
Large parts of the authoritative DNS are only accessible via IPv4, so the resolver must be able to originate IPv4 queries. Authoritative DNS that is only accessible via IPv6 is very rare.
Depending on the connectivity of clients, a resolver may be IPv4-only, IPv6-only, or support IPv4 and IPv6.
#### Addressing
**Using multiple IP addresses for the service address should be considered.**
Using 2 or more IPv4 addresses and 2 or more IPv6 addresses from different RIR will allow resilience in failure at an RIR, either governance, security, or technical. Note that support for multiple addresses for recursive resolvers varies and some clients perform poorly if any address does not respond normally.
There is no need to pick an IPv4 address with all octets the same, like 2.2.2.2 or 11.11.11.11.
**Publishing a list of back-end addresses used for resolving should be considered.**
Publishing a list of back-end addresses used for resolving can be useful for other network & DNS operators (for example, geo-IP location, making sure data is getting to correct places, and so on).
#### High Availability
This can be considered in terms of local and global scope.
##### Local scope
Inside a single location/region, such as an office, campus, or small ISP network, the main availability concern is that a resolver is always reachable. Client systems can be configured with multiple resolver addresses, but the failover behaviour of stub resolvers to a second address can be painful. Ideally the primary address is highly available and such fallback rarely required. How much effort is put into ensuring this is true should probably scale in line with the number of users, or sensitivity of the clients using that resolver to delayed resolution.
There are several ways to promote high availability of an individual resolver address, such as dedicated load balancing equipment, or network techniques like VRRP, or IP anycast. These generally have in common a pool of recursive servers and the means to direct queries to them when a health check has determined them to be capable of answering those queries.
Dedicated free or commercially produced, hardware or software load balancing solutions are available. These typically own the resolver IP address and forward queries to the currently available instances of a pool of recursive servers.
VRRP enables a technique to make the resolver IP address available on multiple servers, often used to provide automatic failover between two. A pool of recursive servers using this technique must reside in the same broadcast domain.
IP anycast in the local scope typically involves a pool of recursive servers advertising a route to a shared resolver IP address into a routing protocol. This can be configured in failover or load-sharing configurations. A load sharing configuration typically requires network equipment able to balance traffic to a destination over equal cost paths (ECMP). A pool of recursive servers using this technique can be distributed in different parts of the network.
##### Global scope
The same concerns as for local service availability are present in the global scope, with the added issue that DNS resolution over long distances may be slow. Practically speaking, only multiple resolver addresses, or IP anycast are useful strategies here. The motivations for finding better failover solutions than multiple resolver addresses have been covered above.
IP anycast in the global scope means routing the same IP prefix to more than one location. This can provide effective solutions for failover and, when optimally configured for routing client queries to the topologically least distant recursive server location. IP anycast in the global scope requires the use of globally routable prefixes. If a separate prefix is to be used for anycasting, usually this means a /24 in IPv4 and a /48 in IPv6, as those are the smallest sizes that will be widely propagated in BGP. A common practice is to use a covering prefix (/23 in IPv4 or /47 in IPv6) for fallback, and a more-specific prefix (/24 or /48) for the traffic. The more-specific prefix can then be withdrawn to send traffic to a backup site; this will happen automatically if the site is disconnected from routing.
[RFC7094](https://www.rfc-editor.org/rfc/rfc7094.html) discusses anycast architecture in detail, including references to various other RFC which discuss anycast in general and to DNS in particular.
[RFC4786](https://datatracker.ietf.org/doc/html/rfc4786) discuses operation of anycast services.
##### Generally
Operators of a globally scoped recursive service are encouraged to also adopt the local scope recommendations in each of the locations where the service is provisioned.
Though the above deals with the shortcomings of reliance on stub resolver failover between a list of addresses those recommendations shouldnât be seen as an exclusive alternative. Multiple resolver addresses, where each is provisioned using differing failover strategies, can provide a resolver of last resort and further improved resilience.
#### Ingress Filtering
**Ingress Filtering to follow BCP 38 should be deployed.**
DNS normally uses UDP traffic, which makes it a common vector of both [reflection](https://en.wikipedia.org/wiki/Reflection_attack) and [amplification](https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-a...) attacks. To minimize the amount of spoofed traffic that a resolver responds to, the network should be configured as recommended in [BCP 38](https://www.rfc-editor.org/rfc/rfc2827.html).
#### RPKI Sign Advertised Routes
**Route Advertisements should be signed using RPKI**
Using RPKI to sign any route advertisements - either toward authoritative servers or toward DNS clients - is straightforward to do and will reduce the impact of BGP misconfigurations and some BGP hijacking attempts.
RPKI validation is also possible, although the effort is greater. It is possible that the hosting provider or the transit provider for your service validates BGP; asking and making this part of your selection criteria is reasonable.
#### (D)DoS measures
Denial-of-Service (DoS) attacks, both distributed (DDoS) and not are a threat to any Internet service. Network operators for a service providing any DNS service must be prepared for large amounts of attack traffic.
In addition to attacks on the service itself, a resolver may be used both as an attack reflector and as an attack amplifier.
Active monitoring of network and service usage, careful logging, and a security team that is able to respond to problem reports is necessary. Mitigation techniques will include filtering or rate-limiting traffic, both on the authoritative and client side of the resolver.
### Capacity planning
#### Server capacity
If using a model that is easy to scale (cloud based, or Kubernetes based, or similar), then getting server capacity correct is largely a
Given the earlier text about Kubernetes being 'similar' to cloud, "or Kubernetes based, " can probably be removed.
question of budgeting. If using a less-flexible model (bare metal for example), then under-estimating will mean problems delivering service.
Hardware performance varies widely, as does operating system and resolver performance. Some lab testing will be necessary to estimate the number of systems needed.
#### Network capacity
Since DNS is mostly UDP-based, it is often easy to generate large amounts of spoofed traffic to and from DNS servers. DNS traffic is small compared to application traffic (videos and other content), but still significant. Authoritative server operators often build their networks and servers to handle 10 times their normal load. Recursive server operators may need to do the same, although the service only
I would split this sentence, to read: server operators may need to do the same. When the service only
accepts traffic from IP addresses that cannot be spoofed (for example users within a network that operated by the same company) then this
remove "then"
can be reduced, for example to 3 times normal load. To estimate expected load, the best approach is to examine historical usage for the actual expected users of the system.
### Resilience
#### System Diversity
In addition to the software considerations above, operators should
Either change to "software **licensing** considerations", or start the sentence with Operators. After all, the previous part of the text is not about software considerations, so current wording may be a bit confusing to linear readers.
consider whether to use different server implementations to provide
s/server/software/ ?
service. This allows continued operation if a critical vulnerability is found in one implementation, by shifting traffic to other implementations.
Placing resolvers and control systems in different physical locations will allow continued operation in the event of a disaster or other problem that impacts a single location. In addition, ensuring diverse connectivity to other networks will prevent single points of failure on the network side. Ensuring network diversity may take some care, as it is not always obvious what fate is shared between any given path; this may be physical, virtual, or organizational, and my sometimes be hidden.
#### Security
In addition to the DNS-specific security considerations, normal security best practices for any Internet service should be followed, including updating software updated regularly, patching software as soon as possible for any known security vulnerabilities, following CERT announcements and so on.
Perhaps CERT/CSIRT. Not super important.
#### Certification
It may be useful or required for an organization to follow specific
s/follow/obtain/ ?
certifications, such as ISO or ITIL. These can be government-defined
Not sure if (unspecified) "ISO or ITIL" are the most relevant examples. I would either remove or replace by say "ISO-IEC 27017, 27018 or SOC 2 Type 2", which all relate to services provided by an organisation, to be relied on by users of that service.
or industry-defined. For end users there is typically not much direct value, but business customers will often look for services that are operated by organizations meeting such standards.
## DNS configuration knobs
The DNS is an old protocol that has a lot of settings that can be tweaked. This section reviews these and provides recommendations on which should be used for a resolver.
### DNSSEC validation
**DNSSEC validation should be enabled.**
For: All DNS resolver operators.
DNSSEC validation is the best way to ensure that the answers from the owner of domain name being queried are returned.
The root KSK must be updated when it changes. While [RFC5011](https://www.rfc-editor.org/rfc/rfc5011.html) defines an automated way to do this, a resolver operator will probably either manage this trust anchor directly or have it updated via OS updates.
[RFC9364](https://www.rfc-editor.org/rfc/rfc9364.html) provides a lot of useful information, and links to further documents about DNSSEC. However, operators usually do not need to know the details, and can simply ensure that DNSSEC validation is enabled in their software.
Resolver software that does not support DNSSEC validation should be avoided.
### DNS Transport Protocols
**UDP and TCP must be supported.**
For: All DNS resolver operators.
UDP is what most clients use, and TCP is necessary for DNS answers that are too large for a single UDP packet.
[RFC7766](https://www.rfc-editor.org/rfc/rfc7766.html) explains why TCP is necessary in more detail.
### Packet Fragmentation Avoidance
**Servers should be configured to avoid fragmentation.**
For: ALL DNS resolver operators.
Packet fragmentation can cause issues with DNS over UDP, especially over IPv6. These issues can be minimized by choosing implementations that set IP options to avoid this, and by taking care with EDNS0 message sizes.
Recommendations are available in [draft-ietf-dnsop-avoid-fragmentation](https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/).
### Encrypted DNS
**At least one of DNS-over-TLS (DoT), DNS-over-HTTPS (DoH), and DNS-over-QUIC (DoQ) should be supported.**
For: All DNS resolver operators.
DoT, DoH, and DoQ are different technologies that all provide an encrypted channel between the resolver and the authoritative server. DoT is the oldest, and provides encrypted DNS using TLS. DoH uses HTTP over TLS as a way to transmit queries and answers, and is widely supported by web browsers. DoQ is the newest, and provides advanced features such as separate streams for each query, avoiding the "head of line" blocking problem common with all protocols layered on top of TCP (such as DoT and DoH).
- DoT - [RFC7858](https://www.rfc-editor.org/rfc/rfc7858.html) - DoH - [RFC8484](https://www.rfc-editor.org/rfc/rfc8484.html) - DoQ - [RFC9250](https://www.rfc-editor.org/rfc/rfc9250.html)
**Discovery of DNS Designated Resolvers**
There are new mechanisms that allow DNS clients to use DNS records to discover encrypted DNS configurations. Resolvers should publish DNS records to assist clients finding encrypted resolvers.
- Discovery of Designated Resolvers - [RFC9462](https://www.rfc-editor.org/rfc/rfc9462.html)
QUESTION: Do we need to publish certificate in other ways that via the DDR mechanisms?
Should this remain in?
### QNAME Minimization
**QNAME minimization should be enabled.**
For: All DNS resolver operators.
Using QNAME minimization, a resolver does not send the full name that it is trying to resolver to authoritative servers higher in the DNS hierarchy. So, for example, when querying "atlas.ripe.net" the servers for ".net" would only be asked for "ripe.net". This improves privacy for the end user querying the name.
[RFC7816](https://www.rfc-editor.org/rfc/rfc7816.html) covers QNAME minimization.
### Aggressive NSEC caching
**Aggressive NSEC caching may be enabled.**
For: Public resolver operators.
"Aggressive NSEC caching", meaning negative caching based on NSEC and NSEC3 values, can reduce traffic greatly. It is important to protect against random subdomain attacks.
This style of caching takes advantage of the way that NSEC and NSEC3 records cover a range of names in a zone. A resolver can know that a query falls within such a range without sending any further queries, by remembering the NSEC or NSEC3 redords that is has seen as answers to earlier queries.
Aggressive NSEC caching is almost always a good idea. However enabling this is less important for DNS resolver operators who have a close relationship with users, since they can stop attacks by blocking users or otherwise directly dealing with the source of abusive queries.
[RFC8189](https://www.rfc-editor.org/rfc/rfc8189.html) describes negative caching in detail.
### ANY Queries
**ANY queries responses should be limited.***
For: All resolver operators.
Public or large-scale resolvers should be exceptionally careful with queries of type ANY, which return all all records at a given name. If a resolver replies with all of the records cached for a given type, the response can be much larger than for a single record type. Strict limits should be enforced on volumes of such queries to prevent amplification abuse, or truncation should be applied to prevent spoofed redirections.
[RFC8482](https://www.rfc-editor.org/rfc/rfc8482.html) describes several approaches to limiting ANY responses.
### Local Root
**Local root should be used.**
For: Public resolver operators.
Running a local root has several benefits, but it is an additional component to maintain. For public resolver operators this is definitely worth the cost, but other resolver operators may choose to simply send all queries to the well-distributed root name servers.
[RFC8806](https://www.rfc-editor.org/rfc/rfc8806.html) describes local root, including several example configurations.
In the future it will be possible to use ZONEMD to validate the copy of the root zone obtained before using it. This is currently available for the root zone.
[RFC8976](https://www.rfc-editor.org/rfc/rfc8976.html) describes ZONEMD.
### DNS Cookies
**Interoperable DNS Cookies may be supported.**
For: Public resolver operators.
DNS cookies provide some improved security over plain UDP, and are designed to be more lightweight than TCP. If more than one server is responding for a given IP address, then the Server Secret must be shared by all servers, and the answer must be constructed in a consistent manner by all server implementations.
Since client-side support for DNS cookies is not very widespread, and since managing server-side secrets involves some work, the costs may outweigh the benefits for some non-public resolver operators.
[RFC7873](https://www.rfc-editor.org/rfc/rfc7873.html) describes DNS cookies, and [RFC9018](https://www.rfc-editor.org/rfc/rfc9018.html) standardizes shared DNS cookies.
### TTL Recommendations
**TTL limits may be adjusted.**
For: All DNS resolver operators.
Software typically defaults to a maximum stored TTL of 1 or 2 days. A lower TTL will mean removing rarely-used records that have long TTL, and should not have much operational impact from a CPU or network point of view.
It is possible to set a minimum TTL in many implementations. This is a violation of the DNS protocol, although may be useful to reduce load from records with very low TTL (less than 5 seconds).
Note that software may set different maximum and minimum TTL independent of the results that the resolver returns. That may have a significant impact on queries as well, but resolver operators cannot influence that.
### TTL-based Record Pre-Fetch
**TTL record pre-fetch should be enabled when available.**
I would remove "when available", seeing that the last sentence of the next paragraph already covers this.
For: All DNS resolver operators.
Some resolvers have the ability to look up a record before it has expired from cache, in order to refresh the value and extend the TTL. This way there is never a time when the records are missing from the cache. This is not currently standardized, but a form of this was proposed in the IETF as [DNS Hammer](https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-hammer-03). We recommend turning this feature on if available.
### EDNS Client Subnet (ECS)
**ECS may be enabled.**
For: All DNS resolver operators.
EDNS Client Subnet (ECS) allows the resolver to include information about the IP address of the client querying it when sending messages to authoritative servers. This may allow authoritative servers to provide different answers which are more appropriate for the client. However, ECS will increase the amount of cache space required by resolvers, may reduce DNS performance, and may have privacy implications.
A resolver operator that has clients that are limited to a specific region may see no benefit. A resolver operator that has a widely distributed anycast network may not have much benefit from ECS, since the locations that initiate the query will be close to the client. But a resolver operator that answers client queries only from a few locations, and expects clients to come from a wide area, may provide better service for end-users by supporting ECS.
EDNS client subnet is described in [RFC7871](https://www.rfc-editor.org/rfc/rfc7871.html), an informational RFC.
### Extended DNS Errors
**Extended DNS errors should be enabled.**
For: All DNS resolver operators.
DNS traditionally provides very broad error reporting, SERVFAIL being the most common. This makes diagnosing and fixing problems difficult. Extended DNS errors provide extra information about failures, for example expired DNSSEC signatures. They also allow resolver operators to report administrative reasons for DNS failures, such as blocks due to legal requirements.
[RFC8914](https://www.rfc-editor.org/rfc/rfc8914.html) defines extended DNS errors.
### Negative Trust Anchors
**Negative trust anchors may be deployed.**
For: All DNS resolver operators.
Negative trust anchors (NTA) allow a resolver operator to handle a case where an authoritative server has a DNSSEC problem and becomes inaccessible. They basically disable DNSSEC checking for a domain. When this is warranted is difficult to know with certainty, and will usually requires some manual checking. Since DNSSEC validation is now widespread, DNSSEC failures on the authoritative side will impact many resolvers.
Because of these reasons this document does not recommend NTA, but also does not recommend that a deployment avoid NTA if it makes sense for that environment.
Negative trust anchors are documented in [RFC7646](https://www.rfc-editor.org/rfc/rfc7646.html).
### DNS Error Reporting
**DNS error reporting may be enabled.**
For: All DNS resolver operators.
DNS error reporting is a way for resolver operators to let authoritative operators know about problems in authoritative servers or zones. It provides little direct value for the resolver operators, but over time should improve the overall quality of the DNS ecosystem. It is neither widely deployed nor standardized, but hopefully will be both soon. Resolver operators are encouraged to enable DNS error
To me, 'may be' does not sound like much encouragement. Should this be 'should be' instead? The paragraph already explains that availability is limited for the moment.
reporting when it is available.
DNS error reporting is proposed in [draft-ietf-dnsop-dns-error-reporting](https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting).
### Trust Anchor Reporting
**Trust anchor reporting should be enabled.**
For: All DNS resolver operators.
Trust anchor reporting is a way for resolver operators to convey their DNSSEC trust anchor configuration to the operator of the zone that it is for. For most resolvers this is only the root zone. This information is intended to be used during a root KSK rollover to ensure that it is safe to proceed. In the future ICANN is planning an algorithm roll for the root KSK, and this information could be helpful. Resolver operators are encouraged to enable trust anchor reporting.
[RFC8145](https://www.rfc-editor.org/rfc/rfc8145.html) covers trust anchor reporting, in both possibilities available.
### Name Server Identification
**Servers should be configured to identify themselves.**
For: All DNS resolver operators.
Large resolver operations, especially publicly available resolvers, should support an in-band method of discovery that is obvious to permit users to discover what node has answered their query. This improves troubleshooting significantly, and may be useful for research and testing purposes. NSID (Name Server Identifier) is ideal for this, though also âCH TXT id.serverâ support is also reasonable. Geographic hints should be provided in this data, though specific host data is optional for arrays of servers in clusters. IATA codes have traditionally been used for naming points-of-presence, though this is at the discretion of the operator.
[RFC5001](https://www.rfc-editor.org/rfc/rfc5001.html) describes NSID.
[RFC4892](https://www.rfc-editor.org/rfc/rfc4892.html) describes name server identification in general, and documents the pre-NSID approaches.
## Privacy, Filtering, Transparency
Reviewing this next part was a bit painful, because I was involved in writing it and yet I see quite a few places where I feel we should improve. After re-reading RFC8932 for the second time, I noticed quite some overlap where RFC8932 is more exhaustive, specific and practicable. By creating overlap, I think we may be watering down our own advise. Below I go over all the items one by one, reference specific sections to advocate for removal of any such overlap.
### Privacy & anonymity
Operators are advised to apply
DNS resolver operators
[RFC8932](https://www.rfc-editor.org/rfc/rfc8932.html)
"Recommendations for DNS Privacy Service Operators" as follows:
1. its operational and policy guidance related to DNS encrypted transports and data handling, by applying all "Threat mitigations" (thereby by meeting its level of "minimally compliant") and additionally by applying the "Optimizations" on EDNS Client Subnet listed in section 5.3.1.
2. its framework on a Recursive operator Privacy Statement, by publishing a privacy statement on their website that is compliant with Section 6.
I suggest we strengthen this sentence a bit, then remove duplicates in the next section: s/that is compliant with/covers all topics in/
#### Logging considerations
1. Public privacy policy: DNS resolvers are recommended to publish their privacy policies transparently on their website. It can be a brief privacy commitment as well or be more elaborate on how the privacy policy was made. (See for example [Cloudflare's statement](https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver) or [Quad9's privacy page](https://www.quad9.net/service/privacy/).)
Such policies should explicitly mention the sampling rate of DNS queries/responses that are kept, and whether these are anonymized.
This is fully covered by the reference to RFC8932, Section 6. I suggest we remove this text.
2. Third party access to personal data: it seems that the only critical personal data that DNS resolvers collect are IP addresses and the queries that are resolved. The other meta data collected can be used to have an understanding of for example which user accessed which website which can reveal information about a personâs health, lifestyle and other personal preferences (we call this profiling). For example, resolving the website for alcoholics anonymous may tell you something about the health of a person behind an IP address. IP addresses are personally identifiable information. Follow the applicable privacy laws or privacy principles when receiving third party requests to access.
Resolvers should only comply with such requests when balancing legitimate third party interest with other fundamental rights.
This goes beyond RFC8932, Section 5.3.3 and Section 6.1.1 item 2 and may therefore be worth keeping. I suggest re-ordering this paragraph a bit to start with the advice. The following is an attempt to reorder: Resolver operators may receive third party requests for information they have logged that relates to users, including IP addresses, queries and meta data. Resolvers should only comply with such requests when balancing legitimate third party interest with the user's fundamental rights, including rights to privacy. Usage information can be personal data, PII or similarly regulated under the privacy laws applicable to the users, operator or third party, revealing a person's health, lifestyle or other personal preferences (profiling). For example, logging information that documents a user resolving a website for alcoholics anonymous may relate to the health of a person behind an IP address.
3. Access to data for researchers: how it is done, who has access and who can request access, how the resolver makes a decision to give access (validated and credible researchers, what they can access and other issues)
Covered in RFC8932, Section 5.3.3. Suggest removal.
4. Data minimization: do not collect personal information not needed for critical operations. Only retain or use what is being asked (the query). If collecting data to make the service more private and secure, explain the rationale for each piece of data (data collection purpose)
Covered in RFC8932 section 5.2.1 and section 5.2.2. Suggest removal.
5. Encryption: If data is encrypted, explain how it has been encrypted (DoH, DoT, or so on).
Covered in RFC8932, Section 6.1.2, item 2. Suggest removal.
6. Data security and retention: when to delete the data and how it is stored
Data retention is covered in RFC8932 section 5.2.1 and section 5.2.2. Section 5.2.1, last bullit under mitigations sets a security goal relating to data access, though the word security is not used (it is the scope of the entire document). Suggest removal. Alternatively, abstract to a level higher than RFC8932 by stating something like the following (with limited operational value): 2. Data security: DNS Resolver operators should take appropriate technical and organisational measures to protect logging information that relates to users.
#### Advertisement Policy
If there is any advertising from the service, the policy should be published as well as how it can potentially affect the users' privacy.
### Filtering and blocking
#### Block Lists
Resolvers can be directed to block or modify answers in various ways. Blocklists may be provided by governments, communities, or other parties (for example security firms).
Response Policy Zone (RPZ) allows a way to both document specific modifications that resolvers will make to DNS answers, and send the rules to resolvers. This allows updates to occur very quickly. If RPZ or some other high-speed blocking technology is used, the parties supplying these sources must be highly trusted, as changes to blocklists will usually immediately impact user queries.
RPZ is not standardized, but there is an IETF draft, [draft-vixie-dnsop-dns-rpz](https://datatracker.ietf.org/doc/draft-vixie-dnsop-dns-rpz/00/).
#### Legal blocking
**Legal requests and blocking and filtering laws:** DNS resolvers
operators
should not filter content and block access to web-services. When the local law requires blocking, and the law applies to the resolver, the resolver should transparently disclose a list of blocked websites and services, when possible (disclosing such a list may not be allowed by law or regulation). Similarly, the resolver should disclose the source of such block lists, when possible.
If it is not possible to disclose the source of blocklists, operators should try to be as transparent as possible about how they receive those blocklists, based on what criteria, and how they mitigate errors and false positives. Disclosing which organizations operators interact with, how they liase, and so on, can help users understand the impact on the service provided.
If possible, resolvers should provide information about blocked responses via the Extended DNS Error with the Blocked, Censored, Filtered, or Prohibited code - whichever applies best - along with a text why the response was blocked, censored, filtered, or prohibited.
[RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html#section-4.16) provides information about the meanings of the different codes.
I like these paragraphs, but they are also covered by RFC8932, section 6.1.1 item 6 (result filtering), which we already advise to apply. As an example of where that section is stronger, it does not feature 'when possible' escape hatches. I'm not sure what to do here. At a minimum, I believe we should make a reference to that content and substantiate why we feel it is worth repeating here (while not the other topics of RFC8932).
**Community governance of blocklists:** blocklists, if mandatory, have to be audited and assessed by third parties and there should be a right to appeal for those blocked. The Internet community can vet the blocklists from time to time to avoid blocking access to websites that are mistakenly blocked. During crisis - when mistakes can have drastic effects on accessing a critical service - preferably filtering and blocking should not be used.
This is not covered by 8932, so relevant to keep.
#### Opt-in/Opt-out Mechanisms
End users may choose to use a DNS resolver that filters specific kinds of traffic. For example, they may wish to avoid potential malware web sites. Or resolver operators may be required to default to filtering but allowed for to provide an unfiltered DNS resolver service.
Depending on the specific requirements, a resolver service may publish different IP addresses and what type of filtering applies to each address. It is also possible to perform client authentication and authorization, using IP-based authentication, TSIG keys, or client-side TLS certificates.
### Transparency
Suggest leading with the advice: Public DNS resolver operators should publish transparency reports to build user trust in their adherence to policies and practices. This goes beyond our advise to apply RFC8932, section 6.2.
DNS resolvers usually provide transparency reports once a year. The
Suggest to replace with: A common frequency is once a year. The
reports inform the public about disclosure of user information and removal of content required by law enforcement and other government agencies.
Transparency reports should (to the extent that the law allows) indicate which government agencies and law enforcement agencies request access on what basis.
It should also be clear from the transparency reports what kind of data has been requested and if content removal and content blocking have been requested. Categories of data include: Content Data, Basic Subscriber Data, Other Non-Content Data and Content Blocking.
#### Voluntary certificates and standards
Some DNS resolvers opt for obtaining certificates in security and privacy. Some also undertake audits on their privacy practices. See for example:https://www.cloudflare.com/trust-hub/compliance-resources/
Suggest removing this; certification is already covered under ### Resilience above. Should the group feel that this is the most appropriate place, I suggest moving that section to replace the one here.
#### Negative Trust Anchor reporting
Negative Trust Anchors (NTA) are discussed in the previous section on DNS configurations. If NTAs are present in the resolver, they should be published with as much detail as possible about them. This includes reasons for insertion, dates of activation and expected removal dates, or a published review date or cycle for when NTAs should be actively examined for deletion if such fine-grained information cannot be shared.
NTAs are equivalent to a security fault, and may even be more significant than a block event as they remove expected trust behavior with limited signal of that trust downgrade ("limited" because few if any clients care about those response bits changing.).
#### Human rights considerations
DNS resolvers can opt for declaring their understanding of their responsibilities regarding human rights from the Universal Declaration of Human Rights. Specifically, Quad9 mentions rights to freedoms
s/Specifically/As an example of a public DNS resolver operator/
without distinction made on the basis of country, no interference with privacy, the right to freedom of opinion and expression, the right to peaceful assembly, and the right to freely participate in the cultural life of the community.
See [Quad9's Human Rights Considerations](https://www.quad9.net/privacy/human-rights-considerations/) for the full statement.
It also invokes other human rights related solutions other than [UDHR](https://www.un.org/en/universal-declaration-human-rights/) such as Articles 8 and 9 of Resolution 42/15 of the United Nations Human Rights Council on the right to privacy in the digital age of 26 September 2019 more directly define the responsibilities of the private sector toward the furtherance of human rights in modern terms. They also follow the Guidelines for Human Rights Protocol and Architecture Consideration of the Human Rights Protocol Considerations Research Group at Internet Research Task Force.
The latest version of the IRTF [Guidelines for HRPC](https://tools.ietf.org/html/draft-irtf-hrpc-guidelines) may be considered for all network operators.
## Appendix A: Why Did RIPE Write This Document?
There is increasing concern that large open DNS resolvers will become centralised points of DNS operations on the Internet. In order to address this, the European Commission issued the [DNS4EU](https://hadea.ec.europa.eu/calls-proposals/equipping-backbone-networks-high-...) proposal. However, such an initiative could lead to centralised guidance or regulation which might interfere with the decentralised way the Internet infrastructure works - including the DNS. See for reference the [RIPE NCC Open House discussion](https://labs.ripe.net/author/chrisb/dns4eu-ripe-ncc-open-house-discussion/) on this topic.
Rather than attempting to respond to the EC proposal or organize specific DNS resolver deployments, the RIPE community has decided that it is best able to provide advice and guidance. The RIPE Community is well positioned to provide a set of Best Current Practices that operators of Open DNS Resolvers will be encouraged to subscribe to.
Maarten, Thank you for your suggestions, edits, and discussion. I've updated the final draft to give us a final, final draft. ð I've included the last (?) version at the bottom of this e-mail, and responded to your suggestions inline below. On 19/03/2024 10.24, Maarten Aertsen wrote:
* Those running public DNS resolver services, and
Should we remove "public" here?
Hm, good point!
  - Data Security: Since you are in control of the physical servers,     there is no risk of data leakage that can occur due to     vulnerabilities in multi-tenant virtualization platforms,     including CPU cache-based side-channel vulnerabilities. It could     be argued that attacks targeting such issues are rare, and their     impact on a DNS resolver service is low, but potential breaches     may have significant privacy impact. It is advised to evaluate     this against your organisation's risk model, or to discuss this     with your information security compliance experts.
The ", or [..]" This feels a bit wordy; we don't suggest who to talk to for all the other recommendations either.
Makes sense. Discussing with experts is basically an option for everything. ð
#### Server capacity
If using a model that is easy to scale (cloud based, or Kubernetes based, or similar), then getting server capacity correct is largely a
Given the earlier text about Kubernetes being 'similar' to cloud, "or Kubernetes based, " can probably be removed.
I'm inclined to leave this in. I'd rather be explicit than implicit.
Since DNS is mostly UDP-based, it is often easy to generate large amounts of spoofed traffic to and from DNS servers. DNS traffic is small compared to application traffic (videos and other content), but still significant. Authoritative server operators often build their networks and servers to handle 10 times their normal load. Recursive server operators may need to do the same, although the service only
I would split this sentence, to read:
server operators may need to do the same. When the service only
Fair.
accepts traffic from IP addresses that cannot be spoofed (for example users within a network that operated by the same company) then this
remove "then"
Done.
### Resilience
#### System Diversity
In addition to the software considerations above, operators should
Either change to "software **licensing** considerations", or start the sentence with Operators. After all, the previous part of the text is not about software considerations, so current wording may be a bit confusing to linear readers.
Makes sense. I've started with Operators, no need to remind people of the other considerations here.
consider whether to use different server implementations to provide
s/server/software/ ?
Makes sense.
In addition to the DNS-specific security considerations, normal security best practices for any Internet service should be followed, including updating software updated regularly, patching software as soon as possible for any known security vulnerabilities, following CERT announcements and so on.
Perhaps CERT/CSIRT. Not super important.
You led me down a short trip to the Wikipedia: https://en.wikipedia.org/wiki/Computer_emergency_response_team In spite of CMU's trademark on the term CERT (?!?!), I see way more CERT in the national lists than CSIRT, so I'll stick with it. In a random note, the RIPE Database has an IRT object type rather than a CERT or CSIRT object type, through some artifact of history. ð
#### Certification
It may be useful or required for an organization to follow specific
s/follow/obtain/ ?
In this case "follow" instead of "obtain" was deliberate. It might not be necessary to actually go through the cost of getting certification in order to get the benefits. But, since this section concludes mentioning that business customers will look for them, "obtain" probably makes more sense.
certifications, such as ISO or ITIL. These can be government-defined
Not sure if (unspecified) "ISO or ITIL" are the most relevant examples. I would either remove or replace by say "ISO-IEC 27017, 27018 or SOC 2 Type 2", which all relate to services provided by an organisation, to be relied on by users of that service.
Replaced with "ISO or SOC 2 Type 2".
QUESTION: Do we need to publish certificate in other ways that via the DDR mechanisms?
Should this remain in?
Good point, removed!
### TTL-based Record Pre-Fetch
**TTL record pre-fetch should be enabled when available.**
I would remove "when available", seeing that the last sentence of the next paragraph already covers this.
I'm leaving it in, since we use that exact phraseology elsewhere.
### DNS Error Reporting
**DNS error reporting may be enabled.**
For: All DNS resolver operators.
DNS error reporting is a way for resolver operators to let authoritative operators know about problems in authoritative servers or zones. It provides little direct value for the resolver operators, but over time should improve the overall quality of the DNS ecosystem. It is neither widely deployed nor standardized, but hopefully will be both soon. Resolver operators are encouraged to enable DNS error
To me, 'may be' does not sound like much encouragement. Should this be 'should be' instead? The paragraph already explains that availability is limited for the moment.
I'm not sure we have enough operational experience to know if this is actually a good idea. It may end up being spammy, or unintentionally result in privacy leaks, or any other kinds of unpleasant side-effects. I don't expect it, but I also don't feel comfortable recommending it strongly.
## Privacy, Filtering, Transparency
Reviewing this next part was a bit painful, because I was involved in writing it and yet I see quite a few places where I feel we should improve. After re-reading RFC8932 for the second time, I noticed quite some overlap where RFC8932 is more exhaustive, specific and practicable. By creating overlap, I think we may be watering down our own advise. Below I go over all the items one by one, reference specific sections to advocate for removal of any such overlap.
Okay, thanks for the detailed re-reading.
### Privacy & anonymity
Operators are advised to apply
DNS resolver operators
Yes.
[RFC8932](https://www.rfc-editor.org/rfc/rfc8932.html)
"Recommendations for DNS Privacy Service Operators" as follows:
  1. its operational and policy guidance related to DNS encrypted   transports and data handling, by applying all "Threat mitigations"   (thereby by meeting its level of "minimally compliant") and   additionally by applying the "Optimizations" on EDNS Client Subnet   listed in section 5.3.1.
  2. its framework on a Recursive operator Privacy Statement, by   publishing a privacy statement on their website that is compliant   with Section 6.
I suggest we strengthen this sentence a bit, then remove duplicates in the next section:
s/that is compliant with/covers all topics in/
Makes sense.
#### Logging considerations
1. Public privacy policy: DNS resolvers are recommended to publish    their privacy policies transparently on their website. It can be a    brief privacy commitment as well or be more elaborate on how the    privacy policy was made. (See for example    [Cloudflare's statement](https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver) or [Quad9's privacy page](https://www.quad9.net/service/privacy/).)
   Such policies should explicitly mention the sampling rate of DNS    queries/responses that are kept, and whether these are anonymized.
This is fully covered by the reference to RFC8932, Section 6. I suggest we remove this text.
Okay, that makes some sense. I kept the examples from Cloudflare and Quad9, but moved them at the end of the previous section.
2. Third party access to personal data: it seems that the only    critical personal data that DNS resolvers collect are IP addresses    and the queries that are resolved. The other meta data collected    can be used to have an understanding of for example which user    accessed which website which can reveal information about a    personâs health, lifestyle and other personal preferences (we call    this profiling). For example, resolving the website for alcoholics    anonymous may tell you something about the health of a person    behind an IP address. IP addresses are personally identifiable    information. Follow the applicable privacy laws or privacy    principles when receiving third party requests to access.
   Resolvers    should only comply with such requests when balancing legitimate    third party interest with other fundamental rights.
This goes beyond RFC8932, Section 5.3.3 and Section 6.1.1 item 2 and may therefore be worth keeping.
I suggest re-ordering this paragraph a bit to start with the advice. The following is an attempt to reorder:
Resolver operators may receive third party requests for information they have logged that relates to users, including IP addresses, queries and meta data. Resolvers should only comply with such requests when balancing legitimate third party interest with the user's fundamental rights, including rights to privacy. Usage information can be personal data, PII or similarly regulated under the privacy laws applicable to the users, operator or third party, revealing a person's health, lifestyle or other personal preferences (profiling). For example, logging information that documents a user resolving a website for alcoholics anonymous may relate to the health of a person behind an IP address.
Makes sense, I've included this text.
3. Access to data for researchers: how it is done, who has access and    who can request access, how the resolver makes a decision to give    access (validated and credible researchers, what they can access    and other issues)
Covered in RFC8932, Section 5.3.3. Suggest removal.
Removed.
4. Data minimization: do not collect personal information not needed    for critical operations. Only retain or use what is being asked    (the query). If collecting data to make the service more private    and secure, explain the rationale for each piece of data (data    collection purpose)
Covered in RFC8932 section 5.2.1 and section 5.2.2. Suggest removal.
Removed.
5. Encryption: If data is encrypted, explain how it has been encrypted    (DoH, DoT, or so on).
Covered in RFC8932, Section 6.1.2, item 2. Suggest removal.
Removed.
6. Data security and retention: when to delete the data and how it is    stored
Data retention is covered in RFC8932 section 5.2.1 and section 5.2.2. Section 5.2.1, last bullit under mitigations sets a security goal relating to data access, though the word security is not used (it is the scope of the entire document).
Suggest removal. Alternatively, abstract to a level higher than RFC8932 by stating something like the following (with limited operational value):
2. Data security: DNS Resolver operators should take appropriate technical and organisational measures to protect logging information that relates to users.
I've included this higher-level recommendation.
**Legal requests and blocking and filtering laws:** DNS resolvers
operators
Updated.
should not filter content and block access to web-services. When the local law requires blocking, and the law applies to the resolver, the resolver should transparently disclose a list of blocked websites and services, when possible (disclosing such a list may not be allowed by law or regulation). Similarly, the resolver should disclose the source of such block lists, when possible.
If it is not possible to disclose the source of blocklists, operators should try to be as transparent as possible about how they receive those blocklists, based on what criteria, and how they mitigate errors and false positives. Disclosing which organizations operators interact with, how they liase, and so on, can help users understand the impact on the service provided.
If possible, resolvers should provide information about blocked responses via the Extended DNS Error with the Blocked, Censored, Filtered, or Prohibited code - whichever applies best - along with a text why the response was blocked, censored, filtered, or prohibited.
[RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html#section-4.16) provides information about the meanings of the different codes.
I like these paragraphs, but they are also covered by RFC8932, section 6.1.1 item 6 (result filtering), which we already advise to apply. As an example of where that section is stronger, it does not feature 'when possible' escape hatches.
I'm not sure what to do here. At a minimum, I believe we should make a reference to that content and substantiate why we feel it is worth repeating here (while not the other topics of RFC8932).
Interesting. The "when possible" language was added in recognition that there may be legal or other barriers preventing such transparency. Also, RFC 8932 6.1.1 just talks about documentation... our text here actually recommends not filtering, which RFC 8932 does not do. RFC 8932 also doesn't reference RFC 8914, which makes sense since they came out very near to each other. So... I understand the concern about re-specifying things, but I'm actually happy to let this text stand.
**Community governance of blocklists:** blocklists, if mandatory, have to be audited and assessed by third parties and there should be a right to appeal for those blocked. The Internet community can vet the blocklists from time to time to avoid blocking access to websites that are mistakenly blocked. During crisis - when mistakes can have drastic effects on accessing a critical service - preferably filtering and blocking should not be used.
This is not covered by 8932, so relevant to keep.
ð
### Transparency
Suggest leading with the advice:
Public DNS resolver operators should publish transparency reports to build user trust in their adherence to policies and practices. This goes beyond our advise to apply RFC8932, section 6.2.
Makes sense. Updated.
DNS resolvers usually provide transparency reports once a year. The
Suggest to replace with:
A common frequency is once a year. The
Done.
#### Voluntary certificates and standards
Some DNS resolvers opt for obtaining certificates in security and privacy. Some also undertake audits on their privacy practices. See for example:https://www.cloudflare.com/trust-hub/compliance-resources/
Suggest removing this; certification is already covered under ### Resilience above. Should the group feel that this is the most appropriate place, I suggest moving that section to replace the one here.
Good point. I added a bit of text mentioning audits or reports, and include the link as an example there.
#### Human rights considerations
DNS resolvers can opt for declaring their understanding of their responsibilities regarding human rights from the Universal Declaration of Human Rights. Specifically, Quad9 mentions rights to freedoms
s/Specifically/As an example of a public DNS resolver operator/
Make sense, updated. -- Shane # DNS Resolver Recommendations About the DNS Resolver Best Common Practice Task Force https://www.ripe.net/participate/ripe/tf/dns-resolver-best-common-practice-t... ## Terminology * Open Resolver: A DNS resolver that accepts queries from any client. Often the result of misconfiguration. * Public Resolver: A resolver intentionally configured to be an open resolver. ## Introduction ### What Is This Document? Who Is It For? This document presents recommendations and best current practices for operating DNS resolvers, both public and non-public ones. It covers technical aspects of operations and provides best practice recommendations for data management, with a particular focus on user privacy, security, and resilience. The document serves as guidance for the wider Internet community, offering input to: * Those running DNS resolver services, and * Those who want to make informed choices between such services. Its purpose is to provide clear guidance and promote effective practices in DNS resolver operation. The intended audience is not the entire DNS community. Advice here is probably not useful for operators of authoritative servers, domain registrars, and so on. It is also not meant to be an introductory or educational document. There are many documents which cover the basics of DNS and the roles of organizations in it; a good overview is: Addressing the challenges of modern DNS - a comprehensive tutorial by van der Toorn et al. https://ris.utwente.nl/ws/files/282427879/1_s2.0_S1574013722000132_main.pdf The document does not consider how to measure adherence to these recommendations. So it is not intended to be used for certification, although certification created based on the principles here is possible. ### How Is This Document Organized? This document has a number of sections, and specific recommendations in each section. The intent is for each recommendations to have clear guidance at the top, and then background and discussion related to the recommendation afterwards. Each recommendation indicates whether it is mostly for operators of public resolvers or for operators of any resolver. ### About Recomendation Text This is not a standards document, and does not propose any way to measure compliance or interoperability. It does use words like "should" or "may be" throughout. These are meant to be interpreted in the usual English sense, and not as IETF-style RFC 2119 jargon. ## System and Network Hardening ### Infrastructure considerations Running any Internet service requires attention to the infrastructure used to operate it. This section discusses various approaches that can be used to run a DNS resolver. Everything applies to both public and non-public DNS resolvers. #### Bare metal or public cloud All DNS resolver software can run either on dedicated servers (rented or colocated), or in virtualized clouds, or in a combination of those. Every approach has pros and cons. Most of these are not specific to running DNS resolvers, however, some of them are. **Running DNS resolver instances as OS level daemons on bare metal hosts:** Pros: - Performance: Bare metal servers have direct access to the underlying hardware, and can offer superior performance/cost balance by avoiding the overhead associated with virtualization. Moreover, you have full control over the server's configurations, down to the hardware level, which can be beneficial for performance and cost optimization once you get the understanding of your typical work load during peak hours. - Data Security: Since you are in control of the physical servers, there is no risk of data leakage that can occur due to vulnerabilities in multi-tenant virtualization platforms, including CPU cache-based side-channel vulnerabilities. It could be argued that attacks targeting such issues are rare, and their impact on a DNS resolver service is low, but potential breaches may have significant privacy impact. It is advised to evaluate this against your organisation's risk model. - Predictability: Because there is no virtualization layer and no "noisy neighbours" on the host, the performance of your servers is more predictable. Cons: - Cost of failure: If you pick hardware configuration that is not optimal for the workload of your DNS resolver, you may need to upgrade and replace hardware components afterwards. Ways to reduce this risk include renting servers instead of buying them, carrying load testing with data similar to production workloads, and providing limited beta access to the service before it fully enters the production phase. - Scalability: Scaling up with physical servers means acquiring or renting, installing, and configuring new hardware, which will take more time than provisioning new virtual servers in a cloud environment. Moreover, most cloud environments will provide you with cluster autoscaling features, which could barely be achieved in bare metal. - Maintenance: You will be responsible for all server maintenance tasks, including hardware issues, which can require significant effort and specific expertise. - Redundancy: Setting up high availability and disaster recovery strategies can be more complex and time consuming compared to the cloud, where these features are often provided as value added products. See the Redundancy section for more details. **Running DNS resolver instances in containers in a public cloud:** Pros: - Scalability: Clouds excel at scaling applications. You can scale up and down rapidly based on load, which is important for a DNS resolver that needs to handle variable query loads. In case of regional or geographically distributed resolvers, in every region where the resolver would be deployed, daily periodicity is likely to be observed, for example peak hour is likely to occur around 19:00 local time, and off-peak hours may begin at around 01:00-03:00. In a situation like that, using cluster autoscaling features and tools, you can run less instances in the night and more instances throughout the day, which may help to optimize your cloud hosting costs. - Fault Tolerance and High Availability: Most clouds have built-in strategies, features, and products for handling node failures, which can increase your service's availability. - Deployment and Management: Cloud providers offer built-in methods to deploy and manage applications, which can simplify operations and reduce the likelihood of human errors if your infrastructure management department is already familiar with these tools. - Cost: While this largely depends on your specific usage, cloud services can sometimes be more cost-effective than managing your own physical servers, especially when you consider the total cost of ownership, including power, cooling, and maintenance. Cons: - Performance: The virtualization layer of public clouds can impact performance. While this certainly could be mitigated through scaling the number of virtual hosts, the cost would also increase accordingly. - Complexity: Advanced cloud technologies are complex systems which come with a steep learning curve. Without prior experience, properly configuring and managing a cloud-based compute cluster can be challenging. - Cost Variability: While the cloud can be cheaper, it can also be more expensive if not properly managed. Costs can rise unexpectedly based on traffic. Make sure to always set some limits on how much may be spent on hosting in the cloud control panel, and to set up notifications to be sent to you when these thresholds are about to be triggered. - Multi-tenancy Risks: In a public cloud environment, the "noisy neighbour" problem could potentially affect your service's performance. Additionally, even though cloud providers take steps to isolate tenant environments, vulnerabilities could potentially expose sensitive data (see the previous section for a detailed explanation). **Additional considerations** - In today's environments, Kubernetes and Terraform are sometimes used as a substitute for cloud APIs when it comes to production services' management. When running a DNS resolver in a Kubernetes cluster on top of a public cloud environment, all the pros and cons of the public cloud apply; basically, Kubernetes becomes your public cloud provider. If you have significant prior experience running services in Kubernetes in production, you may successfully replicate your experience with the DNS resolver software. Otherwise, we would advise against Kubernetes in this case. - The only reason we may find to run a DNS resolver in a Kubernetes cluster on top of self-hosted dedicated servers is when you have significant hands-on experience with Kubernetes and it is natural for you to manage applications this way. Otherwise, running DNS resolver daemons in containers brings little, if any, benefit. Autoscaling features are not available to you in this case, and neither horizontal nor vertical pod autoscaling is of any use, because DNS resolver software typically scales in-host by itself just fine. - When designing a cluster of resolvers for autoscaling, keep in mind that newly spawned resolver machines would need to populate resolver cache first before they are fully useful. Your DNS resolver software may provide cache replication mechanisms. Otherwise, it is safe to overprovision clusters somewhat under heavy load, and discarding excessive instances once all the caches are populated and the average load of a compute instance decreases. In addition, it may be worthwhile to consider sharing cache data between instances. - It is always advised to prefer environments your infrastructure management team is familiar with. ### Software considerations #### Open Source **Recommendation**: Choose any well-maintained DNS software you are comfortable using. Regardless of which software you choose, ensure you have somewhere to go for support. In the case of open source software, consider providing financial support to ensure continued development. Some open source maintainers take donations, while others offer support contracts. There are both open source and proprietary implementations of DNS resolver software. Mixing these is also possible, for example, by using proprietary extensions with open source software or deploying open source software modified in-house. General observations: - Software licensing is orthogonal to software security. Neither is proprietary software less secure on principle nor are contributions by "unknown" developers more of a risk in open source. Benefits of open source: - Open source allows for inspection, independent auditing, and troubleshooting. - Open source can avoid vendor lock-in. - Open source can aid internet standards development. Widely-deployed open source implementations allow proponents of standards drafts to contribute proof of concept implementations without permission or cooperation of vendors. Drawbacks of open source - Both open source and proprietary software require skilled maintenance, which has costs. Proprietary licensed software or appliances typically come with license fees to cover these. In contrast, open source licenses decouple usage by operators from monetary compensation to developers. It is up to operators to consider the financial sustainability of continued maintenance of the open source DNS software they depend upon. Please also consider deploying different software implementations to ensure diversity, as discussed in the diversity section below. ### Networking considerations #### IPv4 and IPv6 **If available, both IPv4 and IPv6 must be deployed.** Large parts of the authoritative DNS are only accessible via IPv4, so the resolver must be able to originate IPv4 queries. Authoritative DNS that is only accessible via IPv6 is very rare. Depending on the connectivity of clients, a resolver may be IPv4-only, IPv6-only, or support IPv4 and IPv6. #### Addressing **Using multiple IP addresses for the service address should be considered.** Using 2 or more IPv4 addresses and 2 or more IPv6 addresses from different RIR will allow resilience in failure at an RIR, either governance, security, or technical. Note that support for multiple addresses for recursive resolvers varies and some clients perform poorly if any address does not respond normally. There is no need to pick an IPv4 address with all octets the same, like 2.2.2.2 or 11.11.11.11. **Publishing a list of back-end addresses used for resolving should be considered.** Publishing a list of back-end addresses used for resolving can be useful for other network & DNS operators (for example, geo-IP location, making sure data is getting to correct places, and so on). #### High Availability This can be considered in terms of local and global scope. ##### Local scope Inside a single location/region, such as an office, campus, or small ISP network, the main availability concern is that a resolver is always reachable. Client systems can be configured with multiple resolver addresses, but the failover behaviour of stub resolvers to a second address can be painful. Ideally the primary address is highly available and such fallback rarely required. How much effort is put into ensuring this is true should probably scale in line with the number of users, or sensitivity of the clients using that resolver to delayed resolution. There are several ways to promote high availability of an individual resolver address, such as dedicated load balancing equipment, or network techniques like VRRP, or IP anycast. These generally have in common a pool of recursive servers and the means to direct queries to them when a health check has determined them to be capable of answering those queries. Dedicated free or commercially produced, hardware or software load balancing solutions are available. These typically own the resolver IP address and forward queries to the currently available instances of a pool of recursive servers. VRRP enables a technique to make the resolver IP address available on multiple servers, often used to provide automatic failover between two. A pool of recursive servers using this technique must reside in the same broadcast domain. IP anycast in the local scope typically involves a pool of recursive servers advertising a route to a shared resolver IP address into a routing protocol. This can be configured in failover or load-sharing configurations. A load sharing configuration typically requires network equipment able to balance traffic to a destination over equal cost paths (ECMP). A pool of recursive servers using this technique can be distributed in different parts of the network. ##### Global scope The same concerns as for local service availability are present in the global scope, with the added issue that DNS resolution over long distances may be slow. Practically speaking, only multiple resolver addresses, or IP anycast are useful strategies here. The motivations for finding better failover solutions than multiple resolver addresses have been covered above. IP anycast in the global scope means routing the same IP prefix to more than one location. This can provide effective solutions for failover and, when optimally configured for routing client queries to the topologically least distant recursive server location. IP anycast in the global scope requires the use of globally routable prefixes. If a separate prefix is to be used for anycasting, usually this means a /24 in IPv4 and a /48 in IPv6, as those are the smallest sizes that will be widely propagated in BGP. A common practice is to use a covering prefix (/23 in IPv4 or /47 in IPv6) for fallback, and a more-specific prefix (/24 or /48) for the traffic. The more-specific prefix can then be withdrawn to send traffic to a backup site; this will happen automatically if the site is disconnected from routing. [RFC7094](https://www.rfc-editor.org/rfc/rfc7094.html) discusses anycast architecture in detail, including references to various other RFC which discuss anycast in general and to DNS in particular. [RFC4786](https://datatracker.ietf.org/doc/html/rfc4786) discuses operation of anycast services. ##### Generally Operators of a globally scoped recursive service are encouraged to also adopt the local scope recommendations in each of the locations where the service is provisioned. Though the above deals with the shortcomings of reliance on stub resolver failover between a list of addresses those recommendations shouldnât be seen as an exclusive alternative. Multiple resolver addresses, where each is provisioned using differing failover strategies, can provide a resolver of last resort and further improved resilience. #### Ingress Filtering **Ingress Filtering to follow BCP 38 should be deployed.** DNS normally uses UDP traffic, which makes it a common vector of both [reflection](https://en.wikipedia.org/wiki/Reflection_attack) and [amplification](https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-a...) attacks. To minimize the amount of spoofed traffic that a resolver responds to, the network should be configured as recommended in [BCP 38](https://www.rfc-editor.org/rfc/rfc2827.html). #### RPKI Sign Advertised Routes **Route Advertisements should be signed using RPKI** Using RPKI to sign any route advertisements - either toward authoritative servers or toward DNS clients - is straightforward to do and will reduce the impact of BGP misconfigurations and some BGP hijacking attempts. RPKI validation is also possible, although the effort is greater. It is possible that the hosting provider or the transit provider for your service validates BGP; asking and making this part of your selection criteria is reasonable. #### (D)DoS measures Denial-of-Service (DoS) attacks, both distributed (DDoS) and not are a threat to any Internet service. Network operators for a service providing any DNS service must be prepared for large amounts of attack traffic. In addition to attacks on the service itself, a resolver may be used both as an attack reflector and as an attack amplifier. Active monitoring of network and service usage, careful logging, and a security team that is able to respond to problem reports is necessary. Mitigation techniques will include filtering or rate-limiting traffic, both on the authoritative and client side of the resolver. ### Capacity planning #### Server capacity If using a model that is easy to scale (cloud based, or Kubernetes based, or similar), then getting server capacity correct is largely a question of budgeting. If using a less-flexible model (bare metal for example), then under-estimating will mean problems delivering service. Hardware performance varies widely, as does operating system and resolver performance. Some lab testing will be necessary to estimate the number of systems needed. #### Network capacity Since DNS is mostly UDP-based, it is often easy to generate large amounts of spoofed traffic to and from DNS servers. DNS traffic is small compared to application traffic (videos and other content), but still significant. Authoritative server operators often build their networks and servers to handle 10 times their normal load. Recursive server operators may need to do the same. When the service only accepts traffic from IP addresses that cannot be spoofed (for example users within a network that operated by the same company) this can be reduced, for example to 3 times normal load. To estimate expected load, the best approach is to examine historical usage for the actual expected users of the system. ### Resilience #### System Diversity Operators should consider whether to use different software implementations to provide service. This allows continued operation if a critical vulnerability is found in one implementation, by shifting traffic to other implementations. Placing resolvers and control systems in different physical locations will allow continued operation in the event of a disaster or other problem that impacts a single location. In addition, ensuring diverse connectivity to other networks will prevent single points of failure on the network side. Ensuring network diversity may take some care, as it is not always obvious what fate is shared between any given path; this may be physical, virtual, or organizational, and my sometimes be hidden. #### Security In addition to the DNS-specific security considerations, normal security best practices for any Internet service should be followed, including updating software updated regularly, patching software as soon as possible for any known security vulnerabilities, following CERT announcements and so on. #### Certification It may be useful or required for an organization to obtain specific certifications, such as ISO or SOC 2 Type 2. These can be government-defined or industry-defined. For end users there is typically not much direct value, but business customers will often look for services that are operated by organizations meeting such standards. Audits or other reports about this may be published, see for example: https://www.cloudflare.com/trust-hub/compliance-resources/ ## DNS configuration knobs The DNS is an old protocol that has a lot of settings that can be tweaked. This section reviews these and provides recommendations on which should be used for a resolver. ### DNSSEC validation **DNSSEC validation should be enabled.** For: All DNS resolver operators. DNSSEC validation is the best way to ensure that the answers from the owner of domain name being queried are returned. The root KSK must be updated when it changes. While [RFC5011](https://www.rfc-editor.org/rfc/rfc5011.html) defines an automated way to do this, a resolver operator will probably either manage this trust anchor directly or have it updated via OS updates. [RFC9364](https://www.rfc-editor.org/rfc/rfc9364.html) provides a lot of useful information, and links to further documents about DNSSEC. However, operators usually do not need to know the details, and can simply ensure that DNSSEC validation is enabled in their software. Resolver software that does not support DNSSEC validation should be avoided. ### DNS Transport Protocols **UDP and TCP must be supported.** For: All DNS resolver operators. UDP is what most clients use, and TCP is necessary for DNS answers that are too large for a single UDP packet. [RFC7766](https://www.rfc-editor.org/rfc/rfc7766.html) explains why TCP is necessary in more detail. ### Packet Fragmentation Avoidance **Servers should be configured to avoid fragmentation.** For: ALL DNS resolver operators. Packet fragmentation can cause issues with DNS over UDP, especially over IPv6. These issues can be minimized by choosing implementations that set IP options to avoid this, and by taking care with EDNS0 message sizes. Recommendations are available in [draft-ietf-dnsop-avoid-fragmentation](https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/). ### Encrypted DNS **At least one of DNS-over-TLS (DoT), DNS-over-HTTPS (DoH), and DNS-over-QUIC (DoQ) should be supported.** For: All DNS resolver operators. DoT, DoH, and DoQ are different technologies that all provide an encrypted channel between the resolver and the authoritative server. DoT is the oldest, and provides encrypted DNS using TLS. DoH uses HTTP over TLS as a way to transmit queries and answers, and is widely supported by web browsers. DoQ is the newest, and provides advanced features such as separate streams for each query, avoiding the "head of line" blocking problem common with all protocols layered on top of TCP (such as DoT and DoH). - DoT - [RFC7858](https://www.rfc-editor.org/rfc/rfc7858.html) - DoH - [RFC8484](https://www.rfc-editor.org/rfc/rfc8484.html) - DoQ - [RFC9250](https://www.rfc-editor.org/rfc/rfc9250.html) **Discovery of DNS Designated Resolvers** There are new mechanisms that allow DNS clients to use DNS records to discover encrypted DNS configurations. Resolvers should publish DNS records to assist clients finding encrypted resolvers. - Discovery of Designated Resolvers - [RFC9462](https://www.rfc-editor.org/rfc/rfc9462.html) ### QNAME Minimization **QNAME minimization should be enabled.** For: All DNS resolver operators. Using QNAME minimization, a resolver does not send the full name that it is trying to resolver to authoritative servers higher in the DNS hierarchy. So, for example, when querying "atlas.ripe.net" the servers for ".net" would only be asked for "ripe.net". This improves privacy for the end user querying the name. [RFC7816](https://www.rfc-editor.org/rfc/rfc7816.html) covers QNAME minimization. ### Aggressive NSEC caching **Aggressive NSEC caching may be enabled.** For: Public resolver operators. "Aggressive NSEC caching", meaning negative caching based on NSEC and NSEC3 values, can reduce traffic greatly. It is important to protect against random subdomain attacks. This style of caching takes advantage of the way that NSEC and NSEC3 records cover a range of names in a zone. A resolver can know that a query falls within such a range without sending any further queries, by remembering the NSEC or NSEC3 redords that is has seen as answers to earlier queries. Aggressive NSEC caching is almost always a good idea. However enabling this is less important for DNS resolver operators who have a close relationship with users, since they can stop attacks by blocking users or otherwise directly dealing with the source of abusive queries. [RFC8189](https://www.rfc-editor.org/rfc/rfc8189.html) describes negative caching in detail. ### ANY Queries **ANY queries responses should be limited.*** For: All resolver operators. Public or large-scale resolvers should be exceptionally careful with queries of type ANY, which return all all records at a given name. If a resolver replies with all of the records cached for a given type, the response can be much larger than for a single record type. Strict limits should be enforced on volumes of such queries to prevent amplification abuse, or truncation should be applied to prevent spoofed redirections. [RFC8482](https://www.rfc-editor.org/rfc/rfc8482.html) describes several approaches to limiting ANY responses. ### Local Root **Local root should be used.** For: Public resolver operators. Running a local root has several benefits, but it is an additional component to maintain. For public resolver operators this is definitely worth the cost, but other resolver operators may choose to simply send all queries to the well-distributed root name servers. [RFC8806](https://www.rfc-editor.org/rfc/rfc8806.html) describes local root, including several example configurations. In the future it will be possible to use ZONEMD to validate the copy of the root zone obtained before using it. This is currently available for the root zone. [RFC8976](https://www.rfc-editor.org/rfc/rfc8976.html) describes ZONEMD. ### DNS Cookies **Interoperable DNS Cookies may be supported.** For: Public resolver operators. DNS cookies provide some improved security over plain UDP, and are designed to be more lightweight than TCP. If more than one server is responding for a given IP address, then the Server Secret must be shared by all servers, and the answer must be constructed in a consistent manner by all server implementations. Since client-side support for DNS cookies is not very widespread, and since managing server-side secrets involves some work, the costs may outweigh the benefits for some non-public resolver operators. [RFC7873](https://www.rfc-editor.org/rfc/rfc7873.html) describes DNS cookies, and [RFC9018](https://www.rfc-editor.org/rfc/rfc9018.html) standardizes shared DNS cookies. ### TTL Recommendations **TTL limits may be adjusted.** For: All DNS resolver operators. Software typically defaults to a maximum stored TTL of 1 or 2 days. A lower TTL will mean removing rarely-used records that have long TTL, and should not have much operational impact from a CPU or network point of view. It is possible to set a minimum TTL in many implementations. This is a violation of the DNS protocol, although may be useful to reduce load from records with very low TTL (less than 5 seconds). Note that software may set different maximum and minimum TTL independent of the results that the resolver returns. That may have a significant impact on queries as well, but resolver operators cannot influence that. ### TTL-based Record Pre-Fetch **TTL record pre-fetch should be enabled when available.** For: All DNS resolver operators. Some resolvers have the ability to look up a record before it has expired from cache, in order to refresh the value and extend the TTL. This way there is never a time when the records are missing from the cache. This is not currently standardized, but a form of this was proposed in the IETF as [DNS Hammer](https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-hammer-03). We recommend turning this feature on if available. ### EDNS Client Subnet (ECS) **ECS may be enabled.** For: All DNS resolver operators. EDNS Client Subnet (ECS) allows the resolver to include information about the IP address of the client querying it when sending messages to authoritative servers. This may allow authoritative servers to provide different answers which are more appropriate for the client. However, ECS will increase the amount of cache space required by resolvers, may reduce DNS performance, and may have privacy implications. A resolver operator that has clients that are limited to a specific region may see no benefit. A resolver operator that has a widely distributed anycast network may not have much benefit from ECS, since the locations that initiate the query will be close to the client. But a resolver operator that answers client queries only from a few locations, and expects clients to come from a wide area, may provide better service for end-users by supporting ECS. EDNS client subnet is described in [RFC7871](https://www.rfc-editor.org/rfc/rfc7871.html), an informational RFC. ### Extended DNS Errors **Extended DNS errors should be enabled.** For: All DNS resolver operators. DNS traditionally provides very broad error reporting, SERVFAIL being the most common. This makes diagnosing and fixing problems difficult. Extended DNS errors provide extra information about failures, for example expired DNSSEC signatures. They also allow resolver operators to report administrative reasons for DNS failures, such as blocks due to legal requirements. [RFC8914](https://www.rfc-editor.org/rfc/rfc8914.html) defines extended DNS errors. ### Negative Trust Anchors **Negative trust anchors may be deployed.** For: All DNS resolver operators. Negative trust anchors (NTA) allow a resolver operator to handle a case where an authoritative server has a DNSSEC problem and becomes inaccessible. They basically disable DNSSEC checking for a domain. When this is warranted is difficult to know with certainty, and will usually requires some manual checking. Since DNSSEC validation is now widespread, DNSSEC failures on the authoritative side will impact many resolvers. Because of these reasons this document does not recommend NTA, but also does not recommend that a deployment avoid NTA if it makes sense for that environment. Negative trust anchors are documented in [RFC7646](https://www.rfc-editor.org/rfc/rfc7646.html). ### DNS Error Reporting **DNS error reporting may be enabled.** For: All DNS resolver operators. DNS error reporting is a way for resolver operators to let authoritative operators know about problems in authoritative servers or zones. It provides little direct value for the resolver operators, but over time should improve the overall quality of the DNS ecosystem. It is neither widely deployed nor standardized, but hopefully will be both soon. Resolver operators are encouraged to enable DNS error reporting when it is available. DNS error reporting is proposed in [draft-ietf-dnsop-dns-error-reporting](https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting). ### Trust Anchor Reporting **Trust anchor reporting should be enabled.** For: All DNS resolver operators. Trust anchor reporting is a way for resolver operators to convey their DNSSEC trust anchor configuration to the operator of the zone that it is for. For most resolvers this is only the root zone. This information is intended to be used during a root KSK rollover to ensure that it is safe to proceed. In the future ICANN is planning an algorithm roll for the root KSK, and this information could be helpful. Resolver operators are encouraged to enable trust anchor reporting. [RFC8145](https://www.rfc-editor.org/rfc/rfc8145.html) covers trust anchor reporting, in both possibilities available. ### Name Server Identification **Servers should be configured to identify themselves.** For: All DNS resolver operators. Large resolver operations, especially publicly available resolvers, should support an in-band method of discovery that is obvious to permit users to discover what node has answered their query. This improves troubleshooting significantly, and may be useful for research and testing purposes. NSID (Name Server Identifier) is ideal for this, though also âCH TXT id.serverâ support is also reasonable. Geographic hints should be provided in this data, though specific host data is optional for arrays of servers in clusters. IATA codes have traditionally been used for naming points-of-presence, though this is at the discretion of the operator. [RFC5001](https://www.rfc-editor.org/rfc/rfc5001.html) describes NSID. [RFC4892](https://www.rfc-editor.org/rfc/rfc4892.html) describes name server identification in general, and documents the pre-NSID approaches. ## Privacy, Filtering, Transparency ### Privacy & anonymity DNS Resolver operators are advised to apply [RFC8932](https://www.rfc-editor.org/rfc/rfc8932.html) "Recommendations for DNS Privacy Service Operators" as follows: 1. its operational and policy guidance related to DNS encrypted transports and data handling, by applying all "Threat mitigations" (thereby by meeting its level of "minimally compliant") and additionally by applying the "Optimizations" on EDNS Client Subnet listed in section 5.3.1. 2. its framework on a Recursive operator Privacy Statement, by publishing a privacy statement on their website covers all topics in Section 6. (See for example [Cloudflare's statement](https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver) or [Quad9's privacy page](https://www.quad9.net/service/privacy/).) #### Logging considerations In addition to the logging recommendations from RFC8932, operators should consider the following: 1. Third party access to personal data: Resolver operators may receive third party requests for information they have logged that relates to users, including IP addresses, queries and meta data. Resolvers should only comply with such requests when balancing legitimate third party interest with the user's fundamental rights, including rights to privacy. Usage information can be personal data, Personally Identifable Infomation (PII) or similarly regulated under the privacy laws applicable to the users, operator or third party, revealing a person's health, lifestyle or other personal preferences (profiling). For example, logging information that documents a user resolving a website for alcoholics anonymous may relate to the health of a person behind an IP address. 2. Data security: DNS Resolver operators should take appropriate technical and organisational measures to protect logging information that relates to users. #### Advertisement Policy If there is any advertising from the service, the policy should be published as well as how it can potentially affect the users' privacy. ### Filtering and blocking #### Block Lists Resolvers can be directed to block or modify answers in various ways. Blocklists may be provided by governments, communities, or other parties (for example security firms). Response Policy Zone (RPZ) allows a way to both document specific modifications that resolvers will make to DNS answers, and send the rules to resolvers. This allows updates to occur very quickly. If RPZ or some other high-speed blocking technology is used, the parties supplying these sources must be highly trusted, as changes to blocklists will usually immediately impact user queries. RPZ is not standardized, but there is an IETF draft, [draft-vixie-dnsop-dns-rpz](https://datatracker.ietf.org/doc/draft-vixie-dnsop-dns-rpz/00/). #### Legal blocking **Legal requests and blocking and filtering laws:** DNS resolver operators should not filter content and block access to web-services. When the local law requires blocking, and the law applies to the resolver, the resolver should transparently disclose a list of blocked websites and services, when possible (disclosing such a list may not be allowed by law or regulation). Similarly, the resolver should disclose the source of such block lists, when possible. If it is not possible to disclose the source of blocklists, operators should try to be as transparent as possible about how they receive those blocklists, based on what criteria, and how they mitigate errors and false positives. Disclosing which organizations operators interact with, how they liase, and so on, can help users understand the impact on the service provided. If possible, resolvers should provide information about blocked responses via the Extended DNS Error with the Blocked, Censored, Filtered, or Prohibited code - whichever applies best - along with a text why the response was blocked, censored, filtered, or prohibited. [RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html#section-4.16) provides information about the meanings of the different codes. **Community governance of blocklists:** blocklists, if mandatory, have to be audited and assessed by third parties and there should be a right to appeal for those blocked. The Internet community can vet the blocklists from time to time to avoid blocking access to websites that are mistakenly blocked. During crisis - when mistakes can have drastic effects on accessing a critical service - preferably filtering and blocking should not be used. #### Opt-in/Opt-out Mechanisms End users may choose to use a DNS resolver that filters specific kinds of traffic. For example, they may wish to avoid potential malware web sites. Or resolver operators may be required to default to filtering but allowed for to provide an unfiltered DNS resolver service. Depending on the specific requirements, a resolver service may publish different IP addresses and what type of filtering applies to each address. It is also possible to perform client authentication and authorization, using IP-based authentication, TSIG keys, or client-side TLS certificates. ### Transparency Public DNS resolver operators should publish transparency reports to build user trust in their adherence to policies and practices. This goes beyond our advise to apply RFC8932, section 6.2. A common frequency is once a year. The reports inform the public about disclosure of user information and removal of content required by law enforcement and other government agencies. Transparency reports should (to the extent that the law allows) indicate which government agencies and law enforcement agencies request access on what basis. It should also be clear from the transparency reports what kind of data has been requested and if content removal and content blocking have been requested. Categories of data include: Content Data, Basic Subscriber Data, Other Non-Content Data and Content Blocking. #### Negative Trust Anchor reporting Negative Trust Anchors (NTA) are discussed in the previous section on DNS configurations. If NTAs are present in the resolver, they should be published with as much detail as possible about them. This includes reasons for insertion, dates of activation and expected removal dates, or a published review date or cycle for when NTAs should be actively examined for deletion if such fine-grained information cannot be shared. NTAs are equivalent to a security fault, and may even be more significant than a block event as they remove expected trust behavior with limited signal of that trust downgrade ("limited" because few if any clients care about those response bits changing.). #### Human rights considerations DNS resolvers can opt for declaring their understanding of their responsibilities regarding human rights from the Universal Declaration of Human Rights. As an example of a public DNS resolver operator, Quad9 mentions rights to freedoms without distinction made on the basis of country, no interference with privacy, the right to freedom of opinion and expression, the right to peaceful assembly, and the right to freely participate in the cultural life of the community. See [Quad9's Human Rights Considerations](https://www.quad9.net/privacy/human-rights-considerations/) for the full statement. It also invokes other human rights related solutions other than [UDHR](https://www.un.org/en/universal-declaration-human-rights/) such as Articles 8 and 9 of Resolution 42/15 of the United Nations Human Rights Council on the right to privacy in the digital age of 26 September 2019 more directly define the responsibilities of the private sector toward the furtherance of human rights in modern terms. They also follow the Guidelines for Human Rights Protocol and Architecture Consideration of the Human Rights Protocol Considerations Research Group at Internet Research Task Force. The latest version of the IRTF [Guidelines for HRPC](https://tools.ietf.org/html/draft-irtf-hrpc-guidelines) may be considered for all network operators. ## Appendix A: Why Did RIPE Write This Document? There is increasing concern that large open DNS resolvers will become centralised points of DNS operations on the Internet. In order to address this, the European Commission issued the [DNS4EU](https://hadea.ec.europa.eu/calls-proposals/equipping-backbone-networks-high-...) proposal. However, such an initiative could lead to centralised guidance or regulation which might interfere with the decentralised way the Internet infrastructure works - including the DNS. See for reference the [RIPE NCC Open House discussion](https://labs.ripe.net/author/chrisb/dns4eu-ripe-ncc-open-house-discussion/) on this topic. Rather than attempting to respond to the EC proposal or organize specific DNS resolver deployments, the RIPE community has decided that it is best able to provide advice and guidance. The RIPE Community is well positioned to provide a set of Best Current Practices that operators of Open DNS Resolvers will be encouraged to subscribe to.
Oh Shane beat me to it and I agree with Shane's changes. However, I am more inclined to keep the issues we draw from RFC8932. I think streamlining and repeating it maybe better than just referencing it and might even help with promoting the RFC. just a thought. Farzaneh On Sun, Mar 24, 2024 at 12:25â¯PM Shane Kerr <shane@time-travellers.org> wrote:
Maarten,
Thank you for your suggestions, edits, and discussion. I've updated the final draft to give us a final, final draft. ð
I've included the last (?) version at the bottom of this e-mail, and responded to your suggestions inline below.
On 19/03/2024 10.24, Maarten Aertsen wrote:
* Those running public DNS resolver services, and
Should we remove "public" here?
Hm, good point!
- Data Security: Since you are in control of the physical servers, there is no risk of data leakage that can occur due to vulnerabilities in multi-tenant virtualization platforms, including CPU cache-based side-channel vulnerabilities. It could be argued that attacks targeting such issues are rare, and their impact on a DNS resolver service is low, but potential breaches may have significant privacy impact. It is advised to evaluate this against your organisation's risk model, or to discuss this with your information security compliance experts.
The ", or [..]" This feels a bit wordy; we don't suggest who to talk to for all the other recommendations either.
Makes sense. Discussing with experts is basically an option for everything. ð
#### Server capacity
If using a model that is easy to scale (cloud based, or Kubernetes based, or similar), then getting server capacity correct is largely a
Given the earlier text about Kubernetes being 'similar' to cloud, "or Kubernetes based, " can probably be removed.
I'm inclined to leave this in. I'd rather be explicit than implicit.
Since DNS is mostly UDP-based, it is often easy to generate large amounts of spoofed traffic to and from DNS servers. DNS traffic is small compared to application traffic (videos and other content), but still significant. Authoritative server operators often build their networks and servers to handle 10 times their normal load. Recursive server operators may need to do the same, although the service only
I would split this sentence, to read:
server operators may need to do the same. When the service only
Fair.
accepts traffic from IP addresses that cannot be spoofed (for example users within a network that operated by the same company) then this
remove "then"
Done.
### Resilience
#### System Diversity
In addition to the software considerations above, operators should
Either change to "software **licensing** considerations", or start the sentence with Operators. After all, the previous part of the text is not about software considerations, so current wording may be a bit confusing to linear readers.
Makes sense. I've started with Operators, no need to remind people of the other considerations here.
consider whether to use different server implementations to provide
s/server/software/ ?
Makes sense.
In addition to the DNS-specific security considerations, normal security best practices for any Internet service should be followed, including updating software updated regularly, patching software as soon as possible for any known security vulnerabilities, following CERT announcements and so on.
Perhaps CERT/CSIRT. Not super important.
You led me down a short trip to the Wikipedia:
https://en.wikipedia.org/wiki/Computer_emergency_response_team
In spite of CMU's trademark on the term CERT (?!?!), I see way more CERT in the national lists than CSIRT, so I'll stick with it.
In a random note, the RIPE Database has an IRT object type rather than a CERT or CSIRT object type, through some artifact of history. ð
#### Certification
It may be useful or required for an organization to follow specific
s/follow/obtain/ ?
In this case "follow" instead of "obtain" was deliberate. It might not be necessary to actually go through the cost of getting certification in order to get the benefits. But, since this section concludes mentioning that business customers will look for them, "obtain" probably makes more sense.
certifications, such as ISO or ITIL. These can be government-defined
Not sure if (unspecified) "ISO or ITIL" are the most relevant examples. I would either remove or replace by say "ISO-IEC 27017, 27018 or SOC 2 Type 2", which all relate to services provided by an organisation, to be relied on by users of that service.
Replaced with "ISO or SOC 2 Type 2".
QUESTION: Do we need to publish certificate in other ways that via the DDR mechanisms?
Should this remain in?
Good point, removed!
### TTL-based Record Pre-Fetch
**TTL record pre-fetch should be enabled when available.**
I would remove "when available", seeing that the last sentence of the next paragraph already covers this.
I'm leaving it in, since we use that exact phraseology elsewhere.
### DNS Error Reporting
**DNS error reporting may be enabled.**
For: All DNS resolver operators.
DNS error reporting is a way for resolver operators to let authoritative operators know about problems in authoritative servers or zones. It provides little direct value for the resolver operators, but over time should improve the overall quality of the DNS ecosystem. It is neither widely deployed nor standardized, but hopefully will be both soon. Resolver operators are encouraged to enable DNS error
To me, 'may be' does not sound like much encouragement. Should this be 'should be' instead? The paragraph already explains that availability is limited for the moment.
I'm not sure we have enough operational experience to know if this is actually a good idea. It may end up being spammy, or unintentionally result in privacy leaks, or any other kinds of unpleasant side-effects. I don't expect it, but I also don't feel comfortable recommending it strongly.
## Privacy, Filtering, Transparency
Reviewing this next part was a bit painful, because I was involved in writing it and yet I see quite a few places where I feel we should improve. After re-reading RFC8932 for the second time, I noticed quite some overlap where RFC8932 is more exhaustive, specific and practicable. By creating overlap, I think we may be watering down our own advise. Below I go over all the items one by one, reference specific sections to advocate for removal of any such overlap.
Okay, thanks for the detailed re-reading.
### Privacy & anonymity
Operators are advised to apply
DNS resolver operators
Yes.
[RFC8932](https://www.rfc-editor.org/rfc/rfc8932.html)
"Recommendations for DNS Privacy Service Operators" as follows:
1. its operational and policy guidance related to DNS encrypted transports and data handling, by applying all "Threat mitigations" (thereby by meeting its level of "minimally compliant") and additionally by applying the "Optimizations" on EDNS Client Subnet listed in section 5.3.1.
2. its framework on a Recursive operator Privacy Statement, by publishing a privacy statement on their website that is compliant with Section 6.
I suggest we strengthen this sentence a bit, then remove duplicates in the next section:
s/that is compliant with/covers all topics in/
Makes sense.
#### Logging considerations
1. Public privacy policy: DNS resolvers are recommended to publish their privacy policies transparently on their website. It can be a brief privacy commitment as well or be more elaborate on how the privacy policy was made. (See for example [Cloudflare's statement]( https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver) or [Quad9's privacy page](https://www.quad9.net/service/privacy/).)
Such policies should explicitly mention the sampling rate of DNS queries/responses that are kept, and whether these are anonymized.
This is fully covered by the reference to RFC8932, Section 6. I suggest we remove this text.
Okay, that makes some sense. I kept the examples from Cloudflare and Quad9, but moved them at the end of the previous section.
2. Third party access to personal data: it seems that the only critical personal data that DNS resolvers collect are IP addresses and the queries that are resolved. The other meta data collected can be used to have an understanding of for example which user accessed which website which can reveal information about a personâs health, lifestyle and other personal preferences (we call this profiling). For example, resolving the website for alcoholics anonymous may tell you something about the health of a person behind an IP address. IP addresses are personally identifiable information. Follow the applicable privacy laws or privacy principles when receiving third party requests to access.
Resolvers should only comply with such requests when balancing legitimate third party interest with other fundamental rights.
This goes beyond RFC8932, Section 5.3.3 and Section 6.1.1 item 2 and may therefore be worth keeping.
I suggest re-ordering this paragraph a bit to start with the advice. The following is an attempt to reorder:
Resolver operators may receive third party requests for information they have logged that relates to users, including IP addresses, queries and meta data. Resolvers should only comply with such requests when balancing legitimate third party interest with the user's fundamental rights, including rights to privacy. Usage information can be personal data, PII or similarly regulated under the privacy laws applicable to the users, operator or third party, revealing a person's health, lifestyle or other personal preferences (profiling). For example, logging information that documents a user resolving a website for alcoholics anonymous may relate to the health of a person behind an IP address.
Makes sense, I've included this text.
3. Access to data for researchers: how it is done, who has access and who can request access, how the resolver makes a decision to give access (validated and credible researchers, what they can access and other issues)
Covered in RFC8932, Section 5.3.3. Suggest removal.
Removed.
4. Data minimization: do not collect personal information not needed for critical operations. Only retain or use what is being asked (the query). If collecting data to make the service more private and secure, explain the rationale for each piece of data (data collection purpose)
Covered in RFC8932 section 5.2.1 and section 5.2.2. Suggest removal.
Removed.
5. Encryption: If data is encrypted, explain how it has been encrypted (DoH, DoT, or so on).
Covered in RFC8932, Section 6.1.2, item 2. Suggest removal.
Removed.
6. Data security and retention: when to delete the data and how it is stored
Data retention is covered in RFC8932 section 5.2.1 and section 5.2.2. Section 5.2.1, last bullit under mitigations sets a security goal relating to data access, though the word security is not used (it is the scope of the entire document).
Suggest removal. Alternatively, abstract to a level higher than RFC8932 by stating something like the following (with limited operational value):
2. Data security: DNS Resolver operators should take appropriate technical and organisational measures to protect logging information that relates to users.
I've included this higher-level recommendation.
**Legal requests and blocking and filtering laws:** DNS resolvers
operators
Updated.
should not filter content and block access to web-services. When the local law requires blocking, and the law applies to the resolver, the resolver should transparently disclose a list of blocked websites and services, when possible (disclosing such a list may not be allowed by law or regulation). Similarly, the resolver should disclose the source of such block lists, when possible.
If it is not possible to disclose the source of blocklists, operators should try to be as transparent as possible about how they receive those blocklists, based on what criteria, and how they mitigate errors and false positives. Disclosing which organizations operators interact with, how they liase, and so on, can help users understand the impact on the service provided.
If possible, resolvers should provide information about blocked responses via the Extended DNS Error with the Blocked, Censored, Filtered, or Prohibited code - whichever applies best - along with a text why the response was blocked, censored, filtered, or prohibited.
[RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html#section-4.16) provides information about the meanings of the different codes.
I like these paragraphs, but they are also covered by RFC8932, section 6.1.1 item 6 (result filtering), which we already advise to apply. As an example of where that section is stronger, it does not feature 'when possible' escape hatches.
I'm not sure what to do here. At a minimum, I believe we should make a reference to that content and substantiate why we feel it is worth repeating here (while not the other topics of RFC8932).
Interesting. The "when possible" language was added in recognition that there may be legal or other barriers preventing such transparency.
Also, RFC 8932 6.1.1 just talks about documentation... our text here actually recommends not filtering, which RFC 8932 does not do.
RFC 8932 also doesn't reference RFC 8914, which makes sense since they came out very near to each other.
So... I understand the concern about re-specifying things, but I'm actually happy to let this text stand.
**Community governance of blocklists:** blocklists, if mandatory, have to be audited and assessed by third parties and there should be a right to appeal for those blocked. The Internet community can vet the blocklists from time to time to avoid blocking access to websites that are mistakenly blocked. During crisis - when mistakes can have drastic effects on accessing a critical service - preferably filtering and blocking should not be used.
This is not covered by 8932, so relevant to keep.
ð
### Transparency
Suggest leading with the advice:
Public DNS resolver operators should publish transparency reports to build user trust in their adherence to policies and practices. This goes beyond our advise to apply RFC8932, section 6.2.
Makes sense. Updated.
DNS resolvers usually provide transparency reports once a year. The
Suggest to replace with:
A common frequency is once a year. The
Done.
#### Voluntary certificates and standards
Some DNS resolvers opt for obtaining certificates in security and privacy. Some also undertake audits on their privacy practices. See for example:https://www.cloudflare.com/trust-hub/compliance-resources/
Suggest removing this; certification is already covered under ### Resilience above. Should the group feel that this is the most appropriate place, I suggest moving that section to replace the one here.
Good point. I added a bit of text mentioning audits or reports, and include the link as an example there.
#### Human rights considerations
DNS resolvers can opt for declaring their understanding of their responsibilities regarding human rights from the Universal Declaration of Human Rights. Specifically, Quad9 mentions rights to freedoms
s/Specifically/As an example of a public DNS resolver operator/
Make sense, updated.
-- Shane
# DNS Resolver Recommendations
About the DNS Resolver Best Common Practice Task Force
https://www.ripe.net/participate/ripe/tf/dns-resolver-best-common-practice-t...
## Terminology
* Open Resolver: A DNS resolver that accepts queries from any client. Often the result of misconfiguration.
* Public Resolver: A resolver intentionally configured to be an open resolver.
## Introduction
### What Is This Document? Who Is It For?
This document presents recommendations and best current practices for operating DNS resolvers, both public and non-public ones. It covers technical aspects of operations and provides best practice recommendations for data management, with a particular focus on user privacy, security, and resilience.
The document serves as guidance for the wider Internet community, offering input to:
* Those running DNS resolver services, and * Those who want to make informed choices between such services.
Its purpose is to provide clear guidance and promote effective practices in DNS resolver operation.
The intended audience is not the entire DNS community. Advice here is probably not useful for operators of authoritative servers, domain registrars, and so on. It is also not meant to be an introductory or educational document. There are many documents which cover the basics of DNS and the roles of organizations in it; a good overview is:
Addressing the challenges of modern DNS - a comprehensive tutorial by van der Toorn et al.
https://ris.utwente.nl/ws/files/282427879/1_s2.0_S1574013722000132_main.pdf
The document does not consider how to measure adherence to these recommendations. So it is not intended to be used for certification, although certification created based on the principles here is possible.
### How Is This Document Organized?
This document has a number of sections, and specific recommendations in each section. The intent is for each recommendations to have clear guidance at the top, and then background and discussion related to the recommendation afterwards. Each recommendation indicates whether it is mostly for operators of public resolvers or for operators of any resolver.
### About Recomendation Text
This is not a standards document, and does not propose any way to measure compliance or interoperability. It does use words like "should" or "may be" throughout. These are meant to be interpreted in the usual English sense, and not as IETF-style RFC 2119 jargon.
## System and Network Hardening
### Infrastructure considerations
Running any Internet service requires attention to the infrastructure used to operate it. This section discusses various approaches that can be used to run a DNS resolver. Everything applies to both public and non-public DNS resolvers.
#### Bare metal or public cloud
All DNS resolver software can run either on dedicated servers (rented or colocated), or in virtualized clouds, or in a combination of those. Every approach has pros and cons. Most of these are not specific to running DNS resolvers, however, some of them are.
**Running DNS resolver instances as OS level daemons on bare metal hosts:**
Pros:
- Performance: Bare metal servers have direct access to the underlying hardware, and can offer superior performance/cost balance by avoiding the overhead associated with virtualization. Moreover, you have full control over the server's configurations, down to the hardware level, which can be beneficial for performance and cost optimization once you get the understanding of your typical work load during peak hours.
- Data Security: Since you are in control of the physical servers, there is no risk of data leakage that can occur due to vulnerabilities in multi-tenant virtualization platforms, including CPU cache-based side-channel vulnerabilities. It could be argued that attacks targeting such issues are rare, and their impact on a DNS resolver service is low, but potential breaches may have significant privacy impact. It is advised to evaluate this against your organisation's risk model.
- Predictability: Because there is no virtualization layer and no "noisy neighbours" on the host, the performance of your servers is more predictable.
Cons:
- Cost of failure: If you pick hardware configuration that is not optimal for the workload of your DNS resolver, you may need to upgrade and replace hardware components afterwards. Ways to reduce this risk include renting servers instead of buying them, carrying load testing with data similar to production workloads, and providing limited beta access to the service before it fully enters the production phase.
- Scalability: Scaling up with physical servers means acquiring or renting, installing, and configuring new hardware, which will take more time than provisioning new virtual servers in a cloud environment. Moreover, most cloud environments will provide you with cluster autoscaling features, which could barely be achieved in bare metal.
- Maintenance: You will be responsible for all server maintenance tasks, including hardware issues, which can require significant effort and specific expertise.
- Redundancy: Setting up high availability and disaster recovery strategies can be more complex and time consuming compared to the cloud, where these features are often provided as value added products. See the Redundancy section for more details.
**Running DNS resolver instances in containers in a public cloud:**
Pros:
- Scalability: Clouds excel at scaling applications. You can scale up and down rapidly based on load, which is important for a DNS resolver that needs to handle variable query loads. In case of regional or geographically distributed resolvers, in every region where the resolver would be deployed, daily periodicity is likely to be observed, for example peak hour is likely to occur around 19:00 local time, and off-peak hours may begin at around 01:00-03:00. In a situation like that, using cluster autoscaling features and tools, you can run less instances in the night and more instances throughout the day, which may help to optimize your cloud hosting costs.
- Fault Tolerance and High Availability: Most clouds have built-in strategies, features, and products for handling node failures, which can increase your service's availability.
- Deployment and Management: Cloud providers offer built-in methods to deploy and manage applications, which can simplify operations and reduce the likelihood of human errors if your infrastructure management department is already familiar with these tools.
- Cost: While this largely depends on your specific usage, cloud services can sometimes be more cost-effective than managing your own physical servers, especially when you consider the total cost of ownership, including power, cooling, and maintenance.
Cons:
- Performance: The virtualization layer of public clouds can impact performance. While this certainly could be mitigated through scaling the number of virtual hosts, the cost would also increase accordingly.
- Complexity: Advanced cloud technologies are complex systems which come with a steep learning curve. Without prior experience, properly configuring and managing a cloud-based compute cluster can be challenging.
- Cost Variability: While the cloud can be cheaper, it can also be more expensive if not properly managed. Costs can rise unexpectedly based on traffic. Make sure to always set some limits on how much may be spent on hosting in the cloud control panel, and to set up notifications to be sent to you when these thresholds are about to be triggered.
- Multi-tenancy Risks: In a public cloud environment, the "noisy neighbour" problem could potentially affect your service's performance. Additionally, even though cloud providers take steps to isolate tenant environments, vulnerabilities could potentially expose sensitive data (see the previous section for a detailed explanation).
**Additional considerations**
- In today's environments, Kubernetes and Terraform are sometimes used as a substitute for cloud APIs when it comes to production services' management. When running a DNS resolver in a Kubernetes cluster on top of a public cloud environment, all the pros and cons of the public cloud apply; basically, Kubernetes becomes your public cloud provider. If you have significant prior experience running services in Kubernetes in production, you may successfully replicate your experience with the DNS resolver software. Otherwise, we would advise against Kubernetes in this case.
- The only reason we may find to run a DNS resolver in a Kubernetes cluster on top of self-hosted dedicated servers is when you have significant hands-on experience with Kubernetes and it is natural for you to manage applications this way. Otherwise, running DNS resolver daemons in containers brings little, if any, benefit. Autoscaling features are not available to you in this case, and neither horizontal nor vertical pod autoscaling is of any use, because DNS resolver software typically scales in-host by itself just fine.
- When designing a cluster of resolvers for autoscaling, keep in mind that newly spawned resolver machines would need to populate resolver cache first before they are fully useful. Your DNS resolver software may provide cache replication mechanisms. Otherwise, it is safe to overprovision clusters somewhat under heavy load, and discarding excessive instances once all the caches are populated and the average load of a compute instance decreases. In addition, it may be worthwhile to consider sharing cache data between instances.
- It is always advised to prefer environments your infrastructure management team is familiar with.
### Software considerations
#### Open Source
**Recommendation**: Choose any well-maintained DNS software you are comfortable using. Regardless of which software you choose, ensure you have somewhere to go for support. In the case of open source software, consider providing financial support to ensure continued development. Some open source maintainers take donations, while others offer support contracts.
There are both open source and proprietary implementations of DNS resolver software. Mixing these is also possible, for example, by using proprietary extensions with open source software or deploying open source software modified in-house.
General observations: - Software licensing is orthogonal to software security. Neither is proprietary software less secure on principle nor are contributions by "unknown" developers more of a risk in open source.
Benefits of open source: - Open source allows for inspection, independent auditing, and troubleshooting. - Open source can avoid vendor lock-in. - Open source can aid internet standards development. Widely-deployed open source implementations allow proponents of standards drafts to contribute proof of concept implementations without permission or cooperation of vendors.
Drawbacks of open source - Both open source and proprietary software require skilled maintenance, which has costs. Proprietary licensed software or appliances typically come with license fees to cover these. In contrast, open source licenses decouple usage by operators from monetary compensation to developers. It is up to operators to consider the financial sustainability of continued maintenance of the open source DNS software they depend upon.
Please also consider deploying different software implementations to ensure diversity, as discussed in the diversity section below.
### Networking considerations
#### IPv4 and IPv6
**If available, both IPv4 and IPv6 must be deployed.**
Large parts of the authoritative DNS are only accessible via IPv4, so the resolver must be able to originate IPv4 queries. Authoritative DNS that is only accessible via IPv6 is very rare.
Depending on the connectivity of clients, a resolver may be IPv4-only, IPv6-only, or support IPv4 and IPv6.
#### Addressing
**Using multiple IP addresses for the service address should be considered.**
Using 2 or more IPv4 addresses and 2 or more IPv6 addresses from different RIR will allow resilience in failure at an RIR, either governance, security, or technical. Note that support for multiple addresses for recursive resolvers varies and some clients perform poorly if any address does not respond normally.
There is no need to pick an IPv4 address with all octets the same, like 2.2.2.2 or 11.11.11.11.
**Publishing a list of back-end addresses used for resolving should be considered.**
Publishing a list of back-end addresses used for resolving can be useful for other network & DNS operators (for example, geo-IP location, making sure data is getting to correct places, and so on).
#### High Availability
This can be considered in terms of local and global scope.
##### Local scope
Inside a single location/region, such as an office, campus, or small ISP network, the main availability concern is that a resolver is always reachable. Client systems can be configured with multiple resolver addresses, but the failover behaviour of stub resolvers to a second address can be painful. Ideally the primary address is highly available and such fallback rarely required. How much effort is put into ensuring this is true should probably scale in line with the number of users, or sensitivity of the clients using that resolver to delayed resolution.
There are several ways to promote high availability of an individual resolver address, such as dedicated load balancing equipment, or network techniques like VRRP, or IP anycast. These generally have in common a pool of recursive servers and the means to direct queries to them when a health check has determined them to be capable of answering those queries.
Dedicated free or commercially produced, hardware or software load balancing solutions are available. These typically own the resolver IP address and forward queries to the currently available instances of a pool of recursive servers.
VRRP enables a technique to make the resolver IP address available on multiple servers, often used to provide automatic failover between two. A pool of recursive servers using this technique must reside in the same broadcast domain.
IP anycast in the local scope typically involves a pool of recursive servers advertising a route to a shared resolver IP address into a routing protocol. This can be configured in failover or load-sharing configurations. A load sharing configuration typically requires network equipment able to balance traffic to a destination over equal cost paths (ECMP). A pool of recursive servers using this technique can be distributed in different parts of the network.
##### Global scope
The same concerns as for local service availability are present in the global scope, with the added issue that DNS resolution over long distances may be slow. Practically speaking, only multiple resolver addresses, or IP anycast are useful strategies here. The motivations for finding better failover solutions than multiple resolver addresses have been covered above.
IP anycast in the global scope means routing the same IP prefix to more than one location. This can provide effective solutions for failover and, when optimally configured for routing client queries to the topologically least distant recursive server location. IP anycast in the global scope requires the use of globally routable prefixes. If a separate prefix is to be used for anycasting, usually this means a /24 in IPv4 and a /48 in IPv6, as those are the smallest sizes that will be widely propagated in BGP. A common practice is to use a covering prefix (/23 in IPv4 or /47 in IPv6) for fallback, and a more-specific prefix (/24 or /48) for the traffic. The more-specific prefix can then be withdrawn to send traffic to a backup site; this will happen automatically if the site is disconnected from routing.
[RFC7094](https://www.rfc-editor.org/rfc/rfc7094.html) discusses anycast architecture in detail, including references to various other RFC which discuss anycast in general and to DNS in particular.
[RFC4786](https://datatracker.ietf.org/doc/html/rfc4786) discuses operation of anycast services.
##### Generally
Operators of a globally scoped recursive service are encouraged to also adopt the local scope recommendations in each of the locations where the service is provisioned.
Though the above deals with the shortcomings of reliance on stub resolver failover between a list of addresses those recommendations shouldnât be seen as an exclusive alternative. Multiple resolver addresses, where each is provisioned using differing failover strategies, can provide a resolver of last resort and further improved resilience.
#### Ingress Filtering
**Ingress Filtering to follow BCP 38 should be deployed.**
DNS normally uses UDP traffic, which makes it a common vector of both [reflection](https://en.wikipedia.org/wiki/Reflection_attack) and [amplification]( https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-a... ) attacks. To minimize the amount of spoofed traffic that a resolver responds to, the network should be configured as recommended in [BCP 38](https://www.rfc-editor.org/rfc/rfc2827.html).
#### RPKI Sign Advertised Routes
**Route Advertisements should be signed using RPKI**
Using RPKI to sign any route advertisements - either toward authoritative servers or toward DNS clients - is straightforward to do and will reduce the impact of BGP misconfigurations and some BGP hijacking attempts.
RPKI validation is also possible, although the effort is greater. It is possible that the hosting provider or the transit provider for your service validates BGP; asking and making this part of your selection criteria is reasonable.
#### (D)DoS measures
Denial-of-Service (DoS) attacks, both distributed (DDoS) and not are a threat to any Internet service. Network operators for a service providing any DNS service must be prepared for large amounts of attack traffic.
In addition to attacks on the service itself, a resolver may be used both as an attack reflector and as an attack amplifier.
Active monitoring of network and service usage, careful logging, and a security team that is able to respond to problem reports is necessary. Mitigation techniques will include filtering or rate-limiting traffic, both on the authoritative and client side of the resolver.
### Capacity planning
#### Server capacity
If using a model that is easy to scale (cloud based, or Kubernetes based, or similar), then getting server capacity correct is largely a question of budgeting. If using a less-flexible model (bare metal for example), then under-estimating will mean problems delivering service.
Hardware performance varies widely, as does operating system and resolver performance. Some lab testing will be necessary to estimate the number of systems needed.
#### Network capacity
Since DNS is mostly UDP-based, it is often easy to generate large amounts of spoofed traffic to and from DNS servers. DNS traffic is small compared to application traffic (videos and other content), but still significant. Authoritative server operators often build their networks and servers to handle 10 times their normal load. Recursive server operators may need to do the same. When the service only accepts traffic from IP addresses that cannot be spoofed (for example users within a network that operated by the same company) this can be reduced, for example to 3 times normal load. To estimate expected load, the best approach is to examine historical usage for the actual expected users of the system.
### Resilience
#### System Diversity
Operators should consider whether to use different software implementations to provide service. This allows continued operation if a critical vulnerability is found in one implementation, by shifting traffic to other implementations.
Placing resolvers and control systems in different physical locations will allow continued operation in the event of a disaster or other problem that impacts a single location. In addition, ensuring diverse connectivity to other networks will prevent single points of failure on the network side. Ensuring network diversity may take some care, as it is not always obvious what fate is shared between any given path; this may be physical, virtual, or organizational, and my sometimes be hidden.
#### Security
In addition to the DNS-specific security considerations, normal security best practices for any Internet service should be followed, including updating software updated regularly, patching software as soon as possible for any known security vulnerabilities, following CERT announcements and so on.
#### Certification
It may be useful or required for an organization to obtain specific certifications, such as ISO or SOC 2 Type 2. These can be government-defined or industry-defined. For end users there is typically not much direct value, but business customers will often look for services that are operated by organizations meeting such standards. Audits or other reports about this may be published, see for example: https://www.cloudflare.com/trust-hub/compliance-resources/
## DNS configuration knobs
The DNS is an old protocol that has a lot of settings that can be tweaked. This section reviews these and provides recommendations on which should be used for a resolver.
### DNSSEC validation
**DNSSEC validation should be enabled.**
For: All DNS resolver operators.
DNSSEC validation is the best way to ensure that the answers from the owner of domain name being queried are returned.
The root KSK must be updated when it changes. While [RFC5011](https://www.rfc-editor.org/rfc/rfc5011.html) defines an automated way to do this, a resolver operator will probably either manage this trust anchor directly or have it updated via OS updates.
[RFC9364](https://www.rfc-editor.org/rfc/rfc9364.html) provides a lot of useful information, and links to further documents about DNSSEC. However, operators usually do not need to know the details, and can simply ensure that DNSSEC validation is enabled in their software.
Resolver software that does not support DNSSEC validation should be avoided.
### DNS Transport Protocols
**UDP and TCP must be supported.**
For: All DNS resolver operators.
UDP is what most clients use, and TCP is necessary for DNS answers that are too large for a single UDP packet.
[RFC7766](https://www.rfc-editor.org/rfc/rfc7766.html) explains why TCP is necessary in more detail.
### Packet Fragmentation Avoidance
**Servers should be configured to avoid fragmentation.**
For: ALL DNS resolver operators.
Packet fragmentation can cause issues with DNS over UDP, especially over IPv6. These issues can be minimized by choosing implementations that set IP options to avoid this, and by taking care with EDNS0 message sizes.
Recommendations are available in [draft-ietf-dnsop-avoid-fragmentation]( https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/).
### Encrypted DNS
**At least one of DNS-over-TLS (DoT), DNS-over-HTTPS (DoH), and DNS-over-QUIC (DoQ) should be supported.**
For: All DNS resolver operators.
DoT, DoH, and DoQ are different technologies that all provide an encrypted channel between the resolver and the authoritative server. DoT is the oldest, and provides encrypted DNS using TLS. DoH uses HTTP over TLS as a way to transmit queries and answers, and is widely supported by web browsers. DoQ is the newest, and provides advanced features such as separate streams for each query, avoiding the "head of line" blocking problem common with all protocols layered on top of TCP (such as DoT and DoH).
- DoT - [RFC7858](https://www.rfc-editor.org/rfc/rfc7858.html) - DoH - [RFC8484](https://www.rfc-editor.org/rfc/rfc8484.html) - DoQ - [RFC9250](https://www.rfc-editor.org/rfc/rfc9250.html)
**Discovery of DNS Designated Resolvers**
There are new mechanisms that allow DNS clients to use DNS records to discover encrypted DNS configurations. Resolvers should publish DNS records to assist clients finding encrypted resolvers.
- Discovery of Designated Resolvers - [RFC9462](https://www.rfc-editor.org/rfc/rfc9462.html)
### QNAME Minimization
**QNAME minimization should be enabled.**
For: All DNS resolver operators.
Using QNAME minimization, a resolver does not send the full name that it is trying to resolver to authoritative servers higher in the DNS hierarchy. So, for example, when querying "atlas.ripe.net" the servers for ".net" would only be asked for "ripe.net". This improves privacy for the end user querying the name.
[RFC7816](https://www.rfc-editor.org/rfc/rfc7816.html) covers QNAME minimization.
### Aggressive NSEC caching
**Aggressive NSEC caching may be enabled.**
For: Public resolver operators.
"Aggressive NSEC caching", meaning negative caching based on NSEC and NSEC3 values, can reduce traffic greatly. It is important to protect against random subdomain attacks.
This style of caching takes advantage of the way that NSEC and NSEC3 records cover a range of names in a zone. A resolver can know that a query falls within such a range without sending any further queries, by remembering the NSEC or NSEC3 redords that is has seen as answers to earlier queries.
Aggressive NSEC caching is almost always a good idea. However enabling this is less important for DNS resolver operators who have a close relationship with users, since they can stop attacks by blocking users or otherwise directly dealing with the source of abusive queries.
[RFC8189](https://www.rfc-editor.org/rfc/rfc8189.html) describes negative caching in detail.
### ANY Queries
**ANY queries responses should be limited.***
For: All resolver operators.
Public or large-scale resolvers should be exceptionally careful with queries of type ANY, which return all all records at a given name. If a resolver replies with all of the records cached for a given type, the response can be much larger than for a single record type. Strict limits should be enforced on volumes of such queries to prevent amplification abuse, or truncation should be applied to prevent spoofed redirections.
[RFC8482](https://www.rfc-editor.org/rfc/rfc8482.html) describes several approaches to limiting ANY responses.
### Local Root
**Local root should be used.**
For: Public resolver operators.
Running a local root has several benefits, but it is an additional component to maintain. For public resolver operators this is definitely worth the cost, but other resolver operators may choose to simply send all queries to the well-distributed root name servers.
[RFC8806](https://www.rfc-editor.org/rfc/rfc8806.html) describes local root, including several example configurations.
In the future it will be possible to use ZONEMD to validate the copy of the root zone obtained before using it. This is currently available for the root zone.
[RFC8976](https://www.rfc-editor.org/rfc/rfc8976.html) describes ZONEMD.
### DNS Cookies
**Interoperable DNS Cookies may be supported.**
For: Public resolver operators.
DNS cookies provide some improved security over plain UDP, and are designed to be more lightweight than TCP. If more than one server is responding for a given IP address, then the Server Secret must be shared by all servers, and the answer must be constructed in a consistent manner by all server implementations.
Since client-side support for DNS cookies is not very widespread, and since managing server-side secrets involves some work, the costs may outweigh the benefits for some non-public resolver operators.
[RFC7873](https://www.rfc-editor.org/rfc/rfc7873.html) describes DNS cookies, and [RFC9018](https://www.rfc-editor.org/rfc/rfc9018.html) standardizes shared DNS cookies.
### TTL Recommendations
**TTL limits may be adjusted.**
For: All DNS resolver operators.
Software typically defaults to a maximum stored TTL of 1 or 2 days. A lower TTL will mean removing rarely-used records that have long TTL, and should not have much operational impact from a CPU or network point of view.
It is possible to set a minimum TTL in many implementations. This is a violation of the DNS protocol, although may be useful to reduce load from records with very low TTL (less than 5 seconds).
Note that software may set different maximum and minimum TTL independent of the results that the resolver returns. That may have a significant impact on queries as well, but resolver operators cannot influence that.
### TTL-based Record Pre-Fetch
**TTL record pre-fetch should be enabled when available.**
For: All DNS resolver operators.
Some resolvers have the ability to look up a record before it has expired from cache, in order to refresh the value and extend the TTL. This way there is never a time when the records are missing from the cache. This is not currently standardized, but a form of this was proposed in the IETF as [DNS Hammer]( https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-hammer-03). We recommend turning this feature on if available.
### EDNS Client Subnet (ECS)
**ECS may be enabled.**
For: All DNS resolver operators.
EDNS Client Subnet (ECS) allows the resolver to include information about the IP address of the client querying it when sending messages to authoritative servers. This may allow authoritative servers to provide different answers which are more appropriate for the client. However, ECS will increase the amount of cache space required by resolvers, may reduce DNS performance, and may have privacy implications.
A resolver operator that has clients that are limited to a specific region may see no benefit. A resolver operator that has a widely distributed anycast network may not have much benefit from ECS, since the locations that initiate the query will be close to the client. But a resolver operator that answers client queries only from a few locations, and expects clients to come from a wide area, may provide better service for end-users by supporting ECS.
EDNS client subnet is described in [RFC7871](https://www.rfc-editor.org/rfc/rfc7871.html), an informational RFC.
### Extended DNS Errors
**Extended DNS errors should be enabled.**
For: All DNS resolver operators.
DNS traditionally provides very broad error reporting, SERVFAIL being the most common. This makes diagnosing and fixing problems difficult. Extended DNS errors provide extra information about failures, for example expired DNSSEC signatures. They also allow resolver operators to report administrative reasons for DNS failures, such as blocks due to legal requirements.
[RFC8914](https://www.rfc-editor.org/rfc/rfc8914.html) defines extended DNS errors.
### Negative Trust Anchors
**Negative trust anchors may be deployed.**
For: All DNS resolver operators.
Negative trust anchors (NTA) allow a resolver operator to handle a case where an authoritative server has a DNSSEC problem and becomes inaccessible. They basically disable DNSSEC checking for a domain. When this is warranted is difficult to know with certainty, and will usually requires some manual checking. Since DNSSEC validation is now widespread, DNSSEC failures on the authoritative side will impact many resolvers.
Because of these reasons this document does not recommend NTA, but also does not recommend that a deployment avoid NTA if it makes sense for that environment.
Negative trust anchors are documented in [RFC7646](https://www.rfc-editor.org/rfc/rfc7646.html).
### DNS Error Reporting
**DNS error reporting may be enabled.**
For: All DNS resolver operators.
DNS error reporting is a way for resolver operators to let authoritative operators know about problems in authoritative servers or zones. It provides little direct value for the resolver operators, but over time should improve the overall quality of the DNS ecosystem. It is neither widely deployed nor standardized, but hopefully will be both soon. Resolver operators are encouraged to enable DNS error reporting when it is available.
DNS error reporting is proposed in [draft-ietf-dnsop-dns-error-reporting]( https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting).
### Trust Anchor Reporting
**Trust anchor reporting should be enabled.**
For: All DNS resolver operators.
Trust anchor reporting is a way for resolver operators to convey their DNSSEC trust anchor configuration to the operator of the zone that it is for. For most resolvers this is only the root zone. This information is intended to be used during a root KSK rollover to ensure that it is safe to proceed. In the future ICANN is planning an algorithm roll for the root KSK, and this information could be helpful. Resolver operators are encouraged to enable trust anchor reporting.
[RFC8145](https://www.rfc-editor.org/rfc/rfc8145.html) covers trust anchor reporting, in both possibilities available.
### Name Server Identification
**Servers should be configured to identify themselves.**
For: All DNS resolver operators.
Large resolver operations, especially publicly available resolvers, should support an in-band method of discovery that is obvious to permit users to discover what node has answered their query. This improves troubleshooting significantly, and may be useful for research and testing purposes. NSID (Name Server Identifier) is ideal for this, though also âCH TXT id.serverâ support is also reasonable. Geographic hints should be provided in this data, though specific host data is optional for arrays of servers in clusters. IATA codes have traditionally been used for naming points-of-presence, though this is at the discretion of the operator.
[RFC5001](https://www.rfc-editor.org/rfc/rfc5001.html) describes NSID.
[RFC4892](https://www.rfc-editor.org/rfc/rfc4892.html) describes name server identification in general, and documents the pre-NSID approaches.
## Privacy, Filtering, Transparency
### Privacy & anonymity
DNS Resolver operators are advised to apply [RFC8932](https://www.rfc-editor.org/rfc/rfc8932.html)
"Recommendations for DNS Privacy Service Operators" as follows:
1. its operational and policy guidance related to DNS encrypted transports and data handling, by applying all "Threat mitigations" (thereby by meeting its level of "minimally compliant") and additionally by applying the "Optimizations" on EDNS Client Subnet listed in section 5.3.1.
2. its framework on a Recursive operator Privacy Statement, by publishing a privacy statement on their website covers all topics in Section 6. (See for example [Cloudflare's statement]( https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver) or [Quad9's privacy page](https://www.quad9.net/service/privacy/).)
#### Logging considerations
In addition to the logging recommendations from RFC8932, operators should consider the following:
1. Third party access to personal data: Resolver operators may receive third party requests for information they have logged that relates to users, including IP addresses, queries and meta data. Resolvers should only comply with such requests when balancing legitimate third party interest with the user's fundamental rights, including rights to privacy. Usage information can be personal data, Personally Identifable Infomation (PII) or similarly regulated under the privacy laws applicable to the users, operator or third party, revealing a person's health, lifestyle or other personal preferences (profiling). For example, logging information that documents a user resolving a website for alcoholics anonymous may relate to the health of a person behind an IP address.
2. Data security: DNS Resolver operators should take appropriate technical and organisational measures to protect logging information that relates to users.
#### Advertisement Policy
If there is any advertising from the service, the policy should be published as well as how it can potentially affect the users' privacy.
### Filtering and blocking
#### Block Lists
Resolvers can be directed to block or modify answers in various ways. Blocklists may be provided by governments, communities, or other parties (for example security firms).
Response Policy Zone (RPZ) allows a way to both document specific modifications that resolvers will make to DNS answers, and send the rules to resolvers. This allows updates to occur very quickly. If RPZ or some other high-speed blocking technology is used, the parties supplying these sources must be highly trusted, as changes to blocklists will usually immediately impact user queries.
RPZ is not standardized, but there is an IETF draft, [draft-vixie-dnsop-dns-rpz]( https://datatracker.ietf.org/doc/draft-vixie-dnsop-dns-rpz/00/).
#### Legal blocking
**Legal requests and blocking and filtering laws:** DNS resolver operators should not filter content and block access to web-services. When the local law requires blocking, and the law applies to the resolver, the resolver should transparently disclose a list of blocked websites and services, when possible (disclosing such a list may not be allowed by law or regulation). Similarly, the resolver should disclose the source of such block lists, when possible.
If it is not possible to disclose the source of blocklists, operators should try to be as transparent as possible about how they receive those blocklists, based on what criteria, and how they mitigate errors and false positives. Disclosing which organizations operators interact with, how they liase, and so on, can help users understand the impact on the service provided.
If possible, resolvers should provide information about blocked responses via the Extended DNS Error with the Blocked, Censored, Filtered, or Prohibited code - whichever applies best - along with a text why the response was blocked, censored, filtered, or prohibited.
[RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html#section-4.16) provides information about the meanings of the different codes.
**Community governance of blocklists:** blocklists, if mandatory, have to be audited and assessed by third parties and there should be a right to appeal for those blocked. The Internet community can vet the blocklists from time to time to avoid blocking access to websites that are mistakenly blocked. During crisis - when mistakes can have drastic effects on accessing a critical service - preferably filtering and blocking should not be used.
#### Opt-in/Opt-out Mechanisms
End users may choose to use a DNS resolver that filters specific kinds of traffic. For example, they may wish to avoid potential malware web sites. Or resolver operators may be required to default to filtering but allowed for to provide an unfiltered DNS resolver service.
Depending on the specific requirements, a resolver service may publish different IP addresses and what type of filtering applies to each address. It is also possible to perform client authentication and authorization, using IP-based authentication, TSIG keys, or client-side TLS certificates.
### Transparency
Public DNS resolver operators should publish transparency reports to build user trust in their adherence to policies and practices. This goes beyond our advise to apply RFC8932, section 6.2.
A common frequency is once a year. The reports inform the public about disclosure of user information and removal of content required by law enforcement and other government agencies.
Transparency reports should (to the extent that the law allows) indicate which government agencies and law enforcement agencies request access on what basis.
It should also be clear from the transparency reports what kind of data has been requested and if content removal and content blocking have been requested. Categories of data include: Content Data, Basic Subscriber Data, Other Non-Content Data and Content Blocking.
#### Negative Trust Anchor reporting
Negative Trust Anchors (NTA) are discussed in the previous section on DNS configurations. If NTAs are present in the resolver, they should be published with as much detail as possible about them. This includes reasons for insertion, dates of activation and expected removal dates, or a published review date or cycle for when NTAs should be actively examined for deletion if such fine-grained information cannot be shared.
NTAs are equivalent to a security fault, and may even be more significant than a block event as they remove expected trust behavior with limited signal of that trust downgrade ("limited" because few if any clients care about those response bits changing.).
#### Human rights considerations
DNS resolvers can opt for declaring their understanding of their responsibilities regarding human rights from the Universal Declaration of Human Rights. As an example of a public DNS resolver operator, Quad9 mentions rights to freedoms without distinction made on the basis of country, no interference with privacy, the right to freedom of opinion and expression, the right to peaceful assembly, and the right to freely participate in the cultural life of the community.
See [Quad9's Human Rights Considerations](https://www.quad9.net/privacy/human-rights-considerations/ ) for the full statement.
It also invokes other human rights related solutions other than [UDHR](https://www.un.org/en/universal-declaration-human-rights/) such as Articles 8 and 9 of Resolution 42/15 of the United Nations Human Rights Council on the right to privacy in the digital age of 26 September 2019 more directly define the responsibilities of the private sector toward the furtherance of human rights in modern terms. They also follow the Guidelines for Human Rights Protocol and Architecture Consideration of the Human Rights Protocol Considerations Research Group at Internet Research Task Force.
The latest version of the IRTF [Guidelines for HRPC](https://tools.ietf.org/html/draft-irtf-hrpc-guidelines) may be considered for all network operators.
## Appendix A: Why Did RIPE Write This Document?
There is increasing concern that large open DNS resolvers will become centralised points of DNS operations on the Internet. In order to address this, the European Commission issued the [DNS4EU]( https://hadea.ec.europa.eu/calls-proposals/equipping-backbone-networks-high-... ) proposal. However, such an initiative could lead to centralised guidance or regulation which might interfere with the decentralised way the Internet infrastructure works - including the DNS. See for reference the [RIPE NCC Open House discussion]( https://labs.ripe.net/author/chrisb/dns4eu-ripe-ncc-open-house-discussion/ ) on this topic.
Rather than attempting to respond to the EC proposal or organize specific DNS resolver deployments, the RIPE community has decided that it is best able to provide advice and guidance. The RIPE Community is well positioned to provide a set of Best Current Practices that operators of Open DNS Resolvers will be encouraged to subscribe to.
Sorry I have found it a bit hard to track the document so some of these may be duplicates ### About Recomendation Text s/Recomendation/Recommendation may have significant s/may have significant /may have a significant/ NSEC3 values, can reduce s/NSEC3 values, can reduce/NSEC3 values can reduce/ NSEC3 redords s/NSEC3 redords/NSEC3 records/ which return all all s/ which return all all / which return all / s/liase/liaise/ On Sun, Mar 24, 2024 at 12:25â¯PM Shane Kerr <shane@time-travellers.org> wrote:
Maarten,
Thank you for your suggestions, edits, and discussion. I've updated the final draft to give us a final, final draft. ð
I've included the last (?) version at the bottom of this e-mail, and responded to your suggestions inline below.
On 19/03/2024 10.24, Maarten Aertsen wrote:
* Those running public DNS resolver services, and
Should we remove "public" here?
Hm, good point!
- Data Security: Since you are in control of the physical servers, there is no risk of data leakage that can occur due to vulnerabilities in multi-tenant virtualization platforms, including CPU cache-based side-channel vulnerabilities. It could be argued that attacks targeting such issues are rare, and their impact on a DNS resolver service is low, but potential breaches may have significant privacy impact. It is advised to evaluate this against your organisation's risk model, or to discuss this with your information security compliance experts.
The ", or [..]" This feels a bit wordy; we don't suggest who to talk to for all the other recommendations either.
Makes sense. Discussing with experts is basically an option for everything. ð
#### Server capacity
If using a model that is easy to scale (cloud based, or Kubernetes based, or similar), then getting server capacity correct is largely a
Given the earlier text about Kubernetes being 'similar' to cloud, "or Kubernetes based, " can probably be removed.
I'm inclined to leave this in. I'd rather be explicit than implicit.
Since DNS is mostly UDP-based, it is often easy to generate large amounts of spoofed traffic to and from DNS servers. DNS traffic is small compared to application traffic (videos and other content), but still significant. Authoritative server operators often build their networks and servers to handle 10 times their normal load. Recursive server operators may need to do the same, although the service only
I would split this sentence, to read:
server operators may need to do the same. When the service only
Fair.
accepts traffic from IP addresses that cannot be spoofed (for example users within a network that operated by the same company) then this
remove "then"
Done.
### Resilience
#### System Diversity
In addition to the software considerations above, operators should
Either change to "software **licensing** considerations", or start the sentence with Operators. After all, the previous part of the text is not about software considerations, so current wording may be a bit confusing to linear readers.
Makes sense. I've started with Operators, no need to remind people of the other considerations here.
consider whether to use different server implementations to provide
s/server/software/ ?
Makes sense.
In addition to the DNS-specific security considerations, normal security best practices for any Internet service should be followed, including updating software updated regularly, patching software as soon as possible for any known security vulnerabilities, following CERT announcements and so on.
Perhaps CERT/CSIRT. Not super important.
You led me down a short trip to the Wikipedia:
https://en.wikipedia.org/wiki/Computer_emergency_response_team
In spite of CMU's trademark on the term CERT (?!?!), I see way more CERT in the national lists than CSIRT, so I'll stick with it.
In a random note, the RIPE Database has an IRT object type rather than a CERT or CSIRT object type, through some artifact of history. ð
#### Certification
It may be useful or required for an organization to follow specific
s/follow/obtain/ ?
In this case "follow" instead of "obtain" was deliberate. It might not be necessary to actually go through the cost of getting certification in order to get the benefits. But, since this section concludes mentioning that business customers will look for them, "obtain" probably makes more sense.
certifications, such as ISO or ITIL. These can be government-defined
Not sure if (unspecified) "ISO or ITIL" are the most relevant examples. I would either remove or replace by say "ISO-IEC 27017, 27018 or SOC 2 Type 2", which all relate to services provided by an organisation, to be relied on by users of that service.
Replaced with "ISO or SOC 2 Type 2".
QUESTION: Do we need to publish certificate in other ways that via the DDR mechanisms?
Should this remain in?
Good point, removed!
### TTL-based Record Pre-Fetch
**TTL record pre-fetch should be enabled when available.**
I would remove "when available", seeing that the last sentence of the next paragraph already covers this.
I'm leaving it in, since we use that exact phraseology elsewhere.
### DNS Error Reporting
**DNS error reporting may be enabled.**
For: All DNS resolver operators.
DNS error reporting is a way for resolver operators to let authoritative operators know about problems in authoritative servers or zones. It provides little direct value for the resolver operators, but over time should improve the overall quality of the DNS ecosystem. It is neither widely deployed nor standardized, but hopefully will be both soon. Resolver operators are encouraged to enable DNS error
To me, 'may be' does not sound like much encouragement. Should this be 'should be' instead? The paragraph already explains that availability is limited for the moment.
I'm not sure we have enough operational experience to know if this is actually a good idea. It may end up being spammy, or unintentionally result in privacy leaks, or any other kinds of unpleasant side-effects. I don't expect it, but I also don't feel comfortable recommending it strongly.
## Privacy, Filtering, Transparency
Reviewing this next part was a bit painful, because I was involved in writing it and yet I see quite a few places where I feel we should improve. After re-reading RFC8932 for the second time, I noticed quite some overlap where RFC8932 is more exhaustive, specific and practicable. By creating overlap, I think we may be watering down our own advise. Below I go over all the items one by one, reference specific sections to advocate for removal of any such overlap.
Okay, thanks for the detailed re-reading.
### Privacy & anonymity
Operators are advised to apply
DNS resolver operators
Yes.
[RFC8932](https://www.rfc-editor.org/rfc/rfc8932.html)
"Recommendations for DNS Privacy Service Operators" as follows:
1. its operational and policy guidance related to DNS encrypted transports and data handling, by applying all "Threat mitigations" (thereby by meeting its level of "minimally compliant") and additionally by applying the "Optimizations" on EDNS Client Subnet listed in section 5.3.1.
2. its framework on a Recursive operator Privacy Statement, by publishing a privacy statement on their website that is compliant with Section 6.
I suggest we strengthen this sentence a bit, then remove duplicates in the next section:
s/that is compliant with/covers all topics in/
Makes sense.
#### Logging considerations
1. Public privacy policy: DNS resolvers are recommended to publish their privacy policies transparently on their website. It can be a brief privacy commitment as well or be more elaborate on how the privacy policy was made. (See for example [Cloudflare's statement]( https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver) or [Quad9's privacy page](https://www.quad9.net/service/privacy/).)
Such policies should explicitly mention the sampling rate of DNS queries/responses that are kept, and whether these are anonymized.
This is fully covered by the reference to RFC8932, Section 6. I suggest we remove this text.
Okay, that makes some sense. I kept the examples from Cloudflare and Quad9, but moved them at the end of the previous section.
2. Third party access to personal data: it seems that the only critical personal data that DNS resolvers collect are IP addresses and the queries that are resolved. The other meta data collected can be used to have an understanding of for example which user accessed which website which can reveal information about a personâs health, lifestyle and other personal preferences (we call this profiling). For example, resolving the website for alcoholics anonymous may tell you something about the health of a person behind an IP address. IP addresses are personally identifiable information. Follow the applicable privacy laws or privacy principles when receiving third party requests to access.
Resolvers should only comply with such requests when balancing legitimate third party interest with other fundamental rights.
This goes beyond RFC8932, Section 5.3.3 and Section 6.1.1 item 2 and may therefore be worth keeping.
I suggest re-ordering this paragraph a bit to start with the advice. The following is an attempt to reorder:
Resolver operators may receive third party requests for information they have logged that relates to users, including IP addresses, queries and meta data. Resolvers should only comply with such requests when balancing legitimate third party interest with the user's fundamental rights, including rights to privacy. Usage information can be personal data, PII or similarly regulated under the privacy laws applicable to the users, operator or third party, revealing a person's health, lifestyle or other personal preferences (profiling). For example, logging information that documents a user resolving a website for alcoholics anonymous may relate to the health of a person behind an IP address.
Makes sense, I've included this text.
3. Access to data for researchers: how it is done, who has access and who can request access, how the resolver makes a decision to give access (validated and credible researchers, what they can access and other issues)
Covered in RFC8932, Section 5.3.3. Suggest removal.
Removed.
4. Data minimization: do not collect personal information not needed for critical operations. Only retain or use what is being asked (the query). If collecting data to make the service more private and secure, explain the rationale for each piece of data (data collection purpose)
Covered in RFC8932 section 5.2.1 and section 5.2.2. Suggest removal.
Removed.
5. Encryption: If data is encrypted, explain how it has been encrypted (DoH, DoT, or so on).
Covered in RFC8932, Section 6.1.2, item 2. Suggest removal.
Removed.
6. Data security and retention: when to delete the data and how it is stored
Data retention is covered in RFC8932 section 5.2.1 and section 5.2.2. Section 5.2.1, last bullit under mitigations sets a security goal relating to data access, though the word security is not used (it is the scope of the entire document).
Suggest removal. Alternatively, abstract to a level higher than RFC8932 by stating something like the following (with limited operational value):
2. Data security: DNS Resolver operators should take appropriate technical and organisational measures to protect logging information that relates to users.
I've included this higher-level recommendation.
**Legal requests and blocking and filtering laws:** DNS resolvers
operators
Updated.
should not filter content and block access to web-services. When the local law requires blocking, and the law applies to the resolver, the resolver should transparently disclose a list of blocked websites and services, when possible (disclosing such a list may not be allowed by law or regulation). Similarly, the resolver should disclose the source of such block lists, when possible.
If it is not possible to disclose the source of blocklists, operators should try to be as transparent as possible about how they receive those blocklists, based on what criteria, and how they mitigate errors and false positives. Disclosing which organizations operators interact with, how they liase, and so on, can help users understand the impact on the service provided.
If possible, resolvers should provide information about blocked responses via the Extended DNS Error with the Blocked, Censored, Filtered, or Prohibited code - whichever applies best - along with a text why the response was blocked, censored, filtered, or prohibited.
[RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html#section-4.16) provides information about the meanings of the different codes.
I like these paragraphs, but they are also covered by RFC8932, section 6.1.1 item 6 (result filtering), which we already advise to apply. As an example of where that section is stronger, it does not feature 'when possible' escape hatches.
I'm not sure what to do here. At a minimum, I believe we should make a reference to that content and substantiate why we feel it is worth repeating here (while not the other topics of RFC8932).
Interesting. The "when possible" language was added in recognition that there may be legal or other barriers preventing such transparency.
Also, RFC 8932 6.1.1 just talks about documentation... our text here actually recommends not filtering, which RFC 8932 does not do.
RFC 8932 also doesn't reference RFC 8914, which makes sense since they came out very near to each other.
So... I understand the concern about re-specifying things, but I'm actually happy to let this text stand.
**Community governance of blocklists:** blocklists, if mandatory, have to be audited and assessed by third parties and there should be a right to appeal for those blocked. The Internet community can vet the blocklists from time to time to avoid blocking access to websites that are mistakenly blocked. During crisis - when mistakes can have drastic effects on accessing a critical service - preferably filtering and blocking should not be used.
This is not covered by 8932, so relevant to keep.
ð
### Transparency
Suggest leading with the advice:
Public DNS resolver operators should publish transparency reports to build user trust in their adherence to policies and practices. This goes beyond our advise to apply RFC8932, section 6.2.
Makes sense. Updated.
DNS resolvers usually provide transparency reports once a year. The
Suggest to replace with:
A common frequency is once a year. The
Done.
#### Voluntary certificates and standards
Some DNS resolvers opt for obtaining certificates in security and privacy. Some also undertake audits on their privacy practices. See for example:https://www.cloudflare.com/trust-hub/compliance-resources/
Suggest removing this; certification is already covered under ### Resilience above. Should the group feel that this is the most appropriate place, I suggest moving that section to replace the one here.
Good point. I added a bit of text mentioning audits or reports, and include the link as an example there.
#### Human rights considerations
DNS resolvers can opt for declaring their understanding of their responsibilities regarding human rights from the Universal Declaration of Human Rights. Specifically, Quad9 mentions rights to freedoms
s/Specifically/As an example of a public DNS resolver operator/
Make sense, updated.
-- Shane
# DNS Resolver Recommendations
About the DNS Resolver Best Common Practice Task Force
https://www.ripe.net/participate/ripe/tf/dns-resolver-best-common-practice-t...
## Terminology
* Open Resolver: A DNS resolver that accepts queries from any client. Often the result of misconfiguration.
* Public Resolver: A resolver intentionally configured to be an open resolver.
## Introduction
### What Is This Document? Who Is It For?
This document presents recommendations and best current practices for operating DNS resolvers, both public and non-public ones. It covers technical aspects of operations and provides best practice recommendations for data management, with a particular focus on user privacy, security, and resilience.
The document serves as guidance for the wider Internet community, offering input to:
* Those running DNS resolver services, and * Those who want to make informed choices between such services.
Its purpose is to provide clear guidance and promote effective practices in DNS resolver operation.
The intended audience is not the entire DNS community. Advice here is probably not useful for operators of authoritative servers, domain registrars, and so on. It is also not meant to be an introductory or educational document. There are many documents which cover the basics of DNS and the roles of organizations in it; a good overview is:
Addressing the challenges of modern DNS - a comprehensive tutorial by van der Toorn et al.
https://ris.utwente.nl/ws/files/282427879/1_s2.0_S1574013722000132_main.pdf
The document does not consider how to measure adherence to these recommendations. So it is not intended to be used for certification, although certification created based on the principles here is possible.
### How Is This Document Organized?
This document has a number of sections, and specific recommendations in each section. The intent is for each recommendations to have clear guidance at the top, and then background and discussion related to the recommendation afterwards. Each recommendation indicates whether it is mostly for operators of public resolvers or for operators of any resolver.
### About Recomendation Text
This is not a standards document, and does not propose any way to measure compliance or interoperability. It does use words like "should" or "may be" throughout. These are meant to be interpreted in the usual English sense, and not as IETF-style RFC 2119 jargon.
## System and Network Hardening
### Infrastructure considerations
Running any Internet service requires attention to the infrastructure used to operate it. This section discusses various approaches that can be used to run a DNS resolver. Everything applies to both public and non-public DNS resolvers.
#### Bare metal or public cloud
All DNS resolver software can run either on dedicated servers (rented or colocated), or in virtualized clouds, or in a combination of those. Every approach has pros and cons. Most of these are not specific to running DNS resolvers, however, some of them are.
**Running DNS resolver instances as OS level daemons on bare metal hosts:**
Pros:
- Performance: Bare metal servers have direct access to the underlying hardware, and can offer superior performance/cost balance by avoiding the overhead associated with virtualization. Moreover, you have full control over the server's configurations, down to the hardware level, which can be beneficial for performance and cost optimization once you get the understanding of your typical work load during peak hours.
- Data Security: Since you are in control of the physical servers, there is no risk of data leakage that can occur due to vulnerabilities in multi-tenant virtualization platforms, including CPU cache-based side-channel vulnerabilities. It could be argued that attacks targeting such issues are rare, and their impact on a DNS resolver service is low, but potential breaches may have significant privacy impact. It is advised to evaluate this against your organisation's risk model.
- Predictability: Because there is no virtualization layer and no "noisy neighbours" on the host, the performance of your servers is more predictable.
Cons:
- Cost of failure: If you pick hardware configuration that is not optimal for the workload of your DNS resolver, you may need to upgrade and replace hardware components afterwards. Ways to reduce this risk include renting servers instead of buying them, carrying load testing with data similar to production workloads, and providing limited beta access to the service before it fully enters the production phase.
- Scalability: Scaling up with physical servers means acquiring or renting, installing, and configuring new hardware, which will take more time than provisioning new virtual servers in a cloud environment. Moreover, most cloud environments will provide you with cluster autoscaling features, which could barely be achieved in bare metal.
- Maintenance: You will be responsible for all server maintenance tasks, including hardware issues, which can require significant effort and specific expertise.
- Redundancy: Setting up high availability and disaster recovery strategies can be more complex and time consuming compared to the cloud, where these features are often provided as value added products. See the Redundancy section for more details.
**Running DNS resolver instances in containers in a public cloud:**
Pros:
- Scalability: Clouds excel at scaling applications. You can scale up and down rapidly based on load, which is important for a DNS resolver that needs to handle variable query loads. In case of regional or geographically distributed resolvers, in every region where the resolver would be deployed, daily periodicity is likely to be observed, for example peak hour is likely to occur around 19:00 local time, and off-peak hours may begin at around 01:00-03:00. In a situation like that, using cluster autoscaling features and tools, you can run less instances in the night and more instances throughout the day, which may help to optimize your cloud hosting costs.
- Fault Tolerance and High Availability: Most clouds have built-in strategies, features, and products for handling node failures, which can increase your service's availability.
- Deployment and Management: Cloud providers offer built-in methods to deploy and manage applications, which can simplify operations and reduce the likelihood of human errors if your infrastructure management department is already familiar with these tools.
- Cost: While this largely depends on your specific usage, cloud services can sometimes be more cost-effective than managing your own physical servers, especially when you consider the total cost of ownership, including power, cooling, and maintenance.
Cons:
- Performance: The virtualization layer of public clouds can impact performance. While this certainly could be mitigated through scaling the number of virtual hosts, the cost would also increase accordingly.
- Complexity: Advanced cloud technologies are complex systems which come with a steep learning curve. Without prior experience, properly configuring and managing a cloud-based compute cluster can be challenging.
- Cost Variability: While the cloud can be cheaper, it can also be more expensive if not properly managed. Costs can rise unexpectedly based on traffic. Make sure to always set some limits on how much may be spent on hosting in the cloud control panel, and to set up notifications to be sent to you when these thresholds are about to be triggered.
- Multi-tenancy Risks: In a public cloud environment, the "noisy neighbour" problem could potentially affect your service's performance. Additionally, even though cloud providers take steps to isolate tenant environments, vulnerabilities could potentially expose sensitive data (see the previous section for a detailed explanation).
**Additional considerations**
- In today's environments, Kubernetes and Terraform are sometimes used as a substitute for cloud APIs when it comes to production services' management. When running a DNS resolver in a Kubernetes cluster on top of a public cloud environment, all the pros and cons of the public cloud apply; basically, Kubernetes becomes your public cloud provider. If you have significant prior experience running services in Kubernetes in production, you may successfully replicate your experience with the DNS resolver software. Otherwise, we would advise against Kubernetes in this case.
- The only reason we may find to run a DNS resolver in a Kubernetes cluster on top of self-hosted dedicated servers is when you have significant hands-on experience with Kubernetes and it is natural for you to manage applications this way. Otherwise, running DNS resolver daemons in containers brings little, if any, benefit. Autoscaling features are not available to you in this case, and neither horizontal nor vertical pod autoscaling is of any use, because DNS resolver software typically scales in-host by itself just fine.
- When designing a cluster of resolvers for autoscaling, keep in mind that newly spawned resolver machines would need to populate resolver cache first before they are fully useful. Your DNS resolver software may provide cache replication mechanisms. Otherwise, it is safe to overprovision clusters somewhat under heavy load, and discarding excessive instances once all the caches are populated and the average load of a compute instance decreases. In addition, it may be worthwhile to consider sharing cache data between instances.
- It is always advised to prefer environments your infrastructure management team is familiar with.
### Software considerations
#### Open Source
**Recommendation**: Choose any well-maintained DNS software you are comfortable using. Regardless of which software you choose, ensure you have somewhere to go for support. In the case of open source software, consider providing financial support to ensure continued development. Some open source maintainers take donations, while others offer support contracts.
There are both open source and proprietary implementations of DNS resolver software. Mixing these is also possible, for example, by using proprietary extensions with open source software or deploying open source software modified in-house.
General observations: - Software licensing is orthogonal to software security. Neither is proprietary software less secure on principle nor are contributions by "unknown" developers more of a risk in open source.
Benefits of open source: - Open source allows for inspection, independent auditing, and troubleshooting. - Open source can avoid vendor lock-in. - Open source can aid internet standards development. Widely-deployed open source implementations allow proponents of standards drafts to contribute proof of concept implementations without permission or cooperation of vendors.
Drawbacks of open source - Both open source and proprietary software require skilled maintenance, which has costs. Proprietary licensed software or appliances typically come with license fees to cover these. In contrast, open source licenses decouple usage by operators from monetary compensation to developers. It is up to operators to consider the financial sustainability of continued maintenance of the open source DNS software they depend upon.
Please also consider deploying different software implementations to ensure diversity, as discussed in the diversity section below.
### Networking considerations
#### IPv4 and IPv6
**If available, both IPv4 and IPv6 must be deployed.**
Large parts of the authoritative DNS are only accessible via IPv4, so the resolver must be able to originate IPv4 queries. Authoritative DNS that is only accessible via IPv6 is very rare.
Depending on the connectivity of clients, a resolver may be IPv4-only, IPv6-only, or support IPv4 and IPv6.
#### Addressing
**Using multiple IP addresses for the service address should be considered.**
Using 2 or more IPv4 addresses and 2 or more IPv6 addresses from different RIR will allow resilience in failure at an RIR, either governance, security, or technical. Note that support for multiple addresses for recursive resolvers varies and some clients perform poorly if any address does not respond normally.
There is no need to pick an IPv4 address with all octets the same, like 2.2.2.2 or 11.11.11.11.
**Publishing a list of back-end addresses used for resolving should be considered.**
Publishing a list of back-end addresses used for resolving can be useful for other network & DNS operators (for example, geo-IP location, making sure data is getting to correct places, and so on).
#### High Availability
This can be considered in terms of local and global scope.
##### Local scope
Inside a single location/region, such as an office, campus, or small ISP network, the main availability concern is that a resolver is always reachable. Client systems can be configured with multiple resolver addresses, but the failover behaviour of stub resolvers to a second address can be painful. Ideally the primary address is highly available and such fallback rarely required. How much effort is put into ensuring this is true should probably scale in line with the number of users, or sensitivity of the clients using that resolver to delayed resolution.
There are several ways to promote high availability of an individual resolver address, such as dedicated load balancing equipment, or network techniques like VRRP, or IP anycast. These generally have in common a pool of recursive servers and the means to direct queries to them when a health check has determined them to be capable of answering those queries.
Dedicated free or commercially produced, hardware or software load balancing solutions are available. These typically own the resolver IP address and forward queries to the currently available instances of a pool of recursive servers.
VRRP enables a technique to make the resolver IP address available on multiple servers, often used to provide automatic failover between two. A pool of recursive servers using this technique must reside in the same broadcast domain.
IP anycast in the local scope typically involves a pool of recursive servers advertising a route to a shared resolver IP address into a routing protocol. This can be configured in failover or load-sharing configurations. A load sharing configuration typically requires network equipment able to balance traffic to a destination over equal cost paths (ECMP). A pool of recursive servers using this technique can be distributed in different parts of the network.
##### Global scope
The same concerns as for local service availability are present in the global scope, with the added issue that DNS resolution over long distances may be slow. Practically speaking, only multiple resolver addresses, or IP anycast are useful strategies here. The motivations for finding better failover solutions than multiple resolver addresses have been covered above.
IP anycast in the global scope means routing the same IP prefix to more than one location. This can provide effective solutions for failover and, when optimally configured for routing client queries to the topologically least distant recursive server location. IP anycast in the global scope requires the use of globally routable prefixes. If a separate prefix is to be used for anycasting, usually this means a /24 in IPv4 and a /48 in IPv6, as those are the smallest sizes that will be widely propagated in BGP. A common practice is to use a covering prefix (/23 in IPv4 or /47 in IPv6) for fallback, and a more-specific prefix (/24 or /48) for the traffic. The more-specific prefix can then be withdrawn to send traffic to a backup site; this will happen automatically if the site is disconnected from routing.
[RFC7094](https://www.rfc-editor.org/rfc/rfc7094.html) discusses anycast architecture in detail, including references to various other RFC which discuss anycast in general and to DNS in particular.
[RFC4786](https://datatracker.ietf.org/doc/html/rfc4786) discuses operation of anycast services.
##### Generally
Operators of a globally scoped recursive service are encouraged to also adopt the local scope recommendations in each of the locations where the service is provisioned.
Though the above deals with the shortcomings of reliance on stub resolver failover between a list of addresses those recommendations shouldnât be seen as an exclusive alternative. Multiple resolver addresses, where each is provisioned using differing failover strategies, can provide a resolver of last resort and further improved resilience.
#### Ingress Filtering
**Ingress Filtering to follow BCP 38 should be deployed.**
DNS normally uses UDP traffic, which makes it a common vector of both [reflection](https://en.wikipedia.org/wiki/Reflection_attack) and [amplification]( https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-a... ) attacks. To minimize the amount of spoofed traffic that a resolver responds to, the network should be configured as recommended in [BCP 38](https://www.rfc-editor.org/rfc/rfc2827.html).
#### RPKI Sign Advertised Routes
**Route Advertisements should be signed using RPKI**
Using RPKI to sign any route advertisements - either toward authoritative servers or toward DNS clients - is straightforward to do and will reduce the impact of BGP misconfigurations and some BGP hijacking attempts.
RPKI validation is also possible, although the effort is greater. It is possible that the hosting provider or the transit provider for your service validates BGP; asking and making this part of your selection criteria is reasonable.
#### (D)DoS measures
Denial-of-Service (DoS) attacks, both distributed (DDoS) and not are a threat to any Internet service. Network operators for a service providing any DNS service must be prepared for large amounts of attack traffic.
In addition to attacks on the service itself, a resolver may be used both as an attack reflector and as an attack amplifier.
Active monitoring of network and service usage, careful logging, and a security team that is able to respond to problem reports is necessary. Mitigation techniques will include filtering or rate-limiting traffic, both on the authoritative and client side of the resolver.
### Capacity planning
#### Server capacity
If using a model that is easy to scale (cloud based, or Kubernetes based, or similar), then getting server capacity correct is largely a question of budgeting. If using a less-flexible model (bare metal for example), then under-estimating will mean problems delivering service.
Hardware performance varies widely, as does operating system and resolver performance. Some lab testing will be necessary to estimate the number of systems needed.
#### Network capacity
Since DNS is mostly UDP-based, it is often easy to generate large amounts of spoofed traffic to and from DNS servers. DNS traffic is small compared to application traffic (videos and other content), but still significant. Authoritative server operators often build their networks and servers to handle 10 times their normal load. Recursive server operators may need to do the same. When the service only accepts traffic from IP addresses that cannot be spoofed (for example users within a network that operated by the same company) this can be reduced, for example to 3 times normal load. To estimate expected load, the best approach is to examine historical usage for the actual expected users of the system.
### Resilience
#### System Diversity
Operators should consider whether to use different software implementations to provide service. This allows continued operation if a critical vulnerability is found in one implementation, by shifting traffic to other implementations.
Placing resolvers and control systems in different physical locations will allow continued operation in the event of a disaster or other problem that impacts a single location. In addition, ensuring diverse connectivity to other networks will prevent single points of failure on the network side. Ensuring network diversity may take some care, as it is not always obvious what fate is shared between any given path; this may be physical, virtual, or organizational, and my sometimes be hidden.
#### Security
In addition to the DNS-specific security considerations, normal security best practices for any Internet service should be followed, including updating software updated regularly, patching software as soon as possible for any known security vulnerabilities, following CERT announcements and so on.
#### Certification
It may be useful or required for an organization to obtain specific certifications, such as ISO or SOC 2 Type 2. These can be government-defined or industry-defined. For end users there is typically not much direct value, but business customers will often look for services that are operated by organizations meeting such standards. Audits or other reports about this may be published, see for example: https://www.cloudflare.com/trust-hub/compliance-resources/
## DNS configuration knobs
The DNS is an old protocol that has a lot of settings that can be tweaked. This section reviews these and provides recommendations on which should be used for a resolver.
### DNSSEC validation
**DNSSEC validation should be enabled.**
For: All DNS resolver operators.
DNSSEC validation is the best way to ensure that the answers from the owner of domain name being queried are returned.
The root KSK must be updated when it changes. While [RFC5011](https://www.rfc-editor.org/rfc/rfc5011.html) defines an automated way to do this, a resolver operator will probably either manage this trust anchor directly or have it updated via OS updates.
[RFC9364](https://www.rfc-editor.org/rfc/rfc9364.html) provides a lot of useful information, and links to further documents about DNSSEC. However, operators usually do not need to know the details, and can simply ensure that DNSSEC validation is enabled in their software.
Resolver software that does not support DNSSEC validation should be avoided.
### DNS Transport Protocols
**UDP and TCP must be supported.**
For: All DNS resolver operators.
UDP is what most clients use, and TCP is necessary for DNS answers that are too large for a single UDP packet.
[RFC7766](https://www.rfc-editor.org/rfc/rfc7766.html) explains why TCP is necessary in more detail.
### Packet Fragmentation Avoidance
**Servers should be configured to avoid fragmentation.**
For: ALL DNS resolver operators.
Packet fragmentation can cause issues with DNS over UDP, especially over IPv6. These issues can be minimized by choosing implementations that set IP options to avoid this, and by taking care with EDNS0 message sizes.
Recommendations are available in [draft-ietf-dnsop-avoid-fragmentation]( https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/).
### Encrypted DNS
**At least one of DNS-over-TLS (DoT), DNS-over-HTTPS (DoH), and DNS-over-QUIC (DoQ) should be supported.**
For: All DNS resolver operators.
DoT, DoH, and DoQ are different technologies that all provide an encrypted channel between the resolver and the authoritative server. DoT is the oldest, and provides encrypted DNS using TLS. DoH uses HTTP over TLS as a way to transmit queries and answers, and is widely supported by web browsers. DoQ is the newest, and provides advanced features such as separate streams for each query, avoiding the "head of line" blocking problem common with all protocols layered on top of TCP (such as DoT and DoH).
- DoT - [RFC7858](https://www.rfc-editor.org/rfc/rfc7858.html) - DoH - [RFC8484](https://www.rfc-editor.org/rfc/rfc8484.html) - DoQ - [RFC9250](https://www.rfc-editor.org/rfc/rfc9250.html)
**Discovery of DNS Designated Resolvers**
There are new mechanisms that allow DNS clients to use DNS records to discover encrypted DNS configurations. Resolvers should publish DNS records to assist clients finding encrypted resolvers.
- Discovery of Designated Resolvers - [RFC9462](https://www.rfc-editor.org/rfc/rfc9462.html)
### QNAME Minimization
**QNAME minimization should be enabled.**
For: All DNS resolver operators.
Using QNAME minimization, a resolver does not send the full name that it is trying to resolver to authoritative servers higher in the DNS hierarchy. So, for example, when querying "atlas.ripe.net" the servers for ".net" would only be asked for "ripe.net". This improves privacy for the end user querying the name.
[RFC7816](https://www.rfc-editor.org/rfc/rfc7816.html) covers QNAME minimization.
### Aggressive NSEC caching
**Aggressive NSEC caching may be enabled.**
For: Public resolver operators.
"Aggressive NSEC caching", meaning negative caching based on NSEC and NSEC3 values, can reduce traffic greatly. It is important to protect against random subdomain attacks.
This style of caching takes advantage of the way that NSEC and NSEC3 records cover a range of names in a zone. A resolver can know that a query falls within such a range without sending any further queries, by remembering the NSEC or NSEC3 redords that is has seen as answers to earlier queries.
Aggressive NSEC caching is almost always a good idea. However enabling this is less important for DNS resolver operators who have a close relationship with users, since they can stop attacks by blocking users or otherwise directly dealing with the source of abusive queries.
[RFC8189](https://www.rfc-editor.org/rfc/rfc8189.html) describes negative caching in detail.
### ANY Queries
**ANY queries responses should be limited.***
For: All resolver operators.
Public or large-scale resolvers should be exceptionally careful with queries of type ANY, which return all all records at a given name. If a resolver replies with all of the records cached for a given type, the response can be much larger than for a single record type. Strict limits should be enforced on volumes of such queries to prevent amplification abuse, or truncation should be applied to prevent spoofed redirections.
[RFC8482](https://www.rfc-editor.org/rfc/rfc8482.html) describes several approaches to limiting ANY responses.
### Local Root
**Local root should be used.**
For: Public resolver operators.
Running a local root has several benefits, but it is an additional component to maintain. For public resolver operators this is definitely worth the cost, but other resolver operators may choose to simply send all queries to the well-distributed root name servers.
[RFC8806](https://www.rfc-editor.org/rfc/rfc8806.html) describes local root, including several example configurations.
In the future it will be possible to use ZONEMD to validate the copy of the root zone obtained before using it. This is currently available for the root zone.
[RFC8976](https://www.rfc-editor.org/rfc/rfc8976.html) describes ZONEMD.
### DNS Cookies
**Interoperable DNS Cookies may be supported.**
For: Public resolver operators.
DNS cookies provide some improved security over plain UDP, and are designed to be more lightweight than TCP. If more than one server is responding for a given IP address, then the Server Secret must be shared by all servers, and the answer must be constructed in a consistent manner by all server implementations.
Since client-side support for DNS cookies is not very widespread, and since managing server-side secrets involves some work, the costs may outweigh the benefits for some non-public resolver operators.
[RFC7873](https://www.rfc-editor.org/rfc/rfc7873.html) describes DNS cookies, and [RFC9018](https://www.rfc-editor.org/rfc/rfc9018.html) standardizes shared DNS cookies.
### TTL Recommendations
**TTL limits may be adjusted.**
For: All DNS resolver operators.
Software typically defaults to a maximum stored TTL of 1 or 2 days. A lower TTL will mean removing rarely-used records that have long TTL, and should not have much operational impact from a CPU or network point of view.
It is possible to set a minimum TTL in many implementations. This is a violation of the DNS protocol, although may be useful to reduce load from records with very low TTL (less than 5 seconds).
Note that software may set different maximum and minimum TTL independent of the results that the resolver returns. That may have a significant impact on queries as well, but resolver operators cannot influence that.
### TTL-based Record Pre-Fetch
**TTL record pre-fetch should be enabled when available.**
For: All DNS resolver operators.
Some resolvers have the ability to look up a record before it has expired from cache, in order to refresh the value and extend the TTL. This way there is never a time when the records are missing from the cache. This is not currently standardized, but a form of this was proposed in the IETF as [DNS Hammer]( https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-hammer-03). We recommend turning this feature on if available.
### EDNS Client Subnet (ECS)
**ECS may be enabled.**
For: All DNS resolver operators.
EDNS Client Subnet (ECS) allows the resolver to include information about the IP address of the client querying it when sending messages to authoritative servers. This may allow authoritative servers to provide different answers which are more appropriate for the client. However, ECS will increase the amount of cache space required by resolvers, may reduce DNS performance, and may have privacy implications.
A resolver operator that has clients that are limited to a specific region may see no benefit. A resolver operator that has a widely distributed anycast network may not have much benefit from ECS, since the locations that initiate the query will be close to the client. But a resolver operator that answers client queries only from a few locations, and expects clients to come from a wide area, may provide better service for end-users by supporting ECS.
EDNS client subnet is described in [RFC7871](https://www.rfc-editor.org/rfc/rfc7871.html), an informational RFC.
### Extended DNS Errors
**Extended DNS errors should be enabled.**
For: All DNS resolver operators.
DNS traditionally provides very broad error reporting, SERVFAIL being the most common. This makes diagnosing and fixing problems difficult. Extended DNS errors provide extra information about failures, for example expired DNSSEC signatures. They also allow resolver operators to report administrative reasons for DNS failures, such as blocks due to legal requirements.
[RFC8914](https://www.rfc-editor.org/rfc/rfc8914.html) defines extended DNS errors.
### Negative Trust Anchors
**Negative trust anchors may be deployed.**
For: All DNS resolver operators.
Negative trust anchors (NTA) allow a resolver operator to handle a case where an authoritative server has a DNSSEC problem and becomes inaccessible. They basically disable DNSSEC checking for a domain. When this is warranted is difficult to know with certainty, and will usually requires some manual checking. Since DNSSEC validation is now widespread, DNSSEC failures on the authoritative side will impact many resolvers.
Because of these reasons this document does not recommend NTA, but also does not recommend that a deployment avoid NTA if it makes sense for that environment.
Negative trust anchors are documented in [RFC7646](https://www.rfc-editor.org/rfc/rfc7646.html).
### DNS Error Reporting
**DNS error reporting may be enabled.**
For: All DNS resolver operators.
DNS error reporting is a way for resolver operators to let authoritative operators know about problems in authoritative servers or zones. It provides little direct value for the resolver operators, but over time should improve the overall quality of the DNS ecosystem. It is neither widely deployed nor standardized, but hopefully will be both soon. Resolver operators are encouraged to enable DNS error reporting when it is available.
DNS error reporting is proposed in [draft-ietf-dnsop-dns-error-reporting]( https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting).
### Trust Anchor Reporting
**Trust anchor reporting should be enabled.**
For: All DNS resolver operators.
Trust anchor reporting is a way for resolver operators to convey their DNSSEC trust anchor configuration to the operator of the zone that it is for. For most resolvers this is only the root zone. This information is intended to be used during a root KSK rollover to ensure that it is safe to proceed. In the future ICANN is planning an algorithm roll for the root KSK, and this information could be helpful. Resolver operators are encouraged to enable trust anchor reporting.
[RFC8145](https://www.rfc-editor.org/rfc/rfc8145.html) covers trust anchor reporting, in both possibilities available.
### Name Server Identification
**Servers should be configured to identify themselves.**
For: All DNS resolver operators.
Large resolver operations, especially publicly available resolvers, should support an in-band method of discovery that is obvious to permit users to discover what node has answered their query. This improves troubleshooting significantly, and may be useful for research and testing purposes. NSID (Name Server Identifier) is ideal for this, though also âCH TXT id.serverâ support is also reasonable. Geographic hints should be provided in this data, though specific host data is optional for arrays of servers in clusters. IATA codes have traditionally been used for naming points-of-presence, though this is at the discretion of the operator.
[RFC5001](https://www.rfc-editor.org/rfc/rfc5001.html) describes NSID.
[RFC4892](https://www.rfc-editor.org/rfc/rfc4892.html) describes name server identification in general, and documents the pre-NSID approaches.
## Privacy, Filtering, Transparency
### Privacy & anonymity
DNS Resolver operators are advised to apply [RFC8932](https://www.rfc-editor.org/rfc/rfc8932.html)
"Recommendations for DNS Privacy Service Operators" as follows:
1. its operational and policy guidance related to DNS encrypted transports and data handling, by applying all "Threat mitigations" (thereby by meeting its level of "minimally compliant") and additionally by applying the "Optimizations" on EDNS Client Subnet listed in section 5.3.1.
2. its framework on a Recursive operator Privacy Statement, by publishing a privacy statement on their website covers all topics in Section 6. (See for example [Cloudflare's statement]( https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver) or [Quad9's privacy page](https://www.quad9.net/service/privacy/).)
#### Logging considerations
In addition to the logging recommendations from RFC8932, operators should consider the following:
1. Third party access to personal data: Resolver operators may receive third party requests for information they have logged that relates to users, including IP addresses, queries and meta data. Resolvers should only comply with such requests when balancing legitimate third party interest with the user's fundamental rights, including rights to privacy. Usage information can be personal data, Personally Identifable Infomation (PII) or similarly regulated under the privacy laws applicable to the users, operator or third party, revealing a person's health, lifestyle or other personal preferences (profiling). For example, logging information that documents a user resolving a website for alcoholics anonymous may relate to the health of a person behind an IP address.
2. Data security: DNS Resolver operators should take appropriate technical and organisational measures to protect logging information that relates to users.
#### Advertisement Policy
If there is any advertising from the service, the policy should be published as well as how it can potentially affect the users' privacy.
### Filtering and blocking
#### Block Lists
Resolvers can be directed to block or modify answers in various ways. Blocklists may be provided by governments, communities, or other parties (for example security firms).
Response Policy Zone (RPZ) allows a way to both document specific modifications that resolvers will make to DNS answers, and send the rules to resolvers. This allows updates to occur very quickly. If RPZ or some other high-speed blocking technology is used, the parties supplying these sources must be highly trusted, as changes to blocklists will usually immediately impact user queries.
RPZ is not standardized, but there is an IETF draft, [draft-vixie-dnsop-dns-rpz]( https://datatracker.ietf.org/doc/draft-vixie-dnsop-dns-rpz/00/).
#### Legal blocking
**Legal requests and blocking and filtering laws:** DNS resolver operators should not filter content and block access to web-services. When the local law requires blocking, and the law applies to the resolver, the resolver should transparently disclose a list of blocked websites and services, when possible (disclosing such a list may not be allowed by law or regulation). Similarly, the resolver should disclose the source of such block lists, when possible.
If it is not possible to disclose the source of blocklists, operators should try to be as transparent as possible about how they receive those blocklists, based on what criteria, and how they mitigate errors and false positives. Disclosing which organizations operators interact with, how they liase, and so on, can help users understand the impact on the service provided.
If possible, resolvers should provide information about blocked responses via the Extended DNS Error with the Blocked, Censored, Filtered, or Prohibited code - whichever applies best - along with a text why the response was blocked, censored, filtered, or prohibited.
[RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html#section-4.16) provides information about the meanings of the different codes.
**Community governance of blocklists:** blocklists, if mandatory, have to be audited and assessed by third parties and there should be a right to appeal for those blocked. The Internet community can vet the blocklists from time to time to avoid blocking access to websites that are mistakenly blocked. During crisis - when mistakes can have drastic effects on accessing a critical service - preferably filtering and blocking should not be used.
#### Opt-in/Opt-out Mechanisms
End users may choose to use a DNS resolver that filters specific kinds of traffic. For example, they may wish to avoid potential malware web sites. Or resolver operators may be required to default to filtering but allowed for to provide an unfiltered DNS resolver service.
Depending on the specific requirements, a resolver service may publish different IP addresses and what type of filtering applies to each address. It is also possible to perform client authentication and authorization, using IP-based authentication, TSIG keys, or client-side TLS certificates.
### Transparency
Public DNS resolver operators should publish transparency reports to build user trust in their adherence to policies and practices. This goes beyond our advise to apply RFC8932, section 6.2.
A common frequency is once a year. The reports inform the public about disclosure of user information and removal of content required by law enforcement and other government agencies.
Transparency reports should (to the extent that the law allows) indicate which government agencies and law enforcement agencies request access on what basis.
It should also be clear from the transparency reports what kind of data has been requested and if content removal and content blocking have been requested. Categories of data include: Content Data, Basic Subscriber Data, Other Non-Content Data and Content Blocking.
#### Negative Trust Anchor reporting
Negative Trust Anchors (NTA) are discussed in the previous section on DNS configurations. If NTAs are present in the resolver, they should be published with as much detail as possible about them. This includes reasons for insertion, dates of activation and expected removal dates, or a published review date or cycle for when NTAs should be actively examined for deletion if such fine-grained information cannot be shared.
NTAs are equivalent to a security fault, and may even be more significant than a block event as they remove expected trust behavior with limited signal of that trust downgrade ("limited" because few if any clients care about those response bits changing.).
#### Human rights considerations
DNS resolvers can opt for declaring their understanding of their responsibilities regarding human rights from the Universal Declaration of Human Rights. As an example of a public DNS resolver operator, Quad9 mentions rights to freedoms without distinction made on the basis of country, no interference with privacy, the right to freedom of opinion and expression, the right to peaceful assembly, and the right to freely participate in the cultural life of the community.
See [Quad9's Human Rights Considerations](https://www.quad9.net/privacy/human-rights-considerations/ ) for the full statement.
It also invokes other human rights related solutions other than [UDHR](https://www.un.org/en/universal-declaration-human-rights/) such as Articles 8 and 9 of Resolution 42/15 of the United Nations Human Rights Council on the right to privacy in the digital age of 26 September 2019 more directly define the responsibilities of the private sector toward the furtherance of human rights in modern terms. They also follow the Guidelines for Human Rights Protocol and Architecture Consideration of the Human Rights Protocol Considerations Research Group at Internet Research Task Force.
The latest version of the IRTF [Guidelines for HRPC](https://tools.ietf.org/html/draft-irtf-hrpc-guidelines) may be considered for all network operators.
## Appendix A: Why Did RIPE Write This Document?
There is increasing concern that large open DNS resolvers will become centralised points of DNS operations on the Internet. In order to address this, the European Commission issued the [DNS4EU]( https://hadea.ec.europa.eu/calls-proposals/equipping-backbone-networks-high-... ) proposal. However, such an initiative could lead to centralised guidance or regulation which might interfere with the decentralised way the Internet infrastructure works - including the DNS. See for reference the [RIPE NCC Open House discussion]( https://labs.ripe.net/author/chrisb/dns4eu-ripe-ncc-open-house-discussion/ ) on this topic.
Rather than attempting to respond to the EC proposal or organize specific DNS resolver deployments, the RIPE community has decided that it is best able to provide advice and guidance. The RIPE Community is well positioned to provide a set of Best Current Practices that operators of Open DNS Resolvers will be encouraged to subscribe to.
-- dns-resolver-tf mailing list dns-resolver-tf@ripe.net https://lists.ripe.net/mailman/listinfo/dns-resolver-tf
I want to agree we should reference RFC8932 but perhaps it is cleaner to include their text in this document, to save folks from bouncing through documents. I've felt one of our big goals would be a document where reading the RFCs or other documents would be for historical or extra details. Willing to be told I'm wrong. On Sun, Mar 24, 2024 at 2:32â¯PM Tim Wicinski <tjw.ietf@gmail.com> wrote:
Sorry I have found it a bit hard to track the document so some of these may be duplicates
### About Recomendation Text
s/Recomendation/Recommendation
may have significant
s/may have significant /may have a significant/
NSEC3 values, can reduce
s/NSEC3 values, can reduce/NSEC3 values can reduce/
NSEC3 redords
s/NSEC3 redords/NSEC3 records/
which return all all
s/ which return all all / which return all /
s/liase/liaise/
On Sun, Mar 24, 2024 at 12:25â¯PM Shane Kerr <shane@time-travellers.org> wrote:
Maarten,
Thank you for your suggestions, edits, and discussion. I've updated the final draft to give us a final, final draft. ð
I've included the last (?) version at the bottom of this e-mail, and responded to your suggestions inline below.
On 19/03/2024 10.24, Maarten Aertsen wrote:
* Those running public DNS resolver services, and
Should we remove "public" here?
Hm, good point!
- Data Security: Since you are in control of the physical servers, there is no risk of data leakage that can occur due to vulnerabilities in multi-tenant virtualization platforms, including CPU cache-based side-channel vulnerabilities. It could be argued that attacks targeting such issues are rare, and their impact on a DNS resolver service is low, but potential breaches may have significant privacy impact. It is advised to evaluate this against your organisation's risk model, or to discuss this with your information security compliance experts.
The ", or [..]" This feels a bit wordy; we don't suggest who to talk to for all the other recommendations either.
Makes sense. Discussing with experts is basically an option for everything. ð
#### Server capacity
If using a model that is easy to scale (cloud based, or Kubernetes based, or similar), then getting server capacity correct is largely a
Given the earlier text about Kubernetes being 'similar' to cloud, "or Kubernetes based, " can probably be removed.
I'm inclined to leave this in. I'd rather be explicit than implicit.
Since DNS is mostly UDP-based, it is often easy to generate large amounts of spoofed traffic to and from DNS servers. DNS traffic is small compared to application traffic (videos and other content), but still significant. Authoritative server operators often build their networks and servers to handle 10 times their normal load. Recursive server operators may need to do the same, although the service only
I would split this sentence, to read:
server operators may need to do the same. When the service only
Fair.
accepts traffic from IP addresses that cannot be spoofed (for example users within a network that operated by the same company) then this
remove "then"
Done.
### Resilience
#### System Diversity
In addition to the software considerations above, operators should
Either change to "software **licensing** considerations", or start the sentence with Operators. After all, the previous part of the text is not about software considerations, so current wording may be a bit confusing to linear readers.
Makes sense. I've started with Operators, no need to remind people of the other considerations here.
consider whether to use different server implementations to provide
s/server/software/ ?
Makes sense.
In addition to the DNS-specific security considerations, normal security best practices for any Internet service should be followed, including updating software updated regularly, patching software as soon as possible for any known security vulnerabilities, following CERT announcements and so on.
Perhaps CERT/CSIRT. Not super important.
You led me down a short trip to the Wikipedia:
https://en.wikipedia.org/wiki/Computer_emergency_response_team
In spite of CMU's trademark on the term CERT (?!?!), I see way more CERT in the national lists than CSIRT, so I'll stick with it.
In a random note, the RIPE Database has an IRT object type rather than a CERT or CSIRT object type, through some artifact of history. ð
#### Certification
It may be useful or required for an organization to follow specific
s/follow/obtain/ ?
In this case "follow" instead of "obtain" was deliberate. It might not be necessary to actually go through the cost of getting certification in order to get the benefits. But, since this section concludes mentioning that business customers will look for them, "obtain" probably makes more sense.
certifications, such as ISO or ITIL. These can be government-defined
Not sure if (unspecified) "ISO or ITIL" are the most relevant examples. I would either remove or replace by say "ISO-IEC 27017, 27018 or SOC 2 Type 2", which all relate to services provided by an organisation, to be relied on by users of that service.
Replaced with "ISO or SOC 2 Type 2".
QUESTION: Do we need to publish certificate in other ways that via the DDR mechanisms?
Should this remain in?
Good point, removed!
### TTL-based Record Pre-Fetch
**TTL record pre-fetch should be enabled when available.**
I would remove "when available", seeing that the last sentence of the next paragraph already covers this.
I'm leaving it in, since we use that exact phraseology elsewhere.
### DNS Error Reporting
**DNS error reporting may be enabled.**
For: All DNS resolver operators.
DNS error reporting is a way for resolver operators to let authoritative operators know about problems in authoritative servers or zones. It provides little direct value for the resolver operators, but over time should improve the overall quality of the DNS ecosystem. It is neither widely deployed nor standardized, but hopefully will be both soon. Resolver operators are encouraged to enable DNS error
To me, 'may be' does not sound like much encouragement. Should this be 'should be' instead? The paragraph already explains that availability is limited for the moment.
I'm not sure we have enough operational experience to know if this is actually a good idea. It may end up being spammy, or unintentionally result in privacy leaks, or any other kinds of unpleasant side-effects. I don't expect it, but I also don't feel comfortable recommending it strongly.
## Privacy, Filtering, Transparency
Reviewing this next part was a bit painful, because I was involved in writing it and yet I see quite a few places where I feel we should improve. After re-reading RFC8932 for the second time, I noticed quite some overlap where RFC8932 is more exhaustive, specific and practicable. By creating overlap, I think we may be watering down our own advise. Below I go over all the items one by one, reference specific sections to advocate for removal of any such overlap.
Okay, thanks for the detailed re-reading.
### Privacy & anonymity
Operators are advised to apply
DNS resolver operators
Yes.
[RFC8932](https://www.rfc-editor.org/rfc/rfc8932.html)
"Recommendations for DNS Privacy Service Operators" as follows:
1. its operational and policy guidance related to DNS encrypted transports and data handling, by applying all "Threat mitigations" (thereby by meeting its level of "minimally compliant") and additionally by applying the "Optimizations" on EDNS Client Subnet listed in section 5.3.1.
2. its framework on a Recursive operator Privacy Statement, by publishing a privacy statement on their website that is compliant with Section 6.
I suggest we strengthen this sentence a bit, then remove duplicates in the next section:
s/that is compliant with/covers all topics in/
Makes sense.
#### Logging considerations
1. Public privacy policy: DNS resolvers are recommended to publish their privacy policies transparently on their website. It can be a brief privacy commitment as well or be more elaborate on how the privacy policy was made. (See for example [Cloudflare's statement]( https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver) or [Quad9's privacy page](https://www.quad9.net/service/privacy/).)
Such policies should explicitly mention the sampling rate of DNS queries/responses that are kept, and whether these are anonymized.
This is fully covered by the reference to RFC8932, Section 6. I suggest we remove this text.
Okay, that makes some sense. I kept the examples from Cloudflare and Quad9, but moved them at the end of the previous section.
2. Third party access to personal data: it seems that the only critical personal data that DNS resolvers collect are IP addresses and the queries that are resolved. The other meta data collected can be used to have an understanding of for example which user accessed which website which can reveal information about a personâs health, lifestyle and other personal preferences (we call this profiling). For example, resolving the website for alcoholics anonymous may tell you something about the health of a person behind an IP address. IP addresses are personally identifiable information. Follow the applicable privacy laws or privacy principles when receiving third party requests to access.
Resolvers should only comply with such requests when balancing legitimate third party interest with other fundamental rights.
This goes beyond RFC8932, Section 5.3.3 and Section 6.1.1 item 2 and may therefore be worth keeping.
I suggest re-ordering this paragraph a bit to start with the advice. The following is an attempt to reorder:
Resolver operators may receive third party requests for information they have logged that relates to users, including IP addresses, queries and meta data. Resolvers should only comply with such requests when balancing legitimate third party interest with the user's fundamental rights, including rights to privacy. Usage information can be personal data, PII or similarly regulated under the privacy laws applicable to the users, operator or third party, revealing a person's health, lifestyle or other personal preferences (profiling). For example, logging information that documents a user resolving a website for alcoholics anonymous may relate to the health of a person behind an IP address.
Makes sense, I've included this text.
3. Access to data for researchers: how it is done, who has access and who can request access, how the resolver makes a decision to give access (validated and credible researchers, what they can access and other issues)
Covered in RFC8932, Section 5.3.3. Suggest removal.
Removed.
4. Data minimization: do not collect personal information not needed for critical operations. Only retain or use what is being asked (the query). If collecting data to make the service more private and secure, explain the rationale for each piece of data (data collection purpose)
Covered in RFC8932 section 5.2.1 and section 5.2.2. Suggest removal.
Removed.
5. Encryption: If data is encrypted, explain how it has been encrypted (DoH, DoT, or so on).
Covered in RFC8932, Section 6.1.2, item 2. Suggest removal.
Removed.
6. Data security and retention: when to delete the data and how it is stored
Data retention is covered in RFC8932 section 5.2.1 and section 5.2.2. Section 5.2.1, last bullit under mitigations sets a security goal relating to data access, though the word security is not used (it is the scope of the entire document).
Suggest removal. Alternatively, abstract to a level higher than RFC8932 by stating something like the following (with limited operational value):
2. Data security: DNS Resolver operators should take appropriate technical and organisational measures to protect logging information that relates to users.
I've included this higher-level recommendation.
**Legal requests and blocking and filtering laws:** DNS resolvers
operators
Updated.
should not filter content and block access to web-services. When the local law requires blocking, and the law applies to the resolver, the resolver should transparently disclose a list of blocked websites and services, when possible (disclosing such a list may not be allowed by law or regulation). Similarly, the resolver should disclose the source of such block lists, when possible.
If it is not possible to disclose the source of blocklists, operators should try to be as transparent as possible about how they receive those blocklists, based on what criteria, and how they mitigate errors and false positives. Disclosing which organizations operators interact with, how they liase, and so on, can help users understand the impact on the service provided.
If possible, resolvers should provide information about blocked responses via the Extended DNS Error with the Blocked, Censored, Filtered, or Prohibited code - whichever applies best - along with a text why the response was blocked, censored, filtered, or prohibited.
[RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html#section-4.16) provides information about the meanings of the different codes.
I like these paragraphs, but they are also covered by RFC8932, section 6.1.1 item 6 (result filtering), which we already advise to apply. As an example of where that section is stronger, it does not feature 'when possible' escape hatches.
I'm not sure what to do here. At a minimum, I believe we should make a reference to that content and substantiate why we feel it is worth repeating here (while not the other topics of RFC8932).
Interesting. The "when possible" language was added in recognition that there may be legal or other barriers preventing such transparency.
Also, RFC 8932 6.1.1 just talks about documentation... our text here actually recommends not filtering, which RFC 8932 does not do.
RFC 8932 also doesn't reference RFC 8914, which makes sense since they came out very near to each other.
So... I understand the concern about re-specifying things, but I'm actually happy to let this text stand.
**Community governance of blocklists:** blocklists, if mandatory, have to be audited and assessed by third parties and there should be a right to appeal for those blocked. The Internet community can vet the blocklists from time to time to avoid blocking access to websites that are mistakenly blocked. During crisis - when mistakes can have drastic effects on accessing a critical service - preferably filtering and blocking should not be used.
This is not covered by 8932, so relevant to keep.
ð
### Transparency
Suggest leading with the advice:
Public DNS resolver operators should publish transparency reports to build user trust in their adherence to policies and practices. This goes beyond our advise to apply RFC8932, section 6.2.
Makes sense. Updated.
DNS resolvers usually provide transparency reports once a year. The
Suggest to replace with:
A common frequency is once a year. The
Done.
#### Voluntary certificates and standards
Some DNS resolvers opt for obtaining certificates in security and privacy. Some also undertake audits on their privacy practices. See for example:https://www.cloudflare.com/trust-hub/compliance-resources/
Suggest removing this; certification is already covered under ### Resilience above. Should the group feel that this is the most appropriate place, I suggest moving that section to replace the one here.
Good point. I added a bit of text mentioning audits or reports, and include the link as an example there.
#### Human rights considerations
DNS resolvers can opt for declaring their understanding of their responsibilities regarding human rights from the Universal Declaration of Human Rights. Specifically, Quad9 mentions rights to freedoms
s/Specifically/As an example of a public DNS resolver operator/
Make sense, updated.
-- Shane
# DNS Resolver Recommendations
About the DNS Resolver Best Common Practice Task Force
https://www.ripe.net/participate/ripe/tf/dns-resolver-best-common-practice-t...
## Terminology
* Open Resolver: A DNS resolver that accepts queries from any client. Often the result of misconfiguration.
* Public Resolver: A resolver intentionally configured to be an open resolver.
## Introduction
### What Is This Document? Who Is It For?
This document presents recommendations and best current practices for operating DNS resolvers, both public and non-public ones. It covers technical aspects of operations and provides best practice recommendations for data management, with a particular focus on user privacy, security, and resilience.
The document serves as guidance for the wider Internet community, offering input to:
* Those running DNS resolver services, and * Those who want to make informed choices between such services.
Its purpose is to provide clear guidance and promote effective practices in DNS resolver operation.
The intended audience is not the entire DNS community. Advice here is probably not useful for operators of authoritative servers, domain registrars, and so on. It is also not meant to be an introductory or educational document. There are many documents which cover the basics of DNS and the roles of organizations in it; a good overview is:
Addressing the challenges of modern DNS - a comprehensive tutorial by van der Toorn et al.
https://ris.utwente.nl/ws/files/282427879/1_s2.0_S1574013722000132_main.pdf
The document does not consider how to measure adherence to these recommendations. So it is not intended to be used for certification, although certification created based on the principles here is possible.
### How Is This Document Organized?
This document has a number of sections, and specific recommendations in each section. The intent is for each recommendations to have clear guidance at the top, and then background and discussion related to the recommendation afterwards. Each recommendation indicates whether it is mostly for operators of public resolvers or for operators of any resolver.
### About Recomendation Text
This is not a standards document, and does not propose any way to measure compliance or interoperability. It does use words like "should" or "may be" throughout. These are meant to be interpreted in the usual English sense, and not as IETF-style RFC 2119 jargon.
## System and Network Hardening
### Infrastructure considerations
Running any Internet service requires attention to the infrastructure used to operate it. This section discusses various approaches that can be used to run a DNS resolver. Everything applies to both public and non-public DNS resolvers.
#### Bare metal or public cloud
All DNS resolver software can run either on dedicated servers (rented or colocated), or in virtualized clouds, or in a combination of those. Every approach has pros and cons. Most of these are not specific to running DNS resolvers, however, some of them are.
**Running DNS resolver instances as OS level daemons on bare metal hosts:**
Pros:
- Performance: Bare metal servers have direct access to the underlying hardware, and can offer superior performance/cost balance by avoiding the overhead associated with virtualization. Moreover, you have full control over the server's configurations, down to the hardware level, which can be beneficial for performance and cost optimization once you get the understanding of your typical work load during peak hours.
- Data Security: Since you are in control of the physical servers, there is no risk of data leakage that can occur due to vulnerabilities in multi-tenant virtualization platforms, including CPU cache-based side-channel vulnerabilities. It could be argued that attacks targeting such issues are rare, and their impact on a DNS resolver service is low, but potential breaches may have significant privacy impact. It is advised to evaluate this against your organisation's risk model.
- Predictability: Because there is no virtualization layer and no "noisy neighbours" on the host, the performance of your servers is more predictable.
Cons:
- Cost of failure: If you pick hardware configuration that is not optimal for the workload of your DNS resolver, you may need to upgrade and replace hardware components afterwards. Ways to reduce this risk include renting servers instead of buying them, carrying load testing with data similar to production workloads, and providing limited beta access to the service before it fully enters the production phase.
- Scalability: Scaling up with physical servers means acquiring or renting, installing, and configuring new hardware, which will take more time than provisioning new virtual servers in a cloud environment. Moreover, most cloud environments will provide you with cluster autoscaling features, which could barely be achieved in bare metal.
- Maintenance: You will be responsible for all server maintenance tasks, including hardware issues, which can require significant effort and specific expertise.
- Redundancy: Setting up high availability and disaster recovery strategies can be more complex and time consuming compared to the cloud, where these features are often provided as value added products. See the Redundancy section for more details.
**Running DNS resolver instances in containers in a public cloud:**
Pros:
- Scalability: Clouds excel at scaling applications. You can scale up and down rapidly based on load, which is important for a DNS resolver that needs to handle variable query loads. In case of regional or geographically distributed resolvers, in every region where the resolver would be deployed, daily periodicity is likely to be observed, for example peak hour is likely to occur around 19:00 local time, and off-peak hours may begin at around 01:00-03:00. In a situation like that, using cluster autoscaling features and tools, you can run less instances in the night and more instances throughout the day, which may help to optimize your cloud hosting costs.
- Fault Tolerance and High Availability: Most clouds have built-in strategies, features, and products for handling node failures, which can increase your service's availability.
- Deployment and Management: Cloud providers offer built-in methods to deploy and manage applications, which can simplify operations and reduce the likelihood of human errors if your infrastructure management department is already familiar with these tools.
- Cost: While this largely depends on your specific usage, cloud services can sometimes be more cost-effective than managing your own physical servers, especially when you consider the total cost of ownership, including power, cooling, and maintenance.
Cons:
- Performance: The virtualization layer of public clouds can impact performance. While this certainly could be mitigated through scaling the number of virtual hosts, the cost would also increase accordingly.
- Complexity: Advanced cloud technologies are complex systems which come with a steep learning curve. Without prior experience, properly configuring and managing a cloud-based compute cluster can be challenging.
- Cost Variability: While the cloud can be cheaper, it can also be more expensive if not properly managed. Costs can rise unexpectedly based on traffic. Make sure to always set some limits on how much may be spent on hosting in the cloud control panel, and to set up notifications to be sent to you when these thresholds are about to be triggered.
- Multi-tenancy Risks: In a public cloud environment, the "noisy neighbour" problem could potentially affect your service's performance. Additionally, even though cloud providers take steps to isolate tenant environments, vulnerabilities could potentially expose sensitive data (see the previous section for a detailed explanation).
**Additional considerations**
- In today's environments, Kubernetes and Terraform are sometimes used as a substitute for cloud APIs when it comes to production services' management. When running a DNS resolver in a Kubernetes cluster on top of a public cloud environment, all the pros and cons of the public cloud apply; basically, Kubernetes becomes your public cloud provider. If you have significant prior experience running services in Kubernetes in production, you may successfully replicate your experience with the DNS resolver software. Otherwise, we would advise against Kubernetes in this case.
- The only reason we may find to run a DNS resolver in a Kubernetes cluster on top of self-hosted dedicated servers is when you have significant hands-on experience with Kubernetes and it is natural for you to manage applications this way. Otherwise, running DNS resolver daemons in containers brings little, if any, benefit. Autoscaling features are not available to you in this case, and neither horizontal nor vertical pod autoscaling is of any use, because DNS resolver software typically scales in-host by itself just fine.
- When designing a cluster of resolvers for autoscaling, keep in mind that newly spawned resolver machines would need to populate resolver cache first before they are fully useful. Your DNS resolver software may provide cache replication mechanisms. Otherwise, it is safe to overprovision clusters somewhat under heavy load, and discarding excessive instances once all the caches are populated and the average load of a compute instance decreases. In addition, it may be worthwhile to consider sharing cache data between instances.
- It is always advised to prefer environments your infrastructure management team is familiar with.
### Software considerations
#### Open Source
**Recommendation**: Choose any well-maintained DNS software you are comfortable using. Regardless of which software you choose, ensure you have somewhere to go for support. In the case of open source software, consider providing financial support to ensure continued development. Some open source maintainers take donations, while others offer support contracts.
There are both open source and proprietary implementations of DNS resolver software. Mixing these is also possible, for example, by using proprietary extensions with open source software or deploying open source software modified in-house.
General observations: - Software licensing is orthogonal to software security. Neither is proprietary software less secure on principle nor are contributions by "unknown" developers more of a risk in open source.
Benefits of open source: - Open source allows for inspection, independent auditing, and troubleshooting. - Open source can avoid vendor lock-in. - Open source can aid internet standards development. Widely-deployed open source implementations allow proponents of standards drafts to contribute proof of concept implementations without permission or cooperation of vendors.
Drawbacks of open source - Both open source and proprietary software require skilled maintenance, which has costs. Proprietary licensed software or appliances typically come with license fees to cover these. In contrast, open source licenses decouple usage by operators from monetary compensation to developers. It is up to operators to consider the financial sustainability of continued maintenance of the open source DNS software they depend upon.
Please also consider deploying different software implementations to ensure diversity, as discussed in the diversity section below.
### Networking considerations
#### IPv4 and IPv6
**If available, both IPv4 and IPv6 must be deployed.**
Large parts of the authoritative DNS are only accessible via IPv4, so the resolver must be able to originate IPv4 queries. Authoritative DNS that is only accessible via IPv6 is very rare.
Depending on the connectivity of clients, a resolver may be IPv4-only, IPv6-only, or support IPv4 and IPv6.
#### Addressing
**Using multiple IP addresses for the service address should be considered.**
Using 2 or more IPv4 addresses and 2 or more IPv6 addresses from different RIR will allow resilience in failure at an RIR, either governance, security, or technical. Note that support for multiple addresses for recursive resolvers varies and some clients perform poorly if any address does not respond normally.
There is no need to pick an IPv4 address with all octets the same, like 2.2.2.2 or 11.11.11.11.
**Publishing a list of back-end addresses used for resolving should be considered.**
Publishing a list of back-end addresses used for resolving can be useful for other network & DNS operators (for example, geo-IP location, making sure data is getting to correct places, and so on).
#### High Availability
This can be considered in terms of local and global scope.
##### Local scope
Inside a single location/region, such as an office, campus, or small ISP network, the main availability concern is that a resolver is always reachable. Client systems can be configured with multiple resolver addresses, but the failover behaviour of stub resolvers to a second address can be painful. Ideally the primary address is highly available and such fallback rarely required. How much effort is put into ensuring this is true should probably scale in line with the number of users, or sensitivity of the clients using that resolver to delayed resolution.
There are several ways to promote high availability of an individual resolver address, such as dedicated load balancing equipment, or network techniques like VRRP, or IP anycast. These generally have in common a pool of recursive servers and the means to direct queries to them when a health check has determined them to be capable of answering those queries.
Dedicated free or commercially produced, hardware or software load balancing solutions are available. These typically own the resolver IP address and forward queries to the currently available instances of a pool of recursive servers.
VRRP enables a technique to make the resolver IP address available on multiple servers, often used to provide automatic failover between two. A pool of recursive servers using this technique must reside in the same broadcast domain.
IP anycast in the local scope typically involves a pool of recursive servers advertising a route to a shared resolver IP address into a routing protocol. This can be configured in failover or load-sharing configurations. A load sharing configuration typically requires network equipment able to balance traffic to a destination over equal cost paths (ECMP). A pool of recursive servers using this technique can be distributed in different parts of the network.
##### Global scope
The same concerns as for local service availability are present in the global scope, with the added issue that DNS resolution over long distances may be slow. Practically speaking, only multiple resolver addresses, or IP anycast are useful strategies here. The motivations for finding better failover solutions than multiple resolver addresses have been covered above.
IP anycast in the global scope means routing the same IP prefix to more than one location. This can provide effective solutions for failover and, when optimally configured for routing client queries to the topologically least distant recursive server location. IP anycast in the global scope requires the use of globally routable prefixes. If a separate prefix is to be used for anycasting, usually this means a /24 in IPv4 and a /48 in IPv6, as those are the smallest sizes that will be widely propagated in BGP. A common practice is to use a covering prefix (/23 in IPv4 or /47 in IPv6) for fallback, and a more-specific prefix (/24 or /48) for the traffic. The more-specific prefix can then be withdrawn to send traffic to a backup site; this will happen automatically if the site is disconnected from routing.
[RFC7094](https://www.rfc-editor.org/rfc/rfc7094.html) discusses anycast architecture in detail, including references to various other RFC which discuss anycast in general and to DNS in particular.
[RFC4786](https://datatracker.ietf.org/doc/html/rfc4786) discuses operation of anycast services.
##### Generally
Operators of a globally scoped recursive service are encouraged to also adopt the local scope recommendations in each of the locations where the service is provisioned.
Though the above deals with the shortcomings of reliance on stub resolver failover between a list of addresses those recommendations shouldnât be seen as an exclusive alternative. Multiple resolver addresses, where each is provisioned using differing failover strategies, can provide a resolver of last resort and further improved resilience.
#### Ingress Filtering
**Ingress Filtering to follow BCP 38 should be deployed.**
DNS normally uses UDP traffic, which makes it a common vector of both [reflection](https://en.wikipedia.org/wiki/Reflection_attack) and [amplification]( https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-a... ) attacks. To minimize the amount of spoofed traffic that a resolver responds to, the network should be configured as recommended in [BCP 38](https://www.rfc-editor.org/rfc/rfc2827.html).
#### RPKI Sign Advertised Routes
**Route Advertisements should be signed using RPKI**
Using RPKI to sign any route advertisements - either toward authoritative servers or toward DNS clients - is straightforward to do and will reduce the impact of BGP misconfigurations and some BGP hijacking attempts.
RPKI validation is also possible, although the effort is greater. It is possible that the hosting provider or the transit provider for your service validates BGP; asking and making this part of your selection criteria is reasonable.
#### (D)DoS measures
Denial-of-Service (DoS) attacks, both distributed (DDoS) and not are a threat to any Internet service. Network operators for a service providing any DNS service must be prepared for large amounts of attack traffic.
In addition to attacks on the service itself, a resolver may be used both as an attack reflector and as an attack amplifier.
Active monitoring of network and service usage, careful logging, and a security team that is able to respond to problem reports is necessary. Mitigation techniques will include filtering or rate-limiting traffic, both on the authoritative and client side of the resolver.
### Capacity planning
#### Server capacity
If using a model that is easy to scale (cloud based, or Kubernetes based, or similar), then getting server capacity correct is largely a question of budgeting. If using a less-flexible model (bare metal for example), then under-estimating will mean problems delivering service.
Hardware performance varies widely, as does operating system and resolver performance. Some lab testing will be necessary to estimate the number of systems needed.
#### Network capacity
Since DNS is mostly UDP-based, it is often easy to generate large amounts of spoofed traffic to and from DNS servers. DNS traffic is small compared to application traffic (videos and other content), but still significant. Authoritative server operators often build their networks and servers to handle 10 times their normal load. Recursive server operators may need to do the same. When the service only accepts traffic from IP addresses that cannot be spoofed (for example users within a network that operated by the same company) this can be reduced, for example to 3 times normal load. To estimate expected load, the best approach is to examine historical usage for the actual expected users of the system.
### Resilience
#### System Diversity
Operators should consider whether to use different software implementations to provide service. This allows continued operation if a critical vulnerability is found in one implementation, by shifting traffic to other implementations.
Placing resolvers and control systems in different physical locations will allow continued operation in the event of a disaster or other problem that impacts a single location. In addition, ensuring diverse connectivity to other networks will prevent single points of failure on the network side. Ensuring network diversity may take some care, as it is not always obvious what fate is shared between any given path; this may be physical, virtual, or organizational, and my sometimes be hidden.
#### Security
In addition to the DNS-specific security considerations, normal security best practices for any Internet service should be followed, including updating software updated regularly, patching software as soon as possible for any known security vulnerabilities, following CERT announcements and so on.
#### Certification
It may be useful or required for an organization to obtain specific certifications, such as ISO or SOC 2 Type 2. These can be government-defined or industry-defined. For end users there is typically not much direct value, but business customers will often look for services that are operated by organizations meeting such standards. Audits or other reports about this may be published, see for example: https://www.cloudflare.com/trust-hub/compliance-resources/
## DNS configuration knobs
The DNS is an old protocol that has a lot of settings that can be tweaked. This section reviews these and provides recommendations on which should be used for a resolver.
### DNSSEC validation
**DNSSEC validation should be enabled.**
For: All DNS resolver operators.
DNSSEC validation is the best way to ensure that the answers from the owner of domain name being queried are returned.
The root KSK must be updated when it changes. While [RFC5011](https://www.rfc-editor.org/rfc/rfc5011.html) defines an automated way to do this, a resolver operator will probably either manage this trust anchor directly or have it updated via OS updates.
[RFC9364](https://www.rfc-editor.org/rfc/rfc9364.html) provides a lot of useful information, and links to further documents about DNSSEC. However, operators usually do not need to know the details, and can simply ensure that DNSSEC validation is enabled in their software.
Resolver software that does not support DNSSEC validation should be avoided.
### DNS Transport Protocols
**UDP and TCP must be supported.**
For: All DNS resolver operators.
UDP is what most clients use, and TCP is necessary for DNS answers that are too large for a single UDP packet.
[RFC7766](https://www.rfc-editor.org/rfc/rfc7766.html) explains why TCP is necessary in more detail.
### Packet Fragmentation Avoidance
**Servers should be configured to avoid fragmentation.**
For: ALL DNS resolver operators.
Packet fragmentation can cause issues with DNS over UDP, especially over IPv6. These issues can be minimized by choosing implementations that set IP options to avoid this, and by taking care with EDNS0 message sizes.
Recommendations are available in [draft-ietf-dnsop-avoid-fragmentation]( https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/).
### Encrypted DNS
**At least one of DNS-over-TLS (DoT), DNS-over-HTTPS (DoH), and DNS-over-QUIC (DoQ) should be supported.**
For: All DNS resolver operators.
DoT, DoH, and DoQ are different technologies that all provide an encrypted channel between the resolver and the authoritative server. DoT is the oldest, and provides encrypted DNS using TLS. DoH uses HTTP over TLS as a way to transmit queries and answers, and is widely supported by web browsers. DoQ is the newest, and provides advanced features such as separate streams for each query, avoiding the "head of line" blocking problem common with all protocols layered on top of TCP (such as DoT and DoH).
- DoT - [RFC7858](https://www.rfc-editor.org/rfc/rfc7858.html) - DoH - [RFC8484](https://www.rfc-editor.org/rfc/rfc8484.html) - DoQ - [RFC9250](https://www.rfc-editor.org/rfc/rfc9250.html)
**Discovery of DNS Designated Resolvers**
There are new mechanisms that allow DNS clients to use DNS records to discover encrypted DNS configurations. Resolvers should publish DNS records to assist clients finding encrypted resolvers.
- Discovery of Designated Resolvers - [RFC9462](https://www.rfc-editor.org/rfc/rfc9462.html)
### QNAME Minimization
**QNAME minimization should be enabled.**
For: All DNS resolver operators.
Using QNAME minimization, a resolver does not send the full name that it is trying to resolver to authoritative servers higher in the DNS hierarchy. So, for example, when querying "atlas.ripe.net" the servers for ".net" would only be asked for "ripe.net". This improves privacy for the end user querying the name.
[RFC7816](https://www.rfc-editor.org/rfc/rfc7816.html) covers QNAME minimization.
### Aggressive NSEC caching
**Aggressive NSEC caching may be enabled.**
For: Public resolver operators.
"Aggressive NSEC caching", meaning negative caching based on NSEC and NSEC3 values, can reduce traffic greatly. It is important to protect against random subdomain attacks.
This style of caching takes advantage of the way that NSEC and NSEC3 records cover a range of names in a zone. A resolver can know that a query falls within such a range without sending any further queries, by remembering the NSEC or NSEC3 redords that is has seen as answers to earlier queries.
Aggressive NSEC caching is almost always a good idea. However enabling this is less important for DNS resolver operators who have a close relationship with users, since they can stop attacks by blocking users or otherwise directly dealing with the source of abusive queries.
[RFC8189](https://www.rfc-editor.org/rfc/rfc8189.html) describes negative caching in detail.
### ANY Queries
**ANY queries responses should be limited.***
For: All resolver operators.
Public or large-scale resolvers should be exceptionally careful with queries of type ANY, which return all all records at a given name. If a resolver replies with all of the records cached for a given type, the response can be much larger than for a single record type. Strict limits should be enforced on volumes of such queries to prevent amplification abuse, or truncation should be applied to prevent spoofed redirections.
[RFC8482](https://www.rfc-editor.org/rfc/rfc8482.html) describes several approaches to limiting ANY responses.
### Local Root
**Local root should be used.**
For: Public resolver operators.
Running a local root has several benefits, but it is an additional component to maintain. For public resolver operators this is definitely worth the cost, but other resolver operators may choose to simply send all queries to the well-distributed root name servers.
[RFC8806](https://www.rfc-editor.org/rfc/rfc8806.html) describes local root, including several example configurations.
In the future it will be possible to use ZONEMD to validate the copy of the root zone obtained before using it. This is currently available for the root zone.
[RFC8976](https://www.rfc-editor.org/rfc/rfc8976.html) describes ZONEMD.
### DNS Cookies
**Interoperable DNS Cookies may be supported.**
For: Public resolver operators.
DNS cookies provide some improved security over plain UDP, and are designed to be more lightweight than TCP. If more than one server is responding for a given IP address, then the Server Secret must be shared by all servers, and the answer must be constructed in a consistent manner by all server implementations.
Since client-side support for DNS cookies is not very widespread, and since managing server-side secrets involves some work, the costs may outweigh the benefits for some non-public resolver operators.
[RFC7873](https://www.rfc-editor.org/rfc/rfc7873.html) describes DNS cookies, and [RFC9018](https://www.rfc-editor.org/rfc/rfc9018.html) standardizes shared DNS cookies.
### TTL Recommendations
**TTL limits may be adjusted.**
For: All DNS resolver operators.
Software typically defaults to a maximum stored TTL of 1 or 2 days. A lower TTL will mean removing rarely-used records that have long TTL, and should not have much operational impact from a CPU or network point of view.
It is possible to set a minimum TTL in many implementations. This is a violation of the DNS protocol, although may be useful to reduce load from records with very low TTL (less than 5 seconds).
Note that software may set different maximum and minimum TTL independent of the results that the resolver returns. That may have a significant impact on queries as well, but resolver operators cannot influence that.
### TTL-based Record Pre-Fetch
**TTL record pre-fetch should be enabled when available.**
For: All DNS resolver operators.
Some resolvers have the ability to look up a record before it has expired from cache, in order to refresh the value and extend the TTL. This way there is never a time when the records are missing from the cache. This is not currently standardized, but a form of this was proposed in the IETF as [DNS Hammer]( https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-hammer-03). We recommend turning this feature on if available.
### EDNS Client Subnet (ECS)
**ECS may be enabled.**
For: All DNS resolver operators.
EDNS Client Subnet (ECS) allows the resolver to include information about the IP address of the client querying it when sending messages to authoritative servers. This may allow authoritative servers to provide different answers which are more appropriate for the client. However, ECS will increase the amount of cache space required by resolvers, may reduce DNS performance, and may have privacy implications.
A resolver operator that has clients that are limited to a specific region may see no benefit. A resolver operator that has a widely distributed anycast network may not have much benefit from ECS, since the locations that initiate the query will be close to the client. But a resolver operator that answers client queries only from a few locations, and expects clients to come from a wide area, may provide better service for end-users by supporting ECS.
EDNS client subnet is described in [RFC7871](https://www.rfc-editor.org/rfc/rfc7871.html), an informational RFC.
### Extended DNS Errors
**Extended DNS errors should be enabled.**
For: All DNS resolver operators.
DNS traditionally provides very broad error reporting, SERVFAIL being the most common. This makes diagnosing and fixing problems difficult. Extended DNS errors provide extra information about failures, for example expired DNSSEC signatures. They also allow resolver operators to report administrative reasons for DNS failures, such as blocks due to legal requirements.
[RFC8914](https://www.rfc-editor.org/rfc/rfc8914.html) defines extended DNS errors.
### Negative Trust Anchors
**Negative trust anchors may be deployed.**
For: All DNS resolver operators.
Negative trust anchors (NTA) allow a resolver operator to handle a case where an authoritative server has a DNSSEC problem and becomes inaccessible. They basically disable DNSSEC checking for a domain. When this is warranted is difficult to know with certainty, and will usually requires some manual checking. Since DNSSEC validation is now widespread, DNSSEC failures on the authoritative side will impact many resolvers.
Because of these reasons this document does not recommend NTA, but also does not recommend that a deployment avoid NTA if it makes sense for that environment.
Negative trust anchors are documented in [RFC7646](https://www.rfc-editor.org/rfc/rfc7646.html).
### DNS Error Reporting
**DNS error reporting may be enabled.**
For: All DNS resolver operators.
DNS error reporting is a way for resolver operators to let authoritative operators know about problems in authoritative servers or zones. It provides little direct value for the resolver operators, but over time should improve the overall quality of the DNS ecosystem. It is neither widely deployed nor standardized, but hopefully will be both soon. Resolver operators are encouraged to enable DNS error reporting when it is available.
DNS error reporting is proposed in [draft-ietf-dnsop-dns-error-reporting]( https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting).
### Trust Anchor Reporting
**Trust anchor reporting should be enabled.**
For: All DNS resolver operators.
Trust anchor reporting is a way for resolver operators to convey their DNSSEC trust anchor configuration to the operator of the zone that it is for. For most resolvers this is only the root zone. This information is intended to be used during a root KSK rollover to ensure that it is safe to proceed. In the future ICANN is planning an algorithm roll for the root KSK, and this information could be helpful. Resolver operators are encouraged to enable trust anchor reporting.
[RFC8145](https://www.rfc-editor.org/rfc/rfc8145.html) covers trust anchor reporting, in both possibilities available.
### Name Server Identification
**Servers should be configured to identify themselves.**
For: All DNS resolver operators.
Large resolver operations, especially publicly available resolvers, should support an in-band method of discovery that is obvious to permit users to discover what node has answered their query. This improves troubleshooting significantly, and may be useful for research and testing purposes. NSID (Name Server Identifier) is ideal for this, though also âCH TXT id.serverâ support is also reasonable. Geographic hints should be provided in this data, though specific host data is optional for arrays of servers in clusters. IATA codes have traditionally been used for naming points-of-presence, though this is at the discretion of the operator.
[RFC5001](https://www.rfc-editor.org/rfc/rfc5001.html) describes NSID.
[RFC4892](https://www.rfc-editor.org/rfc/rfc4892.html) describes name server identification in general, and documents the pre-NSID approaches.
## Privacy, Filtering, Transparency
### Privacy & anonymity
DNS Resolver operators are advised to apply [RFC8932](https://www.rfc-editor.org/rfc/rfc8932.html)
"Recommendations for DNS Privacy Service Operators" as follows:
1. its operational and policy guidance related to DNS encrypted transports and data handling, by applying all "Threat mitigations" (thereby by meeting its level of "minimally compliant") and additionally by applying the "Optimizations" on EDNS Client Subnet listed in section 5.3.1.
2. its framework on a Recursive operator Privacy Statement, by publishing a privacy statement on their website covers all topics in Section 6. (See for example [Cloudflare's statement]( https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver) or [Quad9's privacy page](https://www.quad9.net/service/privacy/).)
#### Logging considerations
In addition to the logging recommendations from RFC8932, operators should consider the following:
1. Third party access to personal data: Resolver operators may receive third party requests for information they have logged that relates to users, including IP addresses, queries and meta data. Resolvers should only comply with such requests when balancing legitimate third party interest with the user's fundamental rights, including rights to privacy. Usage information can be personal data, Personally Identifable Infomation (PII) or similarly regulated under the privacy laws applicable to the users, operator or third party, revealing a person's health, lifestyle or other personal preferences (profiling). For example, logging information that documents a user resolving a website for alcoholics anonymous may relate to the health of a person behind an IP address.
2. Data security: DNS Resolver operators should take appropriate technical and organisational measures to protect logging information that relates to users.
#### Advertisement Policy
If there is any advertising from the service, the policy should be published as well as how it can potentially affect the users' privacy.
### Filtering and blocking
#### Block Lists
Resolvers can be directed to block or modify answers in various ways. Blocklists may be provided by governments, communities, or other parties (for example security firms).
Response Policy Zone (RPZ) allows a way to both document specific modifications that resolvers will make to DNS answers, and send the rules to resolvers. This allows updates to occur very quickly. If RPZ or some other high-speed blocking technology is used, the parties supplying these sources must be highly trusted, as changes to blocklists will usually immediately impact user queries.
RPZ is not standardized, but there is an IETF draft, [draft-vixie-dnsop-dns-rpz]( https://datatracker.ietf.org/doc/draft-vixie-dnsop-dns-rpz/00/).
#### Legal blocking
**Legal requests and blocking and filtering laws:** DNS resolver operators should not filter content and block access to web-services. When the local law requires blocking, and the law applies to the resolver, the resolver should transparently disclose a list of blocked websites and services, when possible (disclosing such a list may not be allowed by law or regulation). Similarly, the resolver should disclose the source of such block lists, when possible.
If it is not possible to disclose the source of blocklists, operators should try to be as transparent as possible about how they receive those blocklists, based on what criteria, and how they mitigate errors and false positives. Disclosing which organizations operators interact with, how they liase, and so on, can help users understand the impact on the service provided.
If possible, resolvers should provide information about blocked responses via the Extended DNS Error with the Blocked, Censored, Filtered, or Prohibited code - whichever applies best - along with a text why the response was blocked, censored, filtered, or prohibited.
[RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html#section-4.16) provides information about the meanings of the different codes.
**Community governance of blocklists:** blocklists, if mandatory, have to be audited and assessed by third parties and there should be a right to appeal for those blocked. The Internet community can vet the blocklists from time to time to avoid blocking access to websites that are mistakenly blocked. During crisis - when mistakes can have drastic effects on accessing a critical service - preferably filtering and blocking should not be used.
#### Opt-in/Opt-out Mechanisms
End users may choose to use a DNS resolver that filters specific kinds of traffic. For example, they may wish to avoid potential malware web sites. Or resolver operators may be required to default to filtering but allowed for to provide an unfiltered DNS resolver service.
Depending on the specific requirements, a resolver service may publish different IP addresses and what type of filtering applies to each address. It is also possible to perform client authentication and authorization, using IP-based authentication, TSIG keys, or client-side TLS certificates.
### Transparency
Public DNS resolver operators should publish transparency reports to build user trust in their adherence to policies and practices. This goes beyond our advise to apply RFC8932, section 6.2.
A common frequency is once a year. The reports inform the public about disclosure of user information and removal of content required by law enforcement and other government agencies.
Transparency reports should (to the extent that the law allows) indicate which government agencies and law enforcement agencies request access on what basis.
It should also be clear from the transparency reports what kind of data has been requested and if content removal and content blocking have been requested. Categories of data include: Content Data, Basic Subscriber Data, Other Non-Content Data and Content Blocking.
#### Negative Trust Anchor reporting
Negative Trust Anchors (NTA) are discussed in the previous section on DNS configurations. If NTAs are present in the resolver, they should be published with as much detail as possible about them. This includes reasons for insertion, dates of activation and expected removal dates, or a published review date or cycle for when NTAs should be actively examined for deletion if such fine-grained information cannot be shared.
NTAs are equivalent to a security fault, and may even be more significant than a block event as they remove expected trust behavior with limited signal of that trust downgrade ("limited" because few if any clients care about those response bits changing.).
#### Human rights considerations
DNS resolvers can opt for declaring their understanding of their responsibilities regarding human rights from the Universal Declaration of Human Rights. As an example of a public DNS resolver operator, Quad9 mentions rights to freedoms without distinction made on the basis of country, no interference with privacy, the right to freedom of opinion and expression, the right to peaceful assembly, and the right to freely participate in the cultural life of the community.
See [Quad9's Human Rights Considerations]( https://www.quad9.net/privacy/human-rights-considerations/) for the full statement.
It also invokes other human rights related solutions other than [UDHR](https://www.un.org/en/universal-declaration-human-rights/) such as Articles 8 and 9 of Resolution 42/15 of the United Nations Human Rights Council on the right to privacy in the digital age of 26 September 2019 more directly define the responsibilities of the private sector toward the furtherance of human rights in modern terms. They also follow the Guidelines for Human Rights Protocol and Architecture Consideration of the Human Rights Protocol Considerations Research Group at Internet Research Task Force.
The latest version of the IRTF [Guidelines for HRPC](https://tools.ietf.org/html/draft-irtf-hrpc-guidelines) may be considered for all network operators.
## Appendix A: Why Did RIPE Write This Document?
There is increasing concern that large open DNS resolvers will become centralised points of DNS operations on the Internet. In order to address this, the European Commission issued the [DNS4EU]( https://hadea.ec.europa.eu/calls-proposals/equipping-backbone-networks-high-... ) proposal. However, such an initiative could lead to centralised guidance or regulation which might interfere with the decentralised way the Internet infrastructure works - including the DNS. See for reference the [RIPE NCC Open House discussion]( https://labs.ripe.net/author/chrisb/dns4eu-ripe-ncc-open-house-discussion/ ) on this topic.
Rather than attempting to respond to the EC proposal or organize specific DNS resolver deployments, the RIPE community has decided that it is best able to provide advice and guidance. The RIPE Community is well positioned to provide a set of Best Current Practices that operators of Open DNS Resolvers will be encouraged to subscribe to.
-- dns-resolver-tf mailing list dns-resolver-tf@ripe.net https://lists.ripe.net/mailman/listinfo/dns-resolver-tf
Some more and apologies as I was thinking the updates were in the git repo which was what confused me. ### TTL Recommendations Software typically defaults to a maximum stored TTL of 1 or 2 days. A lower TTL will mean removing rarely-used records that have long TTL, and should not have much operational impact from a CPU or network point of view Where did this 1 or 2 days come from? From most s/w I've seen the default max-cache-ttl is a few hours. **Discovery of DNS Designated Resolvers** QUESTION: Do we need to publish certificate in other ways that via the DDR mechanisms? three things 1) s/ways that via/ways than via/ 2) s/certificate/certificates/ 3) yes we do but it's still very hand wavey in how this all goes down. ### DNSSEC validation owner of domain name being queried are returned. s/owner of domain name/owner of the domain name/ On Sun, Mar 24, 2024 at 2:42â¯PM Tim Wicinski <tjw.ietf@gmail.com> wrote:
I want to agree we should reference RFC8932 but perhaps it is cleaner to include their text in this document, to save folks from bouncing through documents. I've felt one of our big goals would be a document where reading the RFCs or other documents would be for historical or extra details. Willing to be told I'm wrong.
On Sun, Mar 24, 2024 at 2:32â¯PM Tim Wicinski <tjw.ietf@gmail.com> wrote:
Sorry I have found it a bit hard to track the document so some of these may be duplicates
### About Recomendation Text
s/Recomendation/Recommendation
may have significant
s/may have significant /may have a significant/
NSEC3 values, can reduce
s/NSEC3 values, can reduce/NSEC3 values can reduce/
NSEC3 redords
s/NSEC3 redords/NSEC3 records/
which return all all
s/ which return all all / which return all /
s/liase/liaise/
On Sun, Mar 24, 2024 at 12:25â¯PM Shane Kerr <shane@time-travellers.org> wrote:
Maarten,
Thank you for your suggestions, edits, and discussion. I've updated the final draft to give us a final, final draft. ð
I've included the last (?) version at the bottom of this e-mail, and responded to your suggestions inline below.
On 19/03/2024 10.24, Maarten Aertsen wrote:
* Those running public DNS resolver services, and
Should we remove "public" here?
Hm, good point!
- Data Security: Since you are in control of the physical servers, there is no risk of data leakage that can occur due to vulnerabilities in multi-tenant virtualization platforms, including CPU cache-based side-channel vulnerabilities. It could be argued that attacks targeting such issues are rare, and their impact on a DNS resolver service is low, but potential breaches may have significant privacy impact. It is advised to evaluate this against your organisation's risk model, or to discuss this with your information security compliance experts.
The ", or [..]" This feels a bit wordy; we don't suggest who to talk to for all the other recommendations either.
Makes sense. Discussing with experts is basically an option for everything. ð
#### Server capacity
If using a model that is easy to scale (cloud based, or Kubernetes based, or similar), then getting server capacity correct is largely a
Given the earlier text about Kubernetes being 'similar' to cloud, "or Kubernetes based, " can probably be removed.
I'm inclined to leave this in. I'd rather be explicit than implicit.
Since DNS is mostly UDP-based, it is often easy to generate large amounts of spoofed traffic to and from DNS servers. DNS traffic is small compared to application traffic (videos and other content), but still significant. Authoritative server operators often build their networks and servers to handle 10 times their normal load. Recursive server operators may need to do the same, although the service only
I would split this sentence, to read:
server operators may need to do the same. When the service only
Fair.
accepts traffic from IP addresses that cannot be spoofed (for example users within a network that operated by the same company) then this
remove "then"
Done.
### Resilience
#### System Diversity
In addition to the software considerations above, operators should
Either change to "software **licensing** considerations", or start the sentence with Operators. After all, the previous part of the text is not about software considerations, so current wording may be a bit confusing to linear readers.
Makes sense. I've started with Operators, no need to remind people of the other considerations here.
consider whether to use different server implementations to provide
s/server/software/ ?
Makes sense.
In addition to the DNS-specific security considerations, normal security best practices for any Internet service should be followed, including updating software updated regularly, patching software as soon as possible for any known security vulnerabilities, following CERT announcements and so on.
Perhaps CERT/CSIRT. Not super important.
You led me down a short trip to the Wikipedia:
https://en.wikipedia.org/wiki/Computer_emergency_response_team
In spite of CMU's trademark on the term CERT (?!?!), I see way more CERT in the national lists than CSIRT, so I'll stick with it.
In a random note, the RIPE Database has an IRT object type rather than a CERT or CSIRT object type, through some artifact of history. ð
#### Certification
It may be useful or required for an organization to follow specific
s/follow/obtain/ ?
In this case "follow" instead of "obtain" was deliberate. It might not be necessary to actually go through the cost of getting certification in order to get the benefits. But, since this section concludes mentioning that business customers will look for them, "obtain" probably makes more sense.
certifications, such as ISO or ITIL. These can be government-defined
Not sure if (unspecified) "ISO or ITIL" are the most relevant examples. I would either remove or replace by say "ISO-IEC 27017, 27018 or SOC 2 Type 2", which all relate to services provided by an organisation, to be relied on by users of that service.
Replaced with "ISO or SOC 2 Type 2".
QUESTION: Do we need to publish certificate in other ways that via the DDR mechanisms?
Should this remain in?
Good point, removed!
### TTL-based Record Pre-Fetch
**TTL record pre-fetch should be enabled when available.**
I would remove "when available", seeing that the last sentence of the next paragraph already covers this.
I'm leaving it in, since we use that exact phraseology elsewhere.
### DNS Error Reporting
**DNS error reporting may be enabled.**
For: All DNS resolver operators.
DNS error reporting is a way for resolver operators to let authoritative operators know about problems in authoritative servers or zones. It provides little direct value for the resolver operators, but over time should improve the overall quality of the DNS ecosystem. It is neither widely deployed nor standardized, but hopefully will be both soon. Resolver operators are encouraged to enable DNS error
To me, 'may be' does not sound like much encouragement. Should this be 'should be' instead? The paragraph already explains that availability is limited for the moment.
I'm not sure we have enough operational experience to know if this is actually a good idea. It may end up being spammy, or unintentionally result in privacy leaks, or any other kinds of unpleasant side-effects. I don't expect it, but I also don't feel comfortable recommending it strongly.
## Privacy, Filtering, Transparency
Reviewing this next part was a bit painful, because I was involved in writing it and yet I see quite a few places where I feel we should improve. After re-reading RFC8932 for the second time, I noticed quite some overlap where RFC8932 is more exhaustive, specific and practicable. By creating overlap, I think we may be watering down our own advise. Below I go over all the items one by one, reference specific sections to advocate for removal of any such overlap.
Okay, thanks for the detailed re-reading.
### Privacy & anonymity
Operators are advised to apply
DNS resolver operators
Yes.
[RFC8932](https://www.rfc-editor.org/rfc/rfc8932.html)
"Recommendations for DNS Privacy Service Operators" as follows:
1. its operational and policy guidance related to DNS encrypted transports and data handling, by applying all "Threat mitigations" (thereby by meeting its level of "minimally compliant") and additionally by applying the "Optimizations" on EDNS Client Subnet listed in section 5.3.1.
2. its framework on a Recursive operator Privacy Statement, by publishing a privacy statement on their website that is compliant with Section 6.
I suggest we strengthen this sentence a bit, then remove duplicates in the next section:
s/that is compliant with/covers all topics in/
Makes sense.
#### Logging considerations
1. Public privacy policy: DNS resolvers are recommended to publish their privacy policies transparently on their website. It can be a brief privacy commitment as well or be more elaborate on how the privacy policy was made. (See for example [Cloudflare's statement]( https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver) or [Quad9's privacy page](https://www.quad9.net/service/privacy/).)
Such policies should explicitly mention the sampling rate of DNS queries/responses that are kept, and whether these are anonymized.
This is fully covered by the reference to RFC8932, Section 6. I suggest we remove this text.
Okay, that makes some sense. I kept the examples from Cloudflare and Quad9, but moved them at the end of the previous section.
2. Third party access to personal data: it seems that the only critical personal data that DNS resolvers collect are IP addresses and the queries that are resolved. The other meta data collected can be used to have an understanding of for example which user accessed which website which can reveal information about a personâs health, lifestyle and other personal preferences (we call this profiling). For example, resolving the website for alcoholics anonymous may tell you something about the health of a person behind an IP address. IP addresses are personally identifiable information. Follow the applicable privacy laws or privacy principles when receiving third party requests to access.
Resolvers should only comply with such requests when balancing legitimate third party interest with other fundamental rights.
This goes beyond RFC8932, Section 5.3.3 and Section 6.1.1 item 2 and may therefore be worth keeping.
I suggest re-ordering this paragraph a bit to start with the advice. The following is an attempt to reorder:
Resolver operators may receive third party requests for information they have logged that relates to users, including IP addresses, queries and meta data. Resolvers should only comply with such requests when balancing legitimate third party interest with the user's fundamental rights, including rights to privacy. Usage information can be personal data, PII or similarly regulated under the privacy laws applicable to the users, operator or third party, revealing a person's health, lifestyle or other personal preferences (profiling). For example, logging information that documents a user resolving a website for alcoholics anonymous may relate to the health of a person behind an IP address.
Makes sense, I've included this text.
3. Access to data for researchers: how it is done, who has access and who can request access, how the resolver makes a decision to give access (validated and credible researchers, what they can access and other issues)
Covered in RFC8932, Section 5.3.3. Suggest removal.
Removed.
4. Data minimization: do not collect personal information not needed for critical operations. Only retain or use what is being asked (the query). If collecting data to make the service more private and secure, explain the rationale for each piece of data (data collection purpose)
Covered in RFC8932 section 5.2.1 and section 5.2.2. Suggest removal.
Removed.
5. Encryption: If data is encrypted, explain how it has been encrypted (DoH, DoT, or so on).
Covered in RFC8932, Section 6.1.2, item 2. Suggest removal.
Removed.
6. Data security and retention: when to delete the data and how it is stored
Data retention is covered in RFC8932 section 5.2.1 and section 5.2.2. Section 5.2.1, last bullit under mitigations sets a security goal relating to data access, though the word security is not used (it is the scope of the entire document).
Suggest removal. Alternatively, abstract to a level higher than RFC8932 by stating something like the following (with limited operational value):
2. Data security: DNS Resolver operators should take appropriate technical and organisational measures to protect logging information that relates to users.
I've included this higher-level recommendation.
**Legal requests and blocking and filtering laws:** DNS resolvers
operators
Updated.
should not filter content and block access to web-services. When the local law requires blocking, and the law applies to the resolver, the resolver should transparently disclose a list of blocked websites and services, when possible (disclosing such a list may not be allowed by law or regulation). Similarly, the resolver should disclose the source of such block lists, when possible.
If it is not possible to disclose the source of blocklists, operators should try to be as transparent as possible about how they receive those blocklists, based on what criteria, and how they mitigate errors and false positives. Disclosing which organizations operators interact with, how they liase, and so on, can help users understand the impact on the service provided.
If possible, resolvers should provide information about blocked responses via the Extended DNS Error with the Blocked, Censored, Filtered, or Prohibited code - whichever applies best - along with a text why the response was blocked, censored, filtered, or prohibited.
[RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html#section-4.16) provides information about the meanings of the different codes.
I like these paragraphs, but they are also covered by RFC8932, section 6.1.1 item 6 (result filtering), which we already advise to apply. As an example of where that section is stronger, it does not feature 'when possible' escape hatches.
I'm not sure what to do here. At a minimum, I believe we should make a reference to that content and substantiate why we feel it is worth repeating here (while not the other topics of RFC8932).
Interesting. The "when possible" language was added in recognition that there may be legal or other barriers preventing such transparency.
Also, RFC 8932 6.1.1 just talks about documentation... our text here actually recommends not filtering, which RFC 8932 does not do.
RFC 8932 also doesn't reference RFC 8914, which makes sense since they came out very near to each other.
So... I understand the concern about re-specifying things, but I'm actually happy to let this text stand.
**Community governance of blocklists:** blocklists, if mandatory, have to be audited and assessed by third parties and there should be a right to appeal for those blocked. The Internet community can vet the blocklists from time to time to avoid blocking access to websites that are mistakenly blocked. During crisis - when mistakes can have drastic effects on accessing a critical service - preferably filtering and blocking should not be used.
This is not covered by 8932, so relevant to keep.
ð
### Transparency
Suggest leading with the advice:
Public DNS resolver operators should publish transparency reports to build user trust in their adherence to policies and practices. This goes beyond our advise to apply RFC8932, section 6.2.
Makes sense. Updated.
DNS resolvers usually provide transparency reports once a year. The
Suggest to replace with:
A common frequency is once a year. The
Done.
#### Voluntary certificates and standards
Some DNS resolvers opt for obtaining certificates in security and privacy. Some also undertake audits on their privacy practices. See for example: https://www.cloudflare.com/trust-hub/compliance-resources/
Suggest removing this; certification is already covered under ### Resilience above. Should the group feel that this is the most appropriate place, I suggest moving that section to replace the one here.
Good point. I added a bit of text mentioning audits or reports, and include the link as an example there.
#### Human rights considerations
DNS resolvers can opt for declaring their understanding of their responsibilities regarding human rights from the Universal Declaration of Human Rights. Specifically, Quad9 mentions rights to freedoms
s/Specifically/As an example of a public DNS resolver operator/
Make sense, updated.
-- Shane
# DNS Resolver Recommendations
About the DNS Resolver Best Common Practice Task Force
https://www.ripe.net/participate/ripe/tf/dns-resolver-best-common-practice-t...
## Terminology
* Open Resolver: A DNS resolver that accepts queries from any client. Often the result of misconfiguration.
* Public Resolver: A resolver intentionally configured to be an open resolver.
## Introduction
### What Is This Document? Who Is It For?
This document presents recommendations and best current practices for operating DNS resolvers, both public and non-public ones. It covers technical aspects of operations and provides best practice recommendations for data management, with a particular focus on user privacy, security, and resilience.
The document serves as guidance for the wider Internet community, offering input to:
* Those running DNS resolver services, and * Those who want to make informed choices between such services.
Its purpose is to provide clear guidance and promote effective practices in DNS resolver operation.
The intended audience is not the entire DNS community. Advice here is probably not useful for operators of authoritative servers, domain registrars, and so on. It is also not meant to be an introductory or educational document. There are many documents which cover the basics of DNS and the roles of organizations in it; a good overview is:
Addressing the challenges of modern DNS - a comprehensive tutorial by van der Toorn et al.
https://ris.utwente.nl/ws/files/282427879/1_s2.0_S1574013722000132_main.pdf
The document does not consider how to measure adherence to these recommendations. So it is not intended to be used for certification, although certification created based on the principles here is possible.
### How Is This Document Organized?
This document has a number of sections, and specific recommendations in each section. The intent is for each recommendations to have clear guidance at the top, and then background and discussion related to the recommendation afterwards. Each recommendation indicates whether it is mostly for operators of public resolvers or for operators of any resolver.
### About Recomendation Text
This is not a standards document, and does not propose any way to measure compliance or interoperability. It does use words like "should" or "may be" throughout. These are meant to be interpreted in the usual English sense, and not as IETF-style RFC 2119 jargon.
## System and Network Hardening
### Infrastructure considerations
Running any Internet service requires attention to the infrastructure used to operate it. This section discusses various approaches that can be used to run a DNS resolver. Everything applies to both public and non-public DNS resolvers.
#### Bare metal or public cloud
All DNS resolver software can run either on dedicated servers (rented or colocated), or in virtualized clouds, or in a combination of those. Every approach has pros and cons. Most of these are not specific to running DNS resolvers, however, some of them are.
**Running DNS resolver instances as OS level daemons on bare metal hosts:**
Pros:
- Performance: Bare metal servers have direct access to the underlying hardware, and can offer superior performance/cost balance by avoiding the overhead associated with virtualization. Moreover, you have full control over the server's configurations, down to the hardware level, which can be beneficial for performance and cost optimization once you get the understanding of your typical work load during peak hours.
- Data Security: Since you are in control of the physical servers, there is no risk of data leakage that can occur due to vulnerabilities in multi-tenant virtualization platforms, including CPU cache-based side-channel vulnerabilities. It could be argued that attacks targeting such issues are rare, and their impact on a DNS resolver service is low, but potential breaches may have significant privacy impact. It is advised to evaluate this against your organisation's risk model.
- Predictability: Because there is no virtualization layer and no "noisy neighbours" on the host, the performance of your servers is more predictable.
Cons:
- Cost of failure: If you pick hardware configuration that is not optimal for the workload of your DNS resolver, you may need to upgrade and replace hardware components afterwards. Ways to reduce this risk include renting servers instead of buying them, carrying load testing with data similar to production workloads, and providing limited beta access to the service before it fully enters the production phase.
- Scalability: Scaling up with physical servers means acquiring or renting, installing, and configuring new hardware, which will take more time than provisioning new virtual servers in a cloud environment. Moreover, most cloud environments will provide you with cluster autoscaling features, which could barely be achieved in bare metal.
- Maintenance: You will be responsible for all server maintenance tasks, including hardware issues, which can require significant effort and specific expertise.
- Redundancy: Setting up high availability and disaster recovery strategies can be more complex and time consuming compared to the cloud, where these features are often provided as value added products. See the Redundancy section for more details.
**Running DNS resolver instances in containers in a public cloud:**
Pros:
- Scalability: Clouds excel at scaling applications. You can scale up and down rapidly based on load, which is important for a DNS resolver that needs to handle variable query loads. In case of regional or geographically distributed resolvers, in every region where the resolver would be deployed, daily periodicity is likely to be observed, for example peak hour is likely to occur around 19:00 local time, and off-peak hours may begin at around 01:00-03:00. In a situation like that, using cluster autoscaling features and tools, you can run less instances in the night and more instances throughout the day, which may help to optimize your cloud hosting costs.
- Fault Tolerance and High Availability: Most clouds have built-in strategies, features, and products for handling node failures, which can increase your service's availability.
- Deployment and Management: Cloud providers offer built-in methods to deploy and manage applications, which can simplify operations and reduce the likelihood of human errors if your infrastructure management department is already familiar with these tools.
- Cost: While this largely depends on your specific usage, cloud services can sometimes be more cost-effective than managing your own physical servers, especially when you consider the total cost of ownership, including power, cooling, and maintenance.
Cons:
- Performance: The virtualization layer of public clouds can impact performance. While this certainly could be mitigated through scaling the number of virtual hosts, the cost would also increase accordingly.
- Complexity: Advanced cloud technologies are complex systems which come with a steep learning curve. Without prior experience, properly configuring and managing a cloud-based compute cluster can be challenging.
- Cost Variability: While the cloud can be cheaper, it can also be more expensive if not properly managed. Costs can rise unexpectedly based on traffic. Make sure to always set some limits on how much may be spent on hosting in the cloud control panel, and to set up notifications to be sent to you when these thresholds are about to be triggered.
- Multi-tenancy Risks: In a public cloud environment, the "noisy neighbour" problem could potentially affect your service's performance. Additionally, even though cloud providers take steps to isolate tenant environments, vulnerabilities could potentially expose sensitive data (see the previous section for a detailed explanation).
**Additional considerations**
- In today's environments, Kubernetes and Terraform are sometimes used as a substitute for cloud APIs when it comes to production services' management. When running a DNS resolver in a Kubernetes cluster on top of a public cloud environment, all the pros and cons of the public cloud apply; basically, Kubernetes becomes your public cloud provider. If you have significant prior experience running services in Kubernetes in production, you may successfully replicate your experience with the DNS resolver software. Otherwise, we would advise against Kubernetes in this case.
- The only reason we may find to run a DNS resolver in a Kubernetes cluster on top of self-hosted dedicated servers is when you have significant hands-on experience with Kubernetes and it is natural for you to manage applications this way. Otherwise, running DNS resolver daemons in containers brings little, if any, benefit. Autoscaling features are not available to you in this case, and neither horizontal nor vertical pod autoscaling is of any use, because DNS resolver software typically scales in-host by itself just fine.
- When designing a cluster of resolvers for autoscaling, keep in mind that newly spawned resolver machines would need to populate resolver cache first before they are fully useful. Your DNS resolver software may provide cache replication mechanisms. Otherwise, it is safe to overprovision clusters somewhat under heavy load, and discarding excessive instances once all the caches are populated and the average load of a compute instance decreases. In addition, it may be worthwhile to consider sharing cache data between instances.
- It is always advised to prefer environments your infrastructure management team is familiar with.
### Software considerations
#### Open Source
**Recommendation**: Choose any well-maintained DNS software you are comfortable using. Regardless of which software you choose, ensure you have somewhere to go for support. In the case of open source software, consider providing financial support to ensure continued development. Some open source maintainers take donations, while others offer support contracts.
There are both open source and proprietary implementations of DNS resolver software. Mixing these is also possible, for example, by using proprietary extensions with open source software or deploying open source software modified in-house.
General observations: - Software licensing is orthogonal to software security. Neither is proprietary software less secure on principle nor are contributions by "unknown" developers more of a risk in open source.
Benefits of open source: - Open source allows for inspection, independent auditing, and troubleshooting. - Open source can avoid vendor lock-in. - Open source can aid internet standards development. Widely-deployed open source implementations allow proponents of standards drafts to contribute proof of concept implementations without permission or cooperation of vendors.
Drawbacks of open source - Both open source and proprietary software require skilled maintenance, which has costs. Proprietary licensed software or appliances typically come with license fees to cover these. In contrast, open source licenses decouple usage by operators from monetary compensation to developers. It is up to operators to consider the financial sustainability of continued maintenance of the open source DNS software they depend upon.
Please also consider deploying different software implementations to ensure diversity, as discussed in the diversity section below.
### Networking considerations
#### IPv4 and IPv6
**If available, both IPv4 and IPv6 must be deployed.**
Large parts of the authoritative DNS are only accessible via IPv4, so the resolver must be able to originate IPv4 queries. Authoritative DNS that is only accessible via IPv6 is very rare.
Depending on the connectivity of clients, a resolver may be IPv4-only, IPv6-only, or support IPv4 and IPv6.
#### Addressing
**Using multiple IP addresses for the service address should be considered.**
Using 2 or more IPv4 addresses and 2 or more IPv6 addresses from different RIR will allow resilience in failure at an RIR, either governance, security, or technical. Note that support for multiple addresses for recursive resolvers varies and some clients perform poorly if any address does not respond normally.
There is no need to pick an IPv4 address with all octets the same, like 2.2.2.2 or 11.11.11.11.
**Publishing a list of back-end addresses used for resolving should be considered.**
Publishing a list of back-end addresses used for resolving can be useful for other network & DNS operators (for example, geo-IP location, making sure data is getting to correct places, and so on).
#### High Availability
This can be considered in terms of local and global scope.
##### Local scope
Inside a single location/region, such as an office, campus, or small ISP network, the main availability concern is that a resolver is always reachable. Client systems can be configured with multiple resolver addresses, but the failover behaviour of stub resolvers to a second address can be painful. Ideally the primary address is highly available and such fallback rarely required. How much effort is put into ensuring this is true should probably scale in line with the number of users, or sensitivity of the clients using that resolver to delayed resolution.
There are several ways to promote high availability of an individual resolver address, such as dedicated load balancing equipment, or network techniques like VRRP, or IP anycast. These generally have in common a pool of recursive servers and the means to direct queries to them when a health check has determined them to be capable of answering those queries.
Dedicated free or commercially produced, hardware or software load balancing solutions are available. These typically own the resolver IP address and forward queries to the currently available instances of a pool of recursive servers.
VRRP enables a technique to make the resolver IP address available on multiple servers, often used to provide automatic failover between two. A pool of recursive servers using this technique must reside in the same broadcast domain.
IP anycast in the local scope typically involves a pool of recursive servers advertising a route to a shared resolver IP address into a routing protocol. This can be configured in failover or load-sharing configurations. A load sharing configuration typically requires network equipment able to balance traffic to a destination over equal cost paths (ECMP). A pool of recursive servers using this technique can be distributed in different parts of the network.
##### Global scope
The same concerns as for local service availability are present in the global scope, with the added issue that DNS resolution over long distances may be slow. Practically speaking, only multiple resolver addresses, or IP anycast are useful strategies here. The motivations for finding better failover solutions than multiple resolver addresses have been covered above.
IP anycast in the global scope means routing the same IP prefix to more than one location. This can provide effective solutions for failover and, when optimally configured for routing client queries to the topologically least distant recursive server location. IP anycast in the global scope requires the use of globally routable prefixes. If a separate prefix is to be used for anycasting, usually this means a /24 in IPv4 and a /48 in IPv6, as those are the smallest sizes that will be widely propagated in BGP. A common practice is to use a covering prefix (/23 in IPv4 or /47 in IPv6) for fallback, and a more-specific prefix (/24 or /48) for the traffic. The more-specific prefix can then be withdrawn to send traffic to a backup site; this will happen automatically if the site is disconnected from routing.
[RFC7094](https://www.rfc-editor.org/rfc/rfc7094.html) discusses anycast architecture in detail, including references to various other RFC which discuss anycast in general and to DNS in particular.
[RFC4786](https://datatracker.ietf.org/doc/html/rfc4786) discuses operation of anycast services.
##### Generally
Operators of a globally scoped recursive service are encouraged to also adopt the local scope recommendations in each of the locations where the service is provisioned.
Though the above deals with the shortcomings of reliance on stub resolver failover between a list of addresses those recommendations shouldnât be seen as an exclusive alternative. Multiple resolver addresses, where each is provisioned using differing failover strategies, can provide a resolver of last resort and further improved resilience.
#### Ingress Filtering
**Ingress Filtering to follow BCP 38 should be deployed.**
DNS normally uses UDP traffic, which makes it a common vector of both [reflection](https://en.wikipedia.org/wiki/Reflection_attack) and [amplification]( https://www.cisa.gov/news-events/alerts/2014/01/17/udp-based-amplification-a... ) attacks. To minimize the amount of spoofed traffic that a resolver responds to, the network should be configured as recommended in [BCP 38](https://www.rfc-editor.org/rfc/rfc2827.html).
#### RPKI Sign Advertised Routes
**Route Advertisements should be signed using RPKI**
Using RPKI to sign any route advertisements - either toward authoritative servers or toward DNS clients - is straightforward to do and will reduce the impact of BGP misconfigurations and some BGP hijacking attempts.
RPKI validation is also possible, although the effort is greater. It is possible that the hosting provider or the transit provider for your service validates BGP; asking and making this part of your selection criteria is reasonable.
#### (D)DoS measures
Denial-of-Service (DoS) attacks, both distributed (DDoS) and not are a threat to any Internet service. Network operators for a service providing any DNS service must be prepared for large amounts of attack traffic.
In addition to attacks on the service itself, a resolver may be used both as an attack reflector and as an attack amplifier.
Active monitoring of network and service usage, careful logging, and a security team that is able to respond to problem reports is necessary. Mitigation techniques will include filtering or rate-limiting traffic, both on the authoritative and client side of the resolver.
### Capacity planning
#### Server capacity
If using a model that is easy to scale (cloud based, or Kubernetes based, or similar), then getting server capacity correct is largely a question of budgeting. If using a less-flexible model (bare metal for example), then under-estimating will mean problems delivering service.
Hardware performance varies widely, as does operating system and resolver performance. Some lab testing will be necessary to estimate the number of systems needed.
#### Network capacity
Since DNS is mostly UDP-based, it is often easy to generate large amounts of spoofed traffic to and from DNS servers. DNS traffic is small compared to application traffic (videos and other content), but still significant. Authoritative server operators often build their networks and servers to handle 10 times their normal load. Recursive server operators may need to do the same. When the service only accepts traffic from IP addresses that cannot be spoofed (for example users within a network that operated by the same company) this can be reduced, for example to 3 times normal load. To estimate expected load, the best approach is to examine historical usage for the actual expected users of the system.
### Resilience
#### System Diversity
Operators should consider whether to use different software implementations to provide service. This allows continued operation if a critical vulnerability is found in one implementation, by shifting traffic to other implementations.
Placing resolvers and control systems in different physical locations will allow continued operation in the event of a disaster or other problem that impacts a single location. In addition, ensuring diverse connectivity to other networks will prevent single points of failure on the network side. Ensuring network diversity may take some care, as it is not always obvious what fate is shared between any given path; this may be physical, virtual, or organizational, and my sometimes be hidden.
#### Security
In addition to the DNS-specific security considerations, normal security best practices for any Internet service should be followed, including updating software updated regularly, patching software as soon as possible for any known security vulnerabilities, following CERT announcements and so on.
#### Certification
It may be useful or required for an organization to obtain specific certifications, such as ISO or SOC 2 Type 2. These can be government-defined or industry-defined. For end users there is typically not much direct value, but business customers will often look for services that are operated by organizations meeting such standards. Audits or other reports about this may be published, see for example: https://www.cloudflare.com/trust-hub/compliance-resources/
## DNS configuration knobs
The DNS is an old protocol that has a lot of settings that can be tweaked. This section reviews these and provides recommendations on which should be used for a resolver.
### DNSSEC validation
**DNSSEC validation should be enabled.**
For: All DNS resolver operators.
DNSSEC validation is the best way to ensure that the answers from the owner of domain name being queried are returned.
The root KSK must be updated when it changes. While [RFC5011](https://www.rfc-editor.org/rfc/rfc5011.html) defines an automated way to do this, a resolver operator will probably either manage this trust anchor directly or have it updated via OS updates.
[RFC9364](https://www.rfc-editor.org/rfc/rfc9364.html) provides a lot of useful information, and links to further documents about DNSSEC. However, operators usually do not need to know the details, and can simply ensure that DNSSEC validation is enabled in their software.
Resolver software that does not support DNSSEC validation should be avoided.
### DNS Transport Protocols
**UDP and TCP must be supported.**
For: All DNS resolver operators.
UDP is what most clients use, and TCP is necessary for DNS answers that are too large for a single UDP packet.
[RFC7766](https://www.rfc-editor.org/rfc/rfc7766.html) explains why TCP is necessary in more detail.
### Packet Fragmentation Avoidance
**Servers should be configured to avoid fragmentation.**
For: ALL DNS resolver operators.
Packet fragmentation can cause issues with DNS over UDP, especially over IPv6. These issues can be minimized by choosing implementations that set IP options to avoid this, and by taking care with EDNS0 message sizes.
Recommendations are available in [draft-ietf-dnsop-avoid-fragmentation]( https://datatracker.ietf.org/doc/draft-ietf-dnsop-avoid-fragmentation/).
### Encrypted DNS
**At least one of DNS-over-TLS (DoT), DNS-over-HTTPS (DoH), and DNS-over-QUIC (DoQ) should be supported.**
For: All DNS resolver operators.
DoT, DoH, and DoQ are different technologies that all provide an encrypted channel between the resolver and the authoritative server. DoT is the oldest, and provides encrypted DNS using TLS. DoH uses HTTP over TLS as a way to transmit queries and answers, and is widely supported by web browsers. DoQ is the newest, and provides advanced features such as separate streams for each query, avoiding the "head of line" blocking problem common with all protocols layered on top of TCP (such as DoT and DoH).
- DoT - [RFC7858](https://www.rfc-editor.org/rfc/rfc7858.html) - DoH - [RFC8484](https://www.rfc-editor.org/rfc/rfc8484.html) - DoQ - [RFC9250](https://www.rfc-editor.org/rfc/rfc9250.html)
**Discovery of DNS Designated Resolvers**
There are new mechanisms that allow DNS clients to use DNS records to discover encrypted DNS configurations. Resolvers should publish DNS records to assist clients finding encrypted resolvers.
- Discovery of Designated Resolvers - [RFC9462](https://www.rfc-editor.org/rfc/rfc9462.html)
### QNAME Minimization
**QNAME minimization should be enabled.**
For: All DNS resolver operators.
Using QNAME minimization, a resolver does not send the full name that it is trying to resolver to authoritative servers higher in the DNS hierarchy. So, for example, when querying "atlas.ripe.net" the servers for ".net" would only be asked for "ripe.net". This improves privacy for the end user querying the name.
[RFC7816](https://www.rfc-editor.org/rfc/rfc7816.html) covers QNAME minimization.
### Aggressive NSEC caching
**Aggressive NSEC caching may be enabled.**
For: Public resolver operators.
"Aggressive NSEC caching", meaning negative caching based on NSEC and NSEC3 values, can reduce traffic greatly. It is important to protect against random subdomain attacks.
This style of caching takes advantage of the way that NSEC and NSEC3 records cover a range of names in a zone. A resolver can know that a query falls within such a range without sending any further queries, by remembering the NSEC or NSEC3 redords that is has seen as answers to earlier queries.
Aggressive NSEC caching is almost always a good idea. However enabling this is less important for DNS resolver operators who have a close relationship with users, since they can stop attacks by blocking users or otherwise directly dealing with the source of abusive queries.
[RFC8189](https://www.rfc-editor.org/rfc/rfc8189.html) describes negative caching in detail.
### ANY Queries
**ANY queries responses should be limited.***
For: All resolver operators.
Public or large-scale resolvers should be exceptionally careful with queries of type ANY, which return all all records at a given name. If a resolver replies with all of the records cached for a given type, the response can be much larger than for a single record type. Strict limits should be enforced on volumes of such queries to prevent amplification abuse, or truncation should be applied to prevent spoofed redirections.
[RFC8482](https://www.rfc-editor.org/rfc/rfc8482.html) describes several approaches to limiting ANY responses.
### Local Root
**Local root should be used.**
For: Public resolver operators.
Running a local root has several benefits, but it is an additional component to maintain. For public resolver operators this is definitely worth the cost, but other resolver operators may choose to simply send all queries to the well-distributed root name servers.
[RFC8806](https://www.rfc-editor.org/rfc/rfc8806.html) describes local root, including several example configurations.
In the future it will be possible to use ZONEMD to validate the copy of the root zone obtained before using it. This is currently available for the root zone.
[RFC8976](https://www.rfc-editor.org/rfc/rfc8976.html) describes ZONEMD.
### DNS Cookies
**Interoperable DNS Cookies may be supported.**
For: Public resolver operators.
DNS cookies provide some improved security over plain UDP, and are designed to be more lightweight than TCP. If more than one server is responding for a given IP address, then the Server Secret must be shared by all servers, and the answer must be constructed in a consistent manner by all server implementations.
Since client-side support for DNS cookies is not very widespread, and since managing server-side secrets involves some work, the costs may outweigh the benefits for some non-public resolver operators.
[RFC7873](https://www.rfc-editor.org/rfc/rfc7873.html) describes DNS cookies, and [RFC9018](https://www.rfc-editor.org/rfc/rfc9018.html) standardizes shared DNS cookies.
### TTL Recommendations
**TTL limits may be adjusted.**
For: All DNS resolver operators.
Software typically defaults to a maximum stored TTL of 1 or 2 days. A lower TTL will mean removing rarely-used records that have long TTL, and should not have much operational impact from a CPU or network point of view.
It is possible to set a minimum TTL in many implementations. This is a violation of the DNS protocol, although may be useful to reduce load from records with very low TTL (less than 5 seconds).
Note that software may set different maximum and minimum TTL independent of the results that the resolver returns. That may have a significant impact on queries as well, but resolver operators cannot influence that.
### TTL-based Record Pre-Fetch
**TTL record pre-fetch should be enabled when available.**
For: All DNS resolver operators.
Some resolvers have the ability to look up a record before it has expired from cache, in order to refresh the value and extend the TTL. This way there is never a time when the records are missing from the cache. This is not currently standardized, but a form of this was proposed in the IETF as [DNS Hammer]( https://datatracker.ietf.org/doc/html/draft-wkumari-dnsop-hammer-03). We recommend turning this feature on if available.
### EDNS Client Subnet (ECS)
**ECS may be enabled.**
For: All DNS resolver operators.
EDNS Client Subnet (ECS) allows the resolver to include information about the IP address of the client querying it when sending messages to authoritative servers. This may allow authoritative servers to provide different answers which are more appropriate for the client. However, ECS will increase the amount of cache space required by resolvers, may reduce DNS performance, and may have privacy implications.
A resolver operator that has clients that are limited to a specific region may see no benefit. A resolver operator that has a widely distributed anycast network may not have much benefit from ECS, since the locations that initiate the query will be close to the client. But a resolver operator that answers client queries only from a few locations, and expects clients to come from a wide area, may provide better service for end-users by supporting ECS.
EDNS client subnet is described in [RFC7871](https://www.rfc-editor.org/rfc/rfc7871.html), an informational RFC.
### Extended DNS Errors
**Extended DNS errors should be enabled.**
For: All DNS resolver operators.
DNS traditionally provides very broad error reporting, SERVFAIL being the most common. This makes diagnosing and fixing problems difficult. Extended DNS errors provide extra information about failures, for example expired DNSSEC signatures. They also allow resolver operators to report administrative reasons for DNS failures, such as blocks due to legal requirements.
[RFC8914](https://www.rfc-editor.org/rfc/rfc8914.html) defines extended DNS errors.
### Negative Trust Anchors
**Negative trust anchors may be deployed.**
For: All DNS resolver operators.
Negative trust anchors (NTA) allow a resolver operator to handle a case where an authoritative server has a DNSSEC problem and becomes inaccessible. They basically disable DNSSEC checking for a domain. When this is warranted is difficult to know with certainty, and will usually requires some manual checking. Since DNSSEC validation is now widespread, DNSSEC failures on the authoritative side will impact many resolvers.
Because of these reasons this document does not recommend NTA, but also does not recommend that a deployment avoid NTA if it makes sense for that environment.
Negative trust anchors are documented in [RFC7646](https://www.rfc-editor.org/rfc/rfc7646.html).
### DNS Error Reporting
**DNS error reporting may be enabled.**
For: All DNS resolver operators.
DNS error reporting is a way for resolver operators to let authoritative operators know about problems in authoritative servers or zones. It provides little direct value for the resolver operators, but over time should improve the overall quality of the DNS ecosystem. It is neither widely deployed nor standardized, but hopefully will be both soon. Resolver operators are encouraged to enable DNS error reporting when it is available.
DNS error reporting is proposed in [draft-ietf-dnsop-dns-error-reporting]( https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-error-reporting).
### Trust Anchor Reporting
**Trust anchor reporting should be enabled.**
For: All DNS resolver operators.
Trust anchor reporting is a way for resolver operators to convey their DNSSEC trust anchor configuration to the operator of the zone that it is for. For most resolvers this is only the root zone. This information is intended to be used during a root KSK rollover to ensure that it is safe to proceed. In the future ICANN is planning an algorithm roll for the root KSK, and this information could be helpful. Resolver operators are encouraged to enable trust anchor reporting.
[RFC8145](https://www.rfc-editor.org/rfc/rfc8145.html) covers trust anchor reporting, in both possibilities available.
### Name Server Identification
**Servers should be configured to identify themselves.**
For: All DNS resolver operators.
Large resolver operations, especially publicly available resolvers, should support an in-band method of discovery that is obvious to permit users to discover what node has answered their query. This improves troubleshooting significantly, and may be useful for research and testing purposes. NSID (Name Server Identifier) is ideal for this, though also âCH TXT id.serverâ support is also reasonable. Geographic hints should be provided in this data, though specific host data is optional for arrays of servers in clusters. IATA codes have traditionally been used for naming points-of-presence, though this is at the discretion of the operator.
[RFC5001](https://www.rfc-editor.org/rfc/rfc5001.html) describes NSID.
[RFC4892](https://www.rfc-editor.org/rfc/rfc4892.html) describes name server identification in general, and documents the pre-NSID approaches.
## Privacy, Filtering, Transparency
### Privacy & anonymity
DNS Resolver operators are advised to apply [RFC8932](https://www.rfc-editor.org/rfc/rfc8932.html)
"Recommendations for DNS Privacy Service Operators" as follows:
1. its operational and policy guidance related to DNS encrypted transports and data handling, by applying all "Threat mitigations" (thereby by meeting its level of "minimally compliant") and additionally by applying the "Optimizations" on EDNS Client Subnet listed in section 5.3.1.
2. its framework on a Recursive operator Privacy Statement, by publishing a privacy statement on their website covers all topics in Section 6. (See for example [Cloudflare's statement]( https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver) or [Quad9's privacy page](https://www.quad9.net/service/privacy/).)
#### Logging considerations
In addition to the logging recommendations from RFC8932, operators should consider the following:
1. Third party access to personal data: Resolver operators may receive third party requests for information they have logged that relates to users, including IP addresses, queries and meta data. Resolvers should only comply with such requests when balancing legitimate third party interest with the user's fundamental rights, including rights to privacy. Usage information can be personal data, Personally Identifable Infomation (PII) or similarly regulated under the privacy laws applicable to the users, operator or third party, revealing a person's health, lifestyle or other personal preferences (profiling). For example, logging information that documents a user resolving a website for alcoholics anonymous may relate to the health of a person behind an IP address.
2. Data security: DNS Resolver operators should take appropriate technical and organisational measures to protect logging information that relates to users.
#### Advertisement Policy
If there is any advertising from the service, the policy should be published as well as how it can potentially affect the users' privacy.
### Filtering and blocking
#### Block Lists
Resolvers can be directed to block or modify answers in various ways. Blocklists may be provided by governments, communities, or other parties (for example security firms).
Response Policy Zone (RPZ) allows a way to both document specific modifications that resolvers will make to DNS answers, and send the rules to resolvers. This allows updates to occur very quickly. If RPZ or some other high-speed blocking technology is used, the parties supplying these sources must be highly trusted, as changes to blocklists will usually immediately impact user queries.
RPZ is not standardized, but there is an IETF draft, [draft-vixie-dnsop-dns-rpz]( https://datatracker.ietf.org/doc/draft-vixie-dnsop-dns-rpz/00/).
#### Legal blocking
**Legal requests and blocking and filtering laws:** DNS resolver operators should not filter content and block access to web-services. When the local law requires blocking, and the law applies to the resolver, the resolver should transparently disclose a list of blocked websites and services, when possible (disclosing such a list may not be allowed by law or regulation). Similarly, the resolver should disclose the source of such block lists, when possible.
If it is not possible to disclose the source of blocklists, operators should try to be as transparent as possible about how they receive those blocklists, based on what criteria, and how they mitigate errors and false positives. Disclosing which organizations operators interact with, how they liase, and so on, can help users understand the impact on the service provided.
If possible, resolvers should provide information about blocked responses via the Extended DNS Error with the Blocked, Censored, Filtered, or Prohibited code - whichever applies best - along with a text why the response was blocked, censored, filtered, or prohibited.
[RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html#section-4.16) provides information about the meanings of the different codes.
**Community governance of blocklists:** blocklists, if mandatory, have to be audited and assessed by third parties and there should be a right to appeal for those blocked. The Internet community can vet the blocklists from time to time to avoid blocking access to websites that are mistakenly blocked. During crisis - when mistakes can have drastic effects on accessing a critical service - preferably filtering and blocking should not be used.
#### Opt-in/Opt-out Mechanisms
End users may choose to use a DNS resolver that filters specific kinds of traffic. For example, they may wish to avoid potential malware web sites. Or resolver operators may be required to default to filtering but allowed for to provide an unfiltered DNS resolver service.
Depending on the specific requirements, a resolver service may publish different IP addresses and what type of filtering applies to each address. It is also possible to perform client authentication and authorization, using IP-based authentication, TSIG keys, or client-side TLS certificates.
### Transparency
Public DNS resolver operators should publish transparency reports to build user trust in their adherence to policies and practices. This goes beyond our advise to apply RFC8932, section 6.2.
A common frequency is once a year. The reports inform the public about disclosure of user information and removal of content required by law enforcement and other government agencies.
Transparency reports should (to the extent that the law allows) indicate which government agencies and law enforcement agencies request access on what basis.
It should also be clear from the transparency reports what kind of data has been requested and if content removal and content blocking have been requested. Categories of data include: Content Data, Basic Subscriber Data, Other Non-Content Data and Content Blocking.
#### Negative Trust Anchor reporting
Negative Trust Anchors (NTA) are discussed in the previous section on DNS configurations. If NTAs are present in the resolver, they should be published with as much detail as possible about them. This includes reasons for insertion, dates of activation and expected removal dates, or a published review date or cycle for when NTAs should be actively examined for deletion if such fine-grained information cannot be shared.
NTAs are equivalent to a security fault, and may even be more significant than a block event as they remove expected trust behavior with limited signal of that trust downgrade ("limited" because few if any clients care about those response bits changing.).
#### Human rights considerations
DNS resolvers can opt for declaring their understanding of their responsibilities regarding human rights from the Universal Declaration of Human Rights. As an example of a public DNS resolver operator, Quad9 mentions rights to freedoms without distinction made on the basis of country, no interference with privacy, the right to freedom of opinion and expression, the right to peaceful assembly, and the right to freely participate in the cultural life of the community.
See [Quad9's Human Rights Considerations]( https://www.quad9.net/privacy/human-rights-considerations/) for the full statement.
It also invokes other human rights related solutions other than [UDHR](https://www.un.org/en/universal-declaration-human-rights/) such as Articles 8 and 9 of Resolution 42/15 of the United Nations Human Rights Council on the right to privacy in the digital age of 26 September 2019 more directly define the responsibilities of the private sector toward the furtherance of human rights in modern terms. They also follow the Guidelines for Human Rights Protocol and Architecture Consideration of the Human Rights Protocol Considerations Research Group at Internet Research Task Force.
The latest version of the IRTF [Guidelines for HRPC](https://tools.ietf.org/html/draft-irtf-hrpc-guidelines) may be considered for all network operators.
## Appendix A: Why Did RIPE Write This Document?
There is increasing concern that large open DNS resolvers will become centralised points of DNS operations on the Internet. In order to address this, the European Commission issued the [DNS4EU]( https://hadea.ec.europa.eu/calls-proposals/equipping-backbone-networks-high-... ) proposal. However, such an initiative could lead to centralised guidance or regulation which might interfere with the decentralised way the Internet infrastructure works - including the DNS. See for reference the [RIPE NCC Open House discussion]( https://labs.ripe.net/author/chrisb/dns4eu-ripe-ncc-open-house-discussion/ ) on this topic.
Rather than attempting to respond to the EC proposal or organize specific DNS resolver deployments, the RIPE community has decided that it is best able to provide advice and guidance. The RIPE Community is well positioned to provide a set of Best Current Practices that operators of Open DNS Resolvers will be encouraged to subscribe to.
-- dns-resolver-tf mailing list dns-resolver-tf@ripe.net https://lists.ripe.net/mailman/listinfo/dns-resolver-tf
Tim, On 24/03/2024 20.00, Tim Wicinski wrote:
Some more and apologies as I was thinking the updates were in the git repo which was what confused me.
  ### TTL Recommendations
  Software typically defaults to a maximum stored TTL of 1 or 2 days.   A lower TTL will mean removing rarely-used records that have long TTL,   and should not have much operational impact from a CPU or network   point of view
Where did this 1 or 2 days come from? From most s/w I've seen the default max-cache-ttl is a few hours.
For defaults... It came from a vague memory of mine from a DNS OARC presentation in the mists of history. I recall some presentation where someone measured this and found that most cache entries disappeared after 1 day, and everything else except for a rounding error after 2 days. Neither DuckDuckGo nor Qwant seem to be able to help me find said presentation, so it might be a LLM-style hallucination in my brain. I did check defaults from various open source resolvers: BIND uses 1 week: https://bind9.readthedocs.io/en/stable/reference.html#namedconf-statement-ma... Unbound uses 1 day: https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html Knot Resolver uses 1 day: https://knot-resolver.readthedocs.io/en/stable/daemon-bindings-cache.html#ca... PowerDNS Recursor uses 1 day: https://doc.powerdns.com/recursor/settings.html#max-cache-ttl Cheers, -- Shane
Thanks Shane Before I wrote that I went and dug around looking for examples....and looking at your link I know what I did. I was reading the max-ncache-ttl setting. DOH and double DOH. I am chastised and thanks! tim On Fri, Mar 29, 2024 at 4:09â¯PM Shane Kerr <shane@time-travellers.org> wrote:
Tim,
On 24/03/2024 20.00, Tim Wicinski wrote:
Some more and apologies as I was thinking the updates were in the git repo which was what confused me.
### TTL Recommendations
Software typically defaults to a maximum stored TTL of 1 or 2 days. A lower TTL will mean removing rarely-used records that have long TTL, and should not have much operational impact from a CPU or network point of view
Where did this 1 or 2 days come from? From most s/w I've seen the default max-cache-ttl is a few hours.
For defaults...
It came from a vague memory of mine from a DNS OARC presentation in the mists of history. I recall some presentation where someone measured this and found that most cache entries disappeared after 1 day, and everything else except for a rounding error after 2 days. Neither DuckDuckGo nor Qwant seem to be able to help me find said presentation, so it might be a LLM-style hallucination in my brain.
I did check defaults from various open source resolvers:
BIND uses 1 week:
https://bind9.readthedocs.io/en/stable/reference.html#namedconf-statement-ma...
Unbound uses 1 day:
https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html
Knot Resolver uses 1 day:
https://knot-resolver.readthedocs.io/en/stable/daemon-bindings-cache.html#ca...
PowerDNS Recursor uses 1 day:
https://doc.powerdns.com/recursor/settings.html#max-cache-ttl
Cheers,
-- Shane
hi Shane, On Sun Mar 24, 2024 at 17:25 CET, Shane Kerr wrote:
Thank you for your suggestions, edits, and discussion. I've updated the final draft to give us a final, final draft. ð
I've included the last (?) version at the bottom of this e-mail, and responded to your suggestions inline below.
Thanks, including for your perseverance when Spamhaus ate your homework ;-) Only one comment; in regards to this change:
2. its framework on a Recursive operator Privacy Statement, by publishing a privacy statement on their website covers all topics in Section 6. (See for example [Cloudflare's statement](https://developers.cloudflare.com/1.1.1.1/privacy/public-dns-resolver) or [Quad9's privacy page](https://www.quad9.net/service/privacy/).)
By citing examples in this context, a reader may infer that they meet this recommendation (ie. cover all topics in Section 6), which may or may not be true now and in the future. Checking now: Quad9's current privacy policy explicitly states it intends to meet or exceed the RFC, which makes it a good example at present. Cloudflare's does not. kind regards, Maarten
participants (5)
-
farzaneh badii -
Maarten Aertsen -
Mirjam Kuehne -
Shane Kerr -
Tim Wicinski