BIND 9 restart performance with DNSSEC

Question

At the moment i experimenting with the restart performance of BIND9 (version 9.16.17). With 26000 active zones in the named.conf, the restart is roundabout 10 seconds. but when i start using DNSSEC, at the moment with 500 signed zones (and 25500 unsigned), the restart is up to 40 seconds! when i think forword to over 10000 signed zones, the restart is taking over 12 minutes.

for dnssec signing i use "dnssec-policy", mostly in the default configration.

is there a way to improve the performance?

Answer 1

Nope. This is by design. As is, you letting the primary (formerly called master) authoritative nameserver do number-crunching of public keys while concurrently doing answering of network queries by the millions is no way to go.

An Alternative Approach

But it is common to set up a hidden master nameserver to deal with this long duration and CPU-intensive overhead of DNSSEC preparing the zone database by its signing of each and every record with a new public key.

Hidden-master is simply another primary (master) nameserver chain-added to before the original primary (master) authoritative nameserver (who still remains a master, but in public view).

In short, the overall network design outlines a hidden-master before a primary while in turn serving all secondaries (slaves).

A New Primary to a Primary

Hidden-master would then populate in an incremental manner the usualy primary authoritative nameserver with pre-signed RRSIG DNS records so that zones' AXFR/IXFR record data would transfer incrementally, as each record becomes DNSSEC-signed and ready.

This ensures that the remote but primary authoritative nameserver would NOT be burdened with intensive CPU burn during DNSSEC resigning effort.

The primary authoritative nameserver will still happily perform answer lookups to all queries in their usual speedy manner.

Furthermore, a compromise of your primary nameserver would still not impinge upon your original primary zone database files while your hidden-master hides, nice and snug, behind its corporate DMZ firewall.

Setup, Brief

Using ISC Bind9, the zone database gets relocated to and resides in the hidden master (just no longer resides at the primary authoritative nameserver).

The primary authoritative nameserver is now ALSO the hidden-secondary to its hidden-master while maintaining a public-façade of still being a primary).

Also, SOA MNAME of each zone would still point to the the original primary authoritative nameserver ... unchanged. This alone has broken many DNS administrators' die-hard notion that zone database file must reside at its SOA nameserver, not so anymore here.

In addition to standard settings for zone's type primary, this hidden-master have additional ISC Bind9 options like notify-to-soa yes to distinguish from another downstream primary; also allow-transfer, notify explicit and also-notify are required as well.

Primary authoritative nameserver would still remain to be a lightweight high-performance authoritative server, but tweaked to have allow-update and allow-notify containing this new hidden-master's IP address.

If hidden-master is behind a NAT, then the primary authoritative must refer to its public-facing NAT address of its hidden-master, and not by its corporate internal IP address inside the NAT masqerade. Also firewall open-up a distinctive TCP and UDP port number other than 53 to use for AXFR/IXFR. Of course, such transfer should require a TSIG key.

References

• https://serverfault.com/questions/381920/bind-master-slaves-and-notify
• http://www.ipamworldwide.com/ipam/bind-9-8-2.html
• https://egbert.net/blog/articles/dns-bind9-hidden-primary-port53-not.html