El DNS inverso confirmado hacia adelante ( FCrDNS ), también conocido como DNS inverso de círculo completo , DNS inverso doble o iprev , es una configuración de parámetros de red en la que una dirección IP dada tiene entradas de Sistema de nombres de dominio (DNS) de avance (nombre a dirección) e inverso (dirección a nombre) que coinciden entre sí. Esta es la configuración estándar esperada por los estándares de Internet que admiten muchos protocolos que dependen de DNS. David Barr publicó una opinión en RFC 1912 (Informativo) recomendándolo como la mejor práctica para los administradores de DNS, pero no hay requisitos formales para ello codificados 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 asignado una dirección IP. Si bien es débil, esta autenticación es lo suficientemente fuerte como para que pueda usarse con fines de inclusión en listas blancas, ya que los spammers y los estafadores no suelen poder eludir esta verificación cuando usan computadoras zombi para suplantar correos electrónicos. Es decir, el DNS inverso puede verificar, pero normalmente será parte de un dominio diferente al nombre de dominio reclamado.
El uso del servidor de correo de un ISP como relé puede resolver el problema del DNS inverso, porque el requisito es que la búsqueda directa e inversa para el relé de envío deben coincidir, no tienen que estar relacionados con el campo de origen o el dominio de envío de los mensajes que retransmite.
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 quieran o no puedan configurar un DNS inverso generarán problemas para los hosts de sus redes, en virtud de que no podrán admitir aplicaciones o protocolos que requieran que el DNS inverso coincida con el registro A (o AAAA) correspondiente. Los ISP que no puedan o no quieran proporcionar un DNS inverso, en última instancia, limitarán la capacidad de su base de clientes para utilizar los servicios de Internet que ofrecen 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, lo colocan en el campo de encabezado de seguimiento "Recibido:".
- Algunos agentes de transferencia de correo electrónico realizan una verificación FCrDNS en el nombre de dominio indicado en los comandos SMTP HELO y EHLO. Esto puede violar la RFC 2821 y, por lo tanto, el correo electrónico no suele rechazarse de forma predeterminada.
- El sistema antifalsificación de correo electrónico de Sender Policy Framework utiliza una comprobación FCrDNS en su mecanismo "ptr:". Sin embargo, el uso de este mecanismo "ptr:" se desaconseja desde la primera estandarización de SPF en 2006 (en RFC 4408).
- Algunos filtros de spam de correo electrónico 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 comprobació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 coincidentes correctamente para los servidores de correo. [1] [2]
- Algunos servidores FTP , Telnet y TCP Wrapper realizan comprobaciones FCrDNS.[3] Archivado el 1 de julio de 2020 en Wayback Machine.
- Algunos servidores IRC realizan comprobaciones FCrDNS para evitar abusos.
Referencias
- ^ "Información sobre STD 13 » RFC Editor". Noviembre de 1987. Consultado el 26 de marzo de 2018 .