Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesA DNS secondary server is a synchronized, read-only replica of a primary zone. To configure one reliably, define the secondary relationship, allow authenticated AXFR or IXFR transfers over TCP port 53, enable NOTIFY so changes are detected quickly, and make every primary-side zone change increase the SOA serial. BIND normally requires each secondary zone to be declared in configuration; PowerDNS can either use the same explicit model or automatically create secondary zones with its autoprimary feature.
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
The terms secondary and slave describe the same DNS role. “Secondary” is the current term in most BIND and PowerDNS documentation, while configuration directives may still accept slave as a compatibility synonym.
As an Amazon Associate I earn from qualifying purchases.
A secondary is not an independently edited copy. The primary remains the authoritative editing point. The secondary stores a transferred copy and answers authoritative queries from that copy. Any manual change made only on the secondary will be replaced by the next successful transfer and can create inconsistent answers in the meantime.
The normal design has at least two authoritative servers, published in the zone’s NS record set. Their A and/or AAAA records must themselves be reachable, because resolvers need addresses for both servers. The secondary should be on a separate host, network path, or failure domain from the primary when practical.
#1 Best Overall
How AXFR, IXFR, SOA, and NOTIFY fit together
SOA serial comparison
The secondary periodically obtains the zone’s Start of Authority (SOA) record from the primary and compares the primary serial with its own serial. If the received serial is arithmetically greater, the secondary starts a transfer. Every primary-side edit therefore needs a serial increment. A timestamp-like serial such as 2026101501 is common, but any scheme is acceptable if it increases correctly and remains within DNS serial arithmetic rules.
AXFR for a complete copy
AXFR transfers the complete zone. It is normally used when a secondary has no local copy, when its copy is too old for an incremental history, or when the server is explicitly configured to request a full transfer.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
IXFR for changes
IXFR transfers the differences between serials when the primary has the required change history and both servers support the negotiated mode. It reduces transfer volume for ordinary edits, but it does not remove the need for AXFR: an initial synchronization or an unavailable change history can require a full transfer.
NOTIFY for prompt checks
After loading or reloading a zone, the primary can send NOTIFY to configured secondaries. Receipt of NOTIFY causes the secondary to check the SOA immediately instead of waiting for its normal refresh interval. NOTIFY does not contain the zone data; it prompts the serial check, after which AXFR or IXFR is performed over TCP port 53.
Both TCP and DNS query traffic must be considered in firewall policy. AXFR and IXFR use TCP port 53. SOA queries and NOTIFY use DNS traffic, commonly UDP but potentially TCP depending on response size and implementation behavior.
Plan the relationship before enabling automatic provisioning
- Choose the primary and one or more secondary IP addresses, including IPv6 addresses if used.
- Publish those servers in the zone’s NS RRset and publish reachable address records for each hostname.
- Decide whether zones will be declared individually or created automatically after a trusted notification.
- Permit transfers only from known secondary addresses or authenticated identities.
- Choose whether TSIG will authenticate NOTIFY, transfers, or both. Use the same key name and algorithm on every participating server.
- Reserve a writable, access-controlled directory for transferred zone data. This is especially important with PowerDNS’s BIND backend and autoprimary mode.
- Record the software and release running on each host. Directive names and accepted synonyms can vary between installed BIND and PowerDNS versions.
Automatic setup should reduce repetitive zone declarations, not remove trust decisions. A server that accepts NOTIFY or AXFR from arbitrary Internet addresses can be induced to create unwanted zones or disclose authoritative data.
Configure an explicit secondary in BIND
1. Define the secondary zone
On the receiving BIND server, declare the zone as a secondary and identify the primary in the primaries list. Specify a local file path for the transferred copy. The following is an explanatory pattern; replace the addresses and paths with values from your deployment and validate it against the installed BIND release.
// secondary named.conf
zone "example.com" {
type secondary;
primaries { 192.0.2.10; };
file "slaves/example.com";
};BIND also recognizes type slave as a synonym in versions that retain the legacy term. Using type secondary makes the role clear to operators and aligns with current terminology.
2. Permit the transfer on the primary
On the primary, declare the zone as a primary and restrict allow-transfer to the secondary address. The primary’s zone file must contain the authoritative NS records and an SOA record whose serial is increased whenever the zone changes.
// 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; };
};also-notify is useful when a secondary must receive notifications even though it is not fully represented by the zone’s NS set. On the secondary, allow-notify is normally unnecessary when notifications come from the configured primary; add it only when additional, explicitly trusted notification senders are required.
Free tools Windows power users keep installed
One-click scans. No signup required.
Rank #3
- Used Book in Good Condition
3. Make the transfer path usable
Create the configured storage directory with ownership and permissions that let the BIND service write transferred data while preventing ordinary users from modifying it. Permit TCP port 53 from the secondary to the primary, and permit the required DNS traffic for SOA queries and NOTIFY. Do not expose an unrestricted transfer rule such as an any-address policy.
4. Add TSIG when address-only trust is insufficient
TSIG adds a shared-secret signature to authenticated DNS messages. Define the same key name, secret, and algorithm on both servers, then reference that key in the transfer and notification controls supported by your BIND release. A typical policy is to require the key for allow-transfer and to accept NOTIFY only from the primary address with that key. Keep the key file readable only by the DNS service account and administrators.
Do not mix an unsigned policy on one server with a signed policy on the other. A mismatched key name, algorithm, secret, or system clock can make valid-looking requests fail authentication. Check the installed BIND documentation for the exact server, also-notify, and ACL syntax before deploying.
5. Reload and validate
- Check the configuration and zone-file syntax with the validation utility supplied by your BIND installation.
- Reload the primary, then confirm that it sends NOTIFY to the intended secondary.
- Inspect the secondary’s log for an accepted notification followed by AXFR or IXFR activity.
- Query the primary and secondary directly for the SOA record and compare serials.
- Make a controlled zone edit, increment the serial, reload the primary, and verify that the secondary obtains the new serial.
Configure an explicit secondary in PowerDNS
1. Enable primary/secondary operation
PowerDNS must have primary/secondary support enabled in the relevant configuration. On the primary, set the domain type to MASTER. On the receiving server, set it to SLAVE or SECONDARY, depending on the PowerDNS release and backend. The secondary’s domain configuration must identify the primary IP addresses.
The zone itself must publish the intended authoritative NS records and corresponding address records. Those records are part of the DNS design; the PowerDNS role setting alone does not make unreachable or incorrectly named authoritative servers usable.
Rank #4
2. Configure transfer and notification controls
Permit AXFR and IXFR from the known secondary addresses, and configure the primary to send NOTIFY after a zone load or reload. On the receiving server, configure which sources may send NOTIFY. PowerDNS provides source controls such as allow-notify-from and transfer-source restrictions; exact parameter names and backend behavior depend on the installed release.
3. Protect the backend and zone storage
Ensure the PowerDNS service can write its domain metadata and transferred zone data. A read-only directory, incorrect service-account ownership, or a mandatory-access-control policy can leave the domain entry present while preventing the actual transfer from being saved. Protect the directory from unauthorized edits because a local modification can be overwritten by the next transfer and can obscure the real synchronization state.
4. Test both transfer forms
Test an initial synchronization, which commonly uses AXFR, and then test a later serial increment with NOTIFY and IXFR. If the incremental exchange is unavailable, the servers should fall back to a complete transfer when their configuration and versions permit it. Logs should identify whether the failure is authorization, connectivity, serial comparison, or storage related.
Use PowerDNS autoprimary for automatic secondary creation
What autoprimary does
An autoprimary is a trusted primary host that is allowed to originate zones for which a PowerDNS server should become secondary. When PowerDNS receives a bona fide NOTIFY from that configured autoprimary, it can create the secondary domain entry automatically and begin the transfer. This removes the need to add a separate domain declaration for every zone, but it does not remove the need to define which primaries are trusted.
Required setup sequence
- Enable secondary support in the PowerDNS configuration used at startup.
- Declare the permitted autoprimary address or addresses and associate them with the policy used for automatic provisioning.
- Configure the primary to send NOTIFY after each zone load or reload.
- Restrict accepted NOTIFY sources to the configured autoprimary addresses, and add TSIG requirements where supported.
- Restrict AXFR and IXFR requests and responses so that only the intended secondary relationship is authorized.
- For the BIND backend, include the autoprimary configuration at startup and make the destination directory for generated configuration and transferred zone files writable by the PowerDNS service.
- Reload or restart PowerDNS as required by the release, then send a controlled NOTIFY from the primary.
- Confirm that PowerDNS creates the secondary domain entry, requests the zone, writes the file, and serves the resulting data authoritatively.
Autoprimary is most useful when many zones follow the same trust relationship. It is less appropriate when every zone requires a different policy, approval step, storage location, or transfer key; explicit declarations make those differences visible.
Do not treat any NOTIFY as an enrollment request
A NOTIFY packet is only a trigger to check a serial. In an autoprimary design it can also trigger provisioning, so accepting it from arbitrary addresses effectively lets outsiders request domain creation. Use source ACLs, TSIG, and transfer authorization together. A source address should identify the expected host, while TSIG proves possession of the shared secret.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Secure transfers and notifications with TSIG
AXFR and IXFR can reveal the complete contents of a zone, including hostnames that are not intended for public discovery. Address-based ACLs reduce exposure, but TSIG provides an additional authentication layer. Configure the same key material on both ends and apply it consistently to the messages your deployment signs.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →- Key identity: key names must match exactly, including dots and capitalization conventions used by the software.
- Algorithm: both servers must support and be configured for the same algorithm.
- Secret: copy the secret without whitespace changes and protect its file permissions.
- Policy: require the key for transfers and, where supported, for NOTIFY acceptance and SOA checks.
- Rotation: plan an overlap period in which old and new keys can be recognized, then remove the old key after all participants are updated.
TSIG does not encrypt zone contents. It authenticates the message and helps prevent unauthorized transfers or forged notifications. If confidentiality of the DNS data itself is required, use an architecture and transport mechanism that provides encryption in addition to TSIG.
Verification and troubleshooting
The secondary never receives a zone
- Query the primary’s SOA and confirm that its serial is greater than the secondary’s serial.
- Check that the secondary is configured with the correct primary address and zone name.
- Test TCP port 53 in both directions required by the transfer, not only UDP queries.
- Review the primary log for a refused transfer. An
allow-transferACL that omits the secondary is a common cause. - Review the secondary log for a rejected NOTIFY, a failed SOA query, or a TSIG error.
- Confirm that the secondary’s storage path exists and is writable by the DNS service.
NOTIFY arrives but no transfer starts
NOTIFY does not force a transfer when the serial is unchanged or lower. Verify that the primary zone was actually reloaded and that the SOA serial was incremented. If the notification source is not in the secondary’s accepted list, add only the intended sender or correct the primary’s source address. With TSIG enabled, compare key names, algorithms, secrets, and system clocks.
AXFR works but IXFR fails
Check whether the primary retains the required incremental history and whether both implementations negotiated IXFR. A missing or expired change history can require AXFR. The operational result should still be a matching serial; investigate the reason for the fallback if transfer volume or change frequency makes it significant.
PowerDNS creates the domain but cannot serve it
Inspect backend records and the generated zone-file directory. For BIND-backend autoprimary operation, verify that the startup configuration includes the autoprimary definition and that the destination directory is writable by PowerDNS. Also check mandatory-access-control denials, ownership, disk space, and path spelling.
Recommended Free Tools
The servers answer different data
Query each authoritative server directly, compare SOA serials, and then compare the records affected by the change. If serials differ, resolve transfer authorization, connectivity, notification, or storage problems before editing either secondary. If serials match but answers differ, check whether views, backend data, DNSSEC state, or response policy differs between servers.
BIND explicit configuration versus PowerDNS autoprimary
| Decision point | BIND explicit secondary | PowerDNS autoprimary |
|---|---|---|
| Zone enrollment | Each secondary zone is declared with type secondary, a primaries list, and a storage file. |
A trusted NOTIFY can create the secondary domain entry automatically after autoprimary is configured. |
| Primary authorization | The primary uses allow-transfer; notification behavior can use also-notify. |
Transfer and notification source controls are configured in PowerDNS, with primary-side NOTIFY still required. |
| Notification acceptance | The configured primary is trusted by default for the zone; allow-notify is used when additional senders are needed. |
Autoprimary enrollment must be constrained to trusted source addresses and, where supported, TSIG. |
| Filesystem concern | The secondary’s configured zone-file path must be writable by BIND. | BIND-backend autoprimary requires writable generated-configuration and transferred-zone destinations. |
| Operational visibility | Zone declarations make every enrolled zone visible in configuration. | Automatic enrollment reduces repetitive configuration but requires monitoring of dynamically created domain entries. |
| Best fit | Smaller estates or environments where each zone needs an explicit, reviewable policy. | Larger groups of similarly trusted zones that can share one controlled provisioning relationship. |
Neither model eliminates the need to monitor serials, transfer logs, ACLs, and storage. Automatic enrollment changes where the declaration is created; it does not change the DNS transfer protocol.
Quick Recap
Production checklist
- Primary and secondary hostnames appear in the zone NS RRset.
- Every authoritative hostname has reachable A and/or AAAA records.
- The primary’s SOA serial increases for every zone change.
- TCP port 53 is permitted for AXFR and IXFR.
- DNS query and NOTIFY traffic is permitted according to the implementation and firewall design.
- AXFR is restricted to known secondary addresses or authenticated TSIG identities.
- NOTIFY is enabled on the primary and accepted only from trusted senders.
- TSIG key names, algorithms, and secrets match on both ends when signing is enabled.
- Secondary storage is writable by the service and protected from unauthorized local edits.
- PowerDNS BIND-backend autoprimary directories are writable and the autoprimary definition is loaded at startup.
- An initial AXFR has been tested.
- A subsequent serial increment has been tested with NOTIFY and IXFR or documented AXFR fallback.
- Direct SOA queries to every authoritative server show the expected serial after a change.
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.
