UNBOUND-CONTROL(8)

📦
version 1.26.2 · 12 versions
, in arch rolling, debian trixie, fedora 44

okay bestie, welcome to the UNBOUND-CONTROL(8) page from Unbound 1.26.2 💖 this is the remote server control utility and she is that girl. no cap, let's get into it.

✨ NAME ✨

unbound-control — Unbound 1.26.2 remote server control utility.

✨ SYNOPSIS ✨

unbound-control [-hq] [-c cfgfile] [-s server] command

💅 DESCRIPTION 💅

unbound-control performs remote administration on the unbound(8) DNS server. it reads the configuration file, contacts the Unbound server over TLS, sends the command, and displays the result. periodt.

the available options are:

  • -h — show the version and commandline option help.
  • -c <cfgfile> — the config file to read with settings. if not given, the default config file /etc/unbound/unbound.conf is used.
  • -s <server[@port]> — IPv4 or IPv6 address of the server to contact. if not given, the address is read from the config file.
  • -q — quiet, if the option is given it does not print anything if it works ok.

🎀 COMMANDS 🎀

there are several commands that the server understands:

  • start — start the server. simply execs unbound(8). the unbound executable is searched for in the PATH set in the environment. it is started with the config file specified using -c or the default config file.
  • stop — stop the server. the server daemon exits.
  • reload — reload the server. this flushes the cache and reads the config file fresh.
  • reload_keep_cache — reload the server but try to keep the RRset and message cache if (re)configuration allows for it. that means the caches sizes and the number of threads must not change between reloads.
  • fast_reload [+dpv] — reload the server, but keep downtime to a minimum, so that user queries keep seeing service. this needs the code compiled with threads. the config is loaded in a thread, and prepared, then it briefly pauses the existing server and updates config options. the intent is that the pause does not impact the service of user queries. the cache is kept. also user queries worked on are kept and continue, but with the new config options.
NOTE: this command is experimental at this time. 💀

the amount of temporal memory needed during a fast_reload is twice the amount needed for configuration. this is because Unbound temporarily needs to store both current configuration values and new ones while trying to fast_reload. zones loaded from disk (authority zones and RPZ zones) are included in such memory needs.

options that can be changed are for forwards, stubs, views, authority zones, RPZ zones and local zones.

also access-control and similar options, interface-action and similar options and tcp-connection-limit. it can reload some define-tag changes, more on that below. further options include insecure-lan-zones, domain-insecure, trust-anchor-file, trust-anchor, trusted-keys-file, auto-trust-anchor-file, edns-client-string, ipset, log-identity, infra-cache-numhosts, msg-cache-size, rrset-cache-size, key-cache-size, ratelimit-size, neg-cache-size, num-queries-per-thread, jostle-timeout, use-caps-for-id, unwanted-reply-threshold, tls-use-sni, outgoing-tcp-mss, ip-dscp, max-reuse-tcp-queries, tcp-reuse-timeout, tcp-auth-query-timeout, delay-close. iter-scrub-promiscuous. tls-service-key. tls-service-pem.

it does not work with interface and outgoing-interface changes, also not with remote control, outgoing-port-permit, outgoing-port-avoid, msg-buffer-size, any *-slabs options and statistics-interval changes.

for dnstap these options can be changed: dnstap-log-resolver-query-messages, dnstap-log-resolver-response-messages, dnstap-log-client-query-messages, dnstap-log-client-response-messages, dnstap-log-forwarder-query-messages and dnstap-log-forwarder-response-messages.

it does not work with these options: dnstap-enable, dnstap-bidirectional, dnstap-socket-path, dnstap-ip, dnstap-tls, dnstap-tls-server-name, dnstap-tls-cert-bundle, dnstap-tls-client-key-file and dnstap-tls-client-cert-file.

the options dnstap-send-identity, dnstap-send-version, dnstap-identity, and dnstap-version can be loaded when +p is not used.

the +v option makes the output verbose which includes the time it took to do the reload. with +vv it is more verbose which includes the amount of memory that was allocated temporarily to perform the reload; this amount of memory can be big if the config has large contents. in the timing output the 'reload' time is the time during which the server was paused.

the +p option makes the reload not pause threads, they keep running. locks are acquired, but items are updated in sequence, so it is possible for threads to see an inconsistent state with some options from the old and some options from the new config, such as cache TTL parameters from the old config and forwards from the new config. the stubs and forwards are updated at the same time, so that they are viewed consistently, either old or new values together. the option makes the reload time take eg. 3 microseconds instead of 0.3 milliseconds during which the worker threads are interrupted. so, the interruption is much shorter, at the expense of some inconsistency. after the reload itself, every worker thread is briefly contacted to make them release resources, this makes the delete timing a little longer, and takes up time from the remote control servicing worker thread.

with the nopause option (+p), the reload does not work to reload some options, that fast reload works on without the nopause option: val-bogus-ttl, val-override-date, val-sig-skew-min, val-sig-skew-max, val-max-restart, val-nsec3-keysize-iterations, target-fetch-policy, outbound-msg-retry, max-sent-count, max-query-restarts, do-not-query-address, do-not-query-localhost, private-address, private-domain, caps-exempt, nat64-prefix, do-nat64, infra-host-ttl, infra-keep-probing, ratelimit, ip-ratelimit, ip-ratelimit-cookie, wait-limit-netblock, wait-limit-cookie-netblock, ratelimit-below-domain, ratelimit-for-domain.

the +d option makes the reload drop queries that the worker threads are working on. this is like flush_requestlist. without it the queries are kept so that users keep getting answers for those queries that are currently processed. the drop makes it so that queries during the life time of the query processing see only old, or only new config options.

when there are changes to the config tags, from the define-tag option, then the +d option is implicitly turned on with a warning printout, and queries are dropped. this is to stop references to the old tag information, by the old queries. if the number of tags is increased in the newly loaded config, by adding tags at the end, then the implicit +d option is not needed.

for response ip, that is actions associated with IP addresses, and perhaps intersected with access control tag and action information, those settings are stored with a query when it comes in based on its source IP address. the old information is kept with the query until the queries are done. this is gone when those queries are resolved and finished, or it is possible to flush the requestlist with +d.

  • verbosity number — change verbosity value for logging. same values as the verbosity: keyword in unbound.conf(5). this new setting lasts until the server is issued a reload (taken from config file again), or the next verbosity control command.
  • log_reopen — reopen the logfile, close and open it. useful for logrotation to make the daemon release the file it is logging to. if you are using syslog it will attempt to close and open the syslog (which may not work if chrooted).
  • stats — print statistics. resets the internal counters to zero, this can be controlled using the statistics-cumulative: config statement. statistics are printed with one [name]: [value] per line.
  • stats_noreset — peek at statistics. prints them like the stats command does, but does not reset the internal counters to zero.
  • status — display server status. exit code 3 if not running (the connection to the port is refused), 1 on error, 0 if running.
  • local_zone name type — add new local zone with name and type. like local-zone config statement. if the zone already exists, the type is changed to the given argument.
  • local_zone_remove name — remove the local zone with the given name. removes all local data inside it. if the zone does not exist, the command succeeds.
  • local_data RR data... — add new local data, the given resource record. like local-data: keyword, except for when no covering zone exists. in that case this remote control command creates a transparent zone with the same name as this record.
  • local_data_remove name — remove all RR data from local name. if the name already has no items, nothing happens. often results in NXDOMAIN for the name (in a static zone), but if the name has become an empty nonterminal (there is still data in domain names below the removed name), NOERROR nodata answers are the result for that name. with a specific RR instead of a domain name, that specific record is removed from the local data, and not all the RR data.
  • local_zones — add local zones read from stdin of unbound-control. input is read per line, with name space type on a line. for bulk additions.
  • local_zones_remove — remove local zones read from stdin of unbound-control. input is one name per line. for bulk removals.
  • local_datas — add local data RRs read from stdin of unbound-control. input is one RR per line. for bulk additions.
  • local_datas_remove — remove local data RRs read from stdin of unbound-control. input is one name per line. for bulk removals.
  • dump_cache — the contents of the cache is printed in a text format to stdout. you can redirect it to a file to store the cache in a file. not supported in remote Unbounds in multi-process operation.

🫶 load_cache

okay so bestie, this one slurps the contents of the cache straight out of stdin 💖. It uses the exact same format that dump_cache uses, so like, they're a matching set.

But ⚠️ listen: loading the cache with old, or wrong data can result in old or wrong data returned to clients. That's the whole vibe. Loading data into the cache in this way is supported in order to aid with debugging — that's the entire point of it. And nope, it's not supported in remote Unbounds in multi-process operation. 🙈

🔍 cache_lookup [+t] names

Prints to stdout the RRsets and messages that are in the cache. For every name you list, the content at or under the name is printed. You can hand it several names separated by spaces and every single one gets printed, no skips. When subnetcache is enabled, it also prints matching entries from the subnet cache. ✨

  • +t — allows tld and root names. With it, names like 'com' and '.' can be used, but ngl it takes a lot of effort to look up in the cache.

lookup name

Prints to stdout the name servers that would be used to look up the name you specified. It's giving preview mode. 👑

🧹 flush [+c] name

Removes the name from the cache. Removes the types A, AAAA, NS, SOA, CNAME, DNAME, MX, PTR, SRV, NAPTR, SVCB and HTTPS — because that is fast to do, periodt. Other record types can be removed using flush_type or flush_zone.

  • +c — removes the items also from the cachedb cache. If cachedb is in use.

🎯 flush_type [+c] name type

Removes the name, type information from the cache.

  • +c — removes the items also from the cachedb cache. If cachedb is in use.

🌪️ flush_zone [+c] name

Removes all information at or below the name from the cache. The rrsets and key entries are removed so that new lookups will be performed. Heads up that this needs to walk and inspect the entire cache, and it is a slow operation 😭. The entries are set to expired in the implementation of this command (so, with serve-expired enabled, it'll serve that information but schedule a prefetch for new information).

  • +c — removes the items also from the cachedb cache. If cachedb is in use.

🚮 flush_bogus [+c]

Remove all bogus data from the cache. Clean slate energy.

  • +c — removes the items also from the cachedb cache. If cachedb is in use.

🙅 flush_negative [+c]

Remove all negative data from the cache. That's nxdomain answers, nodata answers and servfail answers. It also removes bad key entries (which could be due to failed lookups) from the dnssec key cache, and iterator last-resort lookup failures from the rrset cache.

  • +c — removes the items also from the cachedb cache. If cachedb is in use.

📊 flush_stats

Reset statistics to zero. Fresh start, slay.

🛑 flush_requestlist

Drop the queries that are worked on. It stops working on the queries that the server is working on now. The cache is unaffected. No reply is sent for those queries, probably making those users request again later. Useful to make the server restart working on queries with new settings, such as a higher verbosity level.

👀 dump_requestlist

Show what is worked on. Prints all queries that the server is currently working on. Prints the time that users have been waiting. For internal requests, no time is printed. And then it prints out the module status. Little caveat: this prints the queries from the first thread, and not queries that are being serviced from other threads.

🏗️ flush_infra all|IP

If all then the entire infra cache is emptied. If a specific IP address, the entry for that address is removed from the cache. It contains EDNS, ping and lameness data.

🔬 dump_infra

Show the contents of the infra cache. Peek behind the curtain bestie.

⚙️ set_option opt: val

Set the option to the given value without a reload. The cache is therefore not flushed. The option must end with a ':' and whitespace must be between the option and the value. Some values may not have an effect if set this way, the new values are not written to the config file, and not all options are supported. This is different from the set_option call in libunbound, where all values work because Unbound has not been initialized.

The values that work are: statistics-interval, statistics-cumulative, do-not-query-localhost, harden-short-bufsize, harden-large-queries, harden-glue, harden-dnssec-stripped, harden-below-nxdomain, harden-referral-path, prefetch, prefetch-key, log-queries, hide-identity, hide-version, identity, version, val-log-level, val-log-squelch, ignore-cd-flag, add-holddown, del-holddown, keep-missing, tcp-upstream, ssl-upstream, max-udp-size, ratelimit, ip-ratelimit, cache-max-ttl, cache-min-ttl, cache-max-negative-ttl.

📖 get_option opt

Get the value of the option. Give the option name without a trailing ':'. The value is printed. If the value is "", nothing is printed and the connection closes. On error 'error ...' is printed (it gives a syntax error on unknown option). For some options a list of values, one on each line, is printed. The options are shown from the config file as modified with set_option. For some options an override may have been taken that does not show up with this command, not results from e.g. the verbosity and forward control commands. Not all options work, see list_stubs, list_forwards, list_local_zones and list_local_data for those.

🌱 list_stubs

List the stub zones in use. These are printed one by one to the output. This includes the root hints in use.

➡️ list_forwards

List the forward zones in use. These are printed zone by zone to the output.

🕳️ list_insecure

List the zones with domain-insecure.

🏠 list_local_zones

List the local zones in use. These are printed one per line with zone type.

📦 list_local_data

List the local data RRs in use. The resource records are printed.

➕ insecure_add zone

Add a domain-insecure for the given zone, like the statement in unbound.conf. Adds to the running Unbound without affecting the cache contents (which may still be bogus, use flush_zone to remove it), and does not affect the config file.

➖ insecure_remove zone

Removes domain-insecure for the given zone.

🚀 forward_add [+it] zone addr ...

Add a new forward zone to running Unbound. With the +i option it also adds a domain-insecure for the zone (so it can resolve insecurely if you have a DNSSEC root trust anchor configured for other names). The addr can be IP4, IP6 or nameserver names, like forward-zone config in unbound.conf. The +t option sets it to use TLS upstream, like forward-tls-upstream: yes.

🗑️ forward_remove [+i] zone

Remove a forward zone from running Unbound. The +i also removes a domain-insecure for the zone.

🌟 stub_add [+ipt] zone addr ...

Add a new stub zone to running Unbound. With the +i option it also adds a domain-insecure for the zone. With +p the stub zone is set to prime, without it it is set to notprime. The addr can be IP4, IP6 or nameserver names, like the stub-zone: config in unbound.conf. The +t option sets it to use TLS upstream, like stub-tls-upstream: yes.

🧽 stub_remove [+i] zone

Remove a stub zone from running Unbound. The +i also removes a domain-insecure for the zone.

🔀 forward [off | addr ... ]

Setup forwarding mode. Configures if the server should ask other upstream nameservers, should go to the internet root nameservers itself, or show the current config. You could pass the nameservers after a DHCP update. 👑

  • Without arguments the current list of addresses used to forward all queries to is printed. On startup this is from the forward-zone "." configuration. Afterwards it shows the status. It prints off when no forwarding is used.
  • If off is passed, forwarding is disabled and the root nameservers are used. This can be used to avoid to avoid buggy or non-DNSSEC supporting nameservers returned from DHCP. But may not work in hotels or hotspots.
  • If one or more IPv4 or IPv6 addresses are given, those are then used to forward queries to. The addresses must be separated with spaces. With '@port' the port number can be set explicitly (default port is 53 (DNS)).

By default the forwarder information from the config file for the root "." is used. The config file is not changed, so after a reload these changes are gone. Other forward zones from the config file are not affected by this command.

🚦 ratelimit_list [+a]

List the domains that are ratelimited. Printed one per line with current estimated qps and qps limit from config. With +a it prints all domains, not just the ratelimited domains, with their estimated qps. The ratelimited domains return an error for uncached (new) queries, but cached queries work as normal.

🚧 ip_ratelimit_list [+a]

List the ip addresses that are ratelimited. Printed one per line with current estimated qps and qps limit from config. With +a it prints all ips, not just the ratelimited ips, with their estimated qps. The ratelimited ips are dropped before checking the cache.

🗂️ list_auth_zones

List the auth zones that are configured. Printed one per line with a status, indicating if the zone is expired and current serial number. Configured RPZ zones are included.

🔄 auth_zone_reload zone

Reload the auth zone (or RPZ zone) from zonefile. The zonefile is read in overwriting the current contents of the zone in memory. This changes the auth zone contents itself, not the cache contents. Such cache contents exists if you set Unbound to validate with for-upstream: yes and that can be cleared with flush_zone zone.

📡 auth_zone_transfer zone

Transfer the auth zone (or RPZ zone) from master. The auth zone probe sequence is started, where the masters are probed to see if they have an updated zone (with the SOA serial check). And then the zone is transferred for a newer zone version.

✅ rpz_enable zone

Enable the RPZ zone if it had previously been disabled.

❌ rpz_disable zone

Disable the RPZ zone.

  • view_list_local_zones view — it's list_local_zones, but scoped to the view you name. 🎀
  • view_local_zone view name type — local_zone, but for the given view.
  • view_local_zone_remove view name — local_zone_remove, but for the given view.
  • view_list_local_data view — list_local_data, but for the given view.
  • view_local_data view RR data... — local_data, but for the given view.
  • view_local_data_remove view name — local_data_remove, but for the given view.
  • view_local_datas_remove view — pulls a whole list of local_data for the given view off stdin. Works just like local_datas_remove. 🫶
  • view_local_datas view — adds a whole list of local_data for the given view, read from stdin. Like local_datas.
  • add_cookie_secret secret — adds a cookie secret, or swaps one in, and persistently at that. The secret has to be a 128 bit hex string, no wiggle room bestie.
    • Cookie secrets come in two flavors: active or staging. Active cookie secrets are the ones used to create DNS Cookies, but verifying a DNS Cookie succeeds with any of the active or staging cookie secrets. Wanna see where your secrets stand? The print_cookie_secrets command prints out the state of the current cookie secrets.
    • If there are no cookie secrets configured yet, the secret gets added as active. If there's already an active cookie secret, the secret gets added as staging, or it replaces an existing staging secret.
    • To "roll" a cookie secret that's used in an anycast set, here's the whole choreography: the new secret has to be added as a staging secret to every node in the anycast set. Once all the nodes can verify DNS Cookies with the new secret, you activate it with the activate_cookie_secret command. Then, after all nodes have had the new secret active for at least one hour, you can drop the previous one with the drop_cookie_secret command. No skipping steps, fr fr. ✨
    • Persistence works by writing to a file, and that file is configured with the cookie-secret-file option in the server section of the config file. It's disabled by default, "".
  • drop_cookie_secret — drops the staging cookie secret. bye bestie 💅
  • activate_cookie_secret — makes the current staging cookie secret the active one, and the current active cookie secret becomes staging. They literally swap places, iconic.
  • print_cookie_secrets — shows the currently configured cookie secrets, each with its status. 👑

💥 EXIT CODE 💥

unbound-control exits with status code 1 when something goes wrong, and 0 when everything's good. That's the whole vibe check.

🛠️ SET UP 🛠️

The setup needs a self-signed certificate and private keys — for both the server and the client, okay? The unbound-control-setup script generates all of that in the default run directory, or you can point it somewhere else with -d.

Now, if you go changing the access control permissions on the key files, you get to decide who's allowed to use unbound-control. By default it's owner and group, but not all users. Run that script under the same username you configured in unbound.conf, or as root, so the daemon is actually permitted to read the files. Like this:

sudo -u unbound unbound-control-setup

If you haven't configured a username in unbound.conf, then the keys need read permission for the user credentials that the daemon is started under. Also worth knowing: the script preserves private keys that are already present in the directory. And after you run the script as root, go turn on control-enable in unbound.conf. That's the last step, don't forget it. 🎀

📊 STATISTIC COUNTERS 📊

The stats and stats_noreset commands show you a whole buffet of statistic counters. Here's every single one, no gatekeeping:

🧵 per-thread counters

  • threadX.num.queries — number of queries received by thread
  • threadX.num.queries_ip_ratelimited — number of queries rate limited by thread
  • threadX.num.queries_cookie_valid — number of queries with a valid DNS Cookie by thread
  • threadX.num.queries_cookie_client — number of queries with a client part only DNS Cookie by thread
  • threadX.num.queries_cookie_invalid — number of queries with an invalid DNS Cookie by thread
  • threadX.num.queries_discard_timeout — number of queries removed due to discard-timeout by thread
  • threadX.num.queries_replyaddr_limit — number of queries removed due to replyaddr limits by thread
  • threadX.num.queries_wait_limit — number of queries removed due to wait-limit by thread
  • threadX.num.cachehits — number of queries that were successfully answered using a cache lookup. slay ✨
  • threadX.num.cachemiss — number of queries that needed recursive processing
  • threadX.num.dnscrypt.crypted — number of queries that were encrypted and successfully decapsulated by dnscrypt.
  • threadX.num.dnscrypt.cert — number of queries that were requesting dnscrypt certificates.
  • threadX.num.dnscrypt.cleartext — number of queries received on dnscrypt port that were cleartext and not a request for certificates.
  • threadX.num.dnscrypt.malformed — number of request that were neither cleartext, not valid dnscrypt messages.
  • threadX.num.dns_error_reports — number of DNS Error Reports generated by thread
  • threadX.num.prefetch — number of cache prefetches performed. Bestie, this number is included in cachehits, because the original query had the unprefetched answer from cache and resulted in recursive processing, taking a slot in the requestlist. It is not part of the recursivereplies (or the histogram thereof) or cachemiss, since a cache response was sent.
  • threadX.num.expired — number of replies that served an expired cache entry.
  • threadX.num.queries_timed_out — number of queries that are dropped because they waited in the UDP socket buffer for too long.
  • threadX.query.queue_time_us.max — the maximum wait time for packets in the socket buffer, in microseconds. This is only reported when sock-queue-timeout is enabled.
  • threadX.num.recursivereplies — the number of replies sent to queries that needed recursive processing. Could be smaller than threadX.num.cachemiss if, due to timeouts, no replies were sent for some queries.
  • threadX.requestlist.avg — the average number of requests in the internal recursive processing request list on insert of a new incoming recursive processing query.
  • threadX.requestlist.max — maximum size attained by the internal recursive processing request list.
  • threadX.requestlist.overwritten — number of requests in the request list that were overwritten by newer entries. This happens when there's a flood of queries that need recursive processing and the server is having a hard time. The counter goes up when, during the flood, the jostle-timeout allows a query to be removed in favor of a new incoming query — the older query gets dropped to make space.
  • threadX.requestlist.exceeded — queries that were dropped because the request list was full. This happens when a flood of queries need recursive processing and the server can't keep up. The counter goes up when, during the flood, there's no space to be made by jostling out an older query, and the new query gets dropped. Since no older queries are removed (see the jostle-timeout setting), there's just no space for the new query.
  • threadX.requestlist.current.all — current size of the request list, including internally generated queries (like priming queries and glue lookups).
  • threadX.requestlist.current.user — current size of the request list, counting only the requests from client queries.
  • threadX.requestlist.current.replies — current count of the number of reply entries waiting on request list entries. Because a single request list entry can send results to multiple reply addresses, this number may be bigger than the size of the request list.
  • threadX.recursion.time.avg — average time it took to answer queries that needed recursive processing. Heads up: queries that were answered straight from the cache are not in this average.
  • threadX.recursion.time.median — the median of the time it took to answer queries that needed recursive processing. Median means 50% of the user queries were answered in less than this time. Because of big outliers (usually queries to non responsive servers), the average can be bigger than the median. This median has been calculated by interpolation from a histogram.
  • threadX.tcpusage — the currently held tcp buffers for incoming connections. It's a spot value taken at the time of the request. Super handy for spotting if the incoming-num-tcp buffers are full. 👀

🌍 totals

  • total.num.queries — summed over threads.
  • total.num.queries_ip_ratelimited — summed over threads.
  • total.num.queries_cookie_valid — summed over threads.
  • total.num.queries_cookie_client — summed over threads.
  • total.num.queries_cookie_invalid — summed over threads.
  • total.num.queries_discard_timeout — summed over threads.
  • total.num.queries_replyaddr_limit — summed over threads.
  • total.num.queries_wait_limit — summed over threads.
  • total.num.cachehits — summed over threads.
  • total.num.cachemiss — summed over threads.
  • total.num.dnscrypt.crypted — summed over threads.
  • total.num.dnscrypt.cert — summed over threads.
  • total.num.dnscrypt.cleartext — summed over threads.
  • total.num.dnscrypt.malformed — summed over threads.
  • total.num.dns_error_reports — summed over threads.
  • total.num.prefetch — summed over threads.
  • total.num.expired — summed over threads.
  • total.num.queries_timed_out — summed over threads.
  • total.query.queue_time_us.max — the maximum of the thread values.
  • total.num.recursivereplies — summed over threads.
  • total.requestlist.avg — averaged over threads.
  • total.requestlist.max — the maximum of the thread requestlist.max values.
  • total.requestlist.overwritten — summed over threads.
  • total.requestlist.exceeded — summed over threads.
  • total.requestlist.current.all — summed over threads.
  • total.requestlist.current.user — summed over threads.
  • total.requestlist.current.replies — summed over threads.
  • total.recursion.time.median — averaged over threads.
  • total.tcpusage — summed over threads.

⏰ time counters

  • time.now — current time in seconds since 1970.
  • time.up — uptime since server boot in seconds.
  • time.elapsed — time since last statistics printout, in seconds.

🔥 EXTENDED STATISTICS 🔥

okay bestie, this is the big one — all the extra counters you get when you ask for extended statistics. every single one, no skips, let's go 💅

  • mem.cache.rrset — memory, in bytes, that the RRset cache is currently eating up 🍓
  • mem.cache.message — memory in bytes being used by the message cache.
  • mem.cache.dnscrypt_shared_secret — memory in bytes in use by the dnscrypt shared secrets cache.
  • mem.cache.dnscrypt_nonce — memory in bytes in use by the dnscrypt nonce cache.
  • mem.mod.iterator — memory in bytes in use by the iterator module.
  • mem.mod.validator — memory in bytes in use by the validator module. heads up: this one includes the key cache and the negative cache too.
  • mem.streamwait — memory in bytes in use by the TCP and TLS stream wait buffers. these are answers just vibing there, waiting to be written back to the clients 🦋
  • mem.http.query_buffer — memory in bytes used by the HTTP/2 query buffers. holds (partial) DNS queries that are waiting for their request stream to complete.
  • mem.http.response_buffer — memory in bytes used by the HTTP/2 response buffers. holds DNS responses waiting to be written back to the clients.
  • mem.quic — memory in bytes used by QUIC. it's holding connection info, stream info, queries that were read, and responses written back to the clients.
  • histogram.<sec>.<usec>.to.<sec>.<usec> — shows a histogram, summed over all threads. every element counts the recursive queries whose reply time fit between the lower and upper bound — so, times larger than or equal to the lowerbound, and smaller than the upper bound. there are 40 buckets, and the bucket sizes double. iykyk 📊
  • num.query.type.A — total number of queries over all threads with query type A. it gets printed for the other query types too, but only for types where queries actually came in — so the =0 entries get omitted for brevity. we love a minimalist king 👑
  • num.query.type.other — number of queries with query types 256-65535.
  • num.query.class.IN — total number of queries over all threads with query class IN (internet). also printed for other classes (like CH (CHAOS), which is sometimes used for debugging), or NONE, ANY, used by dynamic update. num.query.class.other is printed for classes 256-65535.
  • num.query.opcode.QUERY — total number of queries over all threads with query opcode QUERY. also printed for other opcodes, UPDATE, ... and so on.
  • num.query.tcp — number of queries that were made using TCP towards the Unbound server.
  • num.query.tcpout — number of queries that the Unbound server made using TCP outgoing towards other servers.
  • num.query.udpout — number of queries that the Unbound server made using UDP outgoing towards other servers.
  • num.query.tls — number of queries made using TLS towards the Unbound server. note: these are also counted in num.query.tcp, because TLS uses TCP. double-dipping? no, just accurate accounting 💅
  • num.query.tls.resume — number of TLS session resumptions. these are queries over TLS towards the Unbound server where the client negotiated a TLS session resumption key.
  • num.query.https — number of queries made using HTTPS towards the Unbound server. these are also counted in num.query.tcp and num.query.tls, because HTTPS uses TLS and TCP. triple counted, iconic.
  • num.query.quic — number of queries made using QUIC towards the Unbound server. these are also counted in num.query.tls, because TLS is used for these queries.
  • num.query.ipv6 — number of queries made using IPv6 towards the Unbound server.
  • num.query.flags.RD — number of queries that had the RD flag set in the header. also printed for flags QR, AA, TC, RA, Z, AD, CD. careful though: queries with flags QR, AA or TC may have been rejected because of that 👀
  • num.query.edns.present — number of queries that had an EDNS OPT record present.
  • num.query.edns.DO — number of queries that had an EDNS OPT record with the DO (DNSSEC OK) bit set. these queries are also included in the num.query.edns.present number.
  • num.query.ratelimited — number of queries that are turned away from being send to nameserver due to ratelimiting. 🚫
  • num.query.dnscrypt.shared_secret.cachemiss — number of dnscrypt queries that did not find a shared secret in the cache. you can use this to compute the shared secret hitrate, bestie 🧮
  • num.query.dnscrypt.replay — number of dnscrypt queries that found a nonce hit in the nonce cache, and hence are considered a query replay. 💀
  • num.answer.rcode.NXDOMAIN — number of answers to queries, from cache or from recursion, that had the return code NXDOMAIN. also printed for the other return codes.
  • num.answer.rcode.nodata — number of answers to queries that had the pseudo return code nodata. this means the actual return code was NOERROR, but additionally, no data was carried in the answer (making what is called a NOERROR/NODATA answer). these queries are also included in the num.answer.rcode.NOERROR number. common for AAAA lookups when an A record exists, and no AAAA. classic 😭
  • num.answer.secure — number of answers that were secure. the answer validated correctly ✔️ the AD bit might have been set in some of these answers, where the client signalled (with DO or AD bit in the query) that they were ready to accept the AD bit in the answer.
  • num.answer.bogus — number of answers that were bogus. these answers resulted in SERVFAIL to the client because the answer failed validation. not the vibe.
  • num.rrset.bogus — number of rrsets marked bogus by the validator. goes up for every RRset inspection that fails.
  • num.valops — number of validation operations performed by the validator. goes up for every RRSIG verification operation regardless of the validation result. the RRSIG and key combination needs to first pass some sanity checks before Unbound even performs the verification — e.g., length/protocol checks. slay, do your checks first 💅
  • unwanted.queries — number of queries that were refused or dropped because they failed the access control settings.
  • unwanted.replies — replies that were unwanted or unsolicited. could have been random traffic, delayed duplicates, very late answers, or could be spoofing attempts. some low level of late answers and delayed duplicates are to be expected with the UDP protocol. very high values could indicate a threat (spoofing). 👀
  • msg.cache.count — number of items (DNS replies) in the message cache.
  • rrset.cache.count — number of RRsets in the rrset cache. this includes rrsets used by the messages in the message cache, but also delegation information.
  • infra.cache.count — number of items in the infra cache. these are IP addresses with their timing and protocol support information.
  • key.cache.count — number of items in the key cache. these are DNSSEC keys — one item per delegation point — plus their validation status.
  • msg.cache.max_collisions — the maximum number of hash table collisions in the msg cache. this is the number of hashes that are identical when a new element is inserted in the hash table. if the value is very large, like hundreds, something is wrong with the performance of the hash table, the hash values are incorrect, or it's malicious. 🚩
  • rrset.cache.max_collisions — the maximum number of hash table collisions in the rrset cache. this is the number of hashes that are identical when a new element is inserted in the hash table. if the value is very large, like hundreds, something is wrong with the performance of the hash table, hash values are incorrect or malicious. same energy fr fr 🚩
  • dnscrypt_shared_secret.cache.count — number of items in the shared secret cache. these are precomputed shared secrets for a given client public key/server secret key pair. shared secrets are CPU intensive, and this cache lets Unbound avoid recomputing the shared secret when multiple dnscrypt queries are sent from the same client. efficiency queen ✨
  • dnscrypt_nonce.cache.count — number of items in the client nonce cache. this cache is used to prevent dnscrypt queries replay. the client nonce must be unique for each client public key/server secret key pair. this cache should be able to host QPS * replay window interval keys to prevent replay of a query during replay window seconds.
  • num.query.authzone.up — number of queries answered from auth-zone data, upstream queries. these queries would otherwise have been sent (with fallback enabled) to the internet, but are now answered from the auth zone.
  • num.query.authzone.down — number of queries for downstream answered from auth-zone data. these queries are from downstream clients, and have had an answer from the data in the auth zone.
  • num.query.aggressive.NOERROR — number of queries answered using cached NSEC records with NODATA RCODE. these queries would otherwise have been sent to the internet, but are now answered using cached data. saving bandwidth, saving the planet 🌈
  • num.query.aggressive.NXDOMAIN — number of queries answered using cached NSEC records with NXDOMAIN RCODE. these queries would otherwise have been sent to the internet, but are now answered using cached data.
  • num.query.subnet — number of queries that got an answer that contained EDNS client subnet data.
  • num.query.subnet_cache — number of queries answered from the edns client subnet cache. these are counted as cachemiss by the main counters, but hit the client subnet specific cache after getting processed by the edns client subnet module.
  • num.query.cachedb — number of queries answered from the external cache of cachedb. these are counted as cachemiss by the main counters, but hit the cachedb external cache after getting processed by the cachedb module.
  • num.rpz.action.<rpz_action> — number of queries answered using configured RPZ policy, per RPZ action type. possible actions are: nxdomain, nodata, passthru, drop, tcp-only, local-data, disabled, and cname-override. 💖

📁 FILES 📁

  • /etc/unbound/unbound.conf — bestie, this is the Unbound config file. The whole vibe lives in here.
  • /etc/unbound — the directory that's holding all the private keys and self-signed certificates:
    • unbound_server.key and unbound_control.key — the private keys 🔑
    • unbound_server.pem and unbound_control.pem — the self-signed certificates 📜

👀 SEE ALSO 👀

like, go read those too, they're part of the lore 🫶

👑 AUTHOR 👑

The Unbound developers are mentioned in the CREDITS file in the distribution. iconic behavior, honestly.

1999-2026, NLnet Labs

and that's a wrap on UNBOUND-CONTROL(8), bestie!! 💖 This one's version 1.26.2, dated Oct 21, 2026 — so go forth, control your Unbound, and slay 💅✨

📦 where this page comes from