Resumo

  • O UIXP lista duas redes DNS da AFRINIC ligadas diretamente à LAN de peering: AFDSP/NS2 no AS37177 e DotARPA no AS37181. O guia da AFRINIC atribui a cada uma pares diferentes de prefixos IPv4 e IPv6.
  • NS2 presta DNS secundário e não controla o conteúdo da zona; DotARPA integra uma cadeia separada de DNS reverso. Uma medição de um serviço não comprova o outro.
  • Diretórios do UIXP e PeeringDB e registros RDAP demonstram identidade e interface de interconexão. Não demonstram anúncio BGP atual, participação em servidores de rotas, aterrissagem local da consulta, latência, disponibilidade ou resiliência.
  • Um recibo verificável deve acompanhar cada serviço: ASN, prefixos anunciados, modalidade de peering, estado de ativação e saúde, espaços de nomes, ponto de observação, instância que respondeu e horário.

O diretório preserva a diferença

O UIXP diz que as redes de sua página estão conectadas diretamente à LAN de peering. A linha “AFRINIC - DNS - AFDSP” mostra ASN 37177, política aberta e 2025 como ano de entrada. A linha “AFRINIC - DNS - DotARPA” mostra ASN 37181, também com política aberta e o mesmo ano. A organização é uma; as identidades de rede são duas.

A própria página orienta o leitor a usar o looking glass para descobrir se uma rede participa dos servidores de rotas e quais prefixos anuncia. Esse aviso define o alcance do diretório. Uma interface na rede de troca cria um lugar para formar sessões e trocar rotas. Ela não registra o estado instantâneo de uma sessão BGP, os filtros aplicados, os vizinhos que aceitaram os anúncios ou o caminho escolhido por um resolvedor.

A API do PeeringDB oferece uma segunda fotografia declaratória. Nos dados capturados, os dois ASNs aparecem no ix_id 422, correspondente ao UIXP. O AS37177 tem endereços de peering terminados em .5 e ::5; o AS37181 tem endereços terminados em .6 e ::6. Esses são endereços na LAN do ponto de troca. Não são os prefixos anycast do serviço DNS.

As duas classes de endereço respondem a perguntas diferentes. O endereço de peering informa onde os roteadores podem conversar. O prefixo de serviço informa qual destino pode ser aprendido por meio dessa conversa. Confundir os dois transforma um cadastro de interface em uma alegação de disponibilidade. Também apaga a possibilidade de uma interface estar ativa enquanto um prefixo está filtrado, retirado ou anunciado por outro caminho.

Um mapa institucional pode representar a presença com um ponto em Kampala. Um registro de operação precisa manter duas linhas, porque qualquer diferença entre elas será justamente o sinal de que um estado agregado escondeu um problema.

AS37177 é a cadeia do NS2

O guia de implantação da AFRINIC associa NS2 ao AS37177, ao prefixo IPv4 196.216.168.0/24 e ao prefixo IPv6 2001:43f8:120::/48. A página do programa descreve a rede como serviço anycast para infraestrutura secundária de ccTLDs africanos e outras necessidades regionais de DNS.

O termo “secundário” delimita a autoridade. Na descrição do AfDSP, a AFRINIC afirma que os dados de zona são transferidos do servidor primário. A organização não administra o conteúdo da zona. Ela pode operar uma cópia autoritativa adicional e distribuí-la por rotas anycast, mas não passa a decidir quais nomes ou registros devem existir.

Essa divisão não diminui o papel do serviço. Uma cópia secundária bem operada pode acrescentar caminho de resposta, diversidade e continuidade. O ponto é outro: a disponibilidade da cópia e a governança do conteúdo são objetos distintos. Se uma zona contém um dado incorreto, a pergunta começa no primário; se a cópia não responde, a pergunta começa na cadeia de transferência, aplicação, rota e infraestrutura.

Por isso este artigo não repete uma contagem de ccTLDs hospedados. Uma lista de zonas procura descobrir quais delegações ou endereços se juntam aos prefixos NS2. A questão do UIXP é saber se os prefixos do AS37177 são visíveis naquele ponto, quais redes os aprendem e quais consultas chegam à instância de Uganda. A associação de uma zona ao serviço não comprova o estado de um local específico.

Os registros RDAP ligam o AS37177 e seus blocos publicados ao cadastro organizacional da AFRINIC. São evidência de identidade de recursos, não telemetria de roteamento. O RDAP não mostra se 196.216.168.0/24 ou 2001:43f8:120::/48 apareciam no looking glass do UIXP quando as fontes foram congeladas. Também não identifica servidor de rotas, sessão bilateral ou instância que recebeu uma consulta.

Entre a identidade e uma resposta DNS há várias junções: anúncio do prefixo, aceitação pelo vizinho, escolha de rota, seleção da instância anycast, saúde do processo e presença da zona consultada. As páginas públicas esclarecem os identificadores. Elas não autorizam pular as junções não observadas.

AS37181 é a cadeia do DotARPA

Para DotARPA, o guia publica outro conjunto: AS37181, IPv4 196.216.169.0/24 e IPv6 2001:43f8:110::/48. Os números são parecidos com os do NS2, mas não são os mesmos. A semelhança visual facilita uma tabela compacta e aumenta o risco de copiar um campo errado. Não cria equivalência operacional.

O papel também é diferente. A AFRINIC relaciona o AS37181 à infraestrutura de DNS reverso tratada no RFC 5855. O documento estabeleceu identidades de nameserver dedicadas para IN-ADDR.ARPA e IP6.ARPA. A intenção é separar o serviço reverso de dependências desnecessárias com outras funções DNS, reduzindo falhas colaterais. Um ASN e prefixos próprios tornam essa separação legível no roteamento.

Isso não significa que toda consulta reversa feita na África deva chegar a essa instância. O DNS segue delegações, referências e caches. O anycast acrescenta a escolha de instância baseada nas rotas visíveis a partir de cada origem. O nome consultado, a situação do cache, a política de rota e a saúde do servidor selecionado alteram o resultado.

DotARPA também não deve ser confundido com o programa de cópias de servidores raiz. A AFRINIC descreve esse programa separado como uma atividade de facilitação e afirma que não é a operadora da cópia. A organização de servidor raiz mantém essa responsabilidade. Os programas podem compartilhar o objetivo de distribuir infraestrutura crítica, sem compartilhar autoridade ou operação.

RDAP e PeeringDB sustentam a identidade pública do AS37181 e de sua interface no UIXP. Não mostram uma rota nem uma resposta. A consequência mais importante é metodológica: uma consulta NS2 bem-sucedida no AS37177 não preenche o campo de saúde do DotARPA, e uma rota do AS37181 não prova que o NS2 está ativo.

Em anycast, “local” é uma observação

Anycast permite que várias instâncias anunciem o mesmo endereço de serviço. O roteamento escolhe a instância alcançada a partir de uma origem. Essa arquitetura distribui o serviço sem exigir que o cliente escolha um local, mas também torna a palavra “local” dependente da camada que está sendo medida.

Uma máquina pode estar instalada em Uganda. O ASN pode ter interface no UIXP. Uma rede ugandense pode aprender os prefixos de serviço. Uma consulta dessa rede pode ser respondida pela instância local. As quatro afirmações se relacionam, mas nenhuma prova automaticamente a seguinte. Uma máquina pode existir sem anúncio; uma rota pode permanecer enquanto a aplicação falha; uma aplicação saudável pode não ser escolhida pela política de um vizinho; o cache pode evitar a consulta ao autoritativo.

O RFC 4786 separa explicitamente alcance de rede e saúde da aplicação. Se o processo DNS falhar e o prefixo continuar anunciado, o roteamento entregará tráfego a uma instância incapaz de responder. O desenho operacional precisa ligar o sinal de saúde à retirada de rota ou a outro mecanismo que impeça a atração de consultas. Uma rota verde não é um teste DNS.

O inverso também ocorre. Uma aplicação saudável pode não receber tráfego de determinada rede porque ela não usa os servidores de rotas, porque falta uma sessão bilateral, porque um filtro recusa o prefixo ou porque outra rota é preferida. Anycast não garante proximidade geográfica; escolhe conforme a topologia e a política que o BGP enxerga.

O RFC 7094 transforma essa característica em requisito de medição distribuída. Um looking glass mostra a visão de um coletor. Uma consulta mostra a experiência de um ponto em um momento. Para falar em padrão regional, são necessários vários pontos de observação, repetição temporal e um método de identificar a instância que respondeu. Sem identidade da instância, baixa latência não prova que a resposta veio de Uganda. Sem duração, um sucesso não prova disponibilidade.

A AFRINIC apresenta desempenho e resiliência como objetivos do programa. São efeitos plausíveis da arquitetura. O pacote de fontes deste artigo não contém comparação anterior e posterior ao UIXP, teste de failover, série de uptime ou distribuição das consultas por instância. Portanto, não demonstra benefício medido, mas tampouco demonstra ausência de benefício. A disciplina é manter objetivo, presença e resultado em campos separados.

A responsabilidade também é dividida

O guia de implantação pede capacidade BGP, uma rede de gestão separada da rede de peering e ambiente para uma OVA. A configuração-base publicada inclui duas CPUs virtuais, quatro gigabytes de memória e dez gigabytes de disco. São requisitos para o hospedeiro, não uma descrição da topologia real no UIXP. As fontes não dizem se os serviços usam uma ou duas máquinas, um host físico compartilhado ou redundância.

O hospedeiro fornece infraestrutura, energia e conectividade, procura manter a disponibilidade e avisa a AFRINIC sobre interrupções. A AFRINIC mantém software e configuração, trata segurança, coordena BGP, monitora a saúde e participa da solução de problemas. A divisão é normal em um serviço cooperativo. Ela exige, porém, que cada transição deixe rastro.

Se BGP continuar anunciando enquanto DNS falha, devem ser examinados o sinal de saúde e a retirada, além da causa em software ou infraestrutura. Se DNS estiver saudável e um membro não receber a rota, a investigação se move para sessão, servidor de rotas, filtro e política. Se NS2 responder e DotARPA não, um único indicador “nó AFRINIC disponível” produz uma conclusão falsa. Se IPv4 funcionar e IPv6 não, o nível do ASN ainda é agregado demais.

O objetivo não é escolher antecipadamente um culpado. É registrar serviço, ASN, família de endereços, forma de peering, saúde, instância observada e ator capaz de corrigir cada junção. Assim, mesmo uma causa ainda desconhecida tem contorno verificável.

Cinco camadas de evidência

As fontes podem ser organizadas em cinco camadas. A documentação do programa explica finalidade e desenho. O RDAP explica titularidade dos identificadores. UIXP e PeeringDB explicam a interface declarada de interconexão. O looking glass e as RIBs de participantes explicariam anúncios observados. As medições DNS explicariam consultas, respostas e instâncias.

As três primeiras camadas estão presentes; as duas últimas não foram capturadas. A ausência das últimas não nega as primeiras. A presença das primeiras não autoriza inventar as últimas. Separar as camadas evita tanto a alegação cética de que “não há nó” quanto a alegação promocional de que “o benefício está comprovado”.

A política “aberta” de peering expressa disposição, não a lista de todas as sessões estabelecidas. A conexão direta expressa uma interface no tecido, não a propagação atual dos prefixos. O ano de entrada expressa um atributo do diretório, não a data de instalação, ativação, primeiro anúncio ou primeira consulta. Manter o significado temporal de cada registro é parte do controle.

A camada de rota precisa nomear prefixo e família. Para AS37177, procurar os blocos NS2; para AS37181, os blocos DotARPA. Ver apenas IPv4 não demonstra implantação dual-stack. Ver apenas o coletor do servidor de rotas não demonstra a escolha de cada membro. A camada DNS precisa registrar nome, tipo, modo recursivo ou autoritativo, código de resposta, método de identificar instância e horário. Latência isolada não substitui identidade.

Com essas camadas separadas, divergências deixam de ser ruído. Tornam-se perguntas específicas: o cadastro mudou, a sessão caiu, o prefixo foi filtrado, a aplicação falhou, a zona não estava presente ou o resolvedor escolheu outro local?

Dois recibos para uma presença pública

O recibo de NS2 deve começar com AS37177 e os prefixos 196.216.168.0/24 e 2001:43f8:120::/48. O de DotARPA deve começar com AS37181 e 196.216.169.0/24 e 2001:43f8:110::/48. Os endereços .5/::5 e .6/::6 ficam em campo separado como interfaces do UIXP.

Na parte de rota, IPv4 e IPv6 recebem linhas próprias: prefixo esperado, presença, coletor, vizinho ou servidor de rotas e horário. Na parte da aplicação entram classe de serviço ou espaço de nomes, saúde e vínculo com retirada. Na parte de observação entram ponto, modo do resolvedor, nome e tipo de consulta, código, latência, identidade da instância e tempo. Um hash do lote preserva a ligação entre resumo e dados.

Nenhum campo é um atalho. “Ativado” não prova rota atual. Rota não prova DNS saudável. Resposta correta não prova todas as zonas previstas. Uma latência baixa não prova melhoria regional. O valor do recibo está em conservar as junções e permitir comparação sem mudar o significado dos dados.

Hoje, a conclusão defensável é forte por ser limitada: duas identidades DNS da AFRINIC, com funções e recursos diferentes, aparecem como conexões diretas no UIXP. As fontes não mostram que todas as consultas relevantes de Uganda cheguem localmente, nem medem ganho de desempenho ou resiliência. Se esses resultados forem demonstrados, devem chegar como dois recibos operacionais, e não como o brilho de um único ponto no mapa.

Fontes

  1. Guia de implantação DNS anycast da AFRINIC: https://dns.afrinic.net/deployment-guide/
  2. Programa DNS da AFRINIC: https://dns.afrinic.net/
  3. Redes conectadas ao UIXP: https://www.uixp.co.ug/networks
  4. Serviços e servidores de rotas do UIXP: https://www.uixp.co.ug/services
  5. Serviço secundário AfDSP: https://afrinic.net/dns-support.html
  6. Programa de cópias de servidores raiz: https://afrinic.net/root-server-copy.html
  7. RFC 5855: https://www.rfc-editor.org/rfc/rfc5855.html
  8. RFC 4786: https://www.rfc-editor.org/rfc/rfc4786.html
  9. RFC 7094: https://www.rfc-editor.org/rfc/rfc7094.html
  10. RFC 1034: https://www.rfc-editor.org/rfc/rfc1034.html
  11. RDAP AFRINIC, AS37177: https://rdap.afrinic.net/rdap/autnum/37177
  12. RDAP AFRINIC, AS37181: https://rdap.afrinic.net/rdap/autnum/37181
  13. RDAP, 196.216.168.0/24: https://rdap.afrinic.net/rdap/ip/196.216.168.0
  14. RDAP, 196.216.169.0/24: https://rdap.afrinic.net/rdap/ip/196.216.169.0
  15. RDAP, 2001:43f8:120::/48: https://rdap.afrinic.net/rdap/ip/2001:43f8:120::
  16. RDAP, 2001:43f8:110::/48: https://rdap.afrinic.net/rdap/ip/2001:43f8:110::
  17. API PeeringDB, AS37177: https://www.peeringdb.com/api/netixlan?asn=37177
  18. API PeeringDB, AS37181: https://www.peeringdb.com/api/netixlan?asn=37181