IT Toolbox
Guide

How to check a DNS AXFR zone transfer

This BAOI guide provides a structured method for checking a zone transfer dns axfr without multiplying unnecessary changes.

TopicIT Networking →
⌚ About 2 min read
View my favorites
& DNS Network Intermediate. 15-30 min

This BAOI guide provides a structured method for checking a zone transfer dns axfr without multiplying unnecessary changes.

Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une backup ou un retour arrière lorsque l’action peut modifier la configuration.

Étapes à suivre

  1. 1

    Set perimeter

    Identify the equipment, service, affected users and start time.

  2. 2

    Collect Elements

    Record the exact messages, logs and useful settings.

  3. 3

    Test methodically

    Start with the basic dependencies before the application components.

  4. 4

    Apply correction

    Change only the identified parameter or component.

  5. 5

    Validate

    Rewrite the full scenario and document the result.

Commands utiles

ns Outlookup -type=soa example.com.

À retenir

  • Keep the initial values for a backwards.
  • Avoid multiple simultaneous changes.
  • Compare with a functional configuration when possible.
← All les guides
Technical deep dive

Advanced DNS: diagnose DNSSEC and AXFR from the authority

Technical checkpoints

  • DNSSEC SERVFAIL often comes from a broken chain of trust: parent DS, DNSKEY, RRSIG, algorithm or signature dates.
  • Comparing a validating query with a +cd query helps distinguish missing data from validation failure.
  • AXFR should be allowed only to intended secondaries; the SOA serial helps verify they receive the correct version.

Targeted dig

Query DNSKEY/DS/RRSIG and the authority itself before changing the zone.

dig +dnssec example.com A
dig example.com DNSKEY
dig @ns1.example.com example.com AXFR

Topic-specific pitfalls

  • Changing DNSSEC keys without synchronizing the parent DS can prolong SERVFAIL.
  • Opening AXFR to the Internet exposes the entire zone and is not an acceptable production test.

How to validate

  • The DS→DNSKEY→RRSIG chain validates and signature dates are correct.
  • Only authorized secondaries can AXFR and their SOA serial converges.

Operational context

AXFR troubleshooting must separate network reachability, authorization and zone serial/synchronization state. Test from the actual secondary server or an explicitly authorized source because a refused transfer can be correct security behavior.

Step-by-step checks

  1. Confirm the secondary can reach the authoritative primary on the required DNS transport and that firewalls/NAT use the expected source address.
  2. Verify the primary transfer ACL allows the intended secondary and that TSIG configuration matches when used.
  3. Compare SOA serials and confirm the secondary is requesting the correct zone from the intended primary.
  4. Review authoritative DNS logs for REFUSED, NOTAUTH, TSIG or transfer interruption messages.

Useful verification commands

Use commands only on systems you administer and capture the read-only output before making a configuration change.

dig @primary.example.net example.com AXFR
dig @primary.example.net example.com SOA
dig @secondary.example.net example.com SOA

How to validate the result

An authorized AXFR from the intended secondary must complete and the secondary SOA serial must converge to the primary without opening transfers to unauthorized clients.

Evidence to keep

Record primary/secondary addresses, zone name, SOA serials, transfer response, TSIG key name (never secret material) and matching server log entry.

Frequently asked question

Is a refused AXFR always a DNS problem?

No. Public or unauthorized AXFR should normally be refused. The problem exists when an explicitly authorized secondary cannot transfer the zone.

Related BAOI resources: IT tools · procedures · IT dictionary.

♡ 0