{"id":14353,"date":"2025-12-17T14:02:45","date_gmt":"2025-12-17T08:32:45","guid":{"rendered":"https:\/\/www.youstable.com\/blog\/?p=14353"},"modified":"2025-12-24T16:13:35","modified_gmt":"2025-12-24T10:43:35","slug":"how-to-monitor-secure-dns-on-linux-server","status":"publish","type":"post","link":"https:\/\/www.youstable.com\/blog\/how-to-monitor-secure-dns-on-linux-server","title":{"rendered":"How to Monitor &#038; Secure DNS on Linux Server"},"content":{"rendered":"\n<p>To monitor and secure DNS on a Linux server, continuously observe query volume, latency, response codes, and logs; export metrics to Prometheus\/Grafana; and harden your DNS service with patches, ACLs, DNSSEC, TSIG, RRL, and firewall rules. Combine logging (dnstap\/querylog) with IDS\/IPS, rate limiting, and least-privilege configuration to prevent abuse and detect incidents early.<\/p>\n\n\n\n<p>DNS is the phonebook of the internet, and when it fails or is abused, everything on your server feels down. In this guide, you\u2019ll learn exactly how to <a href=\"https:\/\/www.youstable.com\/blog\/how-to-monitor-secure-haproxy-on-linux\/\">monitor &amp; secure DNS on Linux server<\/a> using practical steps, proven configs for BIND and Unbound, defensive firewalling, and production-grade observability\u2014written for admins and site owners at any skill level.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"why-dns-security-and-monitoring-matter-on-linux\"><strong>Why DNS Security and Monitoring Matter on Linux<\/strong><\/h2>\n\n\n\n<p>DNS issues <a href=\"https:\/\/www.youstable.com\/blog\/fix-slow-wordpress-site\/\">cause slow sites<\/a>, broken email, and security incidents like cache poisoning or DDoS amplification. Attackers scan for open resolvers, misconfigured zone transfers, and weak recursion rules. Meanwhile, subtle anomalies\u2014spikes in NXDOMAINs, rising SERVFAILs, or unusual client IPs\u2014often preface an outage. Robust monitoring plus hardening ensures reliability, integrity, and fast recovery.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"quick-checklist-monitor-and-secure-dns-on-linux\"><strong>Quick Checklist: Monitor &amp; Secure DNS on Linux<\/strong><\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep DNS packages updated (BIND, Unbound, PowerDNS) and minimize modules.<\/li>\n\n\n\n<li>Enable detailed logging (querylog or dnstap) and centralize logs.<\/li>\n\n\n\n<li>Export metrics to Prometheus; visualize in Grafana with alerts.<\/li>\n\n\n\n<li>Restrict recursion and zone transfers with ACLs and TSIG.<\/li>\n\n\n\n<li>Turn on DNSSEC validation; sign authoritative zones where applicable.<\/li>\n\n\n\n<li>Apply Response Rate Limiting (RRL) and firewall rate limits.<\/li>\n\n\n\n<li>Run DNS under least privilege, chroot\/jail, with SELinux\/AppArmor.<\/li>\n\n\n\n<li>Monitor QPS, latency, NXDOMAIN\/SERVFAIL rates, top talkers and domains.<\/li>\n\n\n\n<li>Automate backups of configs\/zones and use version control.<\/li>\n\n\n\n<li>Practice incident response: dig\/kdig checks, packet capture, and isolation.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"monitoring-dns-on-linux-tools-and-methods\"><strong>Monitoring DNS on Linux: Tools and Methods<\/strong><\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"1-verify-the-basics-with-dns-clients\"><strong>1) Verify the Basics with DNS Clients<\/strong><\/h3>\n\n\n\n<p>Start with simple, fast checks using command-line clients to validate resolution, authority, and DNSSEC. These commands should be muscle memory during incidents.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Install tools (Debian\/Ubuntu)\nsudo apt update &amp;&amp; sudo apt install dnsutils ldnsutils knot-dnsutils -y\n\n# Basic lookups\ndig A example.com +nocmd +noall +answer\nkdig example.com A @127.0.0.1 +tls-ca # if using DoT upstream\n\n# Trace and DNSSEC status\ndig +trace example.com\ndig example.com A +dnssec +multi\n\n# Authoritative checks\ndig NS yourzone.com @your.authoritative.ip\ndig AXFR yourzone.com @authorized-secondary -k Ktsig.key # with TSIG<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"2-observe-live-traffic-tcpdump-tshark-dnstop\"><strong>2) Observe Live Traffic (tcpdump, tshark, dnstop)<\/strong><\/h3>\n\n\n\n<p>Packet captures reveal anomalies quickly\u2014sudden floods, unusual QTYPEs, or spoofed sources. Use them during triage and to build baselines.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Quick snapshot of queries on port 53\nsudo tcpdump -nni any port 53 -vv\n\n# Summarize top talkers\/types with dnstop\nsudo apt install dnstop -y\nsudo dnstop -l 3 any\n\n# Deeper inspection with tshark\nsudo tshark -i any -f \"port 53\" -T fields -e ip.src -e dns.qry.name -e dns.qry.type | head<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"3-server-metrics-and-logs-bind-unbound\"><strong>3) Server Metrics and Logs (BIND\/Unbound)<\/strong><\/h3>\n\n\n\n<p>Track QPS, cache hit rate, latency, NXDOMAIN\/SERVFAIL ratios, and top clients. Enable logs at useful detail, then forward to a SIEM or central syslog.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># BIND: enable query logging temporarily (performance hit in high QPS)\nsudo rndc querylog on\n# BIND stats snapshot\nsudo rndc stats &amp;&amp; sudo tail -n 50 \/var\/named\/named.stats\n\n# Unbound: control and stats\nsudo unbound-control status\nsudo unbound-control stats_noreset | head\n\n# Journald \/ rsyslog\njournalctl -u named -f\njournalctl -u unbound -f<\/code><\/pre>\n\n\n\n<p>For high-volume visibility with minimal overhead, use dnstap to stream structured query\/response events to a collector.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># BIND dnstap snippet (in options)\ndnstap { all; }\ndnstap-output file \"\/var\/log\/named\/dnstap.log\";<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"4-export-to-prometheus-and-visualize-in-grafana\"><strong>4) Export to Prometheus and Visualize in Grafana<\/strong><\/h3>\n\n\n\n<p>Use exporters to turn raw stats into actionable dashboards and alerts.<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>bind_exporter or named_exporter: QPS, cache, RCODE counts, task queue.<\/li>\n\n\n\n<li>unbound_exporter: thread utilization, msg cache, histogram latencies.<\/li>\n\n\n\n<li>Node exporter: CPU, memory, network saturation for correlation.<\/li>\n<\/ul>\n\n\n\n<pre class=\"wp-block-code\"><code># Example Prometheus alert ideas (pseudocode)\nALERT DNSHighNXDOMAIN\nIF rate(bind_rcode_nxdomain&#91;5m]) &gt; 200\n\nALERT DNSServfailSpike\nIF rate(bind_rcode_servfail&#91;5m]) &gt; 20\n\nALERT DNSTopTalkerAnomaly\nIF topk(1, sum by(client_ip)(rate(dns_queries_total&#91;5m]))) &gt; 1000<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"5-detect-threats-with-ids-ips-and-fail2ban\"><strong>5) Detect Threats with IDS\/IPS and Fail2ban<\/strong><\/h3>\n\n\n\n<p>Suricata or Zeek can flag DNS tunneling, amplification attempts, and malware patterns. Combine with fail2ban to block abusers at the firewall based on logs.<\/p>\n\n\n\n<pre class=\"wp-block-code\"><code># Example fail2ban jail for BIND (jail.local)\n&#91;named-abuse]\nenabled = true\nfilter = named-abuse\nport = 53\nlogpath = \/var\/log\/syslog\nmaxretry = 50\nfindtime = 300\nbantime = 3600\n\n# Example filter (filter.d\/named-abuse.conf)\n&#91;Definition]\nfailregex = named\\&#91;.*\\]: client &lt;HOST&gt;#\\d+: query.*(denied|refused)<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"securing-dns-on-linux-best-practices\"><strong>Securing DNS on Linux: Best Practices<\/strong><\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"patch-and-harden-the-daemon\"><strong>Patch and Harden the Daemon<\/strong><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Choose the right role: authoritative-only vs. resolver. Avoid mixing unless split-brain is intentional.<\/li>\n\n\n\n<li>Keep packages updated and disable unused features or modules.<\/li>\n\n\n\n<li>Run as non-root, inside a chroot\/jail, with limited file capabilities.<\/li>\n\n\n\n<li>Enable SELinux\/AppArmor profiles to confine the daemon.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"restrict-recursion-transfers-and-control\"><strong>Restrict Recursion, Transfers, and Control<\/strong><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>allow-recursion and allow-query to trusted nets only.<\/li>\n\n\n\n<li>allow-transfer only to secondaries using TSIG.<\/li>\n\n\n\n<li>Listen on specific IPs; disable open recursion exposed to the internet.<\/li>\n\n\n\n<li>Restrict RNDC\/unbound-control to localhost or admin subnets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"enable-dnssec-validation-and-signing\"><strong>Enable DNSSEC (Validation and Signing)<\/strong><\/h3>\n\n\n\n<p>Resolvers should validate DNSSEC to protect users from forged responses. Authoritative servers should sign zones to protect domain integrity. Automate key rollover with appropriate lifetimes and monitor validation errors closely.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"response-rate-limiting-and-firewall-controls\"><strong>Response Rate Limiting and Firewall Controls<\/strong><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable BIND\u2019s built-in RRL to blunt amplification.<\/li>\n\n\n\n<li>Apply nftables or iptables rate limits and per-host thresholds.<\/li>\n\n\n\n<li>Drop spoofed\/bogon sources at network edge; prefer UDP with TCP fallback.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"encrypt-client-paths-where-possible\"><strong>Encrypt Client Paths Where Possible<\/strong><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>For resolvers, prefer upstreams via DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH).<\/li>\n\n\n\n<li>For internal clients, use DoT\/DoH-capable forwarders to reduce on-path tampering.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"logging-rotation-and-privacy\"><strong>Logging, Rotation, and Privacy<\/strong><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use logrotate for query logs and dnstap <a href=\"https:\/\/www.youstable.com\/blog\/check-disk-space-files-in-linux\/\">files to avoid disk<\/a> pressure.<\/li>\n\n\n\n<li>Retain only what you need; hash or truncate client IPs if required by policy.<\/li>\n\n\n\n<li>Forward logs to a central system (Elastic, Loki, Graylog) for correlation.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"configuration-examples-you-can-use-today\"><strong>Configuration Examples You Can Use Today<\/strong><\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"bind9-secure-caching-resolver-named-conf-options\"><strong>BIND9: Secure Caching Resolver (named.conf.options)<\/strong><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>options {\n  directory \"\/var\/cache\/bind\";\n  listen-on { 127.0.0.1; 10.0.0.10; };\n  listen-on-v6 { none; };\n\n  \/\/ Recursion restricted to LAN\n  recursion yes;\n  allow-recursion { 127.0.0.1; 10.0.0.0\/24; };\n  allow-query { 127.0.0.1; 10.0.0.0\/24; };\n  allow-query-cache { 127.0.0.1; 10.0.0.0\/24; };\n\n  \/\/ Disable open resolver exposure\n  allow-transfer { none; };\n\n  \/\/ DNSSEC validation\n  dnssec-validation auto;\n  dnssec-enable yes;\n\n  \/\/ Rate limiting (RRL)\n  rate-limit {\n    responses-per-second 20;\n    window 5;\n    log-only no;\n  };\n\n  \/\/ Minimal responses, reduce amplification\n  minimal-responses yes;\n\n  \/\/ Logging\n  querylog yes; \/\/ consider dnstap for performance\n};\n\n\/\/ Example TSIG for zone transfers (authoritative role)\nkey \"tsig-secondary\" {\n  algorithm hmac-sha256;\n  secret \"BASE64SECRET==\";\n};\n\nserver 192.0.2.53 {\n  keys { \"tsig-secondary\"; };\n};<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"unbound-hardened-resolver-unbound-conf\"><strong>Unbound: Hardened Resolver (unbound.conf)<\/strong><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code>server:\n  interface: 127.0.0.1\n  interface: 10.0.0.10\n  access-control: 127.0.0.0\/8 allow\n  access-control: 10.0.0.0\/24 allow\n\n  hide-identity: yes\n  hide-version: yes\n  qname-minimisation: yes\n  harden-referral-path: yes\n  harden-algo-downgrade: yes\n\n  # DNSSEC\n  auto-trust-anchor-file: \"\/var\/lib\/unbound\/root.key\"\n  val-clean-additional: yes\n\n  # Cache and performance\n  prefetch: yes\n  prefetch-key: yes\n  msg-cache-size: 128m\n  rrset-cache-size: 256m\n\n  # Logging (tune for volume)\n  verbosity: 1\n\n# Forward to DNS-over-TLS upstream (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<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"nftables-allow-and-rate-limit-dns\"><strong>nftables: Allow and Rate-Limit DNS<\/strong><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code># Basic nftables rules (IPv4)\nsudo nft add table inet filter\nsudo nft add chain inet filter input { type filter hook input priority 0 \\; }\nsudo nft add rule inet filter input ct state established,related accept\nsudo nft add rule inet filter input iif lo accept\nsudo nft add rule inet filter input tcp dport 53 ct state new limit rate 50\/second accept\nsudo nft add rule inet filter input udp dport 53 limit rate 200\/second burst 400 packets accept\nsudo nft add rule inet filter input drop<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"log-rotation-for-dns-logs\"><strong>Log Rotation for DNS Logs<\/strong><\/h3>\n\n\n\n<pre class=\"wp-block-code\"><code># \/etc\/logrotate.d\/named\n\/var\/log\/named\/*.log {\n  weekly\n  rotate 8\n  compress\n  missingok\n  notifempty\n  postrotate\n    \/usr\/sbin\/rndc reconfig &gt;\/dev\/null 2&gt;&amp;1 || true\n  endscript\n}<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"kpis-alerts-and-a-practical-monitoring-playbook\"><strong>KPIs, Alerts, and a Practical Monitoring Playbook<\/strong><\/h2>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"key-metrics-to-track\"><strong>Key Metrics to Track<\/strong><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Query rate (QPS) by client and zone.<\/li>\n\n\n\n<li>Latency percentiles (p50\/p95\/p99).<\/li>\n\n\n\n<li>RCODE ratios: NOERROR vs. NXDOMAIN vs. SERVFAIL.<\/li>\n\n\n\n<li>Cache hit rate and prefetch effectiveness (resolvers).<\/li>\n\n\n\n<li>Top talkers, top queried domains, rare QTYPE spikes.<\/li>\n\n\n\n<li>CPU, memory, file descriptors, UDP drops, and packet loss.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"daily-weekly-tasks\"><strong>Daily\/Weekly Tasks<\/strong><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Review dashboards for trend deviations and alert history.<\/li>\n\n\n\n<li>Check logs for denied\/refused queries, excessive retries, or timeouts.<\/li>\n\n\n\n<li>Validate DNSSEC status; renew keys as scheduled.<\/li>\n\n\n\n<li>Test failover: secondary servers, anycast nodes, upstream reachability.<\/li>\n\n\n\n<li>Backup configs and zone files; verify restores.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"incident-response-steps\"><strong>Incident Response Steps<\/strong><\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Confirm impact: dig from multiple networks; compare resolver vs. authoritative paths.<\/li>\n\n\n\n<li>Capture traffic (tcpdump) and check exporter metrics for spikes.<\/li>\n\n\n\n<li>Harden quickly: enable RRL\/log-only off, tighten ACLs, raise firewall limits selectively.<\/li>\n\n\n\n<li>Isolate abusive sources with fail2ban or temporary blocks.<\/li>\n\n\n\n<li>Post-mortem: keep PCAP\/logs; tune alerts and configs to prevent recurrence.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"common-pitfalls-to-avoid\"><strong>Common Pitfalls to Avoid<\/strong><\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Running an open resolver on a public IP without ACLs.<\/li>\n\n\n\n<li>Allowing zone transfers to anyone; not using TSIG.<\/li>\n\n\n\n<li>Mixing authoritative and recursive roles on the same interface.<\/li>\n\n\n\n<li>Disabling DNSSEC due to <a href=\"https:\/\/www.youstable.com\/blog\/fix-error-establishing-database-connection\/\">transient validation errors<\/a> instead of fixing upstream issues.<\/li>\n\n\n\n<li>Leaving query logging at high verbosity in production without rotation.<\/li>\n\n\n\n<li>Ignoring UDP drops or kernel limits (e.g., net.core.rmem) under load.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"when-to-choose-managed-dns-or-managed-servers\"><strong>When to Choose Managed DNS or Managed Servers<\/strong><\/h2>\n\n\n\n<p>If your applications are revenue-critical or you lack 24\/7 ops coverage, managed DNS and managed Linux hosting save time and reduce risk. At YouStable, our engineers deploy hardened resolvers\/authoritatives with DNSSEC, RRL, Prometheus\/Grafana, and proactive incident response\u2014so your domains stay fast, secure, and observable without the DIY burden.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\" class=\"wp-block-heading\" id=\"faqs-how-to-monitor-and-secure-dns-on-linux\"><strong>FAQs: How to Monitor &amp; Secure DNS on Linux <\/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-simplest-way-to-see-if-my-linux-dns-is-working\">What\u2019s the simplest way to see if my Linux DNS is working?<\/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>Use dig or kdig locally and remotely. Check A\/AAAA, NS, MX, and DNSSEC flags. If resolution works locally but fails externally, inspect firewall rules, recursion restrictions, and listening interfaces. For authoritatives, verify NS glue and that secondaries are in sync.<\/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-prevent-open-resolver-abuse\">How do I prevent open resolver abuse?<\/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>Disable public recursion by setting allow-recursion and allow-query to trusted subnets only. Bind to private interfaces, enable RRL, and add nftables\/iptables rate limits. Regularly test from an external IP to ensure recursion is not exposed.<\/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-bind-or-unbound-for-resolvers\">Should I use BIND or Unbound for resolvers?<\/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>Both are excellent. Unbound is lightweight, with strong DNSSEC and privacy features, making it ideal for recursive resolvers. BIND is feature-rich and widely used for both authoritative and recursive roles. Choose based on your team\u2019s familiarity and ecosystem (exporters, tooling).<\/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=\"do-i-really-need-dnssec\">Do I really need DNSSEC?<\/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, for integrity. Resolvers should validate to protect users from forged responses. If you run authoritative zones, sign them. While DNSSEC doesn\u2019t encrypt, it ensures authenticity\u2014critical against cache poisoning and hijacking attempts.<\/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=\"what-alerts-should-i-set-for-dns-monitoring\">What alerts should I set for DNS monitoring?<\/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>Alert on spikes in NXDOMAIN\/SERVFAIL, rising latency percentiles, sudden QPS surges, exporter down events, UDP packet drops, and anomalous top talkers. Correlate with system metrics (CPU, memory) to distinguish traffic bursts from resource exhaustion.<\/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 simplest way to see if my Linux DNS is working?\",\n\t\t\t\t\"acceptedAnswer\": {\n\t\t\t\t\t\"@type\": \"Answer\",\n\t\t\t\t\t\"text\": \"<p>Use dig or kdig locally and remotely. Check A\/AAAA, NS, MX, and DNSSEC flags. If resolution works locally but fails externally, inspect firewall rules, recursion restrictions, and listening interfaces. For authoritatives, verify NS glue and that secondaries are in sync.<\/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 prevent open resolver abuse?\",\n\t\t\t\t\"acceptedAnswer\": {\n\t\t\t\t\t\"@type\": \"Answer\",\n\t\t\t\t\t\"text\": \"<p>Disable public recursion by setting allow-recursion and allow-query to trusted subnets only. Bind to private interfaces, enable RRL, and add nftables\/iptables rate limits. Regularly test from an external IP to ensure recursion is not exposed.<\/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 BIND or Unbound for resolvers?\",\n\t\t\t\t\"acceptedAnswer\": {\n\t\t\t\t\t\"@type\": \"Answer\",\n\t\t\t\t\t\"text\": \"<p>Both are excellent. Unbound is lightweight, with strong DNSSEC and privacy features, making it ideal for recursive resolvers. BIND is feature-rich and widely used for both authoritative and recursive roles. Choose based on your team\u2019s familiarity and ecosystem (exporters, tooling).<\/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\": \"Do I really need DNSSEC?\",\n\t\t\t\t\"acceptedAnswer\": {\n\t\t\t\t\t\"@type\": \"Answer\",\n\t\t\t\t\t\"text\": \"<p>Yes, for integrity. Resolvers should validate to protect users from forged responses. If you run authoritative zones, sign them. While DNSSEC doesn\u2019t encrypt, it ensures authenticity\u2014critical against cache poisoning and hijacking attempts.<\/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\": \"What alerts should I set for DNS monitoring?\",\n\t\t\t\t\"acceptedAnswer\": {\n\t\t\t\t\t\"@type\": \"Answer\",\n\t\t\t\t\t\"text\": \"<p>Alert on spikes in NXDOMAIN\/SERVFAIL, rising latency percentiles, sudden QPS surges, exporter down events, UDP packet drops, and anomalous top talkers. Correlate with system metrics (CPU, memory) to distinguish traffic bursts from resource exhaustion.<\/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 monitor and secure DNS on a Linux server, continuously observe query volume, latency, response codes, and logs; export metrics [&hellip;]<\/p>\n","protected":false},"author":13,"featured_media":14499,"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":""}},"iawp_total_views":2,"footnotes":""},"categories":[350],"tags":[2186,2141],"class_list":["post-14353","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-knowledgebase","tag-how-to-monitor-secure-dns-on-linux","tag-linux-server"],"acf":[],"featured_image_src":"https:\/\/www.youstable.com\/blog\/wp-content\/uploads\/2025\/12\/How-to-Monitor-Secure-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\/14353","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=14353"}],"version-history":[{"count":2,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/posts\/14353\/revisions"}],"predecessor-version":[{"id":14550,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/posts\/14353\/revisions\/14550"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/media\/14499"}],"wp:attachment":[{"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/media?parent=14353"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/categories?post=14353"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.youstable.com\/blog\/wp-json\/wp\/v2\/tags?post=14353"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}