Запись SOA в ответе на запрос AAAA, когда IPv6 не поддерживается

Когда я копаю AAAA на веб-сайт, который еще не поддерживает IPv6, в ответе есть запись SOA.

Требуется ли запись SOA в ответ на запрос AAAA, если служба не поддерживает 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

domain-name-system ipv6

Причина, по которой это происходит, - кэширование отрицательных ответов. т.е. если вы выполняете запрос AAAA для www.example.com, и эта запись не существует, то факт ее отсутствия будет добавлен в кеш промежуточных серверов.

Чтобы эти промежуточные серверы знали, как долго кэшировать этот ответ, им нужна запись SOA, потому что именно там определяется TTL. Этот процесс полностью независим от протокола, IPV4 и IPV6 (а также IPV9) получить тот же ответ, что и в additional поле.

Отредактировано в ответ на комментарий

(похоже, моя предыдущая правка была довольно некорректной! - Вот и настоящая)

В результате запись SOA вставляется в раздел Authority.

Согласно RFC 2308 Отрицательное кеширование DNS-запросов Раздел 3

Полномочные серверы имен для зоны ДОЛЖНЫ включать запись SOA зоны в раздел полномочий ответа при сообщении о NXDOMAIN или указании, что данных запрошенного типа не существует. Это необходимо для того, чтобы ответ можно было кэшировать.

Отредактировано для всех, кому интересно после прочтения комментариев здесь!

Похоже, что оригинальный DNS RFC 1034 Концепции и возможности домена возникла проблема с описанием двух мест для SOA, раздела полномочий (в разделе 3.7) и дополнительного раздела (который я изначально цитировал в разделе 4.3.4) RFC 2181 раздел 7.1 Разъяснения к спецификации DNS прояснил это. RFC 2308 позже полностью заменил раздел 4.3.4.

Аннотация

[RFC1034] предоставил описание того, как кэшировать отрицательные ответы. Однако у него был фундаментальный недостаток, заключающийся в том, что он не позволял серверу имен передавать эти кешированные ответы другим распознавателям, тем самым значительно снижая эффект кэширования. В этом документе рассматриваются проблемы, возникшие с учетом опыта, и он заменяет [RFC1034, раздел 4.3.4].