PC 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 & 11Crashes, 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 minuteiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Need a server to try this on? Antihost offers Linux VPS plans with NVMe storage, full root access and a 14-day free trial.
Configure a DNS secondary (still called a “slave” in some software settings) as a read-only replica of a primary server. The reliable design is to publish both servers in the zone’s NS records, permit only the known secondary to transfer the zone, use TCP port 53 for AXFR or IXFR, send NOTIFY messages after every change, and increase the SOA serial on every edit. BIND uses an explicitly declared type secondary zone; PowerDNS can either use an explicitly created secondary domain or automatically provision one with its autoprimary feature. Automatic provisioning must still be restricted by source addresses and, where supported, TSIG authentication.
What a DNS secondary server does
A secondary is an authoritative copy of a zone that it obtains from a primary. You do not edit the secondary’s zone data independently. The primary remains the source of truth; the secondary periodically checks the zone’s SOA record and transfers the newer version.
The transfer decision depends on the SOA serial. If the serial received from the primary is arithmetically greater than the secondary’s current serial, the secondary starts a zone transfer using AXFR (a complete transfer) or IXFR (an incremental transfer), over TCP port 53. A primary can send DNS NOTIFY immediately after loading or reloading a zone, causing the secondary to check the SOA without waiting for its normal refresh interval.
- The primary loads a zone change and increments the SOA serial.
- The primary sends NOTIFY to configured secondaries.
- The secondary accepts the notification only if its notification policy allows that sender.
- The secondary queries the primary’s SOA record and compares serials.
- If the primary serial is higher, the secondary requests IXFR or AXFR over TCP 53.
- The secondary writes the transferred data to its configured storage and serves the new serial authoritatively.
A correct, monotonically increasing serial is therefore essential. Changing a record without changing the serial leaves a correctly functioning secondary believing that no update exists. NOTIFY improves speed, but it does not replace the serial comparison or transfer authorization.
#1 Best Overall
- Used Book in Good Condition
Plan the primary-secondary topology
Publish both authoritative servers
Put the intended primary and secondary names in the zone’s NS RRset. Each name needs reachable A and/or AAAA records in the parent delegation or at the appropriate authoritative level. A secondary that is not reachable by clients, or whose address record is missing, cannot provide useful resilience even when transfers work.
Open the required traffic
- Permit DNS queries and NOTIFY traffic between the servers as required by your network policy. DNS commonly uses UDP, and TCP is also required for reliable transfers and may be used for queries.
- Permit TCP port 53 from the secondary to the primary for AXFR and IXFR.
- Permit the primary to send NOTIFY to the secondary’s address. If a firewall or security group is stateful, allow the corresponding return traffic.
- Do not expose unrestricted zone transfers to the Internet. A transfer contains the complete zone and can reveal internal names.
Choose an update model
| Model | How zones appear on the secondary | When it fits |
|---|---|---|
| BIND explicit secondary | Each zone is declared with type secondary and a primary list. |
Predictable, manually reviewed estates or environments where BIND is already the standard. |
| PowerDNS explicit secondary | An administrator creates a secondary domain entry and identifies its primary addresses. | Deployments that want explicit per-domain control in PowerDNS. |
| PowerDNS autoprimary | A trusted primary notification can create the secondary domain automatically. | Environments onboarding many zones, provided notification sources and storage permissions are tightly controlled. |
Directive names and accepted values can differ between installed BIND and PowerDNS releases. Use the syntax shipped with your version, then validate configuration before restarting a nameserver.
Configure an explicit BIND secondary
1. Prepare the primary
On the primary, declare the zone as a primary zone and restrict transfers to the secondary’s address. The following is an explanatory pattern; replace addresses, paths, and key names with values from your deployment.
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 important boundary: it identifies who may request AXFR or IXFR. also-notify is useful when the secondary should receive NOTIFY but is not fully represented by the zone’s NS set. Keep the address list narrow; add a TSIG identity when your policy requires signed transfers and notifications.
2. Declare the secondary zone
On the receiving BIND server, use type secondary and list the primary in primaries. BIND treats secondary and the older slave spelling as synonyms, but “secondary” is the current terminology.
zone "example.com" {
type secondary;
primaries { 192.0.2.10; };
file "slaves/example.com";
};The file path is where BIND stores the transferred zone. The account running BIND must be able to create and update that file, while ordinary users should not be able to edit it. Use the writable slave-data directory supplied by your operating-system package rather than placing transferred data in a source-controlled master directory.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →3. Control notification senders only when needed
BIND normally accepts NOTIFY from configured primaries. Add allow-notify on the secondary only when additional, explicitly trusted notification senders are required. Broad notification ACLs can cause unnecessary SOA checks and make spoofed update attempts harder to distinguish from legitimate traffic.
4. Validate and reload
- Check the configuration with the validation utility supplied by your BIND package, such as
named-checkconf. Correct syntax errors before reloading. - Confirm that the primary’s zone file has a new SOA serial for every intended change.
- Reload the primary, then inspect its logs for a NOTIFY sent to the secondary.
- Reload or start the secondary and inspect transfer logs for an accepted NOTIFY, an SOA comparison, and an AXFR or IXFR request.
- Query the secondary directly for the SOA record and compare its serial with the primary. Query an address or text record as an additional end-to-end check.
Do not treat an apparently successful daemon reload as proof of synchronization. The decisive check is the serial served by the secondary and the transfer result recorded in its logs.
Configure an explicit PowerDNS secondary
1. Enable secondary operation
Enable primary/secondary functionality in the PowerDNS configuration appropriate to your backend and release. PowerDNS documentation uses MASTER for a primary domain and SLAVE or SECONDARY for a receiving domain, depending on the interface and version.
2. Create the domain on each side
On the primary, set the domain type to MASTER. On the receiving server, create the domain as SLAVE or SECONDARY and record the primary IP address or addresses in the domain’s configuration. If you use more than one primary, list every address that is intended to serve transfers.
3. Make the zone authoritative and coherent
The zone’s NS records must identify the authoritative servers, and corresponding A or AAAA records must resolve those names. Ensure the parent delegation points to the same authoritative set. A transfer can complete successfully while delegation is still wrong, so test from outside the servers as well as by querying each server directly.
4. Configure transfer and notification policy
Permit AXFR or IXFR only from known secondary addresses. Restrict accepted NOTIFY sources with the PowerDNS controls available in your release; documentation commonly refers to allow-notify-from and separate AXFR source controls. If signed operation is enabled, configure matching TSIG metadata and key names on both ends.
5. Verify the result
- Increment the primary SOA serial and reload the primary.
- Confirm that the primary sends NOTIFY and that the secondary accepts it.
- Check the PowerDNS log for the SOA comparison and transfer type.
- Query the secondary for the SOA and changed records.
- Repeat with a second change to verify IXFR or the configured fallback behavior, rather than testing only the initial AXFR.
Automatically provision secondaries with PowerDNS autoprimary
How autoprimary works
An autoprimary is a primary host that the receiving PowerDNS server trusts to originate zones. When a bona fide NOTIFY arrives from that configured primary, PowerDNS can create the secondary domain entry automatically, configure itself as a secondary, and begin the transfer. This removes the need to create a domain record manually for every new zone, but it does not remove the need for transfer ACLs, serial management, or monitoring.
Set up the trust relationship
- Enable secondary support in PowerDNS.
- Configure the autoprimary relationship, including the trusted primary address and any required name or metadata fields for your release.
- Ensure the primary is configured to send NOTIFY to the receiving server after a zone is loaded or changed.
- Restrict accepted NOTIFY senders to the configured primary addresses. Never treat any packet claiming to be a primary as sufficient authorization.
- Restrict AXFR and IXFR sources so that only the intended secondary can request data.
- Trigger a test zone change, then confirm that the notification creates the secondary domain and that the transfer completes.
BIND-backend filesystem requirements
With the PowerDNS BIND backend, autoprimary operation may generate configuration and transferred zone files. The PowerDNS process must be able to write the destination directory and the generated files. A read-only directory, an incorrect owner, or restrictive parent-directory permissions can make automatic provisioning appear to accept NOTIFY while failing at the file-creation or transfer stage.
Free tools Windows power users keep installed
One-click scans. No signup required.
- Choose a dedicated directory for generated secondary data.
- Give only the PowerDNS service account the write permission it needs.
- Keep the directory protected from unprivileged edits; a modified transferred file can corrupt authoritative data.
- Include the autoprimary configuration at startup, not only in a temporary command-line test.
- After provisioning, verify both the generated domain configuration and the resulting zone file on disk.
Exact option names and configuration-file locations vary by PowerDNS release and backend. Treat the release documentation and packaged example configuration as authoritative for the final syntax.
Secure transfers and NOTIFY with TSIG
Address-based ACLs identify where a request came from; TSIG adds a shared-secret signature that authenticates the DNS message. Use both when your threat model requires protection against forged NOTIFY packets or unauthorized transfer requests.
Keep both ends identical
- Install the same key name on the primary and secondary.
- Use the same supported algorithm and secret on both servers.
- Apply the key consistently to transfer authorization and, where configured, NOTIFY authentication.
- Protect key files from other users and avoid placing secrets in world-readable configuration or backups.
- Check logs for key-name, algorithm, clock, or signature mismatches; a transfer can fail even when the IP ACL is correct.
BIND expresses transfer and notification policy with controls such as allow-transfer, also-notify, and allow-notify. PowerDNS provides notification-source, AXFR-source, and TSIG-related settings whose exact names depend on the backend and release. Do not enable signed operation on only one side: an unsigned request will not satisfy a policy that requires a valid TSIG.
BIND explicit setup versus PowerDNS autoprimary
| Decision point | BIND explicit secondary | PowerDNS autoprimary |
|---|---|---|
| Zone creation | Administrator declares every zone with type secondary and a primary list. |
A trusted NOTIFY can create the secondary domain automatically. |
| Primary authorization | allow-transfer limits transfer requesters; notification behavior uses also-notify and optional allow-notify. |
Notification-source and AXFR-source controls limit who may notify and transfer; names vary by release. |
| Operational effort | More deliberate configuration per zone, with straightforward review of every declaration. | Less repetitive onboarding, but trust relationships and automatic changes require stronger monitoring. |
| Storage concern | Secondary zone-file paths must be writable by BIND. | BIND-backend autoprimary also needs writable directories for generated configuration and transferred files. |
| TSIG and DNSSEC | Configure keys and validation policies in BIND; DNSSEC behavior must match the signed zone design. | Configure matching TSIG metadata and backend-specific DNSSEC handling; automatic provisioning does not itself sign a zone. |
| Best fit | Small or tightly governed estates where explicit declarations are desirable. | Large or frequently changing estates with a controlled list of trusted primaries. |
Test initial AXFR and later IXFR updates
Initial provisioning test
- Start with an empty secondary data directory or a newly declared domain.
- Verify that the primary’s transfer ACL permits the secondary address and that TCP 53 is reachable.
- Reload the primary and confirm a NOTIFY event.
- Watch the secondary log for an AXFR request and completion.
- Query the secondary directly for the SOA serial and several representative records.
Incremental update test
- Change one record on the primary and increment the SOA serial.
- Reload the primary and confirm NOTIFY delivery.
- Confirm that the secondary compares serials and requests IXFR when both sides support it, or AXFR when configured or required.
- Query the changed record on the secondary and verify that its SOA serial now matches the primary.
Failure and recovery test
Temporarily block TCP 53 or stop the primary, then observe retries and error logging on the secondary. Restore connectivity and verify that the secondary catches up. This test distinguishes a replica that can recover from an outage from one that merely served an already-copied file.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsTroubleshoot common synchronization failures
The secondary still serves the old serial
- Check that the primary SOA serial was incremented and is arithmetically higher, not merely formatted differently.
- Confirm that the secondary is querying the intended primary address.
- Check whether NOTIFY was sent and accepted; without NOTIFY, wait for the configured refresh interval or trigger a supported reload/check.
- Query both servers directly to avoid confusing a recursive resolver’s cached answer with authoritative data.
Transfer times out
- Test TCP 53 in both directions required by the transfer and stateful firewall rules.
- Check that
allow-transferor the PowerDNS AXFR source policy contains the secondary’s actual address, including the address family in use. - Check TSIG key name, algorithm, and secret on both sides if signing is enabled.
NOTIFY is ignored
- Verify that the message source matches the configured primary or an explicitly allowed sender.
- Check
also-notifyon BIND or the corresponding PowerDNS notification settings. - Ensure the primary is actually reloading the zone after the edit and that the SOA serial changed.
PowerDNS autoprimary creates nothing
- Confirm that the autoprimary relationship is loaded at startup and references the sending primary’s address.
- Confirm that the NOTIFY is bona fide according to the configured trust and source controls.
- Check write permission on the generated-configuration and zone-file directories, including parent directories.
- Inspect logs for a domain-creation decision followed by a filesystem or transfer error.
Clients never use the secondary
- Check that the zone NS RRset and parent delegation list the secondary.
- Verify A and AAAA records for the secondary names and test reachability from outside the server network.
- Confirm that the secondary is answering authoritatively rather than only holding a local, non-authoritative copy.
Production checklist
- Primary and secondary names appear in the zone NS RRset and have reachable address records.
- TCP 53 is permitted for AXFR and IXFR; required query and NOTIFY traffic is also permitted.
- Transfer ACLs contain only intended secondary addresses.
- NOTIFY is enabled, and the secondary accepts only trusted senders.
- Every primary-side zone change increments the SOA serial.
- TSIG keys, algorithms, and names match wherever signed transfers or notifications are required.
- Secondary storage is writable by the DNS service and protected from unauthorized edits.
- Logs are monitored for serial comparisons, transfer failures, rejected NOTIFY messages, and permission errors.
- Both an initial AXFR and a later IXFR/NOTIFY cycle have been tested.
- After each deployment change, query the primary and secondary directly and compare SOA serials.
Bottom line
For BIND, automatic synchronization starts with an explicit type secondary declaration, a correct primaries list, a tightly scoped transfer ACL, and valid NOTIFY behavior. For PowerDNS, explicit secondary domains provide the same control, while autoprimary can create domains after a trusted notification. In either implementation, reliable operation comes from the same fundamentals: increasing SOA serials, reachable TCP 53, restricted transfer and notification sources, matching TSIG settings when used, and writable but protected secondary storage.
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.
