Resumo

  • RFC 10029 mantém uma pergunta DNS principal e pede QTYPEs adicionais por EDNS. A opção de resposta enumera apenas os tipos extras processados por inteiro sob o mesmo RCODE e as mesmas flags relevantes da resposta principal.
  • Receber tudo em um pacote não cria uma fotografia atômica. Tipos omitidos precisam de consultas autônomas, e os RRsets retornados preservam zona, signatário, TTL, cache, validação e uso pela aplicação como estados separados.

Imagine um cliente que escolhe A como pergunta principal e adiciona AAAA e HTTPS. O servidor constrói um pacote válido, sem truncamento. A e AAAA aparecem; HTTPS não consta em MQTYPE-Response. Se a telemetria olhar apenas NOERROR e TC=0, classificará a operação como completa. Se a aplicação precisava de HTTPS para decidir a conexão, ainda há trabalho obrigatório.

O tipo pode ter faltado porque o recursor não o tinha em cache, porque sua resposta individual carregaria outro RCODE ou outra flag, porque o limite de trabalho foi alcançado ou porque todos os registros exigidos não caberiam. Nenhuma dessas causas é provada pela omissão sozinha.

RFC 10029, publicado em julho de 2026 na trilha de padrões, cria um modo explícito de reunir necessidades relacionadas. Ele não reabre a porta para múltiplas perguntas comuns. RFC 9619 determina que uma mensagem QUERY não pode ter QDCOUNT maior que um. Por isso, o novo formato conserva um QNAME, uma classe e um QTYPE principal, colocando os tipos de dados adicionais em EDNS.

A economia de ida e volta fica subordinada a uma regra: cada combinação adicional continua tendo seu próprio teste de completude.

A consulta pede; a resposta certifica o conjunto terminado

MQTYPE-Query usa o código 20. MQTYPE-Response usa o código 21. O registro de parâmetros DNS da IANA marca os dois como opcionais e referencia RFC 10029.

Os códigos diferentes protegem contra intermediários que ecoam opções EDNS. Um eco da entrada não pode parecer uma declaração de saída. A pergunta principal somada à lista da resposta indica exatamente quais combinações de nome, classe e tipo estão completas naquele pacote.

Uma lista vazia ainda confirma suporte: o servidor entendeu a extensão, mas não concluiu tipo adicional algum. A ausência da opção de resposta, a presença indevida da opção de consulta, valores repetidos ou FORMERR levam o cliente ao caminho convencional. Para cada tipo ainda necessário, ele deve emitir consulta separada.

Não é uma nova versão de ANY. RFC 8482 permite que respostas ANY sejam mínimas. O servidor pode devolver um RRset escolhido por ele. RFC 10029 troca a promessa indefinida de totalidade por uma lista verificável de tipos acabados.

O cabeçalho comum tem uma autoridade limitada

Primeiro, o servidor monta a resposta do QTYPE principal. RCODE e flags como AA, AD e TC nascem dessa etapa. Se o principal já exige truncamento, os tipos extras não são processados para a combinação.

Depois, cada QTYPE adicional é avaliado como se tivesse sido consultado sozinho. Só pode entrar quando seu RCODE e suas flags relevantes coincidem com os do principal. Um resultado SERVFAIL não pode ser escondido sob NOERROR. Num corte de zona, uma resposta DS autoritativa e os dados NS não autoritativos do lado pai não podem compartilhar honestamente o mesmo AA.

RFC 2181 esclarece a hierarquia dos dados DNS usada nessa avaliação. Igualdade de classificação, porém, não significa uma única organização, uma única transação de publicação ou uma única cadeia de prova.

Um tipo só entra quando cabe por inteiro

Os registros adicionais vão para as seções que ocupariam numa resposta independente, com remoção de duplicatas na mesma seção. O servidor inclui um QTYPE em MQTYPE-Response apenas quando todo o conjunto necessário para aquela combinação pode ser colocado no pacote.

Se tamanho ou outro limite impedir isso, o tipo é omitido. A manipulação de MQTYPE não deve, por si só, produzir uma resposta truncada. Por esse motivo, TC=0 é uma propriedade do pacote final, não uma prova de que o desejo original do cliente foi satisfeito.

RFC 6891 acrescenta a fronteira do caminho: OPT não é armazenado em cache, o tamanho UDP anunciado vale para a transação e pode ser maior que o caminho real suporta. Firewalls podem bloquear fragmentos e intermediários podem prejudicar opções, apesar das exigências normativas. Suporte é uma observação por trajeto, não um rótulo permanente.

Ausência na lista não é resposta negativa

Omissão pode significar falta no cache, incompatibilidade de RCODE ou flags, indisposição ou limite de trabalho, e pressão de tamanho. O protocolo não transforma essa lista num diagnóstico.

Logo, HTTPS ausente não prova que não existe. Não carrega automaticamente a resposta negativa descrita em RFC 2308, nem a prova autenticada exigida por RFC 4035. Também não prova bloqueio, falha ou falta de relevância para o produto.

A obrigação de consultar separadamente o tipo ainda necessário protege a semântica. Uma implementação que a desativa para manter baixa a contagem de pacotes altera o conjunto de evidências da aplicação sem autorização.

Chegada simultânea não significa origem simultânea

Registros agrupados podem vir de zonas diferentes; provas de inexistência podem ter signatários diferentes. Cada RRset mantém seu TTL, e o recursor pode tê-lo inserido no cache em outro instante. Um pacote pode combinar A antigo no cache, AAAA recém-consultado e HTTPS obtido de outro caminho de autoridade.

Os termos de RFC 9499 precisam sobreviver no modelo operacional: RRset, servidor autoritativo, recursor e cache não devem virar um único campo “DNS”. O ID do pacote ajuda a correlacionar, mas não substitui a proveniência por tipo.

Mesmo um HTTPS completo ainda passa pela decisão do cliente. RFC 9460 deixa prioridades, parâmetros obrigatórios, endereços e viabilidade da conexão para processamento posterior. Entrega não é seleção; seleção não é sucesso.

O livro de completude por tipo

Registrar QNAME, QCLASS, QTYPE principal, lista ordenada de tipos adicionais, trajeto e recursor, tamanho EDNS, presença e conteúdo exato da opção de resposta, RCODE, AA, AD e TC. Calcular explicitamente a diferença entre o conjunto pedido e o conjunto concluído.

Para cada tipo entregue, preservar RRsets e provas, zona de origem, autoridade, signatário, validação DNSSEC, TTL, proveniência do cache e horário. As consultas de fallback, a escolha da aplicação e o resultado da conexão precisam herdar o mesmo identificador de decisão.

Quatro estados ficam distintos: pacote recebido, QTYPE completo, RRset validado e requisito da aplicação atendido.

A primazia do código em execução de Heng Lu impede que publicação e registro sejam tratados como implantação. A proposta de especificação inicial mínima, decisão futura localizada e adoção voluntária favorece formato comum estrito, limites locais, compatibilidade explícita e saída pelas consultas comuns. A defesa da realidade, não da promoção define a conclusão: a IANA registra a possibilidade; o caminho, a lista de tipos, a validação e o resultado demonstram o uso real.

Um pacote compartilhado não concede uma autoridade compartilhada.