Resumo

  • SvcPriority menor só expressa preferência entre registros que o cliente pode usar. Antes da ordenação, dados malformados, inconsistentes ou incompatíveis são removidos; uma chave obrigatória desconhecida torna inelegível a aparente primeira opção.
  • AliasMode delega descoberta sem mudar a origem. ServiceMode vincula endpoint e parâmetros, porém hints, ALPN publicado e até DNS autenticado são entradas; A/AAAA, certificado do nome original, ALPN negociado e resposta da aplicação formam provas posteriores.

A primeira posição não garantiu entrada

Uma origem publica dois registros HTTPS em ServiceMode. Prioridade 1 aponta para uma nova borda e marca como obrigatório um parâmetro experimental. Prioridade 2 mantém a borda existente com parâmetros compreendidos pela base instalada. O painel chama a primeira de destino preferido.

Para um cliente que desconhece a extensão, ela não é candidata. RFC 9460 manda ignorar o registro quando nem todas as chaves obrigatórias são reconhecidas. O cliente avalia a prioridade 2 e pode conectar. A ordem não foi invertida; a elegibilidade foi decidida antes da preferência.

O cenário é analítico, não um relato sobre navegador ou CDN. Ele separa publicação de execução. O dono do DNS pode compor planos de conexão, mas não pode conferir capacidade a todo cliente, abrir a porta na rede, obrigar o servidor a negociar o protocolo ou fazer o certificado autenticar a origem.

Dois modos, autoridades diferentes

RFC 9460 define SVCB como tipo 64 e HTTPS como tipo 65. Cada registro contém SvcPriority, TargetName e SvcParams opcionais. Zero indica AliasMode; valor não zero indica ServiceMode.

AliasMode delega a descoberta de um serviço a outro nome. Seu uso importante é o alias específico no ápice de uma zona, onde CNAME não cabe. O alcance é limitado ao tipo compatível com SVCB e não altera os demais registros do nome. Parâmetros ali são ignorados e a cadeia precisa de limite para não formar um ciclo.

A delegação também não troca o origin. Depois de seguir o TargetName de um provedor, o cliente HTTPS continua apresentando o nome original em SNI, validando o certificado contra esse nome e usando-o em Host ou :authority. Foi entregue uma rota de descoberta, não a identidade confiada pelo leitor.

ServiceMode une alvo, porta, protocolos, hints de endereço e extensões em um candidato. Num ambiente multi-CDN, cada fornecedor publica a combinação que corresponde às suas capacidades. Isso evita combinar endereço de um com parâmetros de outro, mas não comprova que a borda esteja ativa ou sincronizada.

Rejeitar antes de ordenar

Um RR malformado pode invalidar o RRset inteiro e levar ao caminho sem SVCB. Parâmetros conhecidos que se contradizem tornam o registro inconsistente. Uma chave desconhecida comum pode ser ignorada; se constar em mandatory, o registro é incompatível com aquele cliente.

Somente os sobreviventes entram na prioridade. Números menores são tentados primeiro e registros do mesmo nível são embaralhados para distribuição equilibrada, sem o peso configurável de SRV. Baixa prioridade numérica quer dizer “prefira se compatível”, não “obedeça sem condição”.

mandatory tampouco força o servidor. Ele avisa que ignorar uma chave destruiria o significado do plano. As chaves listadas precisam existir no mesmo RR, e mandatory não pode citar a si próprio. Em HTTPS, port e no-default-alpn são automaticamente obrigatórios quando presentes: ignorar a porta escolheria outro serviço; restaurar o protocolo padrão contrariaria a oferta publicada.

DNS anuncia; o handshake decide

alpn informa as suites oferecidas pelo destino e permite preparar HTTP/3 sobre QUIC ou HTTP/2 sobre TLS. A negociação concreta continua no handshake. DNS pode avançar antes da borda, UDP pode ser bloqueado e uma região pode executar uma versão antiga.

A investigação guarda o conjunto ALPN recebido e o valor efetivamente negociado. O mesmo vale para port: o DNS sugere onde tentar, mas política do cliente ou firewall ainda podem recusar.

ipv4hint e ipv6hint reduzem espera; não substituem A/AAAA de TargetName. Se endereços já estiverem disponíveis, o cliente deve ignorar os hints. Caso contrário, ainda consulta o alvo e usa os resultados nas conexões futuras. Pode começar pelo hint e depois migrar para uma resposta diferente por geodistribuição.

O registro de evidência precisa dizer se o IP veio de hint, Answer, Additional, cache ou resolução do proxy, junto com TTL e rede. Apenas registrar a conexão apaga a diferença entre corrida planejada, estado antigo, divisão de fornecedor e desvio hostil.

O nome original permanece no centro

SVCB/HTTPS pode ser transportado por DNS não confiável. DNSSEC pode autenticar origem e integridade do RRset, mas RFC 9460 o torna opcional. Mesmo uma resposta assinada não prova vida, protocolo ou conteúdo do destino.

O endpoint alternativo precisa se autenticar para o serviço original. Certificado válido só para o TargetName do provedor é insuficiente. DNS governa descoberta; TLS governa identidade; ALPN comprova o acordo nesta conexão; HTTP preserva a autoridade e a resposta do aplicativo.

Como HTTP antecede SVCB, o uso costuma ser opcional e o cliente conserva a conexão clássica quando o registro não existe. Mas falha de consulta SVCB protegida — autenticação, SERVFAIL, transporte seguro ou timeout — deveria encerrar a tentativa para impedir remoção seletiva dos parâmetros. Falha comum em DNS não autenticado admite decisão local diferente.

Em multi-CDN, CNAME, HTTPS e A/AAAA podem observar gerações distintas. O cliente precisa buscar endereços do TargetName realmente escolhido. A primazia do código em funcionamento aparece nisso: a declaração só ganha poder quando implementações compatíveis a executam, sem substituir as autoridades próprias de TLS e HTTP.

Fontes