Qual é o objetivo 0.in-addr.arpa e 255.in-addr.arpa na configuração padrão do bind?

Eu tenho o Ubuntu 16 LTS

Qual é o objetivo das zonas 0.in-addr.arpa e 255.in-addr.arpa na configuração padrão do bind? ( named.conf.default-zones)

Eu pergunto aqui porque acho que esses arquivos de zona são comuns nos pacotes do bind em várias distribuições GNU / Linux, não nas específicas do Ubuntu.

— Bulat M.
fonte

Eles são comuns nos pacotes BIND para todos os sistemas operacionais, não apenas para Linux.

— Alnitak

Respostas:

O objetivo das zonas locais padrão no BIND é impedir que as consultas desses intervalos de IP vazem para a Internet global e reduzir a carga nos servidores de nomes raiz, de acordo com a RFC 6303 "zonas DNS localmente servidas" .

Desde a introdução dessa RFC:

Essa recomendação é feita porque os dados mostram que está ocorrendo um vazamento significativo de consultas para esses espaços para nome, apesar das instruções para restringi-las e, portanto, tornou-se necessário implantar servidores de nomes sacrificiais para proteger os
servidores de nome pai imediatos dessas zonas contra consultas excessivas e não intencionais carregar [AS112] [RFC6304] [RFC6305]. Há toda a expectativa de que o carregamento da consulta continue aumentando, a menos que sejam tomadas as etapas descritas aqui.

Além disso, as consultas de clientes atrás de firewalls mal configurados que permitem consultas de saída para esses espaços de nomes, mas eliminam as respostas, carregam uma carga significativa nos servidores raiz (as zonas de encaminhamento, mas não as zonas reversas são configuradas). Eles também causam carga operacional para os operadores do servidor raiz, pois precisam responder a perguntas sobre por que os servidores raiz estão "atacando" esses clientes.

Isso deve ser considerado a referência definitiva, principalmente porque o RFC foi escrito por Mark Andrews, um dos principais desenvolvedores que trabalham no BIND.

Consulte também o Registro da IANA de zonas servidas localmente , que contém a lista de todas as zonas (reversas) que devem ser atendidas assim.

Desde o lançamento do BIND 9.9 em 2011, o BIND9 cria automaticamente as zonas locais padrão no momento da inicialização, a menos que seja explicitamente desativado com o empty-zones-enablesinalizador no named.confarquivo.

O registro da IANA é rastreado pelo ISC e novas entradas são adicionadas às fontes BIND atuais como e quando elas aparecem.

— Alnitak
fonte

Então você disse a mesma coisa que a minha resposta, mas de uma maneira diferente, mas a minha resposta está "desatualizada"?

— Darren

@ Alnitak, então deve-se incluir essas zonas no BIND, para que ele possa lidar com essas consultas sem encaminhar para servidores raiz?

— Bulat M.

@BulatM. com versões modernas BIND não deve ser necessário - que vai ser ativado automaticamente no arranque, a menos que tenha sido desativado por seu pacote distro com a empty-zones-enableconfiguração no named.conf. A lista de zonas vazias deve aparecer na saída do seu syslog quando o BIND for iniciado.

— Alnitak

@BulatM. a criação automática de zonas locais padrão foi introduzida no BIND 9.9, em 2011, BTW.

— Alnitak

@BulatM. depende da versão BIND - se for 9.9 ou posterior, não há necessidade disso include.

— Alnitak

Isso daqui (uma página da MS, mas ainda relevante):

As zonas de pesquisa inversa permitem que o servidor DNS seja autoritário, ou seja, saiba a resposta com antecedência e responda imediatamente às consultas de nome mais comuns, eliminando consultas recursivas desnecessárias. De acordo com as solicitações de comentários pertinentes (RFCs), por padrão, o servidor DNS tem autoridade para três zonas de pesquisa inversa:
0.in-addr.arpa (0.0.0.0)

127.in-addr.arpa (127.0.0.1 - loopback)

255.in-addr.arpa (255. 255. 255. 255 - broadcast)

Em outras palavras; o servidor DNS não consultará um servidor DNS baseado na Internet em busca desses endereços (pois todos são endereços locais).

— Darren
fonte

@BulatM .: Acho que ninguém faria isso deliberadamente, mas esses endereços podem ser capturados em uma ferramenta de uso geral, ou podem acontecer por acidente. Quando isso acontecer, você deseja os resultados corretos. Então, por que não implementar isso?

— Lightness Races in Orbit

@ BululM .: Acho que você está olhando para trás. Você está tentando encontrar um caso de uso. Em vez disso, fazemos as coisas corretamente por especificação, então todos os casos de uso concebíveis e inconcebíveis são cobertos por padrão.

— Lightness Races in Orbit

Mas é perfeitamente razoável ter, por exemplo, uma ferramenta que mostra todos os processos de escuta no seu PC e nas portas, endereços IP aos quais eles estão vinculados e nome de host rDNS correspondente . Essa ferramenta geralmente tenta encontrar o nome do host para "127.0.0.1", "0.0.0.0" etc. E este é apenas o primeiro exemplo que eu criei.

— Josef diz Restabelecer Monica

"muitas vezes" é um pouco de eufemismo. Até 7% do tráfego total chegar a alguns servidores raiz consiste em consultas inversas para endereços IP privados, e uma infra-estrutura de roteamento completo (AS112) foi construído apenas para lidar com este problema

— Calimo

@ Darren está desatualizado porque a lista de zonas recomendada pela IETF e mantida pela IANA contém cerca de 30 entradas, não apenas as 3 mencionadas pela Microsoft. Este tema específico tenha mudado um pouco recentemente, e as ligações eu incluí na minha resposta são as referências definitivas. Não posso responder pelos outros resolvedores populares, mas o BIND faz isso por padrão para toda a lista da IANA.

— Alnitak