<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">A while ago we created a KB article with tips on how to improve your performance with our Kea dhcp server. The tips were fairly obvious to our developers and this was pretty successful. We would like to do something similar for BIND, provide a dozen or so tips for how to maximize your throughput with BIND. However, as usual, everything is more complicated with BIND.<div class=""><br class=""></div><div class="">Can those of you who care about performance, who have worked to improve your performance, share some of your suggestions that have the most impact?  Please also comment if you think any of these ideas below are stupid or dangerous. I have combined advice for resolvers and for authoritative servers, I hope it is clear which is which...<br class=""><div class=""><br class=""></div><div class="">The ideas we have fall into four general categories:</div><div class=""><br class=""></div><div class="">System design</div><div class=""><span id="docs-internal-guid-8bd01d59-7fff-de6c-6b62-d43b75bc5624" class=""><span style="font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; vertical-align: baseline; white-space: pre-wrap;" class="">1a) Use a load balancer</span><span style="font-style: italic; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; vertical-align: baseline; white-space: pre-wrap;" class=""> </span><span style="font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; vertical-align: baseline; white-space: pre-wrap;" class="">to specialize your resolvers and maximize your cache hit ratio.  A load balancer is traditionally designed to spread the traffic out evenly among a pool of servers, but it can also be used to concentrate related queries on one server to make its cache as hot as possible. For example, if all queries for domains in .info are sent to one server in a pool, there is a better chance that an answer will be in the cache there.</span></span></div><div class=""><br class=""></div><div class=""><span id="docs-internal-guid-a7429f5d-7fff-21f2-d35c-7c59e291531b" class=""><span style="font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; vertical-align: baseline; white-space: pre-wrap;" class="">1b) If you have a large authoritative system with many servers, consider dedicating some machines to propagate transfers. These machines, called transfer servers, would not answer client queries, but just send notifies and process IXFR requests.</span></span></div><div class=""><span class=""><span style="font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; vertical-align: baseline; white-space: pre-wrap;" class=""><br class=""></span></span></div><div class=""><span class=""><span style="font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; vertical-align: baseline; white-space: pre-wrap;" class="">1c) Deploy </span></span><span style="white-space: pre-wrap;" class="">ghost secondaries.  If you store copies of authoritative zones on resolvers (resolvers as undelegated secondaries), you can avoid querying those authoritative zones. The most obvious uses of this would be mirroring the root zone locally or mirroring your own authoritative zones on your resolver.</span></div><div class=""><br class=""></div><div class="">we have other system design ideas that we suspect would help, but we are not sure, so I will wait to see if anyone suggests them.</div><div class=""><br class=""></div><div class=""><span class=""><span style="font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; vertical-align: baseline; white-space: pre-wrap;" class="">OS settings and the system environment</span></span></div><div class="">2a) Run on bare metal if possible, not on virtual machines or in the cloud. (any idea how much difference this makes? the only reference we can cite is pretty out of date - <span style="white-space: pre-wrap;" class=""><a href="https://indico.dns-oarc.net/event/19/contributions/234/attachments/217/411/DNS_perf_OARC_Apr_14.pdf" class="">https://indico.dns-oarc.net/event/19/contributions/234/attachments/217/411/DNS_perf_OARC_Apr_14.pdf</a> )</span></div><div class=""><br class=""></div><div class="">2b) Consider using with-tuning-large. (<span style="white-space: pre-wrap;" class=""><a href="https://kb.isc.org/docs/aa-01314" class="">https://kb.isc.org/docs/aa-01314</a>) </span>This is a compile time option, so not something you can switch on and off during production. </div><div class=""><br class=""></div><div class="">2c) Consider which <span style="font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; vertical-align: baseline; white-space: pre-wrap;" class="">R/W lock choice you want to use - </span><span style="text-decoration: underline; color: rgb(17, 85, 204); font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; text-decoration-skip: none; vertical-align: baseline; white-space: pre-wrap;" class=""><a href="https://kb.isc.org/docs/choosing-a-read-write-lock-implementation-to-use-with-named" class="">https://kb.isc.org/docs/choosing-a-read-write-lock-implementation-to-use-with-named</a> </span><span style="caret-color: rgb(34, 34, 34); color: rgb(34, 34, 34);" class="">For the highest tested query rates (> 100,000 queries per second), pthreads read-write locks with hyper-threading </span><em style="caret-color: rgb(34, 34, 34); color: rgb(34, 34, 34); box-sizing: border-box;" class="">enabled</em><span style="caret-color: rgb(34, 34, 34); color: rgb(34, 34, 34);" class=""> </span><span style="caret-color: rgb(34, 34, 34); color: rgb(34, 34, 34);" class="">seem to be the best-performing choice by far.</span></div><div class=""><span style="caret-color: rgb(34, 34, 34); color: rgb(34, 34, 34);" class=""><br class=""></span></div><div class=""><span style="caret-color: rgb(34, 34, 34); color: rgb(34, 34, 34);" class="">2d) Pay attention to your choice of NIC cards. We have found wide variations in their performance. (Can anyone suggest what specifically to look for?)</span></div><div class=""><span style="caret-color: rgb(34, 34, 34); color: rgb(34, 34, 34);" class=""><br class=""></span></div><div class=""><span style="caret-color: rgb(34, 34, 34); color: rgb(34, 34, 34);" class="">2e) Make sure your socket send buffers are big enough. (not sure if this is obsolete advice, do we need to tell people how to tell if their buffers are causing delays?)</span></div><div class=""><br class=""></div><div class="">2f) <span id="docs-internal-guid-8d50db57-7fff-f45a-7f4d-9bbec5aebc28" class=""><span style="font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; vertical-align: baseline; white-space: pre-wrap;" class="">When the number of CPUs is very large (32 or more), the increase in UDP listeners may not provide any performance improvement and might actually reduce throughput slightly due to the overhead of the additional structures and tasks. We suggest trying different values of -U to find the optimal one for your production environment.</span></span></div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap;" class="">named Features</span></div><div class=""><span style="white-space: pre-wrap;" class="">3a) Minimize logging. Query logging is expensive (can cost you 20% or more of your throughput) so don’t do it unless you are using the logs for something. Logging with dnstap is lower impact, but still fairly expensive.  </span><span style="white-space: pre-wrap;" class="">Don’t run in debug mode unless necessary. </span></div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap;" class="">3b) </span><span style="color: rgb(34, 34, 34); white-space: pre-wrap;" class="">Use named.conf option minimal-responses yes; to reduce the amount of work that named needs to do to assemble the query response as well as reducing the amount of outbound traffic</span></div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap;" class="">3c) </span><span style="white-space: pre-wrap;" class="">Disable synth-from-dnssec. While this seemed like a good idea, it turns out, in practice it does not improve performance.</span></div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap;" class="">3d) Tune your zone transfers. </span><span style="white-space: pre-wrap;" class=""> (</span><a href="https://kb.isc.org/docs/aa-00726" style="white-space: pre-wrap;" class="">https://kb.isc.org/docs/aa-00726</a><span style="white-space: pre-wrap;" class="">)</span></div><div class=""><p style="box-sizing: border-box; margin: 0px 0px 1rem; padding: 0px; caret-color: rgb(34, 34, 34); color: rgb(34, 34, 34);" class="">When tuning the behavior of the primary, there are several factors that you can control:</p><p style="box-sizing: border-box; margin: 0px 0px 1rem; padding: 0px; caret-color: rgb(34, 34, 34); color: rgb(34, 34, 34);" class="">- The rate of notifications of changes to secondary servers (serial-query-rate and notify-delay)</p><p style="box-sizing: border-box; margin: 0px 0px 1rem; padding: 0px; caret-color: rgb(34, 34, 34); color: rgb(34, 34, 34);" class="">- Limits on concurrent zone transfers (transfers-out, tcp-clients, tcp-listen-queue, reserved-sockets)</p><p style="box-sizing: border-box; margin: 0px 0px 1rem; padding: 0px; caret-color: rgb(34, 34, 34); color: rgb(34, 34, 34);" class="">- Efficiency/management options (max-transfer-time-out, max-transfer-idle-out, transfer-format)</p><p style="box-sizing: border-box; margin: 0px 0px 1rem; padding: 0px; caret-color: rgb(34, 34, 34); color: rgb(34, 34, 34);" class="">The most important options to focus on are transfers-out, serial-query-rate, tcp-clients and tcp-listen-queue.</p></div><div class="">4e) If you use RPZ, consider using qnane-wait-recurse. We have had issues with RPZ transfers impacting query performance in resolvers. In general, more smaller RPZ zones will transfer faster than a few very large RPZ zones. </div><div class=""><br class=""></div><div class="">4f) Consider enabling prefetch on your resolver, unless you are running 9.10 (which is EOL) <a href="https://kb.isc.org/docs/aa-01122" class="">https://kb.isc.org/docs/aa-01122</a></div><div class=""><br class=""></div><div class=""><span style="white-space: pre-wrap;" class="">Fix your transport network. </span></div><div class=""><span style="white-space: pre-wrap;" class="">Transport network issues cause BIND to keep retrying, which is a performance drain.</span></div><div class=""><span id="docs-internal-guid-86e034a7-7fff-6820-9bb1-bcad17499827" class=""><span style="color: rgb(34, 34, 34); font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; vertical-align: baseline; white-space: pre-wrap;" class="">4a) Disable (in some cases, completely remove in order to prevent ongoing interference) outbound firewalls/packet-filters (particularly that maintain state on connections). These are a frequent cause of problems in the DNS that can cause your DNS server to do a lot of extra work. </span></span></div><div class=""><span class=""><span style="color: rgb(34, 34, 34); font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; vertical-align: baseline; white-space: pre-wrap;" class=""><br class=""></span></span></div><div class=""><span id="docs-internal-guid-a2400cb3-7fff-8adf-a4da-1d499f82fd2f" class=""><span style="color: rgb(34, 34, 34); font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; vertical-align: baseline; white-space: pre-wrap;" class="">4b) Set an appropriate MTU for your network. Ensure that your network infrastructure supports EDNS and large UDP responses up to 4096. </span></span><span style="color: rgb(34, 34, 34); white-space: pre-wrap;" class="">Ensure that your network infrastructure allows transit for and reassembly of fragmented UDP packets (these will be large query responses if you are DNSSEC signing)</span></div><div class=""><span style="color: rgb(34, 34, 34); white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><span style="color: rgb(34, 34, 34); white-space: pre-wrap;" class="">4c) </span><span style="color: rgb(34, 34, 34); white-space: pre-wrap;" class="">Ensure that your network infrastructure allows DNS over TCP.</span></div><div class=""><span style="color: rgb(34, 34, 34); white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><span style="color: rgb(34, 34, 34); white-space: pre-wrap;" class="">4d) </span><span style="color: rgb(34, 34, 34); font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; vertical-align: baseline; white-space: pre-wrap;" class="">Check for, and eliminate any incomplete IPv6 interface set-up (what can go wrong here is that BIND </span><span style="color: rgb(34, 34, 34); font-style: italic; font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; vertical-align: baseline; white-space: pre-wrap;" class="">thinks</span><span style="color: rgb(34, 34, 34); font-variant-ligatures: normal; font-variant-east-asian: normal; font-variant-position: normal; vertical-align: baseline; white-space: pre-wrap;" class=""> that it can use IPv6 authoritative servers, but actually the sends silently fail, leaving named waiting unnecessarily for responses)</span></div><div class=""><div class=""><br class=""></div></div><div class=""><span style="white-space: pre-wrap;" class="">Any further suggestions, corrections or warnings are very welcome. </span></div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap;" class="">Thank you!</span></div><div class=""><span style="white-space: pre-wrap;" class="">Vicky</span></div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap;" class="">---------</span></div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span><div class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Victoria Risk</div><div class="">Product Manager</div><div class="">Internet Systems Consortium</div><div class=""><a href="mailto:vicky@isc.org" class="">vicky@isc.org</a></div><div class=""><br class=""></div></div><br class="Apple-interchange-newline"></div><br class="Apple-interchange-newline"><br class="Apple-interchange-newline">
</div>
<br class=""></div></div></body></html>