26 votos

¿Los estándares de internet requieren de DNS inverso para cada dispositivo?

Los requisitos de los alrededores DNS inversa son confusas! A menudo la gente habla acerca de todo lo que romper si la inversa de DNS no está presente, y que suena de miedo. Incluso en casos donde las aplicaciones no requieren de DNS inversa, Rfc son frecuentemente citados en apoyo de la obligatoriedad del registro PTR de la creación.

Algunos de estos RFCs son:

RFC1912: Común Operativo de DNS y la Configuración de los Errores

Todos los de Internet-accesible host debe tener un nombre. ... Asegúrese de que el PTR y registros de Un partido. Para cada dirección IP, debe haber una coincidencia de registro PTR en la in-addr.arpa de dominio. Si un host es multi-homed, (más de una dirección IP) asegúrese de que todas las direcciones IP tienen una correspondiente registro PTR (no sólo la primera). Falta de coincidencia de registros a y PTR puede causar la pérdida de servicios de Internet similar a la de no estar registrado en el DNS.

RFC1033: LOS ADMINISTRADORES DE DOMINIO DE LA GUÍA DE OPERACIONES

La adición de un host.

 To add a new host to your zone files:

    Edit the appropriate zone file for the domain the host is in.

    Add an entry for each address of the host.

    Optionally add CNAME, HINFO, WKS, and MX records.

    Add the reverse IN-ADDR entry for each host address in the
    appropriate zone files for each network the host in on.

A pesar de todo eso, algunas personas se empeñan en decir que el PTR de creación del registro no es requerido por las normas que regulan la administración de DNS. ¿Cuáles son las necesidades reales?

36voto

Andrew B Puntos 9763

Respuesta Corta

Hacer de las normas que regulan la operación DNS requieren que todos los dispositivos tienen una coincidencia de registro PTR? No.

¿Las normas para ciertos protocolos que requieren PTR de registros que, de acuerdo con el correspondiente A o AAAA registros? Sí.

Hacer que algunas aplicaciones no se rigen por un RFC tienen las mismas necesidades? Sí.

Puede un registro PTR punto en un registro CNAME? Sí, pero el CNAME objetivo debe ser el único nombre del dispositivo en cuestión (y no otro CNAME). ( RFC 2181§10.2 , RFC1034 §3.6.2 )

Es obligatorio el registro PTR creación de una mejor práctica? Comúnmente se cree así, pero tiene sus propios problemas.

Respuesta Larga

Este Q&A se proporciona con el propósito de ayudar a poner a descansar un malentendido común.

Trágicamente underquoted sección de RFC1796 se aplica aquí:

Es lamentablemente así la propagación de la idea errónea de que la publicación como un RFC proporciona un cierto nivel de reconocimiento. No, o al menos no más de lo que la publicación en un diario. De hecho, cada RFC tiene un estado, en relación a su relación con el proceso de estandarización de Internet: Información, Experimental, o de Seguimiento de Normas (Norma Propuesta, el Proyecto de Norma, Estándar de Internet), o Histórico.

RFC1912 es Informativo. RFC1033, a pesar de la falta de etiquetado claro, también es Informativo. No lo definen las Normas, ni puede ser utilizada oficialmente aumentar en un estándar. Ellos nunca deben ser citadas en el contexto que implica que ellos son la definición de un estándar.

Pensar de información RFC sugerencias como un buen consejo y comúnmente aceptadas como las mejores prácticas. El DNS inverso recomendaciones de sentido en un vistazo: el seguimiento de las directrices de reducir su riesgo de ser puesto en situaciones en las que una aplicación no puede trabajar debido a la inversa de DNS era necesario y no planeados. Ciertamente no se puede esperar que un administrador de DNS para saber cada aplicación/protocolo que requiere, y por desgracia, el mismo que tiende a ser cierto de los propietarios de servicio que solicita los registros.

Dicho esto, fuera de muy buena automatización, obligatorio registro PTR políticas de creación también generan contaminación.

  • Es muy común que PTR los registros no se mantiene en sintonía con sus correspondientes A/AAAA registros como los dispositivos son de baja, lo que resulta en una fluencia de falsos PTR datos a través del tiempo. Estos datos sólo sirve para confundir a aquellos que intentan tratar esa información como creíble. Algunos de los propietarios de las aplicaciones están con ganas de saltar sobre él cuando están a la caza de la causa de un fantasma problema. El problema seguirá empeorando a medida que la adopción de IPv6 se vuelve más común, especialmente para los administradores de DNS responsable de portador del tamaño de espacio de direcciones IP.
  • Tener múltiples registros PTR para la misma dirección IP es bastante inútil, y seguir el consejo de Informativos Rfc resultará inevitablemente en esto. Ver: ¿por Qué varios registros PTR en DNS no es recomendable?

Lo que es peor: la ausencia de un registro PTR, o una incorrecta registro PTR? Si un protocolo rompe, porque su norma requiere que la DNS válido, ambos son malos, y el segundo, en realidad podría ser peor. Fuera de eso, todo el mundo tiene una opinión diferente sobre el asunto. Eso está bien: usted es libre de armar las políticas y las herramientas que funcionan mejor para su equipo y en la empresa. Asegúrese de que la escala y producir resultados consistentes, y recuerda que el DNS inverso será tan preciso como el tiempo y la disciplina de los miembros de su equipo tienen que dar.

Pero faltan los registros PTR causa sshd para colgar!

También no es cierto. La gente suele confundir la línea entre la ausencia de un registro PTR (NXDOMAIN), y roto DNS inversa.

Una respuesta de NXDOMAIN sólo va a causar un problema si usted se está comunicando con un servicio que requiere adelante confirmó DNS inversa (FCrDNS). Los servidores de correo, Kerberos, Oracle scan VIPs, etc.

Roto DNS inversa es cuando es imposible para que usted pueda obtener un NXDOMAIN respuesta en forma oportuna. Muchas aplicaciones (la más famosa sshd) de los bloques en la búsqueda de DNS inversa si hay problemas en la adquisición de una respuesta por parte de aguas arriba de las fuentes de una manera oportuna, lo que provoca retrasos en la aplicación.

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: