registro SOA na resposta da consulta AAAA quando o IPv6 não é suportado

Question

Quando eu digito AAAA em um site que ainda não suporta IPv6, a resposta tem um registro SOA.

É necessário ter o registro SOA em resposta a uma consulta AAAA quando o serviço não suporta 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

    

Answer 1

A razão pela qual isso ocorre é para o cache de resposta negativa. ou seja, se você fizer uma consulta AAAA para www.example.com e esse registro não existir, o fato de não existir será adicionado ao cache dos servidores intermediários.

Para que esses servidores intermediários saibam por quanto tempo armazenar em cache essa resposta, eles precisam do registro SOA, porque é onde o TTL é definido. Este processo é completamente independente de protocolo, IPV4 e IPV6 (assim como IPV9 ) obtêm a mesma resposta incluída no additional campo.

Editado em resposta ao comentário

(parece que minha edição anterior estava incorreta! - Então, aqui está a verdadeira)

Como resultado, o registro SOA é inserido na seção Autoridade.

De acordo com a RFC 2308 Cache negativo de consultas DNS Seção 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.

Editado para qualquer pessoa curiosa depois de ler os comentários aqui!

Parece que o RFC 1034 Conceitos e Instalações do Domínio original do DNS teve um problema ao descrever dois locais para a SOA, a seção de autoridade (na seção 3.7) e a seção adicional (que eu havia originalmente citado, na seção 4.3.4) Seção RFC 2181 7.1 Esclarecimentos para a Especificação de DNS esclareceram isso. RFC 2308 mais tarde substituiu a seção 4.3.4 inteiramente.

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