Consulte nuestras guías de configuración y las preguntas frecuentes, o utilice el cuadro de búsqueda debajo para mayor información
You're administrating DNS for a building, office, business, ISP, etc, and you want to use Quad 9. Great choice!
Caching forwarders and their optimal configuration are critical when sending queries en masse to Quad9, and is highly preferred over direct assignment via DHCP to end users with regards to:
When setting Quad9 as the recursive resolver in your infrastructure and caching DNS forwarders, such as BIND, Windows DNS Server, Knot Resolver, dnsdist, Unbound, etc, please consider the following best practices.
For ISPs or organizations with more than 10,000 users behind a forwarding cache, please contact Quad9 Support with the details of your deployment, so that we can work together to ensure a smooth and successful deployment.
Since DNS forwarders use round-robin ordering when forwarding queries to a list of recursive DNS servers, Quad9 must be set as the exclusive recursive DNS servers in your forwarders. Adding additional, non-Quad9 recursive DNS servers will result in a percentage of your DNS queries not being protected by Quad9's threat blocking.
It is imperative that your DNS forwarders are configured to cache response data in order to avoid excessive recursive queries to Quad9 and to provide significantly faster DNS resolution for devices on the network.
Ensure that your DNS forwarders have enough memory or disk space allocated to the cache to avoid the cache filling up.
The amount of memory that should be dedicated to DNS caching varies greatly from megabytes to gigabytes based on the amount of DNS requests originating from your network endpoints.
In some cases, you can share a common cache between forwarders to further increase performance and increase the cache hit ratio.
dndsdist is a highly DNS-, DoS- and abuse-aware loadbalancer with impressive performance and is well suited as a caching and load balancing DNS forwarder.
Caching is disabled by default, but can be enabled for in-memory storage.
Allocated cache size is determined by the msg-cache-size and rrset-cache-size options in the unbound.conf file.
You can check the amount of memory that your cache is currently using to compare against the cache size you allocated in unbound.conf by using the unbound-control command to view stats for mem.cache.rrset and mem.cache.message values.
Unbound can also be configured to use Redis in order to share a common cache between multiple DNS forwarders. Refer to the Cache DB Module Options in the unbound.conf documentation.
Knot Resolver caches on disk by default, but can be configured to use memory/tmpfs, backends, and share cache between instances. Knot Resolver has excellent documentation about all things caching.
Bind caches in memory by default, so the only limitation is exhausting available memory in the system. To check the size of the current cache, you can dump the cache to a local file and then examine the file size, which will be approximately how much memory is being used by cache:
rndc dumpdb -all
ls -alh /var/bind/
In-memory caching can be configured using the Set-DnsServerCache cmd applet.
Memory usage can be checked using the Get-DnsServerStatistics cmd applet.
Configuring both the primary and secondary IP of your desired Quad9 service helps naturally load balance the DNS queries in the Quad9 infrastructure.
If your network is capable of IPv6, also configure the primary and secondary IPv6 addresses of your desired Quad9 service in your DNS forwarders, which helps naturally load balance the DNS queries in the Quad9 infrastructure.
If IPv6 is not in use, Quad9 strongly encourages you to investigate how to get it enabled on your network. IPv6 route paths are often faster compared to IPv4 paths, which leads to a higher chance of success at faster speeds with better redundancy.
Each DNS forwarder should, ideally, send and receive DNS queries to Quad9 using different public IPv4 and IPv6 addresses, even if the addresses are within the same subnet.