Network Working Group P. Srisuresh Request for Comments: 2694 Consultant Categoría: Informativo G. Tsirtsis BT Laboratories P. Akkiraju Cisco Systems A. Heffernan Juniper Networks Septiembre 1999 Extensiones del DNS para Traductores de Direcciones de Red (DNS_ALG) Status de este memorándum Este memorándum proporciona información a la comunidad Internet. No especifica ningún tipo de estándar de Internet. La distribución de este memorándum es ilimitada. Nota de Copyright Copyright (C) The Internet Society (1999). Todos los derechos reservados. Resumen El "Servicio de Nombres de Dominio", Domain Name Service (DNS), proporciona mapeo de nombres a direcciones para una clase de encaminamiento (por ejemplo IP). Los "Traductores de Direcciones de Red", Network Address Translators (NAT), intentan proporcionar encaminamiento transparente entre máquinas en dominios de direcciones dispares de una misma clase de encaminamiento. Habitualmente NAT está presente en la frontera de un dominio, ocultando las direcciones privadas a las direcciones externas. Este documento identifica la necesidad de extensiones de NAT para DNS e indica cómo una "Pasarela de Nivel de Aplicación DNS", DNS Application Level Gateway (DNS_ALG), puede satisfacer los requisitos. La DNS_ALG modifica la carga útil de manera transparente para alterar el mapeo de direcciones de las máquinas según los paquetes DNS pasan desde un dominio de direcciones a otro. El documento también muestra el funcionamiento de DNS_ALG con ejemplos concretos. 1. Introducción A menudo se usan los Traductores de Direcciones de Red (NAT) cuando las direcciones internas de la red no se pueden usar fuera de la red, bien por razones de privacidad, bien porque no son válidas fuera de la red. Srisuresh, et al. Informativo [Pág. 1] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 Idealmente hablando, un nombre de máquina identifica de manera única a una máquina, y su dirección se usa para encontrar los caminos hacia la máquina. Sin embargo, a menudo no se distinguen un nombre de máquina y una dirección y las aplicaciones los usan de manera intercambiable. Las aplicaciones incluyen la dirección IP en la carga útil en lugar de incluir el nombre de máquina. Ejemplos de esta situación son correos electrónicos que especifican la dirección de su servidor MX como ID de remitente (por ejemplo: user@666.42.7.11) en lugar del nombre del servidor (por ejemplo: user@private.com); los ficheros HTML que incluyen direcciones IP en lugar de nombres en las URL, etc. El uso de direcciones IP en lugar del nombre de máquina en la carga útil representa un problema cuando el paquete atraviesa un dispositivo de NAT, puesto que NAT modifica las cabeceras de red y transporte, pero no la carga útil, para adecuarlas a un dominio de direcciones. DNS proporciona mapeo de nombres a direcciones. Por su parte, NAT lleva a cabo traducción de direcciones (en las cabeceras de red y transporte) en los datagramas que cruzan desde un dominio de direcciones privado a uno externo. La Pasarela DNS de Nivel de Aplicación (DNS_ALG) perfilada en este documento ayuda a traducir los mapeos Nombre-Dirección_Privada en las cargas útiles DNS en mapeos Nombre-Dirección_Externa y viceversa, usando la información de estado disponible en NAT. Un "Traductor de Direcciones de Red y Puertos", Network Address Port Translator (NAPT), lleva a cabo traducción de direcciones y puertos de nivel de transporte (es decir, puertos TCP y UDP e IDentificadores de petición ICMP). Sin embargo, la granularidad del mapeo de nombres DNS está limitada a las direcciones IP y no se extiende a los identificadores de nivel de transporte. En consecuencia, se simplifica el procesamiento del DNS_ALG para una configuración NAPT porque todas las direcciones de máquina en una red privada están ligadas a una única dirección externa. La búsqueda DNS de nombres de máquinas privadas (desde máquinas externas) no exige que la asociación entre dirección privada y externa sea reciente, puesto que todas las máquinas privadas están ligadas a una única dirección externa predefinida. Sin embargo, las búsquedas inversas de nombres para la dirección NAPT externa no mapeará a ninguna de las máquinas privadas, y simplemente mapeará al encaminador NAPT. Baste decir que las necesidades de procesamiento para un DNS_ALG que dé soporte a una configuración NAPT son un mero subconjunto de NAT básico. De ahí que la discusión en el resto de este documento esté centrada principalmente en configuraciones de NAT básico, bidireccional y doble, sin menciones concretas a una configuración NAPT. En las [Ref 3] y [Ref 4] se pueden encontrar las definiciones para DNS y los términos relacionados. Las definiciones para los términos Srisuresh, et al. Informativo [Pág. 2] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 relacionados con NAT se encuentran en la [Ref 1]. 2. Requisitos para las extensiones DNS Hay muchas maneras de asegurarse que un nombre de máquina se mapea a una dirección relevante dentro de un dominio de direcciones. En las secciones siguientes se identificará dónde serían necesarias las extensiones DNS. Habitualmente las organizaciones disponen de dos tipos de servidores de nombres autoritarios. Los servidores internos de nombres autoritarios identifican a todos (o a la mayorías de) los recursos corporativos dentro de la organización. Sólo está permitido el acceso desde el mundo exterior a una parte de estas máquinas. El resto de máquinas y sus nombres son únicos a la red privada. Las máquinas visibles desde el mundo exterior y el servidor de nombres autoritario que mapea sus nombres a direcciones de red a menudo se configuran dentro de una "Zona DesMilitarizada", De-Militarized Zone (DMZ), delante de un cortafuegos. Nos referiremos a las máquinas y a los servidores de nombres en la DMZ como máquinas DMZ y servidores DMZ respectivamente. Los nombres de las máquinas DMZ son únicos extremo a extremo porque sus FQDN no se solapan con ningún nodo final con los que puedan comunicarse. Srisuresh, et al. Informativo [Pág. 3] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 \ | / +-----------------------+ | Encaminador del ISP | +-----------------------+ WAN | Extremo A .........|\|.... | +-----------------+ | Encaminador | | Fronterizo | | con NAT | +-----------------+ | | Red - DMZ ------------------------------------------------------------ | | | | | +--+ +--+ +--+ +--+ +-------------+ |__| |__| |__| |__| | Cortafuegos | /____\ /____\ /____\ /____\ +-------------+ DMZ-Host1 DMZ-Host2 ... Servidor Servidor Web | DNS DMZ DMZ, etc. | | Máquinas internas (Red IP privada) | ------------------------------------------------------------ | | | | +--+ +--+ +--+ +--+ |__| |__| |__| |__| /____\ /____\ /____\ /____\ Int-Host1 Int-Host2 ..... Int-Hostn Servidor DNS Interno Figura 1: Configuración de la red DMZ en una red privada. La Figura 1 anterior ilustra la configuración de una red privada que incluye una DMZ. Las configuraciones reales pueden ser diferentes. Sólo los usuarios en la red privada acceden a los servidores de nombres internos. Las consultas y respuestas DNS internas no atraviesan el límite de la red privada. Por otra parte, los servidores de nombres y máquinas DMZ son únicos extremo a extremo y se puede acceder a ellos tanto desde las máquinas internas como desde las externas. A lo largo de este documento, nos centraremos en las máquinas y servidores de nombres DMZ y no incluiremos a las máquinas y servidores de nombres internos, a menos que resulten ser lo mismo. 2.1. NAT asigna direcciones estáticas externas a las máquinas DMZ Suponga que el dispositivo NAT ha asignado direcciones estáticas externas a las máquinas DMZ. Dese cuenta que todas las máquinas en el interior del dominio privado, incluyendo las máquinas DMZ, se Srisuresh, et al. Informativo [Pág. 4] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 identifican mediante su dirección privada. El mapeo estático en el dispositivo NAT permite identificar a las máquinas DMZ mediante sus direcciones públicas en el dominio externo. 2.1.1. Redes privadas sin servidores de nombres DMZ Suponga que existe una red privada en la que no existe un servidor de nombres. Si la red privada está conectada a un único proveedor de servicios para conectar con el exterior, las máquinas DMZ pueden tener sus direcciones externas enumeradas en los servidores de nombres autoritarios del proveedor de servicios, dentro de las zonas de reenvío y de la zona inversa in-addr.arpa. Si la red está conectada a varios proveedores de servicios, los nombres de las máquinas DMZ pueden estar enumerados mediante sus direccion(es) externa(s) dentro de los servidores de nombres autoritarios de cada uno de los proveedores de servicios. Esto es particularmente significativo en el caso de las zonas inversas in- addr.arpa, puesto que la red privada podría tener asignados distintos prefijos de red por cada uno de los proveedores. En ambos casos, las búsquedas DNS generadas externamente no alcanzarán la red privada. Un gran número de dominios privados basados en NAT se deciden por esta opción para tener sus máquinas DMZ enumeradas por sus direcciones externas en los servidores de nombres de los proveedores de servicios. 2.1.2. Redes privadas con servidores de nombres DMZ Suponga la existencia de una red privada donde se opta por mantener un servidor de nombres DMZ autoritario para la zona correspondiente a la propia red interna. Si la red sólo está conectada a un proveedor de servicios, se puede configurar el servidor de nombres DMZ para no interceptar los paquetes DNS como se explica a continuación. Las máquinas en el servidor de nombres DMZ deben estar mapeadas a su dirección externa asignada estáticamente, y el servidor de nombres interno debe estar configurado para saltarse el servidor de nombres DMZ para las consultas relacionadas con las máquinas externas. Este esquema garantiza que los servidores de nombres DMZ están configurados para que sólo puedan acceder a las máquinas externas (ni siquiera a las máquinas DMZ) y por lo tanto se pueden configurar con direcciones externas únicamente. El esquema anterior necesita una cuidadosa planificación administrativa para asegurarse que las máquinas internas no contactan con servidores de nombres DMZ directa o indirectamente (a través de los servidores de nombres internos). El uso de una DNS-ALG eliminará la necesidad de las precauciones administrativas necesarias con esta Srisuresh, et al. Informativo [Pág. 5] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 aproximación. 2.2. NAT asigna direcciones dinámicas externas a las máquinas DMZ Suponga el caso en que las máquinas DMZ de una red privada reciben direcciones externas dinámicas mediante NAT. Mientras que las direcciones concedidas a estas máquinas sean fijas dentro de la red privada, las direcciones conocidas desde el exterior son efímeras, según determina NAT. En dicho escenario, es obligatorio que la organización privada disponga de un servidor de nombres DMZ para permitir el acceso a las máquinas DMZ por su nombre. El servidor de nombres DMZ debería configurarse con direcciones privadas para las máquinas DMZ. La Pasarela de Nivel de Aplicación (DNS_ALG) que reside en el dispositivo NAT interceptará los paquetes DNS dirigidos hacia o desde el(los) servidor(es) de nombre(s) DMZ y realizarán traducción transparente de cargas útiles para que un nombre de máquina DMZ disponga de la dirección mapeada correcta dentro de cada dominio de direcciones (es decir, privados o externos). 3. Interacciones entre NAT y DNS_ALG Este documento parte del supuesto de que interconectar dominios de direcciones puede solapar los espacios de direcciones. Pero los nombres de las máquinas en los dominios interconectados deben ser únicos extremo a extremo para ser accesibles a todas las máquinas. En otras palabras, no deben solaparse los FQDN entre los nodos finales que se comunican entre sí. El siguiente diagrama ilustra cómo un paquete DNS que atraviesa un dispositivo NAT (con DNS_ALG) está sujeto a la traducción de su cabecera y su carga útil. Un paquete DNS puede ser un paquete TCP o UDP con el puerto de origen o destino igual a 53. NAT traducirá las cabeceras IP y TCP/UDP del paquete DNS y notificará al DNS_ALG para que realice los cambios en la carga útil DNS. En caso necesario, la DNS-ALG interactuará con NAT y usará su información de estado para modificar la carga útil. Srisuresh, et al. Informativo [Pág. 6] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 Paquete IP original || || vv +---------------------------------+ +-----------------------+ | | | Pasarela de Nivel de | | Traducción Dirección Red (NAT) |--->| Aplicación (DNS_ALG) | | *modif. cabeceras IP y transp. |<---| *modif. datos DNS | | | | | +---------------------------------+ +-----------------------+ || || vv Paquete IP traducido Figura 2: NAT y DNS-ALG en el camino de traducción de los paquetes DNS 3.1. Consideraciones sobre la asociación de direcciones En los dispositivos NAT distinguiremos entre "Asociación temporal de direcciones" y "Asociación garantizada de direcciones". Esta distinción resulta necesaria porque la DNS-ALG permitirá que los usuarios externos creen información de estado NAT, lo que constituye un riesgo de ataques de denegación de servicio. La asociación temporal de direcciones es la fase en la que se reserva una asociación de direcciones sin haber sesiones NAT usando la asociación. La asociación garantizada de direcciones es la fase en la que ya existe al menos una sesión de NAT usando la asociación entre las direcciones externa y privada. La DNS-ALG usa ambos tipos de asociaciones para modificar las cargas útiles NAT. NAT sólo usa las asociaciones garantizadas de direcciones para modificar las cabeceras IP y de transporte de los datagramas que pertenecen a las sesiones NAT. Para las direcciones con mapeo estático, la anterior distinción no es relevante. Para las direcciones con mapeo dinámico, a menudo la asociación temporal de direcciones precede a la asociación garantizada. La asociación temporal de direcciones sucede cuando se consulta el servidor de nombres DMZ para una búsqueda de nombres. Probablemente la consulta del nombre sea el precursor de una sesión real entre quién realizó la consulta y la máquina consultada. La asociación temporal sólo se convierte en garantizada cuando NAT ve el primer paquete de una sesión entre quién inició la consulta y la máquina consultada. Se puede definir un parámetro para las asignaciones dinámicas de Srisuresh, et al. Informativo [Pág. 7] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 direcciones, "teimpo de validez de la asociación" (Bind-holout time), como el máximo periodo de tiempo durante el que se mantiene activa una asociación temporal de direcciones sin convertirse en una asociación garantizada. Este periodo de "Bind-holdout" se renueva con cada uso de la asociación temporal por parte de la DNS-ALG (para modificar la carga útil DNS). Un tiempo por defecto de "Bind-holdout" igual a un par de minutos debería bastar para la mayoría de las implementaciones de DNS-ALG. Dese cuenta que es posible que una asociación de direcciones garantizada suceda sin venir precedida por una asociación temporal. Al final, cuando NAT está preparado para desligar una asociación de direcciones garantizada, la asociación es convertida en una asociación temporal y se mantiene en esa fase durante un periodo adicional de "Bind-holdout". La asociación sólo se libera una vez ha expirado el tiempo de "Bind-holdout". Los tiempos de "Bind-holdout" que preceden a la asociación de direcciones temporal y a su desligadción son necesarios para asegurarse que las máquinas finales disponen del tiempo suficiente para iniciar una sesión de datos siguiente a una búsqueda de nombres. Por ejemplo, digamos que una red privada con prefijo de dirección 10/8 se mapea a 198.76.29/24. Cuando una máquina externa hace una consulta DNS para host7, que tiene dirección 10.0.0.7, el servidor de nombres DMZ en la red privada responde con un RR de tipo A para host7 tal como: host7 Ai 10.0.0.7 El DNS-ALG interceptará el paquete de respuesta y si 10.0.0.7 aún no tiene asignada una dirección externa, hará una petición al NAT para crear una asociación de direcciones temporal con la dirección externa, e iniciará el temporizador de "Bind-holdout" para envejecer la asociación. Digamos que la dirección externa asignada es 198.76.29.1. El DNS-ALG usará esta asociación temporal para modificar el RR de la respuesta DNS, sustituyendo 10.0.0.7 por la dirección externa y respondiendo con: host7 A 198.76.29.1 Cuando quién inició la consulta recibe la respuesta DNS, sólo se ve la dirección externa asignada. En un breve plazo de tiempo (habitualmente antes de que expire el temporizador de "Bind- holdout"), quien inició la consulta iniciará una sesión con host6. Cuando NAT detecte el comienzo de una nueva sesión dirigida hacia 198.76.29.1, NAT parará el temporizador de "Bind-holdout" y convertirá la asociación temporal entre 198.76.29.1 y 10.0.0.7 en una asociación garantizada. Para minimizar los ataques de denegación de servicio, en los que un Srisuresh, et al. Informativo [Pág. 8] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 usuario malicioso sigue intentando resolver nombres, sin siquiera iniciar una conexión, NAT tendría que monitorizar las asociaciones de direcciones temporales que no se hayan convertido en asociaciones garantizadas. Podría haber un límite en el número de asociaciones temporales y los intentos de generar asociaciones temporales adicionales podrían ser directamente rechazados. Puede haber otras soluciones heurístcias para repeler este tipo de ataques maliciosos. En las siguientes subsecciones consideraremos el NAT bidireccional para ilustrar el uso de la asociación temporal por parte de una DNS- ALG, aunque el concepto es aplicable también a otras modalidades de NAT. 3.2. Consultas entrantes Para iniciar sesiones entrantes, una máquina externa obtiene la dirección IPv4 de la máquina DMZ con la que trata de conectar realizando una consulta DNS. Esta consulta constituye el preludio del comienzo de una potencial nueva sesión. El resolver de la máquina externa realiza una búsqueda para la máquina DMZ a través de su servidor DNS. Cuando el servidor DNS no tiene un registro de la dirección IPv4 asociado a este nombre, en cierto momento la búsqueda de nombre se redirige al servidor DNS primario/respaldo (es decir, en la DMZ) del extremo del dominio privado. En el camino hacia los servidores de nombres DMZ, la DNS-ALG interceptará el datagrama y modificará la consulta de la siguiente manera: a) Para las consultas de nombre de máquina a dirección de máquina: No se modifica la carga útil DNS. b) Para consults de dirección de máquina a nombre de máquina: sustituir los octetos externos de la dirección IPv4 (en orden inverso) que preceden a la cadena "IN-ADDR.ARPA" por la dirección privada IPv4 correspondiente, si ya existe dicha asociación de direcciones. Sin embargo, si una asociación no existe, el DNS-ALG simplemente devolverá un código de respuesta (RCODE) 5 (SE NEGÓ a responder debido a las políticas del servidor), tal y como haría un servidor de nombres, y en la sección cabecera de la respouesta pondría a cero ANCOUNT, NSCOUNT y ARCOUT. En el sentido inverso, según la respuesta DNS circula desde el servidor DNS en la red privada, la DNS-ALG de nuevo interceptará el paquete y lo modificaría como se explica a continuación: Srisuresh, et al. Informativo [Pág. 9] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 a) Para consultas de nombre de máquina a dirección de máquina, sustituye la dirección privada enviada por el servidor de nombres DMZ por una dirección pública aasignada internamente por el encaminador NAT. Si no se ha asignado previamente una dirección pública a la dirección privada de la máquina, en este momento NAT le asignaría una. b) Para consultas de dirección de máquina a nombre de máquina, sustituye los octetos de la dirección privada que precede a la cadena "IN-ADDR.ARPA" en los RR de respuesta por sus asignaciones de direcciones externas. Aquí puede darse el caso de que cuando el servidor de nombres DMZ responda, el temporizador de "bind-holdout" en el NAT para la dirección en cuestión haya expirado. En tal caso, DNS-ALG simplemente descartará la respuesta. El remitente tendrá que volver a enviar la consulta (tal y como sucede cuando un encaminador intermedio descarta la respuesta). Para las asignaciones estáticas de direcciones, el valor de TTL suministrado en el RR original se deja sin cambios. Para las asignaciones dinámicas de direcciones, la DNS-ALG establecerá el valor del TTL en los registros de recursos (RR) DNS a cero, implicando que los RR sólo se deberían usar para la transacción en curso, y no deberían ser cacheados. Por razones de compatibilidad con implementaciones defectuosas, en la práctica un TTL igual a 1 podría funcionar mejor. Está claro que establecer el TTL igual a cero creará más tráfico que si las direcciones fueran estáticas, porque el mapeo de nombres a direcciones no se cachea. En concreto, las aplicaciones basadas en la red necesitarán usar nombres en lugar de direcciones para identificar a los nodos interlocutores y deben usar DNS para cada resolución de nombres, puesto que no se pueden aprovechar los mapeos de nombre a dirección utilizados por las aplicaciones previamente ejecutadas. Además, se podría solicitar al NAT que ponga en marcha un temporizador de "bind-holdout" tras la asignación. Si no se inicia ninguna sesión con la máquina privada durante el plazo de "bind- holdout", NAT finalizará la asociación temporal. 3.3. Peticiones salientes Para los NAT básico y bidireccional no hay necesidad de distinguir entre las asociaciones temporales y garantizadas para las consultas salientes. Esto se debe a que la DNS-ALG no modifica los paquetes DNS dirigidos hacia y desde los servidores de nombres externos (que se usan durante las sesiones salientes), a diferencia de las sesiones DNS entrantes. Srisuresh, et al. Informativo [Pág. 10] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 Digamos que una máquina privada necesita comunicarse con una máquina externa. La consulta DNS llega al servidor de nombres interno (de existir uno) y desde allí a los correspondientes servidores de nombres autoritarios/caché en el exterior del dominio privado. La respuesta sigue la misma ruta pero ni la consulta ni la respuesta están sujetas a traducciones DNS-ALG. Sin embargo este no será el caso con direcciones aisladas por NAT doble entre los dominios privado y esterno. En tal caso, NAT interceptaría todos los paquetes DNS y hará modificaciones en la dirección de la carga útil como se ha mostrado en la sección anterior. Las asociaciones temporales entre las direcciones privadas y externas se crean cuando los servidores DNS envían las respuestas, y las asociaciones temporales entre direcciones externas y privadas son creadas cuando se envían las respuestas desde los servidores DNS. 4. Modificaciones en la carga útil DNS por parte de DNS-ALG Típicamente se usa UDP como el mecanismo de transporte para las consultas y respuestas DNS y TCP para las actividades de refresco de zonas. En cualquier caso, los servidores de nombres son accedidos usando el puerto conocido 53 (decimal) para los servidores DNS y todas las cargas útiles DNS tienen el siguiente formato de datos [Ref 4]. Mientras que NAT es el responsable de traducir las cabeceras IP y TCP/UDP de un paquete DNS, la DNS-ALG es reponsable de actualizar la carga útil DNS. La sección de cabecera dentro de la carga útil DNS siempre está presente e incluye campos que especifican cuáles de las restantes secciones están presentes. La cabecera identifica si el mensaje es una consulta o una respuesta. La DNS-ALG no necesita hacer cambios en la sección cabecera. La DNS-ALG interpretará las cargas útiles cuyas QCLASS sea igual a IN (clase IP). +---------------------+ | Cabecera | +---------------------+ | Pregunta | la pregunta para el servidor de nombres +---------------------+ | Respuesta | los RR que responden a la pregunta +---------------------+ | Autoridad | los RR que apuntan hacia una autoridad +---------------------+ | Adicional | los RR que llevan información adicional +---------------------+ 4.1. Sección pregunta Srisuresh, et al. Informativo [Pág. 11] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 La sección pregunta contiene QDCOUNT entradas (habitulamente 1), según se especifica en la sección cabecera, con cada una de las entradas en el siguiente formato: 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / QNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QTYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QCLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4.1.1. Consultas de tipo PTR La DNS-ALG debe identificar todos los nombres, cuyos "Nombres de Dominio Plenamente Cualificados", Fully Qualified Domain Names (FQDN), sean dominios IN-ADDR.ARPA, y sustituir los octetos de dirección (en orden inverso) que preceden a la cadena "INN-ADDR.ARPA" con los octetos en orden inverso correspondientes a la dirección asignada, sólo si la asociación de dirección está activa en el encaminador NAT. Si la dirección que precede a la cadena "IN- ADDR.ARPA" cae dentro del mapa de direcciones NAT, pero no tiene al menos una asociación temporal de direcciones, la DNS-ALG simplemente responderá (como haría un servidor de nombres DNS) con un código de respuesta (RCODE) igual a 5 (SE NEGO a responder debido a las políticas del servidor) y pondrá ANCOUNT, NSCOUNT y ARCOUT a cero en la sección cabecera de la respuesta. Dese cuenta que la anterior forma de consultas de dirección de máquina a nombre de máquina probablemente resulte en diferentes resultados en momentos distintos, dependiendo del estado de la asociación de direcciones en el NAT en un momento dado. Por ejemplo, un resolver que desee encontrar el nombre de máquina correspondiente a la dirección 198.76.29.1 (externamente) intentará una consulta de la forma: QTYPE = PTR, QCLASS = IN, QNAME = 1.29.76.198.IN-ADDR.ARPA. La DNS-ALG entraría en acción y si la dirección 198.76.29.1 está internamente mapeada a la dirección privada 10.0.0.1, modificará la consulta como se muestra a continuaciónn y la reenviará al servidor de nombres DMZ en la red privada: Srisuresh, et al. Informativo [Pág. 12] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 QTYPE = PTR, QCLASS = IN, QNAME = 1.0.0.10.IN-ADDR.ARPA Presumiblemente el servidor de nombres DMZ sea el servidor de nombres autoritario para la zona 10.IN-ADDR.ARPA y responderá con un RR en la sección respuesta, con el formato mostrado a continuación. Las traducciones de los RR respuesta por parte del DNS-ALG los consideraremos en una sección posterior. 1.0.0.10.IN-ADDR.ARPA PTR host1.fooboo_org.provider_domain Un ejemplo de traducción inversa son los programas de correo electrónico que usan traducción inversa para trazar el correo originado en las máquinas para prevenir el correo basura (spam). Verifica que la dirección desde la que se envió el correo de hecho pertenece al mismo nombre de dominio que el remitente afirma en el "sender ID". Las modificaciones de las consultas de esta naturaleza probablemente cambiarán la longitud de la carga útil DNS. Como resultado, las correspondientes sumas de verificación de las cabeceras IP y TCP/UDP deben ser actualizadas. En el caso de consultas basadas en TCP, NAT debe hacer un seguimiento de las diferencias en los números de secuencia para que la diferencia pueda ser aplicada a los siguientes números de secuencia de los datagramas en la misma dirección y a los números de asentimiento de los datagramas en la dirección contraria. En el caso de consultas basadas en UDP, el tamaño de los mensajes está limitado a 512 octetos (sin contar las cabeceras IP o UDP). Los mensajes mayores deben ser cortados y se debería poner a 1 el bit TC en la cabecera. Por último, cualquier nombre de dominio comprimido que use punteros para representar denominaciones comunes de dominios debe ser actualizado para reflejar los nuevos punteros con los desplazamientos correspondientes, si es que el nombre de dominio original tuvo que ser traducido por NAT. 4.1.2. Consultas de tipo A, MX, NS y SOA Para estas consultas, la DNS-ALG no modificaría ninguno de los campos en la sección consulta, ni tan siquiera el campo nombre. 4.1.3. Consultas de tipo AXFR AXFR es un tipo de consulta de transferencia de zonas especial. Se debe evitar las transferencias de zonas desde el dominio de direcciones privado para las asignaciones de direcciones que no sean estáticas. Típicamente se usa TCP para las consultas AXFR. Srisuresh, et al. Informativo [Pág. 13] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 Cuando se hacen cambios en la zona, deben ser distribuidos a todos los servidores de nombres. El modelo general de transferencia o refresco de zonas automático es que uno de los servidores de nombres es el maestro o primario para la zona. Los cambios se coordinan en el primario, típicamente editando un fichero maestro para la zona. Después de editar, el administrador envía una señal al servidor maestro para cargar la nueva zona. Los demás servidores no maestros o secundarios para la zona comprueban periódicamente los cambios en el campo SERIAL del SOA (sondeando cada cierto tiempo) y obtienen nuevas copias de la zona cuando se han hecho cambios. Las transferencias de zonas normalmente se hacen desde el servidor de nombres primario a los servidores de respaldo. En el caso de que NAT soportase redes privadas, se aconseja que los servidores primarios y de respaldo estén en el mismo dominio privado (digamos, private.zone) para que la transferencia de zonas no atraviese el dominio y para que no sea un problema el soporte de la DNS-ALG para las transferencias de zonas. En el supuesto de que el servidor de nombres secundarios esté situado fuera del dominio privado, no deben estar permitidas las transferencias de zonas para las asignaciones de direcciones no estáticas. Se necesita que los servidores primario y secundarios estén en el mismo dominio privado porque todas las referencias a los datos en la zona deben ser capturados. Con asignaciones y asociaciones dinámicas de direcciones, es imposible traducir los datos AXFR para que esté actualizados. De ahí que, si el servidor secundario para private.zone estuviera situado fuera del dominio, contendría datos erróneos. Sin embargo, dese cuenta que los requisitos aquí indicados no están de acuerdo con la RFC2182, que recomienda que los servidores primario y secundarios estén situados en localizaciones de Internet dispersas, tanto topológica como geográficamente. Durante las transferencias de zonas, la DNS-ALG debe examinar todos los registros de tipo A y sustituir los octetos originales de dirección con los octetos de dirección asignados estáticamente. La DNS-ALG también puede examinar si hay un intento de transferir registros para máquinas que no tengan asignadas direcciones estáticas y, bien descartar sólo esos registros, bien la transferencia entera. Esto minimizaría los errores humanos y las configuraciones incorrectas. 4.1.4. Actualizaciones dinámicas del DNS Un servidor de nombres autoritario puede recibir actualizaciones automáticas desde los nodos en la zona sin intervención del NAT ni de la DNS-ALG, mientras que evite la difusión de zonas DNS a través de dominios de direcciones. Recomendamos mantener una zona DNS dentro del mismo dominio del que es responsable. En este caso el tráfico de Srisuresh, et al. Informativo [Pág. 14] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 actualizaciones DNS no atravesará los dominios de direcciones y por lo tanto no será tomado en consideración por el DNS-ALG. Además, si las actualizaciones dinámicas no atraviesan dominios de direcciones, y las actualizaciones deben estar aseguradas mediante DNSSEC, entonces dichas actualizaciones están claramente fuera del alcance de la DNS-ALG (como se describe en la sección 7). 4.2. Registros de recursos (RR) en las demás secciones Las secciones respuesta, autoridad y adicional comparten todas ellas el mismo formato, con un número variable de registros de recursos (RR). El número de RR específicos de cada una de las secciones se puede encontrar en los correspondientes campos de conteo de la cabecera DNS. Cada registro de recursos tiene el formato siguiente: No se modificará el valor del TTL suministrado en los RR originales para las asignaciones estáticas de direcciones. Para las asignaciones dinámicas de direcciones, la DNS-ALG establecerá el TTL a 0, para que los RR sólo se usen en la transacción en curso, y que no sean cacheados. La RFC2181 exige que todos los RR de un RRset (RR con el mismo nombre, clase y tipo, pero con RDATA distintos) tengan el mismo TTL. De manera que si el TTL de un RR se establece a 0, la DNS-ALG también deberá poner a 0 todos los otros RR dentro del mismo RRset. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | | / / / NAME / | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TYPE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | CLASS | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | TTL | | | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | RDLENGTH | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--| / RDATA / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 4.2.1. RR de tipo PTR Las consideraciones especificadas para la sección pregunta son Srisuresh, et al. Informativo [Pág. 15] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 igualmente válidas con nombres para los RR de tipo PTR. Las direcciones privadas que preceden a la cadena "IN-ADDR.ARPA" (con los octetos en orden inverso) deben ser sustituidas por su asignación de dirección externa (en orden inverso), de existir una asociación. Los campos restantes para este RR permanecen sin cambios. 4.2.2. RR de tipo A El RDATA para los registros A es una dirección IP de 4 octetos. La DNS-ALG simplemente sustituirá la dirección original en RDATA con su dirección IP asignada externamente, si tuvo éxito encontrando una asociación de direcciones. La traducción de direcciones satisfactoria no debería causar cambios en la longitud de la carga útil. Sólo la suma de verificación en la cabecera de transporte necesitará ser actualizada. En el caso de no encontrarse una asociación de direcciones, la DNS-ALG debería descartar el registro y decrementar el correspondiente campo COUNT en la sección cabecera. 4.2.3. RR de tipo CNAME, MX, NS y SOA No es necesario que la DNS-ALG haga cambios en estos RR, puesto que los RDATA no contienen direcciones IP. Los nombres de máquina dentro de RDATA permanecen sin cambios entre dominios. 5. Demostración de DNS-ALG junto con NAT bidireccional El siguiente diagrama ilustra la operación de DNS-ALG en un encaminador NAT bidireccional. Lo ilustraremos mediante la explicación detallada de cómo se procesan las consultas directas e inversas de nombres. Srisuresh, et al. Informativo [Pág. 16] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 . ________________ . External.com ( ) . +-------------+ ( ) . | Encaminador | +--+ ( Internet )-.---| Fronterizo | |__|------ ( ) . +-------------+ /____\ (________________) . | Servidor | . | DNS raíz | . --------------- +---------------+ . | | | Encaminador | . +--+ +--+ | del Proveedor | . |__| |__| +---------------+ . /____\ /____\ | . Servidor DNS Host X Dominio externo | . 171.68.1.1 171.68.10.1 ...........................|............................... Dominio privado | | Private.com | +--------------------------------------+ | Encaminador NAT bidir. con DNS-ALG | | | | Direcciones privadas: 172.19/16 | | Direcciones externas: 131.108.1/24 | +--------------------------------------+ | | ---------- ---------- | | Servidor DNS +--+ +--+ Autoritario |__| |__| para private.com /____\ /____\ Host A Servidor DNS 172.19.1.10 172.19.2.1 (Mapeado a 131.108.1.8) Figura 3: Funcionamiento de DNS-ALG en un NAT bidireccional El diagrama anterior ilustra un escenario donde una empresa private.com que usa el espacio de direcciones privado 172.19/16 se conecta a Internet usando un NAT bidireccional. El DNS-ALG está incluído en el dispositivo NAT para efectuar los cambios necesarios en la carga útil. El NAT está configurado para traducir el espacio de direcciones privado en el bloque de direcciones externo 131.108.1/24. El NAT también está configurado con una traducción estática para el servidor DNS de private.com, de manera que puede ser accedido en el dominio externo mediante una dirección válida. La empresa external.com está situada en el dominio externo, usando el Srisuresh, et al. Informativo [Pág. 17] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 bloque de direcciones registrado 171.68/16. En la topología también se muestra un servidor DNS raíz. En la anterior configuración se realizaron las siguientes simplificaciones: * private.com sólo tiene una interface de red y todo el tráfico hacia el exterior sólo atraviesa un NAT * El servidor DNS para private.com es autoritario para el dominio private.com y apunta al servidor raíz para las resoluciones DNS. Lo mismo puede decirse del servidor DNS en external.com. * Los servidores de nombres internos para private.com y external.com son los mismos que sus servidores de nombres DMZ. Los servidores DMZ para estos dominios se configuran con direcciones privadas de la organización. * Los resolvers de nombres en las máquinas finales no disponen en sí mismos de recursión y solicitan el servicio recursivo de los servidores. Se asume que todos los servidores de nombres proporcionan servicio recursivo. 5.1. Consultas salientes de búsquedas de nombres Supongamos que Host A en private.com necesita efectuar una búsqueda de nombres para Host X en external.com para iniciar una sesión con X. Se procedería de la siguiente manera: 1. Host A envía a su servidor DNS local una consulta basada en UDP para buscar el nombre (registro A) de "X.External.Com". 2. El servidor DNS local envía la consulta al servidor raíz a través del NAT. NAT modificará las cabeceras IP y UDP para reflejar las direcciones externas asignadas estátitcamente por el DNS. La DNS- ALG no hará cambios a la carga útil. 3. Por su parte, el servidor raíz llama al servidor DNS local para consultarle al servidor DNS acerca de External.com. Esta llamada atraviesa el NAT intermedio hasta el servidor DNS local. El NAT simplemente traducirá las cabeceras IP y UDP del paquete entrante para reflejar la dirección privada del DNS. La DNS-ALG no hace cambios en la carga útil. 4. Ahora el servidor DNS de private.com enviará la consulta al servidor DNS de external.com, de nuevo, a través del NAT. Como en el caso de la consulta al servidor raíz, el encaminador NAT cambiará las cabeceras IP y UDP para reflejar la dirección externa Srisuresh, et al. Informativo [Pág. 18] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 del servidor DNS asignada estáticamente. Y el DNS-ALG no hace cambios en la carga útil. 5. El servidor DNS para external.com responde con la dirección IP 171.68.10.1. Esta respuesta también alcanza el NAT. El NAT traducirá las cabeceras IP y UDP del paquete entrante para reflejar la dirección privada del servidor DNS. De nuevo, el DNS- ALG no hace cambios en la carga útil. 6. El servidor DNS en Private.com responde a Host A. Cuando Host A encuentra la dirección de Host X, A inicia una sesión con Host X, usando 171.68.10.1 como dirección destino. Este datagrama y cualquier otro que venga a continuación en esta sesión será traducido como de costumbre por el NAT. Dese cuenta que el DNS-ALG no modifica la carga útil de los paquetes DNS en ninguna dirección. 5.2. Búsquedas inversas de nombres originadas en el dominio privado Este escenario es una continuación del caso anterior, haciendo que Host A en Private.com realice una búsqueda inversa de nombres para 171.68.10.1, que es la dirección global de la máquina X. A continuación se muestra la secuencia de eventos: 1. Host A envía a su servidor DNS local una consulta para una búsqueda inversa de nombre basada en UDP (registro PTR) para "1.10.68.171.IN-ADDR.ARPA.". 2. El servidor DNS local envía la consulta al servidor raíz a través del NAT. Como antes, el NAT cambiará las cabeceras IP y UDP para reflejar la dirección externa asignada estáticamente del servidor DNS. El DNS-ALG no hará cambios a la carga útil. 3. Por su parte, el servidor raíz llama al servidor DNS local para consultar al servidor DNS acerca de External.com. Esta llamada atraviesa el NAT intermedio y llega al servidor DNS local. El NAT simplemente traducirá las cabeceras IP y UDP del paquete entrante para reflejar la dirección privada del servidor DNS. El DNS-ALG no hará cambios a la carga útil. 4. Ahora el servidor DNS de private.com enviará la consulta al servidor DNS de external.com, de nuevo, atravesando el NAT. Como en el caso de la consulta al servidor raíz, el encaminador NAT cambiará las cabeceras IP y UDP para reflejar la dirección externa asignada estáticamente del servidor DNS. Y el DNS-ALG no hará cambios a la carga útil. Srisuresh, et al. Informativo [Pág. 19] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 5. El servidor DNS de external.com responde con el nombre de máquina de "X.External.Com.". Esta respuesta también atraviesa el NAT. El NAT traducirá las cabeceras IP y UDP del paquete entrante para reflejar la dirección privada del servidor DNS. De nuevo, el DNS- ALG no hará cambios a la carga útil. 6. El servidor DNS en Private.com responde a Host A. Dese cuenta que el DNS-ALG no cambia la carga útil en ninguna dirección. 5.3. Consultas de búsquedas de nombres entrantes En esta ocasión, Host X en external.com desea iniciar una sesión con Host A en Private.com. A continuación se muestra la secuencia de eventos que tienen lugar. 1. Host X envía a su servidor DNS local una consulta para búsqueda de nombres basada en UDP (registro A) para "A.Private.com". 2. El servidor DNS local en External.com envía la consulta al servidor raíz. 3. Por su parte, el servidor raíz llama al servidor DNS en External.com para consultarle acerca de private.com. 4. Ahora el servidor DNS de External.com enviará la consulta al servidor DNS de Private.com. Esta consulta atraviesa el encaminador NAT. El NAT cambiará las cabeceras IP y UDP del paquete para reflejar la dirección privada del servidor DNS. El DNS-ALG no hará cambios a la carga útil. 5. El servidor DNS de Private.com responde con la dirección IP 172.19.1.10 de Host A. Esta respuesta también atraviesa el NAT. El NAT traducirá las cabeceras IP y UDP del paquete saliente del servidor DNS. La DNS-ALG solicitará al NAT (a) establecer una asociación temporal para Host A (172.19.1.10) con una dirección externa y (b) iniciar el temporizador de "bind-holdout". Cuando el NAT establezca una asociación temporal de manera satisfactoria con una dirección externa (digamos, 131.108.1.12), la DNS-ALG modificará la carga útil para sustituir la dirección privada de A con su dirección externa asignada y pondrá a 0 el temporizador de cache. 6. El servidor en External.com responde a Host X. Cuando Host X encuentra la dirección de Host A, X inicia una sesión Srisuresh, et al. Informativo [Pág. 20] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 con A, usando 131.108.1.12 como dirección IP destino. Este datagrama y cualesquiera otros que vengan a continuación en esta sesión serán traducidos como de costumbre por el NAT. Dese cuenta que la DNS-ALG sólo cambia los paquetes de respuesta desde el servidor DNS para el dominio Private.com. 5.4. Búsquedas inversas de nombres originadas en el dominio externo Este escenario es la continuación del caso anterior (sección 5.3), y en él Host X en External.com realiza una búsqueda inversa de nombre para 131.108.1.12, que es la dirección externa asignada a Host A. Tiene lugar la siguiente secuencia de eventos: 1. Host X envía a su servidor DNS local una búsqueda inversa de nombres basada en UDP (registro PTR) para "12.1.108.131.IN- ADDR.ARPA.". 2. El servidor DNS local en External.com envía la consulta al servidor raíz. 3. Por su parte, el servidor raíz, llama al servidor DNS local para consultarle acerca de Private.com. 4. Ahora el servidor DNS de External.com enviará la consulta al servidor DNS de Private.com. Esta consulta atraviesa el encaminador NAT. El NAT cambiará las cabeceras IP y UDP para reflejar la dirección privada del servidor DNS. La DNS-ALG preguntará al NAT la dirección privada asociada con la dirección externa 131.108.1.12 y modificará la carga útil, sustituyendo 131.108.1.12 por la dirección privada 172.19.1.10. 5. El servidor DNS de Private.com responde con el nombre de máquina "A.Private.Com.". Esta respuesta también atraviesa el NAT. El NAT traducirá las cabeceras IP y UDP del paquete entrante para reflejar la dirección privada del servidor DNS. De nuevo la DNS-ALG preguntará al NAT la dirección externa asignada asociada con la dirección privada 172.19.1.10 y modificará la carga útil, sustituyendo 172.19.1.10 por la dirección externa 131.108.1.12. 6. El servidor DNS en External.com responde a Host X. Dese cuenta que la DNS-ALG modifica los paquetes de la consulta así como los de la respuesta provenientes del servidor DNS del dominio Private.com. Srisuresh, et al. Informativo [Pág. 21] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 6. Demostración de la DNS-ALG junto con NAT doble El siguiente diagrama ilustra la operación de una DNS-ALG en un encaminador NAT doble. Como en el caso anterior, lo ilustraremos mediante la descripción detallada de cómo se procesan las consultas directas e inversas de nombres. . ________________ . External.com ( ) . +-------------+ ( ) . | Encaminador | +--+ ( Internet )-.---| Fronterizo | |__|------ ( ) . +-------------+ /____\ (________________) . | Servidor | . | DNS raíz | . --------------- +---------------+ . | | | Encaminador | . +--+ +--+ | del Proveedor | . |__| |__| +---------------+ . /____\ /____\ | . Servidor DNS Host X Dominio externo | . 171.68.1.1 171.68.10.1 ............................|............................... Dominio privado | | Private.com | +-------------------------------------------+ | Encaminador NAT doble con DNS_ALG | | | | Direcciones privadas: 171.68/16 | | Dir. externas asignadas: 131.108.1/24 | | | | Direcciones externas: 171.68/16 | | Direcciones externas asignadas: 10/8 | +-------------------------------------------+ | | ---------- ---------- | | Servidor DNS +--+ +--+ Autoritario |__| |__| para private.com /____\ /____\ Host A Servidor DNS 171.68.1.10 171.68.2.1 (Mapeado a 131.108.1.8) Figura 4: Funcionamiento de DNS-ALG junto con NAT doble En este escenario, las máquinas en private.com no tienen asignadas Srisuresh, et al. Informativo [Pág. 22] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 direcciones del espacio reservado 172.19/16 especificado en el RFC 1918, sino que se les asignó direcciones de la red encaminable globalmente 171.68/16, la misma que en external.com. private.com no sólo necesita un servicio de traducción para sus propias direcciones de máquina, sino que también necesita un servicio de traducción si cualquiera de estas máquinas debe ser capaz de intercambiar datagramas con las máquinas en external.com. El NAT doble permite la transición mediante la traducción del espacio de direcciones solapado usado en external.com a un bloque de direcciones único (10/8) especificado en el espacio de direcciones de la RFC 1918. Se establecen rutas en el interior del dominio privado para dirigir los datagramas destinados al bloque de direcciones 10/8 a través del dispositivo NAT doble, hacia el espacio de red externo global. Las simplificaciones y asunciones hechas en la sección 5.0 también serán válidas aquí. 6.1. Consultas salientes de búsquedas de nombres Digamos que Host A en private.com necesita realizar una búsqueda de nombres para Host X en external.com (Host X tiene un FQDN igual a "X.external.com"), para encontrar su dirección. Los hechos sucederán como se muestra a continuación. 1. Host A envía a su servidor DNS local una cosulta de búsqueda de nombre basada en UDP (registro A) para "X.External.com". 2. El servidor DNS local envía la consulta al servidor raíz a través de NAT. El NAT modificará las cabeceras IP y UDP para reflejar la dirección externa del servidor DNS asignada estáticamente. La DNS- ALG no hará cambios a la carga útil. 3. Por su parte, el servidor raíz llama al servidor DNS local para consultarle acerca de External.com. Esta llamada atraviesa el NAT intermedio hasta llegar al servidor DNS local. El NAT simplemente traducirá las cabecers IP y UDP del paquete entrante para reflejar la dirección privada del servidor DNS. La DNS-ALG solicitará al NAT una dirección privada asignada para el servidor llamante y en la carga útil sustituirá la dirección externa con su dirección privada asignada. 4. Ahora el servidor DNS de Private.com enviará la consulta al servidor DNS de external.com, usando su dirección privada asignada, a través del NAT. En esta ocasión NAT modificará las cabeceras IP y UDP para reflejar las direcciones externas de los servidores DNS. Es decir, se cambia la dirección IP del servidor DNS en Private.com por su dirección externa asignada, y la Srisuresh, et al. Informativo [Pág. 23] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 dirección privada asignada del servidor DNS en External.com se cambia por su dirección externa. La DNS-ALG no hará cambios a la carga útil. 5. El servidor DNS para external.com responde con la dirección IP 171.68.10.1. Esta respuesta también atraviesa en NAT. El NAT de nuevo traducirá las cabeceras IP y UDP del paquete entrante para reflejar las direcciones privadas de los servidores DNS. Es decir, la dirección IP del servidor DNS en Private.com se cambia por su dirección privada, y la dirección externa del servidor DNS en External.com se sustituye por su dirección privada asignada. La DNS-ALG solicitará a NAT que (a) establezca una asociación temporal para Host X (171.68.10.1) con una dirección privada, y (b) inicie un temporizador de "bind-holdout". Cuando NAT establezca satisfactoriamente una asociación temporal con una dirección privada (digamos 10.0.0.254), la DNS-ALG modificará la carga útil para sustituir la dirección externa de X con su dirección privada asignada, y establecerá el temporizador de caché a 0. 6. El servidor DNS en Private.com responde a Host A. Cuando Host A encuentra la dirección de Host X, A inicia una sesión con Host X, usando una dirección IP destino igual a 10.0.0.254. Este datagrama y cualesquiera otros que vengan a continuación en esta sesión serán traducidos como de costumbre por el NAT doble. Dese cuenta que la DNS-ALG ha debido cambiar la carga útil en ambas direcciones. 6.2. Búsquedas inversas de nombres originadas en el dominio privado Este escenario es una continuación del caso anterior, y en él Host A en Private.com realiza una búsqueda inversa de nombre para 10.0.0.254, que es la dirección privada asignada a Host X. La secuencia de eventos se muestra a continuación: 1. Host A envía a su servidor DNS local una consulta inversa de nombre basada en UDP (registro PTR) para "254.0.0.10.IN- ADDR.ARPA.". 2. El servidor DNS local envía la consulta al servidor raíz a través del NAT. Como en otras ocasiones, NAT modificará las cabeceras IP y UDP para reflejar la dirección externa asignada estáticamente al servidor DNS. Srisuresh, et al. Informativo [Pág. 24] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 El DNS-ALG traducirá la dirección privada asignada 10.0.0.254 por su dirección externa 171.68.10.1. 3. Por su parte, el servidor raíz llama al servidor DNS local para consultarle acerca de External.com. Esta llamada atraviesa el NAT en su camino hacia el servidor DNS local. El NAT simplemente traducirá las cabeceras IP y UDP del paquete entrante para reflejar la dirección privada del servidor DNS. Como en la consulta original, la DNS-ALG traducirá la dirección privada asignada 10.0.0.254 a la dirección externa 171.68.10.1. Además, la DNS-ALG sustituirá en la carga útil la dirección externa del sevidor llamante (es decir, el servidor DNS para External.com) por su dirección privada asignada. 4. Ahora el servidor DNS de Private.com enviará la consulta al servidor DNS para external.com, usando su dirección privada asignada, a través del NAT. En esta ocasión, el NAT cambiará las cabeceras IP y UDP para reflejar la dirección en External.com de los servidores DNS. Es decir, la dirección IP del servidor DNS para Private.com se sustituye por su dirección externa asignada, y la dirección en Private asignada al servidor DNS para External.com se sustituye por su dirección externa. Como en la consulta original, la DNS-ALG traducirá la dirección privada asignada 10.0.0.254 a su dirección externa 171.68.10.1. 5. El servidor DNS para external.com responde con el FQDN igual a "X.External.Com.". Esta respuesta también atraviesa el NAT. De nuevo el NAT traducirá las cabeceras IP y UDP del paquete entrante para reflejar las direcciones privadas de los servidores DNS. Es decir, la dirección IP del servidor DNS para Private.com se cambia por dirección privada, y la dirección externa del servidor DNS para External.com se sustituye por su dirección privada asignada. De nuevo, la DNS-ALG traducirá la sección consulta, sustituyendo la dirección externa 171.68.10.1 por su dirección externa asignada 10.0.0.254. 6. El servidor DNS en Private.com responde a Host A. Dese cuenta que el DNS-ALG tuvo que modificar la carga útil en ambas direcciones. 6.3. Consultas entrantes de búsqueda de nombres En esta ocasión, Host X en external.com desea iniciar una sesión con Host A en Private.com. A continuación se muestra la secuencia de Srisuresh, et al. Informativo [Pág. 25] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 eventos que tienen lugar: 1. Host X envía a su servidor DNS local una consulta de nombres basada en UDP (registro A) para "A.Private.com". 2. El servidor DNS local en External.com envía la consulta al servidor raíz. 3. Por su parte, el servidor raíz llama al servidor DNS en External.com para consultarle acerca de private.com. 4. Ahora el servidor DNS de external.com enviará la consulta al servidor DNS de Private.com. Esta consulta atraviesa el encaminador NAT. El NAT modificará las cabeceras IP y UDP para reflejar la dirección privada de los servidores DNS. Es decir, la dirección IP privada del servidor DNS para Private.com es sustituida por su dirección privada y la dirección externa del servidor DNS para External.com es sustituída por su dirección privada asignada. La DNS-ALG no hará cambios a la carga útil. 5. El servidor DNS para Private.con responde con la dirección IP 171.68.1.10 para Host A. Esta respuesta también atraviesa el NAT. El NAT de nuevo traducirá las cabeceras IP y UDP del paquete entrante para reflejar la dirección externa de los servidores DNS. Es decir, la dirección IP del servidor DNS de Private.com se sustituye por si dirección externa, y la dirección privada asignada al servidor DNS de External.com se sustitutye por su dirección externa. El DNS-ALG solicitará al NAT que (a) establezca una asociación temporal para Host A (171.68.1.10) con una dirección externa y (b) inicie un temporizador de "bind-holdout". Cuando NAT tenga éxito al buscar una dirección externa (digamos, 131.108.1.12) para asociarla temporalmente con Host A, la DNS-ALG modificará la carga útil para sustituir la dirección privada de A por su dirección externa asignada y establecerá a 0 el temporizador de cachá. 6. El servidor en External.com responde a Host X Cuando Host X encuentra la dirección de Host A, X inicia una sesión con A, usando como dirección IP destino 131.108.1.12. Este datagrama y cualquier otro que siga en esta sesión será traducido como de costumbre por el NAT. Dese cuenta que la DNS-ALG sólo cambia los paquetes de respuesta desde el servidor DNS del dominio Private. Srisuresh, et al. Informativo [Pág. 26] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 6.4. Búsquedas inversas de nombres originadas en el dominio externo Este escenario es una continuación del caso anterior (sección 6.3), y en él Host X en External.com realiza una búsqueda inversa de nombre para 131.108.1.12, que es la dirección externa asignada a Host A. Tiene lugar la siguiente secuencia de eventos: 1. Host X envía a su servidor DNS local una consulta de búsqueda inversa de nombre basada en UDP. 2. El servidor DNS local para External.com envía la consulta al servidor raíz. 3. Por su parte, el servidor raíz llama al servidor DNS local para consultarle acerca de Private.com. 4. Ahora el servidor DNS de External.com enviará la consulta al servidor DNS de Private.com. Esta consulta atraviesa el encaminador NAT. El NAT traducirá las cabeceras IP y UDP para reflejar la dirección privada de los servidores DNS. Es decir, la dirección IP para el servidor DNS de Private.com se sustituye por su dirección privada, y la dirección externa del servidor DNS de External.com se sustituye por su dirección privada asignada. La DNS-ALG preguntará al NAT la dirección privada asociada con la dirección externa 131.108.1.12 y modificará la carga útil, sustituyendo 131.108.1.12 por la dirección privada 171.68.1.10. 5. El servidor DNS de Private.com responde con el nombre de máquina "A.Private.Com". Esta respuesta también atraviesa el NAT. El NAT de nuevo traducuirá las cabeceras IP y UDP del paquete entrante para reflejar la dirección externa de los servidores DNS. Es decir, la dirección IP del servidor DNS de Private.com se sustituye por su dirección externa asignada, y la dirección privada asignada del servidor DNS de External.com se sustituye por su dirección externa. De nuevo el DNS-ALG preguntará al NAT la dirección externa asignada asociada con la dirección privada 172.19.1.10 y modificará la carga útil, sustituyendo 171.68.1.10 por la dirección externa asignada 131.108.1.12. 6. El servidor DNS en External.com responde a Host X. Dese cuenta que el DNS-ALG modifica tanto los paquetes de la consulta como los de la respuesta desde el servidor DNS en el dominio Private. 7. Limitaciones de las DNS-ALG y trabajo futuro Srisuresh, et al. Informativo [Pág. 27] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 El NAT incrementa la posibilidad de direccionamientos erróneos. Por ejemplo, la misma dirección local podría estar asociada a diferentes direcciones públicas en momentos diferentes, y viceversa. En consecuencia, las máquinas que almacenen temporalmente los mapeos de nombre a dirección durante periodos superiores a los que el encaminador NAT tiene configurado para mantener estos mapeos es probable que puedan mal-direccionar sus sesiones. Dese cuenta que esto es un problema sobre todo con malas implementaciones de máquinas que mantengan los registros DNS durante más tiempo que el TTL que estos registros permiten, y no es directamente achacable al mecanismo aquí descrito. La DNS-ALG no puede soportar servidores de nombres DNS seguros en el dominio privado. Es decir, las respuestas firmadas desde un servidor de nombres DNS autoritario en la DMZ en respuesta a consultas originadas en el mundo exterior serán corrompidas por la DNS-ALG. Como mucho, la DNS-ALG sería capaz de transformar los datos seguros DNSSEC en datos desprotegidos. Los nodos finales que demanden respuestas DNS firmadas puede que rechacen las respuestas que hayan sido modificadas por la DNS-ALG. Y puesto que el servidor DNS no tiene ninguna manera de saber de dónde provienen las consultas (es decir, del interior o del exterior), lo más probable es que tenga que recurrir al común denominador del DNS inseguro actual. Ambas son serias limitaciones de las DNS-ALG. Las transferencias de zonas entre servidores DNS-SEC se ven afectadas de la misma manera, si la transferencia atraviesa dominios de direcciones. Sin embargo, las buenas noticias son que sólo los nodos finales de la DMZ pagan el precio de la limitación anterior en un NAT tradicional (o en un NAT bidireccional), puesto que los nodos finales externos puede que no accedan a las máquinas internas debido a que las respuestas DNS no son seguras. Sin embargo, para las sesiones salientes (desde la red privada) en una configuración de NAT bidireccional, las consultas DNS pueden ser firmadas y aceptadas con seguridad por la DMZ y otras máquinas internas, puesto que la DNS-ALG no intercepta las consultas DNS salientes y las respuestas entrantes. Por último, las transferencias de zonas entre servidores DNS-SEC dentro de la misma red privada no se ven afectadas. Está claro que con el despliegue de DNS SEC en los servidores DNS y en los resolvers de las máquinas finales, el esquema sugerido en este documento no funcionará. 8. Consideraciones de seguridad Si los paquetes DNS están encriptados/autenticados mediante DNSSEC, la DNS-ALG fallará porque no será capaz de realizar modificaciones en la carga útil. Alternativamente, si se deben preservar los paquetes Srisuresh, et al. Informativo [Pág. 28] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 en un dominio de direcciones, la DNS-ALG necesitará mantener la clave secreta para descrifrar/verificar la carga útil antes de reenviar los paquetes a un dominio diferente. Por ejemplo, si la DNS-ALG, NAT y la pasarela IPsec (que proporciona el servicio de túneles seguros) están presentes en el mismo dispositivo, la DNS-ALG tendrá acceso a las claves de asociación de seguridad de IPsec. La sección anterior, "Limitaciones de las DNS-ALG y trabajo futuro" dispone de información acerca de las consideraciones de seguridad. Además, con DNS-ALG existe la posibilidad de ataques de denegación de servicio por parte de un usuario malicioso, como se señaló en la sección 3.1. La sección 3.1 sugiere algunas maneras de repeler estos ataques. REFERENCIAS [1] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, Agosto 1999. [2] Egevang, K. and P. Francis, "The IP Network Address Translator (NAT)", RFC 1631, Mayo 1994. [3] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, Febrero 1996. [4] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, Noviembre 1987. [5] Mockapetris, P., "Domain Names - Implementation and Specifica­ tion", STD 13, RFC 1035, Noviembre 1987. [6] Reynolds J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, Octubre 1994. [7] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, Octubre 1989. [8] Braden, R., "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, Octubre 1989. [9] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, Junio 1995. [10] Carpenter, B., Crowcroft, J. and Y. Rekhter, "IPv4 Address Behaviour Today", RFC 2101, Febrero 1997. Srisuresh, et al. Informativo [Pág. 29] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 [11] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, Marzo 1999. [12] Vixie, P., Thompson, S., Rekhter Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, Abril 1997. [13] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, Abril 1997. [14] Elz R. and R. Bush, "Clarifications to the DNS specification", RFC 2181, Julio 1997. [15] Elz, R., R. Bush, Bradner S. and M. Patton, "Selection and Oper­ ation of Secondary DNS Servers", RFC 2182, Julio 1997. Srisuresh, et al. Informativo [Pág. 30] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 Direcciones de los autores Pyda Srisuresh 849 Erie Circle Milpitas, CA 95035 U.S.A. Teléfono: +1 (408) 263-7527 EMail: srisuresh@yahoo.com George Tsirtsis Internet Transport Group B29 Room 129 BT Laboratories Martlesham Heath IPSWICH Suffolk IP5 3RE Inglaterra Teléfono: +44 1473 640756 Fax: +44 1473 640709 EMail: george@gideon.bt.co.uk Praveen Akkiraju Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA Teléfono: +1 (408) 526-5066 EMail: spa@cisco.com Andy Heffernan Juniper Networks, Inc. 385 Ravensdale Drive. Mountain View, CA 94043 USA Teléfono: +1 (650) 526-8037 Fax: +1 (650) 526-8001 EMail: ahh@juniper.net Srisuresh, et al. Informativo [Pág. 31] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 Traducción al castellano: José Luis Domingo López c/ Cruz del Sur 22 28007 Madrid - España EMail: jdomingo@internautas.org Srisuresh, et al. Informativo [Pág. 32] RFC 2694 Extensiones del DNS para NAT Septiembre 1999 Declaración completa de copyright Copyright (C) The Internet Society (1999). Todos los derechos reser­ vados. Este documento y sus traducciones puede ser copiado y facilitado a otros, y los trabajos derivados que lo comentan o lo explican o ayu­ dan a su implementación pueden ser preparados, copiados, publicados y distribuídos, enteros o en parte, sin restricción de ningún tipo, siempre que se incluyan este párrafo y la nota de copyright expuesta arriba en todas esas copias y trabajos derivados. Sin embargo, este documento en sí no debe ser modificado de ninguna forma, tal como eliminando la nota de copyright o referencias a la 'Internet Society' u otras organizaciones de Internet, excepto cuando sea necesario en el desarrollo de estándares Internet, en cuyo caso se seguirán los procedimientos para copyrights definidos en el proceso de Estándares Internet, o con motivo de su traducción a otras lenguas aparte del Inglés. Este documento y la información contenida en él se proporcionan en su forma "TAL CUAL" y LA INTERNET SOCIETY Y LA INTERNET ENGINEERING TASK FORCE RECHAZAN CUALESQUIERA GARANTIAS, EXPRESAS O IMPLICITAS, INCLUYENDO, PERO NO LIMITADAS A, CUALQUIER GARANTIA DE QUE EL USO DE LA INFORMACION AQUI EXPUESTA NO INFRINGIRA NINGUN DERECHO O GARANTIAS IMPLICITAS DE COMERCIALIZACION O IDONEIDAD PARA UN PROPOSITO ESPECI­ FICO. Reconocimientos En la actualidad, la financiación para las funciones del editor RFC es proporcionada por la Internet Society. Srisuresh, et al. Informativo [Pág. 33]