Summary

  • The DNS Authoritative Answer flag is tied to the queried name or first owner name in the Answer section. Alias targets, Authority records, glue and other Additional data in the same reply can have different provenance.
  • A defensible resolver receipt preserves each RRset’s owner, type, section, zone cut, cache source and DNSSEC state, plus every follow-up query, instead of converting one header bit into packet-wide authority or authenticity.

Imagine asking an authoritative server for shop.example and receiving three useful pieces of information. The Answer begins with a CNAME owned by shop.example. A later address RRset names a target in another zone and came from cache. The Additional section supplies another address that can spare the resolver a query. The header has AA set.

A packet-shaped audit table now makes a tempting move. It writes all three RRsets beneath authoritative = true. Months later, the target address conflicts with a direct answer from its own zone. The table cannot explain the conflict because it discarded the distinction between authority for the first name, cached data reached through an alias, and information added for convenience.

This is a hypothetical failure of evidence design, not a reported DNS incident. It exposes the unusually precise boundary built into a one-bit field.

A bit with one anchor

RFC 1035, authored by Paul Mockapetris, defines the AA bit in the DNS response header. It says the responding name server is an authority for the domain name in the Question section. It immediately handles the difficult case: the Answer can contain multiple owner names because of aliases, so AA corresponds to the name matching the query name, or to the first owner name in the Answer.

That sentence prevents a packet-level shortcut. AA is one flag, not a parallel bit beside every RRset. It reports something about the responder’s authority at the beginning of the answer path. It does not repaint all later names, all message sections or all data sources with the same provenance.

The distinction is not a defect in the flag. A compact DNS header cannot encode the complete path by which every RRset entered a response. The error begins when an observer asks that compact signal to replace the path.

Mockapetris’s companion document, RFC 1034, shows why the path can branch. A server matching authoritative zone data may copy a CNAME into the Answer, change QNAME to the canonical name and restart processing. At a delegation it puts NS records in Authority and available addresses in Additional, drawing from glue, authoritative data or cache. Before sending a response it can add other locally available records it considers useful.

One wire message can therefore be coherent and useful without being one evidence class.

The section is evidence, but not the verdict

RFC 1035 gives the response sections different jobs. Answer records answer the question. Authority records point toward an authoritative name server. Additional records relate to the query but are not strictly answers. Preserving the section is the first repair to a flattened packet, not the last.

An NS RRset in Authority and its address records in Additional work together to move a resolver forward. At a zone cut, some address data may be glue supplied by the parent because the child’s server name would otherwise be difficult to reach. That makes the data operationally necessary. It does not make the parent authoritative for all names below the cut, and it does not turn the glue into a child-zone address assertion.

The same section can also hold records with different histories at different times. A resolver needs owner name, type, class, bailiwick, source server, cache receipt and expiry—not merely “Additional”. The message layout tells where the record was carried. It does not by itself finish the provenance analysis.

RFC 2181 makes the ranking explicit. Primary-zone and zone-transfer data other than glue rank above authoritative Answer data; Authority data from an authoritative reply, glue, non-authoritative Answer data and Additional data occupy distinct lower positions. An authoritative answer from a reply can replace a cached RRset obtained earlier as Additional, while Additional information should not displace better authoritative or zone-file data.

The ranking matters because a cache is capable of laundering context accidentally. If a system stores an Additional RRset without its source rank, a later export may return it as an ordinary answer. What began as a navigation aid now looks like a direct assertion. The bytes did not become more authoritative while resting in memory.

An alias makes the boundary visible

Aliases are the strongest counterexample to “AA covers the reply”. RFC 2181 says the Answer section of an authoritative reply normally contains authoritative data, but when the sought name is an alias only the record describing the alias is necessarily authoritative. Other records may have come from cache. A client requiring authoritative data should query again for the canonical name.

RFC 6604 later restated this in terms of CNAME and DNAME chains. Authoritative status can differ for each answer in an xNAME chain. The rule for AA remains anchored to whether the server is authoritative for the zone containing the first owner name in the Answer.

Suppose the first server is authoritative for shop.example and returns a CNAME to service.vendor.test. It may be perfectly correct to set AA for the alias. A cached address for the target can still be useful. Yet a receipt that says “authoritative address for service.vendor.test” has crossed a zone boundary without recording a new authority. A follow-up query to the target’s authoritative servers is a separate event, with its own response and flags.

The evidence model should keep each alias step as an edge: input name, CNAME or DNAME RRset, authoritative zone, source response, next name and the query that followed. Collapsing the chain to the final address may be convenient for an application cache. It is not sufficient for an audit that needs to say which authority asserted what.

Authority is not authenticity

The word “authoritative” invites an even larger mistake: treating AA as a cryptographic assurance. RFC 6604 is direct that the AA header flag is not protected by DNSSEC. Transaction security such as TSIG or SIG(0) can protect communication with a server, but DNSSEC validation of data remains a different process.

RFC 4035 assigns security status to RRsets. A resolver can classify one as Secure when it builds a chain from a trust anchor, Insecure when it knows no such chain applies, Bogus when expected proof fails, or Indeterminate when it cannot decide. Those states arise from DNSKEY, DS, signatures, denial proofs, policy and validation—not from AA.

The AD flag has another defined scope. A security-aware server must not set it unless it considers all RRsets in Answer and Authority authentic, subject to the specification’s detailed rules. RFC 6604 deliberately contrasts this with AA. Even then, a client must know whether it trusts the recursive server and its channel; an upstream AD assertion is not automatically the client’s own validation receipt. Additional data is outside the headline AD condition and still needs its own treatment.

A careful record can therefore contain several simultaneous truths: AA was set correctly for the first answer owner; one RRset validated Secure; another was Insecure; a glue address arrived in Additional; and the transport to an intermediary was not authenticated. Reducing that row set to one green “authoritative” badge destroys information.

Mockapetris’s place in the record

The Internet Hall of Fame profile credits Paul Mockapetris with inventing DNS in 1983 while at USC’s Information Sciences Institute. RFC 1034 and RFC 1035 preserve his authorship of the concepts and wire specification that followed. The profile also supplies the historical public portrait used to ground this article’s editorial image.

That record establishes identity and contribution, not present operational authority. Mockapetris does not become the operator of a resolver, the owner of a zone or the source of a modern deployment decision because his name appears on the foundation documents. Later RFCs are collective standards work that clarify how implementations should preserve distinctions already exposed by the original design.

The useful human lesson is narrower. DNS scaled naming by distributing authority, and its messages had to carry results from different stages of that distribution. The AA bit was never a universal certificate stamped over every byte. Its restraint is part of the architecture.

Build an RRset receipt, not a packet label

Start with the query tuple: QNAME, QTYPE, QCLASS, recursion intent, DNSSEC OK and Checking Disabled choices, transaction identifier and send time. Save the response bytes, endpoint, transport, receipt time and any transaction-authentication evidence before normalization.

Then split the message by RRset. For each set, retain owner, type, class, section, observed TTL, zone cut and bailiwick. Record whether the source was local zone data, a transfer, cache, glue or fresh resolution when that information is available. A recursive client may not know the authoritative server’s internal source, so uncertainty must remain explicit rather than being filled from AA.

Store the AA anchor separately: original query name, first Answer owner, responder and zone for which the responder was considered authoritative. Record every alias transition and follow-up query. For referrals, keep the parent NS RRset, glue addresses, child query and later authoritative child answer as linked but independent receipts.

Finally, attach per-RRset DNSSEC status and validation evidence. Preserve signatures, trust-anchor path, validation time, policy and failure reason. Keep any received AD flag as an upstream assertion, not a replacement for local validation. When an application consumes the result, record which RRset and cache generation it used.

The final statement can then be exact: this server set AA for this first owner; this RRset came from this section and source; this validator assigned this security state; this later query established or failed to establish authority for the next name; this application used this result. One bit remains valuable because it is no longer forced to speak for the whole reply.

Sources