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

¡Los requisitos que rodean el DNS inverso son confusos! La gente habla frecuentemente de que todo se rompe si el DNS inverso no está presente, y eso suena aterrador. Incluso en los casos en que las aplicaciones no requieren DNS inverso, los RFC se citan con frecuencia en apoyo de la creación obligatoria de registros PTR.

Algunos de estos RFC incluyen:

RFC1912 : Errores comunes de operación y configuración de DNS

Cada host accesible a Internet debe tener un nombre. ... Asegúrese de que sus registros PTR y A coincidan. Para cada dirección IP, debe haber un registro PTR coincidente en el dominio in-addr.arpa. Si un host es multitarjeta (más de una dirección IP), asegúrese de que todas las direcciones IP tengan un registro PTR correspondiente (no solo la primera). No tener registros PTR y A coincidentes puede causar la pérdida de servicios de Internet similares a no estar registrado en el DNS.

RFC1033 : GUÍA DE OPERACIONES DE ADMINISTRADORES DE DOMINIO

Agregar 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 todavía insisten en decir que la creación de registros PTR no es requerida por los estándares que rigen la administración de DNS. ¿Cuáles son los requisitos reales?

Respuesta corta

¿Los estándares que rigen la operación de DNS requieren que todos los dispositivos tengan un registro PTR coincidente? No.

¿Los estándares para ciertos protocolos requieren PTRregistros que coinciden con los correspondientes Ao AAAAregistros? Sí.

¿Algunas aplicaciones no regidas por un RFC tienen los mismos requisitos? Sí.

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

¿Es la creación obligatoria de registros PTR una mejor práctica? Comúnmente se cree así, pero tiene sus propios problemas.

Respuesta larga

Este Q&A se proporciona con la intención de ayudar a calmar un malentendido común.

Aquí se aplica una sección trágicamente subcotizada de RFC1796 :

Es una idea equivocada lamentablemente bien difundida que la publicación como RFC proporciona cierto nivel de reconocimiento. No lo hace, o al menos no más que la publicación en una revista regular. De hecho, cada RFC tiene un estado, en relación con su relación con el proceso de estandarización de Internet: Seguimiento informativo, experimental o de normas (Norma propuesta, Proyecto de norma, Norma de Internet) o Histórico.

RFC1912 es informativo. RFC1033 no está claramente etiquetado y tiene una designación oficial de DESCONOCIDO , lo que significa que es tan antiguo que no debe considerarse una referencia para nada . No definen Estándares, ni pueden usarse para aumentar oficialmente un estándar. Nunca deben citarse en el contexto que implique que están definiendo un estándar.

Piense en las sugerencias informativas de RFC como buenos consejos y mejores prácticas comúnmente aceptadas. Las recomendaciones de DNS inverso tienen sentido de un vistazo: seguir estas pautas reduce el riesgo de ser puesto en situaciones en las que una aplicación no funciona porque el DNS inverso era necesario y no estaba planeado. Ciertamente, no puede esperar que un administrador de DNS conozca todas las aplicaciones / protocolos que lo requieren, y lamentablemente lo mismo suele suceder con los propietarios de servicios que solicitan esos registros.

Dicho esto, fuera de muy buena automatización , las políticas obligatorias de creación de registros PTR también crean contaminación.

• Es extremadamente común que los PTRregistros no se mantengan sincronizados con sus registros A/ correspondientes a AAAAmedida que los dispositivos se retiran del servicio, lo que resulta en un PTRflujo de datos falsos con el tiempo. Estos datos solo sirven para engañar a quienes intentan tratar esa información como creíble. Algunos propietarios de aplicaciones están ansiosos por saltar cuando buscan la causa de un problema fantasma. El problema solo continuará empeorando a medida que la adopción de IPv6 se vuelva más común, particularmente para los administradores de DNS responsables del espacio de IP del tamaño del operador.
• Tener múltiples registros PTR para la misma dirección IP es bastante inútil, y cumplir con el consejo de los RFC informativos inevitablemente resultará en esto. Ver: ¿Por qué no se recomiendan múltiples registros PTR en DNS?

¿Qué es peor: ausencia de un registro PTR o un registro PTR inexacto? Si un protocolo se rompe porque su estándar requiere un DNS válido, ambos son malos y el último podría ser peor . Fuera de eso, todos tienen una opinión diferente al respecto. Eso está bien: usted es libre de reunir las políticas y herramientas que funcionan mejor para su equipo y empresa. Solo asegúrese de que escalen y produzcan resultados consistentes, y recuerde que el DNS inverso solo será tan preciso como el tiempo y la disciplina que los miembros de su equipo tienen que brindarle.

¡Pero la falta de registros PTR hace que sshd se cuelgue!

Tampoco es cierto. La gente a menudo confunde la línea entre la ausencia de un registro PTR (NXDOMAIN) y el DNS inverso roto .

Una respuesta de NXDOMAINsolo causará un problema si se está comunicando con un servicio que requiere un DNS inverso confirmado por reenvío (FCrDNS). Servidores de correo, Kerberos, Oracle escanean VIP, etc.

El DNS inverso roto es cuando es imposible para usted obtener una NXDOMAINrespuesta a tiempo. Muchas aplicaciones (más famosas sshd) se bloquearán en la búsqueda inversa de DNS si hay problemas para obtener una respuesta de fuentes ascendentes de manera oportuna, causando demoras dentro de la aplicación.