¿Cuál es el propósito de 0.in-addr.arpa y 255.in-addr.arpa en la configuración predeterminada de bind?

Tengo Ubuntu 16 LTS

¿Cuál es el propósito de las zonas 0.in-addr.arpa y 255.in-addr.arpa en la configuración predeterminada de bind? ( named.conf.default-zones)

Pregunto aquí porque creo que estos archivos de zona son comunes en los paquetes de bind en varias distribuciones de GNU / Linux, no en las específicas de Ubuntu.

— Bulat M.
fuente

Son comunes en los paquetes BIND para todos los sistemas operativos, no solo Linux.

— Alnitak

Respuestas:

El propósito de las zonas locales predeterminadas en BIND es evitar que las consultas para esos rangos de IP se filtren en Internet global y reducir la carga en los servidores de nombres raíz, según RFC 6303 "Zonas DNS servidas localmente" .

De la introducción a ese RFC:

Esta recomendación se hace porque los datos han demostrado que se está produciendo una fuga significativa de consultas para estos espacios de nombres, a pesar de las instrucciones para restringirlos, y porque, por lo tanto, se ha vuelto necesario implementar servidores de nombres sacrificados para proteger los
servidores de nombres primarios inmediatos para estas zonas de consultas excesivas e involuntarias cargar [AS112] [RFC6304] [RFC6305]. Existe la expectativa de que la carga de la consulta continuará aumentando a menos que se tomen los pasos descritos aquí.

Además, las consultas de clientes detrás de firewalls mal configurados que permiten consultas salientes para estos espacios de nombres, pero eliminan las respuestas, ponen una carga significativa en los servidores raíz (se configuran zonas de reenvío pero no zonas de reversa). También causan una carga operativa para los operadores del servidor raíz, ya que tienen que responder a las preguntas sobre por qué los servidores raíz están "atacando" a estos clientes.

Esto debería considerarse la referencia definitiva, sobre todo porque el RFC fue escrito por Mark Andrews, uno de los principales desarrolladores que trabajan en BIND.

Consulte también el Registro de zonas servidas localmente de la IANA , que contiene la lista de todas las zonas (inversas) que deberían servirse así.

Desde el lanzamiento de BIND 9.9 en 2011, BIND9 crea automáticamente las zonas locales predeterminadas en el momento del inicio, a menos que se desactive explícitamente con la empty-zones-enablemarca en el named.confarchivo.

ISC rastrea el registro de IANA y agrega nuevas entradas a las fuentes BIND actuales cuando aparecen.

— Alnitak
fuente

Entonces, ¿has dicho lo mismo que mi respuesta pero de una manera diferente, pero mi respuesta está "desactualizada"?

— Darren

@Alnitak, ¿debería incluir estas zonas en BIND, para que pueda manejar tales consultas sin reenviar a los servidores raíz?

— Bulat M.

@BulatM. con las versiones modernas de BIND no debería ser necesario: se habilitarán automáticamente al inicio, a menos que hayan sido desactivadas por su paquete de distribución con la empty-zones-enableconfiguración en named.conf. La lista de zonas vacías debería aparecer en su salida de syslog cuando se inicia BIND.

— Alnitak

@BulatM. La creación automática de zonas locales predeterminadas se introdujo en BIND 9.9, en 2011, por cierto.

— Alnitak

@BulatM. depende de la versión BIND: si es 9.9 o posterior, entonces no hay necesidad de eso include.

— Alnitak

Esto desde aquí (una página de MS, pero aún relevante):

Las zonas de búsqueda inversa permiten que el servidor DNS tenga autoridad, es decir, conocer la respuesta de antemano y responder de inmediato a las consultas de nombre más comunes, eliminando consultas recursivas innecesarias. De acuerdo con las Solicitudes de Comentarios (RFC) pertinentes, de manera predeterminada, el servidor DNS tiene autoridad para tres zonas de búsqueda 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)

En otras palabras; el servidor DNS no consultará un servidor DNS basado en Internet para esas direcciones (ya que todas son direcciones locales).

— Darren
fuente

@BulatM .: No creo que nadie lo haga deliberadamente, pero tales direcciones pueden quedar atrapadas en una herramienta de propósito más general, o puede ocurrir por accidente. Cuando lo hace, quieres los resultados correctos. Entonces, ¿por qué no implementar esto?

— ligereza corre en órbita el

@BulatM .: Creo que estás mirando esto al revés. Estás tratando de encontrar un caso de uso. En cambio, hacemos las cosas correctamente según la especificación, luego todos los casos de uso concebibles e inconcebibles están cubiertos por defecto.

— Carreras de ligereza en órbita

Pero es perfectamente razonable tener, por ejemplo, una herramienta que le muestre todos los procesos de escucha en su PC y los puertos, las direcciones IP a las que están vinculados y que coincidan con el nombre de host rDNS . Con frecuencia, dicha herramienta intentará encontrar el nombre de host para "127.0.0.1", "0.0.0.0", etc. Y este es solo el primer ejemplo que se me ocurrió.

— Josef dice Reinstate Monica

"bastante a menudo" es un poco insuficiente. Hasta el 7% del tráfico total que llega a algunos servidores raíz consiste en consultas inversas para direcciones IP privadas, y se ha construido una infraestructura de enrutamiento completa (AS112) solo para manejar este problema

— Calimo

@Darren está desactualizado porque la lista de zonas recomendadas por IETF y mantenida por IANA contiene alrededor de 30 entradas, no solo las 3 mencionadas por Microsoft. Este tema en particular ha cambiado bastante recientemente, y los enlaces que he incluido en mi respuesta son las referencias definitivas. No puedo responder por los otros solucionadores populares, pero BIND lo hace de manera predeterminada para toda la lista de IANA.

— Alnitak