Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minutePC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Configure a secondary DNS server as a controlled replica of a primary: declare the zone as type secondary in BIND or as a secondary domain in PowerDNS, restrict transfers to known addresses, enable NOTIFY, and require a higher SOA serial before copying data. For hands-off provisioning, PowerDNS autoprimary can create a secondary zone after accepting a trusted notification; BIND normally requires each zone to be declared explicitly.
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
What a DNS secondary server does
A DNS secondary—historically called a slave—is an authoritative replica of data held on a primary server. It is not an independently edited copy. Zone changes are made on the primary, the primary’s SOA serial is increased, and the secondary retrieves the newer version.
As an Amazon Associate I earn from qualifying purchases.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →The arrangement improves availability and spreads authoritative queries across separate hosts or networks. It also gives you an operational fallback if the primary is unavailable. A secondary still depends on correct delegation, reachable server addresses, transfer permissions, and current zone data; simply running a second DNS process does not make it authoritative.
BIND and PowerDNS documentation increasingly use secondary, while configuration directives and older documentation may still use slave. Treat the terms as equivalent unless a specific software release says otherwise.
#1 Best Overall
- Used Book in Good Condition
How AXFR, IXFR, SOA and NOTIFY fit together
1. The SOA serial is the change marker
Every authoritative zone has an SOA record containing a serial number. The secondary periodically reads the primary’s SOA and compares that value with the serial it has stored. A transfer is required only when the received serial is arithmetically greater than the secondary’s current serial. Increase the serial for every change made on the primary; changing records without changing the serial leaves the secondary unaware of the update.
2. AXFR copies the complete zone
AXFR is a full zone transfer. It is normally used for the first copy of a zone or when an incremental history is unavailable. The transfer uses TCP port 53, so permitting only UDP DNS traffic is insufficient.
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Clear out junk files and repair common Windows errors3Scan for outdated or missing drivers - takes under a minute3. IXFR copies changes
IXFR is an incremental zone transfer. When the primary retains the necessary version history and both sides are configured to use it, only changes between serials are sent. If an incremental transfer cannot be satisfied, the servers can fall back to a full AXFR.
4. NOTIFY reduces detection time
After loading or reloading a zone, the primary can send a DNS NOTIFY message to its configured secondaries. On receipt, the secondary immediately checks the SOA instead of waiting for its normal refresh interval. NOTIFY does not itself carry the zone; it prompts the SOA check that leads to AXFR or IXFR.
For this sequence to work, the secondary must accept the notification source, the primary must be allowed to transfer to that secondary, and TCP port 53 must work in the transfer direction.
Plan the deployment before editing configuration
Choose stable addresses and names
Give the primary and secondary stable IPv4 and, where applicable, IPv6 addresses. Publish both authoritative names in the zone’s NS record set and publish reachable A or AAAA records for those names. The addresses in the NS records must lead to the same servers that are permitted to transfer the zone.
Open only the required traffic
| Traffic | Direction | Purpose | Minimum consideration |
|---|---|---|---|
| DNS queries | Clients to each authoritative server | Normal authoritative answers | Permit the DNS transport used by your clients; UDP is common and TCP is required for larger responses and some operations. |
| NOTIFY | Primary to secondary | Prompt SOA recheck after a reload | Permit DNS port 53 and accept notifications only from intended senders. |
| AXFR or IXFR | Secondary to primary | Transfer the zone | Permit TCP port 53 from the secondary’s address to the primary. |
Decide whether provisioning is manual or automatic
With BIND, each secondary zone is normally declared in configuration. With PowerDNS, you can also use an autoprimary relationship: a trusted primary notification causes PowerDNS to create the secondary domain entry and begin the transfer. Automatic creation is useful when many zones are delegated to the same service, but it must be constrained by source address and authentication controls.
Prepare storage and service permissions
Ensure the DNS service account can create and update secondary data. This is especially important for PowerDNS using the BIND backend with autosecondary operation: generated configuration and transferred zone files must be writable in the destination directory. Keep that directory protected so an unprivileged user cannot alter authoritative data.
Configure a BIND secondary server
The following is an explanatory configuration shape. Replace the example addresses, zone name, paths, and keys with values from your environment, then validate it with the BIND version installed on each host. The snippet is not a claim of execution or testing.
Step 1: Define the zone on the secondary
// secondary named.conf
zone "example.com" {
type secondary;
primaries { 192.0.2.10; };
file "slaves/example.com";
};type secondary; tells BIND that this server obtains the zone from another authoritative server. primaries lists the address or addresses from which it may obtain the zone. BIND accepts slave as a compatibility synonym for secondary, but using the current term makes the role clearer.
Recommended Free Tools
The file directive identifies local secondary storage. It is not an editing location: changes made there will be replaced by a later transfer and do not propagate to the primary.
Step 2: Permit the secondary on the primary
// primary named.conf zone controls
zone "example.com" {
type primary;
file "master/example.com";
allow-transfer { 192.0.2.20; };
also-notify { 192.0.2.20; };
};allow-transfer is the essential boundary. List only the secondary addresses that should receive the zone; do not leave transfers open to arbitrary clients. also-notify sends NOTIFY to a specified host even when that host is not fully represented by the zone’s NS set. This is useful when the secondary is deliberately hidden from the public NS set during a staged rollout.
Step 3: Handle notification sources deliberately
The secondary normally accepts NOTIFY from the primary declared for the zone. Use allow-notify only when additional, explicitly trusted notification senders are required. Adding broad notification permissions does not make transfers safe: it merely permits more hosts to trigger SOA checks, so keep the transfer ACL independently restricted.
Step 4: Add more than one primary when appropriate
If the zone has multiple primary addresses, list each in primaries. Make sure every listed address is authoritative for the zone and is covered by the primary-side transfer policy. A secondary can try another configured primary when one is unavailable, but inconsistent zone data or serials across those sources can produce confusing results; coordinate updates so the serial identifies the same logical version.
Step 5: Validate and reload safely
- Check the configuration syntax with the validation utility supplied by your BIND installation, such as
named-checkconf, before reloading. - Check the zone file on the primary with the corresponding zone-checking utility, commonly
named-checkzone, and correct any syntax or SOA errors. - Reload the primary, then reload or restart the secondary using the service manager appropriate to the operating system.
- Watch the BIND logs for NOTIFY acceptance, SOA comparison, and AXFR or IXFR success. A successful reload alone does not prove that a transfer occurred.
Optional: authenticate transfers with TSIG
TSIG adds a shared secret and algorithm to DNS messages. Define the same key name, secret, and algorithm on both servers, then reference that key in the transfer and notification policy supported by your BIND release. Use the key consistently: a mismatch in spelling, secret, or algorithm causes an otherwise reachable transfer to fail authentication. Store the secret with permissions that prevent ordinary users from reading it.
Configure an explicit PowerDNS secondary
Step 1: Enable secondary operation
Enable primary/secondary functionality in the PowerDNS configuration used by the receiving server. The exact setting names and file locations vary by PowerDNS release and backend, so inspect the configuration for the installed version rather than copying settings from an unrelated release.
Step 2: Create the domain roles
On the primary, set the domain type to MASTER. On the receiving server, create the corresponding domain as SLAVE or SECONDARY, according to the terminology accepted by that release, and supply the primary IP address or addresses. The secondary must know where to request the zone; the primary must recognize the secondary as an allowed transfer client.
Step 3: Check the authoritative records
Put both authoritative servers in the zone’s NS RRset and provide address records for those names where required. Query the primary directly to confirm it serves the intended NS and SOA records before asking the secondary to transfer.
Step 4: Set transfer and notification controls
Restrict AXFR and IXFR sources to the known secondary addresses. Restrict accepted NOTIFY sources with the PowerDNS controls available in your release, including allow-notify-from where supported. If your deployment uses TSIG, configure the matching key metadata and require it for the relevant notification and transfer paths.
Use PowerDNS autoprimary for automatic zone creation
What autoprimary does
An autoprimary is a primary host trusted to originate zones for which the receiving PowerDNS server should become secondary. When PowerDNS receives a bona fide NOTIFY from a configured autoprimary, it can provision the domain automatically, configure itself as a secondary, and start the transfer. This removes the need to create a separate secondary-domain record for every zone.
Step 1: Define the trusted relationship
Configure the autoprimary address and the associated secondary behavior in the PowerDNS settings used at startup. A notification from an address that is not in this trusted relationship must not create a domain. Treat the relationship as an allowlist, not as a discovery mechanism for arbitrary DNS hosts.
Step 2: Enable secondary support
Ensure the receiving PowerDNS instance has secondary operation enabled and that its backend can store the generated domain state. If you change a setting that is read only at startup, restart the service in the controlled manner required by your platform.
Free tools Windows power users keep installed
One-click scans. No signup required.
Step 3: Make the destination writable and protected
For the BIND backend, include the autoprimary configuration at startup and verify that the destination directory for generated zone files is writable by the PowerDNS service account. The directory should not be writable by unrelated users. A read-only directory can allow the notification to be accepted while preventing the zone from being persisted, leaving the new secondary unusable after a restart.
Step 4: Send a valid notification from the primary
After the primary has loaded the zone, have it send NOTIFY to the PowerDNS secondary. PowerDNS should verify that the sender is the configured autoprimary, create the secondary domain state, and request AXFR or IXFR. Check the PowerDNS logs for each stage rather than assuming that receipt of a UDP packet means provisioning completed.
Step 5: Keep automatic provisioning bounded
Automatic setup should be limited by all of the following: trusted notification source addresses, transfer-source restrictions, and TSIG where your software and topology support it. Do not combine autoprimary with unrestricted AXFR. A forged or misdirected NOTIFY should not be able to turn an arbitrary host into a persistent secondary.
Secure transfers and notifications with ACLs and TSIG
Address controls are the first boundary
On BIND, use allow-transfer on the primary and carefully scope allow-notify on the secondary when extra senders are needed. On PowerDNS, use its AXFR source controls and allow-notify-from or the equivalent setting for the installed release. Address ACLs should contain the exact primary and secondary addresses, including IPv6 addresses if those paths are enabled.
TSIG authenticates the message path
TSIG lets the receiving server verify that a NOTIFY or transfer request was generated by a holder of the shared secret. Configure identical key names, secrets, and algorithms at both ends. A signed request sent with an unknown key, an expired or invalid MAC, or a differently spelled key name is rejected even when the network route and ACL are correct.
Separate notification and transfer decisions
A notification is a trigger, not proof that a sender is authorized to transfer data. Continue to enforce transfer ACLs after enabling NOTIFY and TSIG. If a secondary can receive signed notifications but the primary does not permit its address in allow-transfer, provisioning will still fail at the transfer stage.
Account for DNSSEC without changing the replication model
DNSSEC records are transferred as part of the zone data. Keep signing and key-management policy on the authoritative system that performs it, and ensure the secondary software is configured to serve the transferred DNSSEC records. DNSSEC does not replace TSIG: signatures on DNS data and authentication of zone-transfer control traffic address different risks.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Verify an initial transfer and an automatic update
Check the primary directly
dig @192.0.2.10 example.com SOA
dig @192.0.2.10 example.com NSConfirm that the SOA serial is the version you expect and that the NS RRset names the intended authoritative servers. Remove the leading space before the second command if your shell treats it specially.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Check the secondary directly
dig @192.0.2.20 example.com SOA
dig @192.0.2.20 example.com NSCompare the serial returned by the secondary with the primary. Querying a recursive resolver does not prove that the secondary itself has transferred the zone, because the resolver may answer from cache.
Test the complete automatic path
- Make a harmless, identifiable change on the primary and increase the SOA serial.
- Reload the primary so it loads the new serial and sends NOTIFY.
- Confirm in logs that the secondary accepted the notification from the expected source.
- Confirm that the secondary opened a TCP connection to port 53 and completed IXFR or AXFR.
- Query the changed record and the SOA directly on the secondary.
- Repeat the test after a service restart to verify that the transferred data and any automatically created domain state persist.
Troubleshoot failures by symptom
| Symptom | Likely cause | What to check |
|---|---|---|
| The secondary never updates | The SOA serial was not increased, or NOTIFY is not reaching the secondary. | Compare SOA values directly; inspect the primary’s notify log and the secondary’s accepted-notify log. |
| NOTIFY arrives but no transfer starts | The sender is not allowed to notify, the secondary has no usable primary address, or TCP/53 is blocked. | Check allow-notify or the PowerDNS notification ACL, the primaries list, and a firewall path for TCP port 53. |
| Transfer is refused | The primary’s transfer ACL excludes the secondary, or TSIG authentication fails. | Verify the source address seen by the primary, allow-transfer or PowerDNS AXFR controls, and exact TSIG key details. |
| Initial transfer works but updates fail | IXFR history is unavailable, NOTIFY is misconfigured, or later serials are not greater. | Test a forced SOA check, inspect IXFR/AXFR fallback logs, and confirm monotonically increasing serials. |
| PowerDNS autoprimary receives NOTIFY but creates nothing | The sender is not a configured autoprimary, secondary support is disabled, or generated files cannot be written. | Check the startup-loaded autoprimary configuration, the sender address, service-account permissions, and destination-directory ownership. |
| The zone disappears after restart | Secondary state or zone files were written to a non-persistent or unwritable location. | Verify the configured storage path, permissions, filesystem persistence, and backend records. |
| The secondary serves old data while the primary is current | A resolver cache is being queried instead of the secondary, or the secondary’s own serial is stale. | Query the secondary’s address directly and compare its SOA serial with the primary. |
| Only some clients receive answers | Delegation, A/AAAA records, firewall rules, or one authoritative server’s data is inconsistent. | Query each authoritative address separately and check the parent delegation and reachability over the enabled transports. |
BIND explicit zones versus PowerDNS autoprimary
| Decision point | BIND explicit secondary | PowerDNS autoprimary |
|---|---|---|
| How a zone appears | An administrator declares each zone with type secondary, a primaries list, and storage. |
A trusted NOTIFY can create the secondary domain automatically after the autoprimary relationship is configured. |
| Primary-side transfer policy | Use allow-transfer; use also-notify for secondary addresses that need explicit notification. |
Use the PowerDNS transfer-source controls for the installed release and restrict the trusted autoprimary relationship. |
| Notification policy | The declared primary is normally trusted; allow-notify is for additional required senders. |
Use the autoprimary allowlist and notification controls such as allow-notify-from where supported. |
| Filesystem concern | The secondary storage path must be writable by BIND and protected from manual edits. | BIND-backend autosecondary operation additionally needs writable generated configuration and zone-file destinations. |
| TSIG | Configure matching key material and reference it in transfer and notification policy supported by the release. | Configure matching TSIG metadata and require it for the relevant transfer and notification paths where supported. |
| Operational style | Predictable and reviewable in configuration management; each zone is visible before service reload. | Efficient for large or changing zone sets, but requires stronger monitoring of who may trigger provisioning. |
Production checklist
- Publish the intended primary and secondary in the zone NS RRset, with reachable A and/or AAAA records.
- Allow DNS queries and the required NOTIFY traffic on the transports used by your topology.
- Allow TCP port 53 from each secondary to each primary for AXFR and IXFR.
- Restrict AXFR and IXFR to known secondary addresses; never expose unrestricted transfers.
- Configure NOTIFY and verify that the secondary accepts the sender.
- Increase the SOA serial for every primary-side zone change.
- Use the same TSIG key names, secrets, and algorithms on both ends when signing is enabled.
- Confirm that secondary storage and, for PowerDNS BIND-backend autoprimary, generated-file destinations are writable by the service account and protected from unauthorized edits.
- Query each authoritative server directly and compare SOA serials after a change.
- Test both the first AXFR and a later IXFR or AXFR fallback triggered by NOTIFY.
- Retain transfer and provisioning logs long enough to diagnose a stale secondary or an unexpected automatic zone creation.
Operational conclusion
The reliable pattern is simple even when the implementation differs: the primary owns the zone, the SOA serial identifies its version, NOTIFY prompts a check, and AXFR or IXFR copies an authorized newer version over TCP. BIND gives you explicit, per-zone declarations; PowerDNS can add trusted autoprimary provisioning. In either case, narrow source ACLs, consistent TSIG settings, correct NS records, reachable port 53, and writable protected storage are what turn automatic setup into a dependable secondary service.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
