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.
Reportagens
O nó anycast da AFRINIC em Uganda reúne dois serviços, não um
O resumo de inteligência sobre O nó anycast da AFRINIC em Uganda reúne dois serviços, não um explica o desenvolvimento, as evidências públicas disponíveis aos leitores, as organizações envolvidas, o contexto regional, a exposição de mercado e as possíveis consequências de…
ICANN
A integração de nomes alternativos da ICANN precisa de desligamento verificável
O relatório inicial da ICANN recomenda que qualquer integração entre um gTLD e outro sistema de nomes chegue à avaliação com um plano obrigatório de desligamento. É uma salvaguarda importante, sobretudo porque a cobertura de emergência EBERO não parece incluir essa camada…
Reportagens
O teste do ccTLD não define o limite do IPv6 de um país
A verificação dos servidores do registro é útil. A conclusão de que nenhum site abaixo deles pode ser alcançado por IPv6, porém, ignora o caminho que um resolvedor recursivo pode fazer.
IETF
DNS ANY deve ser retirado por finalidade, não apenas pelo código de consulta
Trocar a resposta de um servidor é mais rápido do que descobrir o que seus clientes faziam com ela. Uma retirada responsável de ANY precisa fechar as finalidades herdadas, com consultas explícitas, testes funcionais e exceções que tenham dono e prazo.
IETF
Uma troca de servidor ULD precisa provar que os serviços locais sobreviveram
A troca de um roteador pode terminar sem derrubar a internet e, ainda assim, deixar para trás um pedaço da rede local. O novo servidor de descoberta responde, os clientes o escolheram e quase todos os dispositivos reaparecem. O “quase” é o problema: uma escolha correta não…
IETF
O backup não existe; a zona ainda tem algumas horas de futuro
Uma chave privada DNSSEC pode desaparecer enquanto a zona continua íntegra aos olhos dos validadores. O que resta nos servidores autoritativos não é a chave, mas um estoque de assinaturas com prazo de validade. Usá-lo bem exige reconstruir a capacidade de assinar sem destruir o…
IETF
DANCE 14 reduz quatro resultados TLSA a uma decisão binária do servidor
Um `handshake_failure` pode encerrar quatro histórias diferentes antes que elas apareçam no painel. A revisão 14 do mecanismo DANE para autenticar clientes agora separa falha de validação, resposta não autenticada, NXDOMAIN e NODATA. Depois, deixa todas diante da mesma política…
IETF
O EDE 33 pode indicar uma NTA sem provar que ela mudou a resposta
O número 33 já aparece no registro da IANA, mas o documento que explica seu uso ainda está numa chamada de adoção do DNSOP. A combinação expõe duas fronteiras. Uma alocação não é uma decisão final do grupo de trabalho. E um aviso de que uma Negative Trust Anchor estava ativa não…
Reportagens
Os quatro glues IPv6 antigos da RIPE NCC agora são três — porque a raiz não é corrigida em lote
O glue de `.ps` passou a coincidir com o endereço atual do servidor, enquanto `.ne`, `.sd` e `.tj` continuam divergentes. A separação dos resultados mostra que uma única renumeração produz quatro processos de delegação, cada um com sua própria autorização.
História
Gihan Dias e o dia em que duas escritas entraram na raiz
O Sri Lanka já trocava e-mails e operava redes quando surgiu outra fronteira: fazer com que o sistema global de nomes reconhecesse o país em cingalês e tâmil. Na trajetória de Gihan Dias, conexão, linguagem e responsabilidade institucional deixam de ser problemas separados.
Reportagens
LACNIC assina 150 arquivos de DNS reverso, sem manifesto do lote
Há uma assinatura para cada peça, mas não há uma lista assinada dizendo quais peças formam a edição completa. Para quem espelha o diretório de DNS reverso do LACNIC, essa diferença separa integridade de completude.
História
Demi Getschko e o código de país que chegou antes de o Brasil falar TCP/IP
Em 18 de abril de 1989, o `.br` já constava na raiz do DNS. A rede acadêmica brasileira tinha conexões internacionais e trocava mensagens por BITNET e HEPnet, mas a FAPESP só começaria a trafegar TCP/IP em janeiro de 1991. Na trajetória de Demi Getschko, o nome veio primeiro…
Reportagens
O mapa de ccTLDs da AFRINIC conta 27. Três exigem cruzar o endereço.
O total publicado pela AFRINIC passa no teste técnico, mas não por uma busca de nomes. Em 24 delegações, o nome do servidor revela o registro. Em .so, .ng e .ml, é preciso ligar o endereço aos prefixos anycast do NS2 para enxergar a mesma relação.
ICANN
Anne-Marie Eklund Löwinder e a chave que não podia assinar a raiz
A chave de Anne-Marie Eklund Löwinder abria uma caixa de segurança, não a Internet. O detalhe desmonta um mito popular e revela uma escolha institucional mais importante: a confiança na raiz do DNS foi organizada para que nenhuma reputação, posse ou função bastasse sozinha.
Serviços de Nuvem Globais
O que o ASN pode provar — e o que ainda não prova — sobre a AlmazCloud
Os registros públicos podem mostrar que uma organização controla recursos de rede. Eles não bastam, sozinhos, para demonstrar que existe uma nuvem operacional, com infraestrutura implantada, serviços acessíveis e clientes dependentes dela.
ICANN
A autoridade operacional da ICANN é uma cadeia de instrumentos, não um único poder
A autoridade da ICANN sobre operadores e participantes do sistema de identificadores da Internet emerge de uma cadeia verificável: o propósito corporativo e os estatutos definem a instituição; os acordos com registros e registradores transformam parte dessa autoridade em…
Serviços de Nuvem Globais
O que ainda pode ser verificado sobre almazcloud.network e AS210328
O resumo de inteligência sobre O que ainda pode ser verificado sobre almazcloud.network e AS210328 explica o desenvolvimento, as evidências públicas disponíveis aos leitores, as organizações envolvidas, o contexto regional, a exposição de mercado e as possíveis consequências de…
Serviços de Nuvem Globais
AlmazCloud e AS210328: o que seria necessário para provar uma operação de nuvem observável
A existência administrativa de um domínio e de um número de sistema autônomo pode ser documentada. Demonstrar que ambos sustentam hoje uma operação de nuvem voltada a clientes é uma afirmação diferente — e exige uma cadeia de evidências que atravesse registro, roteamento, DNS…
Reportagens
O inventário AuthDNS do RIPE NCC conta 43 nós, mas não a cobertura entregue às redes de acesso
O plano do RIPE NCC não pede apenas mais pontos no mapa: ele procura grandes redes de acesso, redes que trocam tráfego com elas e IXPs capazes de aproximar o AuthDNS de uma população hoje mal atendida. O inventário público comprova 43 instâncias hospedadas em operação, mas ainda…
Serviços em Nuvem da Europa e Oriente Médio
O que os registros públicos podem — e não podem — provar sobre o controle de rede da Genesis Cloud
A infraestrutura pública da Genesis Cloud aparece, em tese, como uma cadeia de camadas distintas: identidade de domínio, delegação DNS, registro de sistema autônomo, política de roteamento, observação de prefixos e declarações de interconexão. O problema analítico é que essas…