Resumo

  • Registros SVCB e HTTPS agrupam um endpoint com seus parâmetros e permitem que o publicador recomende uma ordem. DNSSEC pode autenticar esse anúncio, mas não comprova suporte do cliente, alcance da rota, identidade TLS ou sucesso da aplicação.
  • A decisão executável continua no cliente: ele rejeita registros inválidos, interpreta chaves obrigatórias, embaralha empates, aplica políticas de proxy e endereço, tenta alternativas, faz fallback quando permitido e valida a origem original.

Um operador publica dois destinos. O primeiro, prioridade 1, oferece HTTP/3 e exige uma capacidade nova. O segundo, prioridade 2, mantém HTTP/2. O relatório DNS confirma que a zona assinada já se propagou, mas a telemetria ainda mostra tráfego no segundo. Isso pode ser defeito — ou pode ser exatamente o comportamento previsto.

Clientes antigos não entendem a chave obrigatória. Uma rede bloqueia UDP. Outro cliente começou uma conexão compatível com o segundo destino antes de receber todos os dados associados. O registro define alternativas coerentes; não elimina estado local, topologia nem diferenças de implementação.

O RFC 9460 define SVCB como tipo 64 e HTTPS como tipo 65 compatível. A proposta é fornecer informação de conexão antes do primeiro intercâmbio de aplicação. Em vez de aprender tarde que havia um endpoint melhor, o cliente recebe uma coleção estruturada de opções.

Com SvcPriority igual a zero, AliasMode delega o serviço a um TargetName. Com valor positivo, ServiceMode associa o TargetName aos SvcParams da mesma entrada. Essa associação é essencial: ALPN, porta, pistas de IP e outros parâmetros descrevem o endpoint correto, não uma combinação acidental entre RRsets que mudaram em momentos diferentes.

AliasMode não é um CNAME para tudo. Ele afeta somente o tipo compatível consultado, não altera outros registros do nome e não muda a origem HTTPS. Pode resolver delegação no apex, mas clientes legados ainda precisam de A e AAAA funcionais. A zona abre uma opção para implementações participantes; não reescreve a capacidade dos demais.

Em ServiceMode, o cliente monta seu conjunto elegível. Conteúdo malformado pode fazer o RRset inteiro ser rejeitado; parâmetros reconhecidos que se contradizem tornam a entrada imprestável. Chaves desconhecidas podem ser ignoradas, salvo quando mandatory declara que ignorá-las impediria o funcionamento correto do endpoint.

Essa distinção permite evolução sem fingir compatibilidade. Um recurso opcional pode aparecer sem quebrar software antigo. Um requisito genuíno pode ser marcado como obrigatório, removendo conscientemente clientes que não o entendem. Usar mandatory como campanha de adoção, e não como necessidade funcional, transforma uma preferência editorial em indisponibilidade operacional.

O registro IANA de parâmetros SVCB, atualizado em 25 de junho de 2026, inclui mandatory, ALPN, supressão do ALPN padrão, porta e pistas IPv4/IPv6, além de ECH, caminho DoH, OHTTP, grupos TLS, DNS sobre CoAP, PvD e confiança operacional por transporte para servidores DNS. Registro fornece número e significado. Não comprova implementação universal nem adequação a todo mapeamento.

Prioridade também não significa comando. O menor valor positivo é a recomendação do dono do domínio. Entradas empatadas devem ser embaralhadas para balanceamento uniforme, sem peso como em SRV. Em regra, o cliente tenta prioridades maiores primeiro e recua para as menores — aqui “maior” significa preferência, isto é, número menor.

O próprio RFC admite exceções de desempenho: testar mais de uma opção em paralelo, buscar vários TargetName antecipadamente, preferir uma entrada que dispensa nova consulta DNS ou continuar uma conexão em andamento compatível. Portanto, a distribuição real não precisa reproduzir uma leitura literal do arquivo de zona.

ALPN mostra a passagem da oferta para a execução. O parâmetro informa suites oferecidas. O cliente mantém apenas as que suporta, e o RFC 7301 governa a negociação dentro do handshake TLS. Publicar h3 não habilita QUIC no dispositivo, não libera UDP na rede e não obriga o servidor a completar a negociação naquele instante.

As pistas de endereço são outra aceleração limitada. Se A ou AAAA já estiver disponível, RFC 9460 orienta ignorar ipv4hint e ipv6hint. Caso contrário, o cliente ainda consulta o TargetName e pode abandonar a conexão iniciada com a pista quando chegam endereços reais. Tratar pista como autoridade permanente pode contornar balanceamento geográfico.

Com vários endereços, o cliente pode aplicar Happy Eyeballs v2 e colocar IPv6 e IPv4 em competição. A família vencedora depende da temporização e do caminho atual. A zona sugere; a rede responde.

DNSSEC autentica uma camada diferente. Registros HTTPS não são autênticos por definição. RFC 9460 modela DNS como canal possivelmente hostil e torna assinatura e validação opcionais. Se A/AAAA é protegido, a mesma política deve alcançar SVCB, evitando que um registro falso contorne os endereços validados. O RFC 4035 descreve os estados dessa validação.

Um RRset Secure prova que a zona assinada publicou aquele conteúdo sem alteração detectada. Não prova saúde do endpoint, suporte à chave obrigatória, autorização do proxy ou validade do certificado. Autenticidade da recomendação e êxito da conexão são evidências complementares, não sinônimos.

O TargetName tampouco vira a origem. TLS SNI e HTTP Host ou :authority continuam apontando para o serviço originalmente solicitado. O RFC 9525 confirma que usar SVCB ou HTTPS não muda as exigências PKIX existentes para HTTP ou DNS sobre TLS. Um CDN recebe a conexão, mas precisa autenticar a origem original.

O paralelo com Alt-Svc reforça a fronteira. Alt-Svc pode trocar host, porta e protocolo sem trocar a origem, e o cliente escolhe segundo critérios próprios de segurança. HTTPS RR antecipa informação semelhante via DNS e usa TTL; Alt-Svc chega por HTTP e usa ma. As noções de origem e autoridade do RFC 9110 permanecem acima das duas rotas.

Fallback facilita implantação gradual. Para protocolos existentes como HTTP, SVCB normalmente é opcional: depois de falhas nas alternativas, o cliente pode voltar ao modo tradicional. O ganho de disponibilidade, porém, pode esconder downgrade. Se a primeira opção oferecia ECH, HTTP/3 ou outra propriedade, bloquear essa rota pode empurrar clientes para proteção menor. Alt-Svc registra risco equivalente.

Proxies criam outro limite. Um proxy orientado a nomes pode resolver A/AAAA. Se o cliente consultar SVCB por fora, revela o destino a uma parte extra. RFC 9460 manda o cliente opcional desativar SVCB quando não há resolução separada com privacidade adequada; um cliente dependente deve rejeitar a configuração. Quando usado, compatibilidade inclui o proxy, cuja localização influencia os endereços.

O mapeamento do RFC 9461 para DoT, DoH e DoQ mostra que formato comum não elimina semântica específica. Cada protocolo define chaves aplicáveis, autenticação e fallback. Um número no registro global não resolve essas decisões.

As distinções de Heng Lu sobre código em execução, especificação mínima e decisão futura localizada e camadas da realidade organizam a prova: a norma define, a zona oferece, o resolvedor entrega, o cliente filtra, TLS negocia e a aplicação demonstra o resultado.

Uma auditoria útil não termina no dig. Ela liga RRset e DNSSEC à versão do cliente, às chaves reconhecidas, ao proxy, à entrada escolhida, aos endereços tentados, ao ALPN, ao certificado, ao motivo de fallback e à resposta final. O publicador prova sua oferta. A conexão observada prova o uso.