{"id":13750,"date":"2025-12-16T15:07:13","date_gmt":"2025-12-16T09:37:13","guid":{"rendered":"https:\/\/www.youstable.com\/blog\/?p=13750"},"modified":"2025-12-24T16:13:51","modified_gmt":"2025-12-24T10:43:51","slug":"optimize-dns-on-linux","status":"publish","type":"post","link":"https:\/\/www.youstable.com\/blog\/optimize-dns-on-linux","title":{"rendered":"How to Optimize DNS on Linux Server"},"content":{"rendered":"\n<p>To optimize DNS on Linux server, reduce lookup latency and increase reliability by using a local caching resolver, tightening \/etc\/resolv.conf timeouts, tuning your resolver (Unbound, dnsmasq, or BIND), enabling DNSSEC and QNAME minimization, right-sizing kernel buffers, and benchmarking with dig or dnsperf. This cuts round trips, prevents timeouts, and hardens security.<\/p>\n\n\n\n<p>If your Linux apps feel \u201cslow\u201d on first connections, DNS is often the bottleneck. In this guide, I\u2019ll show you how to optimize DNS on a Linux server step-by-step\u2014covering caching, resolver selection, Unbound\/dnsmasq\/BIND tuning, network and security best practices, and performance testing\u2014so queries resolve faster and more reliably.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"what-dns-optimization-means-and-why-it-matters\"><strong>What DNS Optimization Means (and Why It Matters)<\/strong><\/h2>\n\n\n\n<p>DNS <a href=\"https:\/\/www.youstable.com\/blog\/optimize-lets-encrypt-on-linux\/\">optimization on a Linux server<\/a> means reducing query latency, increasing cache efficiency, and improving reliability and security of lookups. Done right, it speeds up web apps, APIs, <a href=\"https:\/\/www.youstable.com\/blog\/install-cron-jobs-on-linux\/\">cron jobs<\/a>, and package managers, while lowering outbound traffic and protecting you from DNS-based outages.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"know-your-dns-role-resolver-vs-authoritative-vs-client\"><strong>Know Your DNS Role: Resolver vs Authoritative vs Client<\/strong><\/h2>\n\n\n\n<p>Before you tweak anything, identify how your server uses DNS. The right strategy depends on your role.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"client-only-servers-most-web-app-nodes\"><strong>Client-only servers (most web\/app nodes)<\/strong><\/h3>\n\n\n\n<p>These servers mainly resolve external hostnames. Use a <em>local caching stub<\/em> (systemd-resolved or dnsmasq) forwarding to fast upstream resolvers (e.g., Cloudflare, Google, Quad9) or your organization\u2019s resolvers. Keep caching on-box to minimize round trips.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"recursive-resolvers-internal-dns-for-many-clients\"><strong>Recursive resolvers (internal DNS for many clients)<\/strong><\/h3>\n\n\n\n<p>Run a full resolver like <strong>Unbound<\/strong> or <strong>BIND (named)<\/strong>. Focus on cache size, threading, EDNS buffer size, rate limiting, and access controls to avoid \u201copen resolver\u201d abuse.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"authoritative-dns-serving-your-domains\"><strong>Authoritative DNS (serving your domains)<\/strong><\/h3>\n\n\n\n<p>Priorities: minimal responses, proper TCP handling, serve-stale, RRL (Response Rate Limiting), and correct zone hygiene. Consider offloading to a managed Anycast DNS provider for global performance.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"quick-checklist-to-optimize-dns-on-linux\"><strong>Quick Checklist to Optimize DNS on Linux<\/strong><\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use a local caching resolver to reduce external lookups.<\/li>\n\n\n\n<li>Point to low-latency, reliable upstream DNS (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9) or your corporate resolvers.<\/li>\n\n\n\n<li>Tune \/etc\/resolv.conf timeouts, attempts, rotate, and edns0.<\/li>\n\n\n\n<li>Right-size Unbound\/dnsmasq\/BIND threads, cache, EDNS buffer (1232 bytes), and connection limits.<\/li>\n\n\n\n<li>Enable DNSSEC validation and QNAME minimization; prevent open recursion.<\/li>\n\n\n\n<li>Tune kernel socket buffers and file descriptors for busy resolvers.<\/li>\n\n\n\n<li>Benchmark with dig and dnsperf; monitor cache hit-ratio.<\/li>\n\n\n\n<li>Fix common issues: IPv6 path MTU, firewall blocking UDP\/TCP 53, broken upstreams.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"step-1-audit-your-current-dns-path\"><strong>Step 1: Audit Your Current DNS Path<\/strong><\/h2>\n\n\n\n<p>First, learn which resolver you\u2019re using, how fast it responds, and whether you already have caching.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Check systemd-resolved (if present)\nresolvectl status\n\n# Inspect \/etc\/resolv.conf\ncat \/etc\/resolv.conf\n\n# Quick latency + caching test\ndig +stats youstable.com\ndig +stats youstable.com  # Run twice; second should be faster if caching works\n\n# Test alternate resolvers directly\ndig @1.1.1.1 google.com +time=1 +tries=1\ndig @8.8.8.8 google.com +time=1 +tries=1<\/code><\/pre>\n\n\n\n<p>If \/etc\/resolv.conf points to 127.0.0.53, systemd-resolved is your stub. If it lists public IPs, you\u2019re querying upstream resolvers directly without local caching.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"step-2-choose-a-dns-strategy\"><strong>Step 2: Choose a DNS Strategy<\/strong><\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"option-a-fast-external-resolvers-simplest\"><strong>Option A: Fast external resolvers (simplest)<\/strong><\/h3>\n\n\n\n<p>If you don\u2019t want to run a <a href=\"https:\/\/www.youstable.com\/blog\/tally-on-cloud-vs-local-installation\/\">local service,<\/a> point resolv.conf to nearby Anycast resolvers. It\u2019s simple but lacks on-box caching and TLS unless your stub supports it.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/resolv.conf (example)\nnameserver 1.1.1.1\nnameserver 8.8.8.8\noptions timeout:1 attempts:2 rotate edns0 trust-ad<\/code><\/pre>\n\n\n\n<p>The options lower timeouts, try alternates, enable EDNS0, and honor DNSSEC AD flags from upstream.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"option-b-local-caching-with-systemd-resolved-or-dnsmasq\"><strong>Option B: Local caching with systemd-resolved or dnsmasq<\/strong><\/h3>\n\n\n\n<p>systemd-resolved provides a lightweight cache and can use DNS over TLS. dnsmasq adds flexible forwarding and larger cache options.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># systemd-resolved example: \/etc\/systemd\/resolved.conf\n&#91;Resolve]\nDNS=1.1.1.1 9.9.9.9\nFallbackDNS=8.8.8.8\nDNSOverTLS=yes\nCache=yes\n# Optional: restrict LLMNR\/mDNS if not needed\nLLMNR=no\nMulticastDNS=no\n\n# Activate and link resolv.conf\nsudo systemctl enable --now systemd-resolved\nsudo ln -sf \/run\/systemd\/resolve\/stub-resolv.conf \/etc\/resolv.conf<\/code><\/pre>\n\n\n\n<pre class=\"wp-block-code\"><code># dnsmasq example: \/etc\/dnsmasq.d\/local.conf\nno-resolv\nserver=1.1.1.1\nserver=9.9.9.9\ncache-size=10000\ndns-forward-max=300\nneg-ttl=60\nmin-cache-ttl=300\n# Optional DNSSEC validation (requires trust-anchors)\ndnssec\ntrust-anchor=.,19036,8,2,49AAC11D7B6F644D...\ntrust-anchor=.,20326,8,2,E06D44B80B8F1D21...\n# Listen on loopback for local clients\nlisten-address=127.0.0.1\nbind-interfaces\n\nsudo systemctl enable --now dnsmasq\n# Point resolv.conf to dnsmasq\necho -e \"nameserver 127.0.0.1\\noptions timeout:1 attempts:2 rotate edns0 trust-ad\" | sudo tee \/etc\/resolv.conf<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"option-c-full-recursive-resolver-with-unbound-best-balance\"><strong>Option C: Full recursive resolver with Unbound (best balance)<\/strong><\/h3>\n\n\n\n<p>Unbound is fast, secure, and ideal for busy servers or internal DNS. It supports DNSSEC, QNAME minimization, prefetching, and DNS over TLS.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/unbound\/unbound.conf (basic, secure, performant)\nserver:\n  username: \"unbound\"\n  interface: 0.0.0.0\n  interface: ::0\n  access-control: 127.0.0.0\/8 allow\n  access-control: ::1 allow\n  # Restrict LAN as needed; deny others to prevent open recursion\n  # access-control: 10.0.0.0\/8 allow\n\n  num-threads: 2\n  so-reuseport: yes\n  cache-min-ttl: 60\n  cache-max-ttl: 86400\n  prefetch: yes\n  prefetch-key: yes\n  qname-minimisation: yes\n  harden-algo-downgrade: yes\n  harden-below-nxdomain: yes\n  hide-identity: yes\n  hide-version: yes\n\n  # Avoid IP fragmentation issues (good for IPv6)\n  edns-buffer-size: 1232\n\n  # Serve stale answers during outages\n  serve-expired: yes\n  serve-expired-ttl: 86400\n\n  # TLS root anchors usually shipped by the distro\n  auto-trust-anchor-file: \"\/var\/lib\/unbound\/root.key\"\n\n# Example upstream forwarding over TLS (optional)\nforward-zone:\n  name: \".\"\n  forward-tls-upstream: yes\n  forward-addr: 1.1.1.1@853#cloudflare-dns.com\n  forward-addr: 9.9.9.9@853#dns.quad9.net\n\nsudo systemctl enable --now unbound\necho -e \"nameserver 127.0.0.1\\noptions timeout:1 attempts:2 rotate edns0 trust-ad\" | sudo tee \/etc\/resolv.conf<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"step-3-tune-resolver-and-client-settings\"><strong>Step 3: Tune Resolver and Client Settings<\/strong><\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"tune-etc-resolv-conf\"><strong>Tune \/etc\/resolv.conf<\/strong><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/resolv.conf recommended options\noptions timeout:1 attempts:2 rotate edns0 trust-ad<\/code><\/pre>\n\n\n\n<p>Timeout 1s avoids long hangs on bad networks; attempts 2 retries with the next nameserver. Rotate balances requests. edns0 enables modern features. trust-ad preserves DNSSEC validation info from upstream.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"tune-dnsmasq\"><strong>Tune dnsmasq<\/strong><\/h3>\n\n\n\n<p>Increase <em>cache-size<\/em> for busy hosts, <a href=\"https:\/\/www.youstable.com\/blog\/monitor-secure-dns-on-linux\/\">set <em>dns-forward-max<\/em><\/a> for concurrency, and define <em>min-cache-ttl<\/em> to keep hot names longer. If DNSSEC is enabled, ensure valid trust anchors and correct time (NTP).<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"tune-unbound\"><strong>Tune Unbound<\/strong><\/h3>\n\n\n\n<p>Increase <em>num-threads<\/em> to match CPU cores, enable <em>so-reuseport<\/em> for multi-queue sockets, keep <em>edns-buffer-size<\/em> at 1232 to reduce fragmentation, and use <em>prefetch<\/em> to refresh popular records proactively. Monitor and raise cache <em>msg-cache-size<\/em> and <em>rrset-cache-size<\/em> if you see evictions.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"tune-bind-recursive-or-authoritative\"><strong>Tune BIND (recursive or authoritative)<\/strong><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/bind\/named.conf.options (illustrative)\noptions {\n  recursion yes;\n  allow-recursion { 127.0.0.1; 10.0.0.0\/8; }; \/\/ restrict!\n  minimal-responses yes;\n  edns-udp-size 1232;\n  max-udp-size 1232;\n\n  tcp-clients 200;\n  clients-per-query 100;\n  recursive-clients 10000;\n\n  \/\/ Serve stale during upstream issues (newer BIND)\n  serve-stale yes;\n  max-stale-ttl 86400;\n\n  \/\/ DNSSEC validation\n  dnssec-validation auto;\n  auth-nxdomain no;\n};\n\n\/\/ Response Rate Limiting (authoritative)\nrate-limit {\n  responses-per-second 20;\n  window 5;\n  slip 2;\n};<\/code><\/pre>\n\n\n\n<p>Never expose recursion to the Internet. Whitelist only your hosts or subnets. For authoritative-only nodes, disable recursion entirely.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"step-4-kernel-and-system-tuning-for-high-qps\"><strong>Step 4: Kernel and System Tuning for High QPS<\/strong><\/h2>\n\n\n\n<p>Busy recursive or authoritative resolvers benefit from larger socket buffers and more file descriptors. Apply conservative, safe defaults first and adjust based on monitoring.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/sysctl.d\/99-dns.conf\nnet.core.rmem_max=4194304\nnet.core.wmem_max=4194304\nnet.core.netdev_max_backlog=4096\nnet.ipv4.udp_rmem_min=131072\nnet.ipv4.udp_wmem_min=131072\n\n# Apply\nsudo sysctl --system\n\n# Increase process file descriptors (example)\necho \"* soft nofile 65536\" | sudo tee -a \/etc\/security\/limits.conf\necho \"* hard nofile 65536\" | sudo tee -a \/etc\/security\/limits.conf<\/code><\/pre>\n\n\n\n<p>Also ensure NTP is enabled\u2014DNSSEC validation fails with incorrect time. Keep your resolver and root hints up to date.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"step-5-security-hardening\"><strong>Step 5: Security Hardening<\/strong><\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Prevent open resolvers: restrict <em>allow-recursion<\/em> (BIND) or <em>access-control<\/em> (Unbound).<\/li>\n\n\n\n<li>Enable DNSSEC validation and QNAME minimization to reduce data leakage and protect integrity.<\/li>\n\n\n\n<li>Use DNS over TLS for upstream privacy when possible (systemd-resolved, Unbound forward-tls-upstream).<\/li>\n\n\n\n<li>Enable RRL (BIND) or rate limits to prevent abuse in authoritative mode.<\/li>\n\n\n\n<li>Firewall UDP\/TCP 53 to intended subnets; allow TCP 53 for large responses and fallback.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"step-6-test-benchmark-and-monitor\"><strong>Step 6: Test, Benchmark, and Monitor<\/strong><\/h2>\n\n\n\n<p>Validate improvements and watch cache efficiency. Aim for high cache hit-rates and low median\/95th percentile latency.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Latency and cache behavior\ndig github.com +stats\ndig github.com +stats\n\n# Trace a problematic name\ndig +trace example.com\n\n# systemd-resolved stats\nresolvectl statistics\n\n# Unbound stats\nunbound-control stats\n\n# BIND statistics (enable and query via rndc or exporter)\nrndc stats<\/code><\/pre>\n\n\n\n<p>For load testing, use <em>dnsperf<\/em> or <em>kdig<\/em> from the Knot DNS tools. Export metrics to Prometheus with <em>unbound_exporter<\/em> or <em>bind_exporter<\/em> to track QPS, cache hits, and failures over time.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"troubleshooting-slow-or-flaky-dns\"><strong>Troubleshooting Slow or Flaky DNS<\/strong><\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>High latency on first query:<\/strong> Add a local cache (dnsmasq or Unbound), reduce <em>timeout<\/em> in resolv.conf, ensure upstreams are geographically close.<\/li>\n\n\n\n<li><strong>Intermittent timeouts:<\/strong> Allow TCP 53; set EDNS buffer to 1232; check firewalls and MTU\/fragmentation.<\/li>\n\n\n\n<li><strong>IPv6 issues:<\/strong> If IPv6 is misconfigured, prefer IPv4 or fix v6 routing. Test with <code>dig -6<\/code> and <code>dig -4<\/code>.<\/li>\n\n\n\n<li><strong>DNSSEC failures:<\/strong> Ensure correct system time and updated trust anchors.<\/li>\n\n\n\n<li><strong>Open resolver risk:<\/strong> Verify recursion is limited to loopback\/LAN only. Scan from the Internet to confirm.<\/li>\n\n\n\n<li><strong>Slow NSS resolution:<\/strong> Check <code>\/etc\/nsswitch.conf<\/code> and place <em>files<\/em> and <em>dns<\/em> before mDNS. Disable mDNS if unused.<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/nsswitch.conf (common minimal)\nhosts: files dns myhostname<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"when-to-use-managed-dns-and-hosting\"><strong>When to Use Managed DNS and Hosting<\/strong><\/h2>\n\n\n\n<p>If you run customer-facing apps or expect high DNS QPS, consider managed DNS and managed servers. At YouStable, our managed VPS and dedicated hosting come with production-ready DNS tuning (Unbound with secure defaults, DoT-capable upstreams, monitoring, and firewall hardening), so your team ships features instead of babysitting resolvers.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"faqs-optimizing-dns-on-linux-server\"><strong>FAQs: Optimizing DNS on Linux Server<\/strong><\/h2>\n\n\n\t\t<section\t\thelp class=\"sc_fs_faq sc_card    \"\n\t\t\t\t>\n\t\t\t\t<h3 id=\"whats-the-fastest-way-to-optimize-dns-on-a-single-linux-server\">What\u2019s the fastest way to optimize DNS on a single Linux server?<\/h3>\t\t\t\t<div>\n\t\t\t\t\t\t<div class=\"sc_fs_faq__content\">\n\t\t\t\t\n\n<p>Install a local caching resolver (systemd-resolved, dnsmasq, or Unbound), point \/etc\/resolv.conf to 127.0.0.1, set timeout:1 attempts:2 rotate, choose low-latency upstreams, and test with dig. This alone can cut average lookup times by 30\u201370% for typical workloads.<\/p>\n\n\t\t\t<\/div>\n\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<section\t\thelp class=\"sc_fs_faq sc_card    \"\n\t\t\t\t>\n\t\t\t\t<h3 id=\"should-i-use-unbound-or-dnsmasq-for-caching\">Should I use Unbound or dnsmasq for caching?<\/h3>\t\t\t\t<div>\n\t\t\t\t\t\t<div class=\"sc_fs_faq__content\">\n\t\t\t\t\n\n<p>For lightweight caching and forwarding, dnsmasq is simple and efficient. For full recursion, DNSSEC validation, QNAME minimization, prefetch, and DoT upstreams with more control, Unbound is the better choice. Many teams start with dnsmasq, then graduate to Unbound as scale grows.<\/p>\n\n\t\t\t<\/div>\n\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<section\t\thelp class=\"sc_fs_faq sc_card    \"\n\t\t\t\t>\n\t\t\t\t<h3 id=\"how-do-i-flush-dns-cache-on-linux\">How do I flush DNS cache on Linux?<\/h3>\t\t\t\t<div>\n\t\t\t\t\t\t<div class=\"sc_fs_faq__content\">\n\t\t\t\t\n\n<p>systemd-resolved: <code>resolvectl flush-caches<\/code>. Unbound: <code>unbound-control flush_zone .<\/code> or restart <code>unbound<\/code>. dnsmasq: <code>sudo killall -HUP dnsmasq<\/code>. BIND: <code>rndc flush<\/code> or <code>rndc flushname &lt;name><\/code>.<\/p>\n\n\t\t\t<\/div>\n\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<section\t\thelp class=\"sc_fs_faq sc_card    \"\n\t\t\t\t>\n\t\t\t\t<h3 id=\"is-dns-over-tls-worth-enabling-on-servers\">Is DNS over TLS worth enabling on servers?<\/h3>\t\t\t\t<div>\n\t\t\t\t\t\t<div class=\"sc_fs_faq__content\">\n\t\t\t\t\n\n<p>Yes, when privacy is required or networks are untrusted. DoT prevents passive snooping of queries. The overhead is minimal with modern CPUs. Enable it in systemd-resolved or Unbound when upstream providers support DoT (e.g., Cloudflare, Quad9, Google).<\/p>\n\n\t\t\t<\/div>\n\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<section\t\thelp class=\"sc_fs_faq sc_card    \"\n\t\t\t\t>\n\t\t\t\t<h3 id=\"how-do-i-pick-the-best-upstream-dns-for-low-latency\">How do I pick the best upstream DNS for low latency?<\/h3>\t\t\t\t<div>\n\t\t\t\t\t\t<div class=\"sc_fs_faq__content\">\n\t\t\t\t\n\n<p>Test Anycast providers from your server\u2019s region with <code>dig @resolver-ip example.com +stats +time=1<\/code>. Compare Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9), and your ISP\/corporate resolvers. Choose the lowest median and 95th percentile latency with solid reliability.<\/p>\n\n\n\n<p>By applying these practices, you\u2019ll optimize DNS on your Linux server for speed, stability, and security\u2014backed by caching, smart timeouts, right-sized buffers, and modern resolver features. If you\u2019d like it done-for-you, YouStable\u2019s <a href=\"https:\/\/www.youstable.com\/blog\/benefits-of-web-hosting-control-panel-for-managed-hosting\/\">managed hosting<\/a> stacks ship with these optimizations baked in.<\/p>\n\n\t\t\t<\/div>\n\t\t<\/div>\n\t\t<\/section>\n\t\t\n<script type=\"application\/ld+json\">\n\t{\n\t\t\"@context\": \"https:\/\/schema.org\",\n\t\t\"@type\": \"FAQPage\",\n\t\t\"mainEntity\": [\n\t\t\t\t\t{\n\t\t\t\t\"@type\": \"Question\",\n\t\t\t\t\"name\": \"What\u2019s the fastest way to optimize DNS on a single Linux server?\",\n\t\t\t\t\"acceptedAnswer\": {\n\t\t\t\t\t\"@type\": \"Answer\",\n\t\t\t\t\t\"text\": \"<p>Install a local caching resolver (systemd-resolved, dnsmasq, or Unbound), point \/etc\/resolv.conf to 127.0.0.1, set timeout:1 attempts:2 rotate, choose low-latency upstreams, and test with dig. This alone can cut average lookup times by 30\u201370% for typical workloads.<\/p>\"\n\t\t\t\t\t\t\t\t\t}\n\t\t\t}\n\t\t\t,\t\t\t\t{\n\t\t\t\t\"@type\": \"Question\",\n\t\t\t\t\"name\": \"Should I use Unbound or dnsmasq for caching?\",\n\t\t\t\t\"acceptedAnswer\": {\n\t\t\t\t\t\"@type\": \"Answer\",\n\t\t\t\t\t\"text\": \"<p>For lightweight caching and forwarding, dnsmasq is simple and efficient. For full recursion, DNSSEC validation, QNAME minimization, prefetch, and DoT upstreams with more control, Unbound is the better choice. Many teams start with dnsmasq, then graduate to Unbound as scale grows.<\/p>\"\n\t\t\t\t\t\t\t\t\t}\n\t\t\t}\n\t\t\t,\t\t\t\t{\n\t\t\t\t\"@type\": \"Question\",\n\t\t\t\t\"name\": \"How do I flush DNS cache on Linux?\",\n\t\t\t\t\"acceptedAnswer\": {\n\t\t\t\t\t\"@type\": \"Answer\",\n\t\t\t\t\t\"text\": \"<p>systemd-resolved: resolvectl flush-caches. Unbound: unbound-control flush_zone . or restart unbound. dnsmasq: sudo killall -HUP dnsmasq. BIND: rndc flush or rndc flushname &lt;name>.<\/p>\"\n\t\t\t\t\t\t\t\t\t}\n\t\t\t}\n\t\t\t,\t\t\t\t{\n\t\t\t\t\"@type\": \"Question\",\n\t\t\t\t\"name\": \"Is DNS over TLS worth enabling on servers?\",\n\t\t\t\t\"acceptedAnswer\": {\n\t\t\t\t\t\"@type\": \"Answer\",\n\t\t\t\t\t\"text\": \"<p>Yes, when privacy is required or networks are untrusted. DoT prevents passive snooping of queries. The overhead is minimal with modern CPUs. Enable it in systemd-resolved or Unbound when upstream providers support DoT (e.g., Cloudflare, Quad9, Google).<\/p>\"\n\t\t\t\t\t\t\t\t\t}\n\t\t\t}\n\t\t\t,\t\t\t\t{\n\t\t\t\t\"@type\": \"Question\",\n\t\t\t\t\"name\": \"How do I pick the best upstream DNS for low latency?\",\n\t\t\t\t\"acceptedAnswer\": {\n\t\t\t\t\t\"@type\": \"Answer\",\n\t\t\t\t\t\"text\": \"<p>Test Anycast providers from your server\u2019s region with dig @resolver-ip example.com +stats +time=1. Compare Cloudflare (1.1.1.1), Google (8.8.8.8), Quad9 (9.9.9.9), and your ISP\/corporate resolvers. Choose the lowest median and 95th percentile latency with solid reliability.<\/p><p>By applying these practices, you\u2019ll optimize DNS on your Linux server for speed, stability, and security\u2014backed by caching, smart timeouts, right-sized buffers, and modern resolver features. If you\u2019d like it done-for-you, YouStable\u2019s <a>managed hosting<\/a> stacks ship with these optimizations baked in.<\/p>\"\n\t\t\t\t\t\t\t\t\t}\n\t\t\t}\n\t\t\t\t\t\t]\n\t}\n<\/script>\n","protected":false},"excerpt":{"rendered":"<p>To optimize DNS on Linux server, reduce lookup latency and increase reliability by using a local caching resolver, tightening \/etc\/resolv.conf [&hellip;]<\/p>\n","protected":false},"author":13,"featured_media":14071,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[350],"tags":[2170,2141,2169],"class_list":["post-13750","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-knowledgebase","tag-dns-on-linux","tag-linux-server","tag-optimize-dns-on-linux"],"acf":[],"featured_image_src":"https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2025\/12\/How-to-Optimize-DNS-on-Linux-Server.jpg","author_info":{"display_name":"Prahlad Prajapati","author_link":"https:\/\/www.youstable.com\/blog\/author\/prahladblog"},"_links":{"self":[{"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/posts\/13750","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/users\/13"}],"replies":[{"embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/comments?post=13750"}],"version-history":[{"count":2,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/posts\/13750\/revisions"}],"predecessor-version":[{"id":14129,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/posts\/13750\/revisions\/14129"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/media\/14071"}],"wp:attachment":[{"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/media?parent=13750"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/categories?post=13750"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/tags?post=13750"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}