SOA record in AAAA query reply when IPv6 is not supported

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

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 512
    ;; QUESTION SECTION:
    ;quora.com.         IN  AAAA

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

    ;; Query time: 35 msec
    ;; SERVER: 10.0.2.3#53(10.0.2.3)
    ;; WHEN: Mon Mar 21 08:27:49 UTC 2016
    ;; MSG SIZE  rcvd: 110

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.

Abstract

[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].