When I do dig AAAA to a website that doesn't support IPv6 yet, the reply has an SOA record.

Is it a requirement to have the SOA record in response to a AAAA query when the service doesn't support IPv6 ?

    dig quora.com AAAA

    ; <<>> DiG 9.9.5-3ubuntu0.6-Ubuntu <<>> quora.com AAAA
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8704
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

    ; EDNS: version: 0, flags:; udp: 512
    ;quora.com.         IN  AAAA

    quora.com.      976 IN  SOA ns1.p28.dynect.net. zone-admin.dyndns.com. 2016031101 3600 600 604800 3600

    ;; Query time: 35 msec
    ;; SERVER:
    ;; WHEN: Mon Mar 21 08:27:49 UTC 2016
    ;; MSG SIZE  rcvd: 110
  • The SOA is isn't an Answer - its simply telling you who is authoritative for the domain. The lack of an Answer or Error for AAAA indicates the absence of that record – pete Mar 21 '16 at 8:53
  • I understand that SOA isn't an Answer. But my question is, is it required to include the SOA record in this case ? dig AAAA for a service that does have IPv6 support doesn't have the SOA record in the reply. – Manohar Mar 21 '16 at 9:10
  • Ok, I had just wanted to clarify^^. I'll save the 'required' part for whomever pulls an answer from the RFC; but note you will find the same behavior if you dig for an absent A, or any other rr in a valid zone – pete Mar 21 '16 at 9:28
  • Thanks @pete you nerd snipped me into going and finding the RFC. – Michael B Mar 21 '16 at 14:02

The reason that this occurs is for Negative Response Caching. i.e. if you do a AAAA query for www.example.com and that record doesn't exist then the fact that it doesn't exist will be added to the cache of the intermediate servers.

In order for those intermediate servers to know how long to cache that response for they need the SOA record, because that is where TTL is defined. This process is completely protocol agnostic, IPV4 and IPV6 (as well as IPV9) get the same response included in the additional field.

Edited in response to comment

(it seems my previous edit was rather incorrect! - So here's the real one)

As a result the SOA record is inserted into the Authority section.

According to RFC 2308 Negative Caching of DNS Queries Section 3

Name servers authoritative for a zone MUST include the SOA record of the zone in the authority section of the response when reporting an NXDOMAIN or indicating that no data of the requested type exists. This is required so that the response may be cached.

Edited for anyone curious after reading the comments here!

It seems that the original DNS RFC 1034 Domain Concepts and Facilities had an issue in describing two locations for the SOA, the authority section (in section 3.7) and the additional section (which I'd originally quoted, in section 4.3.4) RFC 2181 section 7.1 Clarifications to the DNS Specification clarified this. RFC 2308 later replaced section 4.3.4 entirely.


[RFC1034] provided a description of how to cache negative responses. It however had a fundamental flaw in that it did not allow a name server to hand out those cached responses to other resolvers, thereby greatly reducing the effect of the caching. This document addresses issues raise in the light of experience and replaces [RFC1034 Section 4.3.4].

  • 1
    Your IPv9 link is a joke. IANA has allocated version number 9 to RFC 1347 (which nobody is using). – kasperd Mar 21 '16 at 17:43
  • @kasperd Are you sure? I've just got my 1 billion IPV9 addresses assigned for my house (and due to some bureaucratic fumbling, 2 billion assigned to my shed - not to mention the million the dog had allocated, though that could just be based on flee count) - Although, DNS is still protocol agnostic, whether we're talking IPV4,6 or 9 (whether the april fool's version or tuba - which does use DNS) You'll still get an SOA with the reply.(if only I was smart enough to have made that the joke) – Michael B Mar 21 '16 at 17:56
  • To explain the joke (and therefore ruthlessly murder it): whether the version of IP is real or imaginary, DNS as a protocol is agnostic to the transport layer. It has no idea what version of IP the requesting client implements, nor does it care. You get exactly what you ask for, V4 or otherwise, and it's up to the OS's stub resolver to be smart enough to ask for what it needs. – Andrew B Mar 21 '16 at 20:06
  • 1
    @Manohar RFC 2308 §2.2 is a better link. Your example reply is a synthetic state called NODATA, where the server is saying that the requested name exists but not with that particular record type. Note that the first paragraph states "The authority section will contain an SOA record, or there will be no NS records there.". – Andrew B Mar 21 '16 at 20:13
  • 1
    That's because you can't use the RFCs comprising STD 13 as an exhaustive reference for the specification. They've been updated by numerous RFCs. Suffice it to say: 1) the reply that you see in the question contains a SOA record in the authority section, and 2) the RFC 2308 citation I included above directly contradicts this assertion. The authority field frequently contains the SOA data when the rcode is NXDOMAIN or when the response is the synthetic state NODATA. (rcode NOERROR + 0 answers) – Andrew B Mar 22 '16 at 16:11

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.