Skip to main content

3. Zone Contents

This section describes which DNS resource records (RRs) are included in an AXFR response and which are excluded. The contents of a zone transfer are not arbitrary; specific rules govern what is and is not included.

3.1. Records to Include​

An AXFR server MUST include the following RRs in an AXFR response:

  1. SOA RR: The SOA RR for the zone apex MUST appear as the first RR in the answer section of the first response message and as the last RR in the answer section of the last response message.

  2. All authoritative RRs: All authoritative RRs owned by domain names within the zone MUST be included. This includes, but is not limited to, the following RR types:

    • NS RRs at the zone apex
    • A, AAAA, MX, CNAME, TXT, and other standard RR types
    • DNSSEC-related RRs (DNSKEY, RRSIG, NSEC, NSEC3, DS at the zone apex if present)
    • Any unknown or experimental RR types defined according to [RFC3597]

  3. RRsets: All RRs of the same owner name, class, and type constitute an RRset. All members of an RRset MUST be included in the zone transfer. It is RECOMMENDED that all RRs of the same RRset appear consecutively in the AXFR response for efficiency.

  4. Empty non-terminals: Empty non-terminal (ENT) domain names do not own any RRs but serve as placeholders in the domain name tree. However, because ENTs do not own RRs, they are not explicitly represented in AXFR responses. They are implicitly defined by the existence of subordinate names.

An AXFR server MUST NOT include the following in an AXFR response:

  1. Out-of-zone data: RRs that are not owned by domain names within the zone MUST NOT be included (except for glue records, as described in Section 3.3).

  2. Non-authoritative data: Cached data, hints, or any other non-authoritative information MUST NOT be included.

  3. OPT RRs in the answer section: EDNS(0) OPT pseudo-RRs are not zone data and MUST NOT appear in the answer section. They MAY appear only in the additional section.

3.2. Delegation Records​

A zone cut (delegation point) is a domain name in a zone where authority is delegated to another zone. At a zone cut, NS RRs indicate the delegation. The handling of delegation records in AXFR is nuanced.

Delegation NS RRs: NS RRs at a zone cut (delegating authority to a child zone) MUST be included in the AXFR response. These NS RRs are authoritative for the parent zone and indicate where authority has been delegated.

Example: If the zone example.com contains a delegation to child.example.com, the NS RRs for child.example.com MUST be included in the AXFR response for example.com.

DS RRs at zone cuts: For DNSSEC-signed zones, DS (Delegation Signer) RRs MAY appear at a zone cut in the parent zone. DS RRs at a delegation point MUST be included in the AXFR response for the parent zone.

Other RR types at zone cuts: At a zone cut, only NS RRs (and optionally DS RRs for DNSSEC) are authoritative in the parent zone. Other RR types that might exist at the same domain name are either:

  • Glue records (see Section 3.3), or
  • Occluded by the zone cut (see Section 3.5).

No other authoritative RR types (besides NS and DS) exist at a zone cut in the parent zone.

3.3. Glue Records​

Glue records are address records (A or AAAA) that exist outside the zone's authoritative scope but are necessary to prevent circular dependencies when resolving the zone's name servers.

Definition: Glue records are A or AAAA RRs that provide IP addresses for name servers listed in the zone's NS RRs, where those name servers reside within a delegated child zone.

Example: If example.com delegates to child.example.com and one of the NS RRs for child.example.com is ns1.child.example.com, then an A or AAAA RR for ns1.child.example.com would be glue in the context of the example.com zone.

AXFR behavior:

  1. Glue records MUST NOT be included in an AXFR response. Glue records are out-of-zone data and are not authoritative for the zone being transferred. The AXFR server MUST NOT send glue records in the answer section of an AXFR response.

  2. The AXFR client is responsible for obtaining glue records through other means (e.g., by querying the child zone or relying on cached data).

Rationale: Including glue records in AXFR responses would mix authoritative and non-authoritative data, potentially leading to confusion and inconsistency. By excluding glue records, the AXFR response contains only authoritative data for the zone.

Historical note: Some older DNS implementations included glue records in AXFR responses. Modern implementations MUST NOT include glue records, as this behavior is non-standard and can cause interoperability issues.

3.4. Name Compression​

DNS message format supports name compression, a technique to reduce the size of DNS messages by replacing repeated domain names with pointers to earlier occurrences of the same name within the message.

AXFR and name compression:

  1. Name compression MAY be used within individual AXFR response messages. Each DNS message in an AXFR sequence is independent in terms of name compression; pointers MUST NOT reference names in previous or subsequent messages.

  2. Name compression is particularly beneficial in AXFR responses because many RRs share common domain name suffixes (e.g., the zone name itself).

  3. An AXFR server SHOULD use name compression to reduce bandwidth and improve efficiency, but it is not required to do so.

  4. An AXFR client MUST support name compression and correctly decompress names in AXFR responses.

3.5. Occluded Names​

An occluded name is a domain name that would normally be within a zone but is hidden from the zone's view due to a zone cut. Occluded names exist subordinate to a delegation point.

Example: If example.com delegates to child.example.com, any domain names subordinate to child.example.com (such as www.child.example.com or ftp.child.example.com) are occluded from the example.com zone's perspective.

AXFR behavior:

  1. Occluded names and their associated RRs MUST NOT be included in an AXFR response for the parent zone. Only the zone cut (the NS RRs at the delegation point) is included.

  2. The contents of the delegated zone (child.example.com in the example) are transferred only via an AXFR session specifically for that zone.

Rationale: Including occluded names in a parent zone's AXFR response would violate the hierarchical structure of the DNS and would mix data from multiple zones.

Special case - DNAME: If a zone contains a DNAME RR [RFC2672], the DNAME creates a redirection, and any names subordinate to the DNAME owner are effectively occluded in the same manner as names subordinate to a delegation. DNAME-occluded names MUST NOT be included in an AXFR response.

Last updated on