Add both address families when relevant
05NS, MX and SRV answers refer to other names. Their additional-address processing includes relevant IPv4 and IPv6 records available locally.
The illustrated application gate stops an assumption that received DNS data is automatically authenticated. Adding AAAA or an ip6.arpa name does not itself verify it or encrypt traffic.
Source for this drawing: RFC 3596 · Read RFC section 3 ↗
New to this? Start hereA quick picture + helpful background
A message needs an address.
Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.
Helpful first, if these ideas are unfamiliar
These pictures are analogies to help you learn. The linked RFC explains the actual rules.
Terms in this drawing
Related RFCs and changes
“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.
Include relevant local address data without inventing it.
- NS identifies a name server, MX a mail exchanger, and SRV a service location. Their existing A additional processing is redefined to include both A and AAAA.
- The server must add relevant IPv4 and IPv6 addresses available locally to Additional when processing those query types. This is not a requirement to fetch every missing address from elsewhere.
- An AAAA question does not trigger this additional processing. Additional entries are not extra AAAA answers or a signal that an application has connected.
NS/MX/SRV drawings summarize target names, not their complete wire fields. Section 3 uses ordinary lowercase must; this guide preserves its requirement without inventing new SHOULD/MAY policy. Section 4 says DNS information is unsafe without appropriate security techniques. This RFC adds no authentication or encryption. Historical security references 2535/2845 are not taught as current implementations; see the related DNSSEC guide for modern background.
Read the RFC section ↗