Remediation Guides

How to Fix BIND Version Disclosure (Nessus 10028): Hide version.bind in named.conf

26 September 2026 8 min read

BIND version disclosure means your DNS server answers a CHAOS-class TXT query for version.bind with its software version, which Nessus reports as plugin 10028. Fix it by adding version none; (or a decoy such as version “not disclosed”;) to the options block of named.conf, running rndc reconfig, and rescanning. This only hides the banner; keep BIND patched.

What the scanner is actually detecting

The check sends one DNS query: name version.bind, type TXT, class CHAOS (CH). BIND answers it from a built-in zone, and unless you configure otherwise, the answer is the real version of the running server. Nothing is exploited. The scanner simply records whatever string comes back.

  • Nessus plugin 10028, “DNS Server BIND version Directive Remote Version Detection” (family: DNS, severity: Info). Tenable’s synopsis is that it is possible to obtain the version number of the remote DNS server, and its solution is to use the version directive in the options section of named.conf.
  • Greenbone (OpenVAS) feeds include their own remote DNS version detection, which may report the same condition under a different title. Match it by port 53 and the version string in the result; the fix is the same.

Despite “BIND” in the title, Tenable’s description covers BIND or another DNS server that answers this query. Unbound, NSD and PowerDNS all answer version.bind unless configured otherwise, and dnsmasq answers CHAOS TXT queries in the bind domain unless –no-ident is set. Tenable also notes that the reported version is not necessarily accurate and could be forged, because some servers take it from a configuration file.

Real-world risk, stated honestly

This is an informational finding, and it is rated that way for a reason. Knowing the version does not give anyone access to the server. What it does is save an attacker effort: one quiet query tells them which published ISC advisories might apply, with no noisy probing. On an Internet-facing authoritative server, that makes your host easy to sort into “worth trying” lists.

Hiding the banner does not make a vulnerable BIND safe. Other techniques, such as behavioral fingerprinting, can sometimes still identify the software, and an unpatched server stays unpatched. So treat this in two parts:

  • The banner itself: low priority, quick to fix, worth doing on anything reachable from untrusted networks.
  • The version it reveals: check it against current ISC security advisories. If the banner shows a release with open advisories, that is your real finding, and patching comes first.

The companion query hostname.bind returns the machine’s hostname by default, which can reveal internal naming conventions. It is worth closing in the same change.

How to confirm it on the host

Query the server from the same network position as the scanner. Replace 192.0.2.53 with your DNS server’s address.

dig @192.0.2.53 version.bind txt chaos
dig @192.0.2.53 -c CH -t TXT version.bind +short

If the server discloses its version, the ANSWER section contains a line like version.bind. 0 CH TXT “…” with the version string in quotes. Distribution builds may append a packaging suffix to the upstream number.

Nmap’s dns-nsid script performs the same query and also asks for id.server and the NSID option:

nmap -sSU -p 53 --script dns-nsid 192.0.2.53

On the server, compare the installed version with what the configuration says:

# Version of the named binary actually installed
named -v

# Parsed configuration: look for version, hostname and server-id
named-checkconf -p | grep -E '^[[:space:]]*(version|hostname|server-id) '

If the grep returns nothing, all three options are at their defaults: version returns the real version, hostname returns the name from gethostname(), and server-id is none.

How to fix it

BIND 9: hide the BIND version in named.conf

Edit /etc/named.conf on RHEL and its rebuilds, or /etc/bind/named.conf.options on Debian and Ubuntu, and add the directives inside the existing options block:

options {
    // keep your existing settings
    version none;
    hostname none;
};

Three details from the BIND reference manual matter here:

  • version and hostname are valid only in the options block, not inside a view or zone.
  • Setting version to any value, including none, also disables authors.bind queries.
  • server-id already defaults to none. Leave it alone unless you deliberately use it to identify anycast nodes.

Check the syntax, then apply without a restart:

named-checkconf
rndc reconfig

rndc reconfig reloads the configuration file and loads new zones without re-reading existing zone files. rndc reload also works, but it reloads the zones too, which is slower on servers with many of them. If rndc is not set up, use the service manager: systemctl reload named on RHEL, or systemctl restart bind9 on Ubuntu.

named.conf version none or a decoy string?

You can also return a string of your choice:

options {
    version "not disclosed";
};

This hides the real number, but the server still answers the query with a TXT record, so a scanner may still raise the finding and show your text as the “version”. Per the BIND manual, version none; disables processing of the query, so no string comes back at all. If the goal is a clean report, use none.

Alternative: an explicit CHAOS view

The BIND manual describes a second route: hide the built-in CHAOS view by defining your own view of class CHAOS that matches all clients. This is heavier than it sounds. Once any explicit view exists, every zone statement must sit inside a view, and every non-IN view needs its own hint zone. For most servers, the options directives above are the simpler fix.

Other DNS servers that answer version.bind

Server Setting Where it goes
Unbound hide-version: yes (plus hide-identity: yes for id.server and hostname.bind) server: clause of unbound.conf; the queries are then REFUSED
NSD hide-version: yes (plus hide-identity: yes) server: clause of nsd.conf
PowerDNS Authoritative version-string=anonymous (returns SERVFAIL) or a custom string pdns.conf
PowerDNS Recursor recursor.version_string (old style: version-string) set to a custom string Recursor configuration
dnsmasq no-ident (command line: –no-ident) dnsmasq.conf; stops CHAOS TXT answers in the bind domain

Reload or restart the service after each change. For Unbound, unbound-control reload rereads the config but also flushes the cache.

How to verify the fix and rescan

  1. From the scanner’s network position, run dig @192.0.2.53 version.bind txt chaos +short. You should get no version string back: an empty answer or an error status, depending on the server software.
  2. Repeat over TCP (+tcp) and against every address the server listens on, including IPv6. For anycast or load-balanced addresses, test each node directly.
  3. Check the related names: dig @192.0.2.53 hostname.bind txt chaos +short and dig @192.0.2.53 authors.bind txt chaos +short.
  4. Space your test queries a little. BIND limits its built-in CHAOS view to three responses per second, so in a tight loop a dropped response (a timeout) can look like success.
  5. Rescan with the scanner that raised the finding. Nessus 10028 (or the Greenbone equivalent) should no longer report a version.

What can break and how to roll back

  • Inventory and monitoring scripts. Anything that queries version.bind remotely to record BIND versions loses its data. Move those checks to named -v or the package manager on the host.
  • Your own unauthenticated scans. Remote checks that rely on the self-reported version lose the banner they depend on and may stop flagging an outdated BIND. Use credentialed scans so the installed package version is still assessed.
  • Anycast troubleshooting. Operators sometimes use hostname.bind to see which node answered. If you need that, keep hostname enabled on internal-only servers or configure server-id deliberately.
  • Typos. A missing semicolon or quote breaks the config. Always run named-checkconf before rndc reconfig.

Rollback is a one-line change:

# Remove or comment out the version and hostname lines, then
named-checkconf
rndc reconfig

Common false positive reasons

  • The IP is not your BIND server. Firewalls, routers and load balancers can run their own DNS proxy on port 53 and answer version.bind themselves. The fix then belongs in that device’s configuration.
  • A decoy string is being reported. If the output shows a string you configured, no real version is leaking. Document it, or switch to version none; for a clean report.
  • Scanner inside the allowed range. The BIND manual states that most global options, including allow-query, also apply to the built-in CHAOS view. An internal scanner may see the banner while Internet clients are refused. Still worth fixing, but at a lower priority.
  • Banner version versus patched package. Distribution packages often backport security fixes without changing the upstream version number. If the banner feeds other version-based BIND findings, check the package changelog before trusting them; our guide to false positives caused by backported patches shows how to prove it.

FAQ

Does hiding the BIND version fix any vulnerability?

No. It removes an easy reconnaissance signal and nothing more. Any vulnerability in the installed release is still there, so keep BIND updated against ISC advisories.

Do I need to restart named after changing version?

No. Run named-checkconf, then rndc reconfig or rndc reload. A service reload or restart also works.

How do I fix Nessus 10028 on Unbound or NSD?

Set hide-version: yes in the server: clause, reload or restart the service, and rescan. Add hide-identity: yes to cover hostname.bind and id.server as well.

Why does dig still return a version after the change?

Usually you are querying a different instance: another anycast node, a load-balanced backend, or a device proxying DNS. Also confirm with named-checkconf -p that the configuration contains the directive and that rndc reconfig completed without errors.

Tracking this finding across many hosts

Plugin 10028 tends to appear on every DNS server, forwarder and network appliance at once, so one consolidated list makes it easier to see which hosts still leak a banner after the change. If that list is hard to keep, a self-hosted platform such as SITEY can help: it imports findings from 16 scanners (Nessus results by uploading the exported .nessus file) and merges duplicates per scanner. For Nessus findings, it can also retest an individual finding to confirm that it has closed.

Sources

SITEY closes the loop, not just the report.Discover, validate, fix and verify in your own infrastructure.

See pricing