Resumo

  • Um registro DNS HTTPS publica instruções de conexão; ele não executa um teste.
  • A escolha depende de prioridade, parâmetros compreendidos, resolução e capacidade do cliente.
  • Dicas de endereço, anúncio ALPN e sucesso após fallback são evidências diferentes.
  • A prontidão requer um registro de validação que ligue o RRset observado a uma resposta autenticada para cada grupo relevante de clientes.

Imagine um painel de implantação que fica verde assim que um novo registro HTTPS aparece no DNS. O registro anuncia HTTP/3 e inclui uma dica de endereço IPv6. Um monitor convencional continua abrindo a página, portanto a migração é declarada concluída. Contudo, todas as tentativas HTTP/3 de um grupo de acesso móvel falham. Esses usuários chegam ao serviço apenas porque seus clientes fazem fallback para HTTP/2 no endpoint original.

O registro DNS não estava errado. O erro foi tratar publicação como entrega.

O RFC 9460 define registros SVCB e HTTPS para que um cliente descubra endpoints alternativos e parâmetros antes de abrir a conexão habitual. O mecanismo pode reduzir latência, permitir HTTP/3 direto, indicar portas não padrão e manter parâmetros relacionados no mesmo registro. Isso é informação útil de controle, não uma transação sintética.

A estrutura altera a seleção. SvcPriority igual a zero significa AliasMode, uma delegação para outro nome. Um valor diferente de zero significa ServiceMode, que associa TargetName a parâmetros. Números menores têm preferência, mas registros com a mesma prioridade são embaralhados. Guardar apenas “HTTPS RR presente” não preserva qual opção o cliente podia usar, qual escolheu nem o motivo.

Compatibilidade cria outro limite. mandatory informa as chaves que o cliente precisa compreender. Se uma delas for desconhecida, o registro não é utilizável por esse cliente. alpn anuncia protocolos e no-default-alpn pode remover o protocolo normalmente implícito no esquema. O mesmo RRset válido pode produzir escolhas diferentes entre navegadores, sistemas, bibliotecas e políticas de dispositivos gerenciados.

Os endereços sugeridos por ipv4hint e ipv6hint costumam ganhar autoridade demais. Eles permitem começar de forma otimista. Segundo o RFC 9460, o cliente deve preferir registros A ou AAAA já disponíveis localmente; caso contrário, deve consultar o TargetName e usar os endereços obtidos em conexões futuras. Uma sugestão não prova rota, passagem de UDP, comportamento de NAT ou firewall, nem escuta do protocolo no destino. Ela indica onde tentar; não demonstra que os pacotes chegaram.

O limite de autoridade TLS continua valendo. Um alias SVCB não muda a origem a ser autenticada: o cliente ainda valida o certificado para o nome original. A resposta DNS pode estar presente e bem interpretada enquanto certificado, SNI ou handshake TLS falha no destino anunciado.

No HTTP/3, o RFC 9114 coloca a aplicação sobre QUIC, definido pelo RFC 9000. Depois do DNS ainda vêm conexão QUIC, autenticação TLS, configurações HTTP/3 e resposta da aplicação. Cada transição pode falhar separadamente. Reduzi-las a “HTTP/3 ativado” elimina a evidência necessária para localizar o defeito.

O fallback esconde essa perda com facilidade. O RFC 9460 prevê que um cliente rejeite registros malformados ou incompatíveis e volte à conexão sem SVCB. Uma solicitação pode funcionar embora o endpoint alternativo nunca tenha sido tentado ou tenha falhado. É bom para disponibilidade, mas não é prova de aceitação.

O inverso também não vale: uma falha isolada não prova defeito geral. O cliente pode não aceitar o ALPN, receber resposta específica do resolvedor, selecionar outro destino de igual prioridade, usar proxy, sofrer bloqueio UDP local ou manter DNS antigo. Prontidão é uma afirmação por grupo, não uma propriedade universal inferida de um aparelho.

O registro comprobatório de prontidão começa com nome consultado, resolvedor DNS, rede, versão do cliente, ponto de observação e horário. Preserva o RRset HTTPS completo, a validação DNS, o TTL e a idade do cache; prioridade, destino e parâmetros compreendidos; endereços resolvidos ou sugeridos; e a razão para aceitar, ignorar ou rejeitar cada registro.

Depois acompanha a execução: endereço, protocolo e porta tentados; resultado QUIC ou TCP; ALPN negociado; nome e validação do certificado; status HTTP e impressão digital da representação HTTP; e eventual fallback. Termina com grupo de clientes, duração, resultado final e o componente autorizado a declarar prontidão.

Assim, “RR HTTPS observado” significa que o resolvedor o devolveu. “Alternativa selecionada” significa que o cliente aceitou uma opção ServiceMode. “HTTP/3 conectado” exige QUIC, TLS e HTTP/3 concluídos. “Serviço entregue” exige a transação de aplicação pretendida. Os eventos ficam na mesma linha do tempo sem que o primeiro fabrique os demais.

A separação melhora o diagnóstico. Registro ignorado leva a compatibilidade e chaves obrigatórias. Endereço resolvido com falha QUIC leva a caminho e política de transporte. Falha TLS leva à autenticação da origem e à implantação. Sucesso apenas após fallback preserva o serviço, mas mantém pendente a validação do endpoint alternativo.

Dentro de seu limite, o registro HTTPS é evidência útil: mostra o vínculo publicado e observado. A prontidão começa quando um cliente identificado segue esse vínculo e devolve um resultado autenticado da aplicação.

Fontes

RFC 9460 — Registros SVCB e HTTPS; RFC 9114 — HTTP/3; RFC 9000 — QUIC.