Summary

  • The IP version carrying a DNS exchange does not determine the address family of the records being requested: an AAAA query can travel over IPv4, and an A query over IPv6.
  • RFC 3596 paired the new 128-bit AAAA record with updates to DNS's existing response rules, while keeping DNS's name space and its transport path conceptually separate.

One question, two different layers

Consider a resolver sending a DNS question inside an IPv4 packet: “What AAAA records are associated with this name?” The packet's IPv4 header describes how that particular message travels. The question's type asks for IPv6 address data. There is no contradiction. RFC 3596 says explicitly that the IP version used to query records is independent of the protocol version of the records; RFC 4472 later restates the operational consequence: AAAA can be queried over IPv4, and A over IPv6.

That sentence is easy to skip because two different meanings of “IPv4” and “IPv6” sit beside each other. One names the network-layer envelope. The other names data in a DNS resource record. Treating them as one switch would make a DNS response depend on the path taken by the question, even where that path says nothing about what address data belongs to the name.

The separation also cuts in the other direction. An IPv6 transport does not force a DNS question to ask for AAAA; a resolver can use it to ask for A. A DNS server should not infer that a requester can use an answer's address family from the family of the packet that reached it. The specification defines the independence, not the eventual reachability or success of any application connection.

Extending the record, not replacing the road

The earlier DNS model had the A record for a 32-bit IPv4 address. RFC 1886 introduced AAAA as the corresponding way to store a 128-bit IPv6 address, together with reverse-lookup support. RFC 3152 separately moved the reverse tree from IP6.INT to IP6.ARPA. RFC 3596 consolidated the IPv6 DNS changes, retained the existing IPv4 support, and made the forward record explicit: an AAAA record of type 28 contains one IPv6 address.

This was an extension to the data model inside DNS, not a new transport protocol for DNS messages. A question and answer still use the ordinary DNS exchange machinery. The network carrying that exchange can be IPv4 or IPv6 independently of whether the requested record is A or AAAA. DNS's globally shared name space did not have to split into an “IPv4 DNS” and an “IPv6 DNS” simply because records could now contain both families.

The design discussion had a real alternative. A6 records could represent parts of an address and link those pieces through DNS, offering a way to reduce some updates during prefix changes. That flexibility came with chained lookups and dependencies. RFC 3363 recorded the standards decision to keep AAAA on the standards track and move A6 and Bit Labels to Experimental; RFC 3364 set out the tradeoffs. RFC 3596 therefore chose a complete address record that was straightforward to retrieve, not a universal answer to renumbering or deployment.

The reply rules mattered too

RFC 3596 did more than assign a record type. It updated additional-section processing for NS, SRV and MX questions so that relevant A and AAAA addresses available locally could be included. An AAAA query itself does not trigger additional-section processing. These distinctions matter because an RR requested directly and an address supplied as supporting data in another answer are separate response behaviors.

But “the server can include” is not “the response proves every address exists.” The specification describes protocol behavior; local data may be absent, caches may be incomplete, and a record is not a test packet. RFC 4472 warns against choosing or filtering answer data merely from the transport family: the family used to reach a DNS server often does not correspond to the family of the records the client needs. Suppressing one family on that basis can make the same name appear to have different facts depending on which network path delivered the query.

The distinction persists after DNS responds. An AAAA answer is evidence that DNS returned IPv6 address data for a name. It does not prove that an IPv6 route exists from this resolver, that a service listens at that address, that a firewall permits a session, that DNSSEC validated the data, or that an application connected. Likewise, receiving that answer over IPv4 says nothing about whether a later service connection will use IPv4 or IPv6.

A boundary that made coexistence legible

RFC 3596's historical contribution is often summarized as “DNS gained AAAA.” It also preserved an important invariant while the Internet added another address family: the envelope transporting a query and the address family encoded in its answer are independent dimensions. That gave resolvers and servers a common namespace in which IPv4 transport could retrieve IPv6 data during transition—and IPv6 transport could still retrieve IPv4 data—without claiming that either path or answer guaranteed service.

The standard establishes the mechanism and the intended separation. It does not establish how widely implementations followed it, whether any particular resolver behaved correctly, or whether a name's A and AAAA records were simultaneously useful. Those questions need implementation, configuration, measurement and reachability evidence of their own.

Sources: RFC 1034; RFC 1035; RFC 1886; RFC 3152; RFC 3363; RFC 3364; RFC 3596; RFC 3597; RFC 4472.