El DNS inverso confirmado hacia adelante ( FCrDNS ), también conocido como DNS inverso de círculo completo , DNS doble inverso o iprev , es una configuración de parámetros de red en la que una dirección IP determinada tiene tanto directa (nombre a dirección) como inversa ( dirección a nombre) Entradas del sistema de nombres de dominio (DNS) que coinciden entre sí. Esta es la configuración estándar que esperan los estándares de Internet que admiten muchos protocolos que dependen de DNS. David Barr publicó una opinión en RFC 1912 (Informativo) recomendándola como la mejor práctica para los administradores de DNS, pero no existen requisitos formales para que esté codificada dentro del propio estándar DNS. [1]
Una verificación FCrDNS puede crear una forma débil de autenticación de que existe una relación válida entre el propietario de un nombre de dominio y el propietario de la red a la que se le ha dado una dirección IP. Si bien es débil, esta autenticación es lo suficientemente fuerte como para que se pueda usar con fines de inclusión en listas blancas porque los spammers y los phishers generalmente no pueden pasar por alto esta verificación cuando usan computadoras zombies para falsificar correos electrónicos. Es decir, el DNS inverso puede verificar, pero generalmente será parte de otro dominio que no sea el nombre de dominio reclamado.
El uso del servidor de correo de un ISP como retransmisor puede resolver el problema del DNS inverso, ya que el requisito es que la búsqueda hacia adelante y hacia atrás para el retransmisor de envío debe coincidir, no tiene que estar relacionado con el campo de origen o el dominio de envío de los mensajes. relés.
Otros métodos para establecer una relación entre una dirección IP y un dominio en el correo electrónico son el Sender Policy Framework (SPF) y el registro MX .
Los ISP que no configuran o no pueden configurar el DNS inverso generarán problemas para los hosts en sus redes, en virtud de que no pueden admitir aplicaciones o protocolos que requieran que el DNS inverso esté de acuerdo con el registro A (o AAAA) correspondiente. Los ISP que no pueden o no proporcionarán DNS inverso en última instancia, limitarán la capacidad de su base de clientes para utilizar los servicios de Internet que brindan de manera efectiva y segura.
Aplicaciones
- La mayoría de los agentes de transferencia de correo electrónico (software de servidor) utilizan una verificación FCrDNS y, si hay un nombre de dominio válido, colóquelo en el campo de encabezado de seguimiento "Recibido:".
- Algunos agentes de transferencia de correo electrónico realizarán la verificación FCrDNS en el nombre de dominio proporcionado en los comandos SMTP HELO y EHLO. Esto puede violar RFC 2821 y, por lo tanto, el correo electrónico generalmente no se rechaza de forma predeterminada.
- El sistema anti-falsificación de correo electrónico del Marco de políticas del remitente utiliza una verificación FCrDNS en su mecanismo "ptr:". Sin embargo, se desaconseja el uso de este mecanismo "ptr:" desde la primera estandarización de SPF en 2006 (en RFC 4408 ).
- Algunos filtros de correo no deseado utilizan comprobaciones FCrDNS como método de autenticación para nombres de dominio o para fines de listas blancas , según RFC 8601 , por ejemplo.
- SpamCop utiliza la verificación FCrDNS, que a veces causa problemas a los usuarios de SpamCop que también son clientes de proveedores de servicios de Internet que no proporcionan registros DNS y rDNS adecuados para los servidores de correo. [1] [2]
- Algunos servidores FTP , Telnet y TCP Wrapper realizan comprobaciones FCrDNS. [3]
- Algunos servidores IRC realizan comprobaciones FCrDNS para evitar abusos.
Referencias
- ^ "Información sobre STD 13» RFC Editor " . Consultado el 26 de marzo de 2018 .
