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.
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.
Arquivo de Caso
O resumo conferiu, mas a zona continuava errada: ZONEMD e o limite da integridade criptográfica
Criptografia pode confirmar com exatidão um objeto que jamais deveria ter sido publicado. Para quem opera DNS, ZONEMD é uma prova valiosa de integridade da zona — desde que não seja promovida a aprovação automática da decisão que veio antes dela.
Arquivo de Caso
O sinal estava assinado. A delegação ainda não era segura: CDS/CDNSKEY e a autoridade para publicar DS
CDS e CDNSKEY permitem que o lado filho apresente ao pai uma mudança de confiança em formato legível por máquinas. A assinatura torna a origem verificável dentro de uma cadeia definida; ela não transforma controle do DNS, autorização do titular, aceitação parental e resultado nos…
Arquivo de Caso
O catálogo era válido. A exclusão, não: DNS Catalog Zones e a autoridade de provisionar
Quando uma zona de cliente some do catálogo, o efeito pode ir muito além de parar de servi-la. Dependendo do consumidor, arquivos, journal, temporizadores e chaves DNSSEC podem ser removidos junto com a configuração. Uma ausência em PTR passa a decidir a custódia de estado…
Tendências de serviços em nuvem na Europa e no Oriente Médio
A fronteira regional por trás da GPU: como testar a capacidade realmente implantável da Genesis Cloud
A presença de aceleradores em um catálogo não descreve, sozinha, um sistema de inteligência artificial utilizável. No caso da Genesis Cloud, a documentação recuperada estabelece uma fronteira arquitetônica concreta: a conectividade privada entre instâncias fica limitada à mesma…
História
Um desvio não podia ser também o destino: o limite desenhado pelo DNS CNAME
O DNS podia conservar um nome antigo e conduzi-lo a outro lugar, mas exigia que o nó de origem abrisse mão das próprias respostas comuns. O CNAME transformou essa renúncia numa instrução confiável: guardar o desvio, reiniciar a pergunta no nome de destino e separar o poder sobre…
Arquivo de Caso
A resposta expirou; a falha não: DNS serve-stale e a autoridade depois do TTL
Um resolvedor pode manter um serviço disponível com dados que já perderam a validade comum de cache. Isso não renova a palavra da zona. Depois do TTL, serve-stale é uma decisão operacional própria: usar uma memória conhecida diante de uma atualização impossível, por tempo…