Summary

  • O RFC 1383 propôs buscar no DNS reverso um gateway de acesso a uma rede periférica com múltiplas conexões, poupando as tabelas globais do anúncio de cada rede interna.
  • O software experimental descrito esperava um ICMP de destino inalcançável para consultar o DNS. O próprio RFC avisava que isso podia perder o primeiro pacote; o registro RX também não provava que o gateway estava funcionando.

O pacote parte. O roteador declara o destino inalcançável. Um gestor lê essa falha, consulta o DNS e prepara o caminho para os pacotes seguintes. Christian Huitema descreveu essa sequência no RFC 1383, em dezembro de 1992. A perda inicial podia ser o gatilho de uma nova rota, escolhida sem alterar profundamente o código IP comum.

A preocupação era o crescimento das tabelas. O memorando registrava mais de 5 mil redes no NSFNET e mais de 7 mil no EBONE naquele momento. Cada anúncio novo exigia memória dos roteadores de trânsito, tráfego de controle e decisões de política. Agregar endereços numa hierarquia ajudava, mas uma rede atendida por mais de um provedor podia querer trocar conexões e conservar seus endereços.

Huitema importou a lógica de escolha dos registros MX do correio. Um domínio periférico D teria dois gateways, I1 e I2, visíveis da Internet. Eles saberiam chegar às redes internas de D sem divulgar cada uma para o resto do mundo. Um host de origem consultaria in-addr.arpa para o endereço de destino, obteria uma lista experimental RX, escolheria um gateway e encaminharia o pacote com rota indicada na origem. Nos primeiros ensaios, o dado RX era texto num registro TXT: identificador, preferência e IP do gateway. Um tipo DNS definitivo ficava para depois.

Escolher apenas uma vez era essencial. Se cada roteador intermediário consultasse o DNS, todos precisariam de atualização; alguns poderiam mandar para I1 e outros para I2, criando desvios ou ciclos. A origem ou seu primeiro roteador tomaria a decisão, e o trajeto seguiria consistente. Ter dois gateways reduzia o risco de um único ponto de falha e a dependência de um único provedor. A lista DNS, porém, não media saúde. O remetente precisava excluir gateways conhecidos como inalcançáveis; detectar a queda rápido o bastante continuava em aberto.

O catálogo não podia ficar trancado no endereço que pretendia revelar. D teria de manter cópias dos dados RX em servidores de nomes acessíveis pelo núcleo da Internet. Uma resposta guardada apenas atrás da rota quebrada jamais chegaria ao remetente.

Enquanto o DNS respondia, o encaminhador segurava os pacotes numa fila. O relógio de cada um continuava correndo. Sem informação RX para aquele destino, o programa esvaziava a fila e registrava que não havia caminho.

O RFC preferia uma integração direta com o roteamento IP quando essa alteração fosse possível, justamente para não depender do ICMP que podia custar o primeiro pacote. O registro oficial classifica o texto como Experimental. Sua conclusão dizia que o código estava em desenvolvimento no INRIA. Havia também uma aposta econômica: se anunciar endereços próprios fosse cobrado, RX poderia oferecer a clientes multiconectados uma alternativa à renumeração sob o provedor.

O trânsito economizaria conhecimento compartilhado; a origem assumiria busca, escolha e recuperação. O DNS podia indicar uma porta. A entrega teria de mostrar que ela continuava aberta.

Sources