Tópico
Poder de delegação do DNS
Na faceta Tópico, a inteligência do tópico Poder de delegação do DNS conecta artigos que compartilham um assunto específico, foco de sinal ou tema de monitoramento. A página oferece aos leitores um percurso mais rico por meio de reportagens relacionadas, evidências de fontes, atores do mercado e implicações de infraestrutura, com contexto suficiente para entender por que o tópico é relevante em movimentações de empresas, decisões de governança, exposição regional e risco operacional. Os leitores podem comparar sinais recorrentes, organizações afetadas, evidências públicas, contexto de mercado, continuidade de serviço, compras, concorrência, conformidade e questões de planejamento estratégico por trás do assunto, em vez de se limitar a uma lista enxuta de artigos correspondentes. A página explica o que o tópico abrange, quais atores ou políticas de infraestrutura estão envolvidos, quais evidências sustentam a cobertura e por que o assunto pode ser importante para operadores, clientes, investidores e leitores de políticas.
ICANN
Uma mudança na ISO pode acionar a saída de um ccTLD IDN. Ela não dá à ICANN um veredito territorial.
Sistemas de coordenação precisam de referências externas. Isso é uma virtude: quem opera identificadores não deve ter de decidir todos os fatos do mundo que tornam uma regra necessária. O risco aparece quando a instituição que reage à referência passa a ser descrita como se…
Arquivo de Caso
A etiqueta foi resolvida. A aeronave não foi localizada: RFC 9886
Uma resposta DNS pode chegar assinada, com chave pública, certificado e dados estáticos de identificação remota, enquanto o céu observado continua sem alvo. O RFC 9886 torna o DRIP Entidade Tag consultável; não transforma identidade registrada em coordenada, presença ou…
História
Os códigos correspondiam. O circuito ainda exigia permissão: RFC 1394
O operador podia encontrar o mesmo país em quatro colunas e continuar sem conseguir enviar uma mensagem. O número telefônico, o código de telex, o answerback e o domínio de Internet pertenciam a sistemas diferentes. RFC 1394 os aproximou para facilitar a busca, mas registrou que…
ICANN
No plano da ICANN, o acento levaria o registro inteiro na mudança
A proposta para diacríticos latinos permitiria que certos sufixos coexistissem sob um mesmo operador. Mas a ligação não terminaria na aprovação do pedido: alcançaria fornecedores, mudanças de controle e transições de emergência. A possibilidade de sair precisa fazer parte da…
História
A entrada de domínio apontava para a organização, mas não era a organização: RFC 1279
Um sincronizador costuma começar com uma tarefa modesta e terminar com poderes que ninguém lhe concedeu. RFC 1279 antecipou esse risco ao propor uma ferramenta capaz de levar records DNS até um diretório X.500: ela podia escrever o que transportava, mas devia deixar todos os…
IETF
Wes Hardaker e o servidor DNS que precisou sobreviver a dois TTLs
Em uma migração de DNS, o servidor antigo pode parecer ocioso e ainda ser necessário. Basta que um resolvedor tenha guardado, de forma válida, a cópia da delegação cujo relógio termina por último.
História
O nome era local. O número ainda precisava de registro: a fronteira de mapeamento DNS da RFC 1101
Em 1989, o DNS já distribuía informações de hosts, mas ainda não oferecia um modo padronizado de perguntar como uma rede era chamada a partir de seu número. A RFC 1101 sugeriu uma resposta feita de PTRs, nomes de host-zero em `IN-ADDR.ARPA` e máscaras. A lição não é que uma…
IETF
Tobias Fiebig e os quatro comprovantes de alcance do DNS
Milhões de zonas podem depender da mesma correção de glue, embora cada cliente enxergue apenas o próprio painel. A concentração torna uma falha de delegação local um risco coletivo. A RFC 10001 oferece uma unidade simples para enxergar esse risco: dois serviços autoritativos…
História
O serviço de nomes quase foi um negociador: como a RFC 830 separou domínios de capacidades
Um cache consegue lembrar onde o domínio foi encontrado ontem. Ele não consegue, por esse fato, responder o que a aplicação oferece hoje. A RFC 830 colocou essa diferença no centro do sistema: a parte distribuída localizava o ponto de serviço do domínio; uma conversa posterior…
IETF
David Lawrence e a resposta DNS que ultrapassou o TTL
O TTL acabou, mas a origem autoritativa não conseguiu responder a tempo. A RFC 8767 permite que o resolvedor preserve a continuidade com a cópia vencida, desde que tente atualizar de verdade, limite a exceção, informe o que fez e continue buscando a fonte. O cache pode sustentar…
IETF
Steve Sheng e o bloqueio que não interrompeu a manutenção do DNSSEC
Um domínio pode aparecer como bloqueado no painel e, ainda assim, ter seu conjunto de DS alterado de forma legítima no pai. A aparente contradição desaparece quando se pergunta quem definiu o bloqueio, qual ator e qual comando ele restringe e por que uma via de manutenção…
IETF
Peter Thomassen e a atualização que precisava de cada servidor autoritativo
Uma automação do DNS pode receber uma solicitação perfeitamente assinada e ainda assim não ter evidência suficiente para agir. No RFC 9975, Peter Thomassen define o que falta: a mesma intenção precisa aparecer no serviço autoritativo inteiro que o pai já delegou.
Arquivo de Caso
O domínio publicou uma intenção de venda; a autoridade para vender estava em outro lugar
O RFC 10023 transforma disponibilidade em um sinal consultável no DNS, mesmo quando o domínio continua operando. Essa conveniência inicia uma diligência — não substitui identidade, mandato, contrato, pagamento ou transferência.
Arquivo de Caso
O IPv6 funcionou porque havia IPv4 por trás: RFC 10001 e a proveniência do caminho DNS
Um recursor IPv6-only alcança um servidor autoritativo por NAT64 e registra sucesso. A métrica está correta e, ao mesmo tempo, incompleta: a autoridade continuou dependendo de uma rota IPv4, de um prefixo de síntese e de um tradutor. RFC 10001 não proíbe esse arranjo. Ele obriga…
Arquivo de Caso
O pacote não foi truncado. A resposta ainda estava incompleta: RFC 10029 e a prova por tipo DNS
O bit de truncamento ficou em zero, o endereço chegou e o tempo de resposta melhorou. Mesmo assim, um dos tipos solicitados não coube no conjunto completo e desapareceu da lista de conclusão. RFC 10029 separa duas métricas que painéis costumam juntar: integridade do pacote e…
Arquivo de Caso
O registro publicou o TTL, mas o resolvedor manteve o próprio relógio: RFC 10037 e a janela de mudança DNS
Cinco minutos podem ter terminado para um cache e nem ter começado para outro. Ao expor um TTL pelo RDAP, o registro mostra uma configuração administrativa útil, não uma contagem regressiva comum a toda a Internet. O RFC 10037 melhora o diagnóstico justamente porque delimita essa…
Arquivo de Caso
O erro voltou como uma nova pergunta: DNS Report-Channel e a autoridade do retorno
Um servidor autoritativo pode continuar entregando respostas sem enxergar que validadores as rejeitam. DNS Error Reporting cria uma volta controlada: a autoridade anuncia um agente, o resolvedor transforma sua falha local em outra consulta e o destinatário precisa decidir quanto…
Arquivo de Caso
O pacote escondeu o tamanho exato, mas o padrão continuou falando: EDNS Padding e os limites da privacidade DNS
Criptografar o DNS oculta nomes e respostas, mas pode deixar uma silhueta útil para quem observa o caminho. EDNS Padding acrescenta bytes para tornar essa silhueta menos precisa. O resultado não depende do volume adicionado isoladamente, e sim de quantas trocas diferentes passam…
Arquivo de Caso
O DNS amarrou as alternativas; o cliente escolheu a conexão: SVCB, HTTPS e autoridade operacional
Uma zona pode anunciar antecipadamente o endpoint, o protocolo e a porta preferidos, todos protegidos por DNSSEC. Ainda assim, só o cliente sabe se entende os parâmetros, se o proxy permite a rota, qual endereço responde e qual certificado aparece no fim.
Arquivo de Caso
A lista chegou íntegra; a resposta foi decisão local: DNS RPZ e a autoridade para reescrever a resolução
Receber inteligência de ameaça com origem e versão verificadas resolve a custódia do dado. Não resolve quem pode transformar uma resposta verdadeira em NXDOMAIN, silêncio ou redirecionamento para os usuários de uma rede.