Member of The Internet Defense League Últimos cambios
Últimos Cambios
Blog personal: El hilo del laberinto Geocaching

Desarrollo de una Herramienta Software para el Acceso a Redes TCP/IP a través de la Red Telefónica Conmutada

Última Actualización: 30 de Junio de 1.996 - Domingo

Capítulo 11:
El Módulo DNS

El módulo DNS (Domain Name System) [RFC1034] [RFC1035] es el responsable, fundamentalmente, de realizar la traducción entre un nombre jeráquico y una serie de "identificadores" asociados. Dichos identificadores pueden constituir cualquier información de interés práctico.

Tradicionalmente estos sistemas se han utilizado para la obtención de la dirección IP de una máquina dado su nombre jerárquico, así como para identificar la máquina o máquinas responsables de un dominio de correo. No sería exagerado decir que el DNS constituye el verdadero núcleo aglutinador de una red de las características de "Internet", ya que es lo que proporciona al usuario una visión homogenea y organizada de las máquinas y servicios disponibles.

En [RFC1101] se define una extensión del DNS para soportar la traducción de nombres jerárquicos de redes, X.500, etc., no sólo de máquinas. En [RFC1383] se describe una idea muy novedosa y atractiva desde un punto de vista teórico, como es el encaminamiento de los datagramas IP utilizando las tablas DNS. En cierto modo constituye una generalización de la idea utilizada ya para el encaminamiento del correo electrónico. Ello haría posible, además de reducir el tamaño de las tablas de enrutado, el acceso a redes desacopladas del cuerpo principal del sistema (como sucede ya con el correo electrónico), al igual que ocurre con los sistemas PROXY. Constituye una idea muy atractiva.

En [RFC1664] se propone un servicio de conectividad entre el correo electrónico tradicional de "Internet" [RFC822] y la familia de recomendaciones CCITT X.400. Por otra parte [RFC1788] define un protocolo experimental para realizar la traducción entre direcciones IP y nombres jerárquicos empleando datagramas ICMP, ya que el estándar "IN_ADDR" tiene muchos problemas cuando la interfaz de una red está constituida por varias pasarelas, así como por cuestiones de escala. En [RFC1876] se especifica un protocolo para almacenar información geográfica, tales como la latitud, longitud y altura de la máquina desde el nivel del mar.

Para acomodar el DNS a las necesidades de IPv6, en [RFC1886] se define una extensión estándar que posibilita el traducir las nuevas direcciones IPv6 de 128 bits, en vez de los 32 tradicionales del IPv4.

Por último, existen numerosos RFC's adicionales proponiendo nuevas extensiones, advirtiendo de diversos errores de implementación, comentando fallos típicos en las configuraciones, etc. En la sección de bibliografía puede encontrarse más información.


Interfaz

La interfaz de este módulo está constituida por diversos procesos cooperantes y una rutina que se ejecuta en el contexto del llamante.


PROC_DNS_BC

Este proceso es el encargado de inicializar este módulo. Debe ser invocado con un mensaje "MSG_INIT" o "MSG_QUIT". La inicialización de este módulo debe ser posterior a la del módulo UDP.


PROC_DNS_SUP

Este es el proceso que recibe los mensajes de las capas superiores y los gestiona adecuadamente. El único mensaje definido aquí es:

  • MSG_DNS_QUERY

    Este mensaje solicita una traducción entre un nombre jerárquico y su direccion IP equivalente.

    campo1: Contiene un identificador de 32 bits utilizado para relacionar las peticiones con las respuestas.
    campo2: Es un MBUF (uno sólo, no una cadena) que contiene el nombre jerárquico a traducir. Su longitud debe ser exactamente igual a la longitud del nombre en sí, sin tener en cuenta ningún símbolo adicional, como podría ser el '\0' de final de cadena.
    campo3: Proceso al cual hay que informar del resultado.

    Este módulo se encarga de intentar efectuar la traducción y devolver el resultado o un error. El nombre jerárquico puede ser una dirección IP de punto. En ese caso se devuelve un mensaje "MSG_DNS_ANSWER", con el formato:

    campo1: Identificador de 32 bits especificado en el mensaje de petición
    campo2: Dirección IP de 32 bits
    campo3: Indefinido

    Si este módulo no dispone de espacio suficiente en sus tablas internas para gestionar una nueva petición, se devuelve un mensaje "MSG_DNS_ERROR":

    campo1: Identificador de petición de 32 bits
    campo2: ERR_DNS_OVERFLOW
    campo3: Indefinido

    Si el servidor DNS no responde tras una serie de reintentos se enviará un mensaje "MSG_DNS_ERROR":

    campo1: Identificador de 32 bits indicado en el "MSG_DNS_QUERY"
    campo2: ERR_DNS_TIMEOUT
    campo3: Indefinido

    En el caso de que la dirección del servidor DNS no haya sido establecida correctamente, o bien que el módulo IP desconozco cómo llegar hasta él, se devolverá un mensaje "MSG_DNS_ERROR":

    campo1: Identificador de 32 bits
    campo2: ERR_DNS_INVALID
    campo3: Indefinido


PROC_DNS_INF

Este proceso es el encargado de interactuar con el módulo UDP para gestionar las respuestas del servidor DNS. Los mensajes que genera hacia arriba son:

  • MSG_DNS_ANSWER

    La traducción ha tenido éxito.

    campo1: Identificador de la petición
    campo2: Dirección IP resuelta
    campo3: Indefinido

  • MSG_DNS_ERROR

    El DNS ha devuelto un error.

    campo1: Identificador de la peticón
    campo2: Código del error:

    • ERR_DNS_FORMAT: El formato de la petición es inválido
    • ERR_DNS_SERVER: Error del servidor
    • ERR_DNS_NAME: El nombre jerárquico especificado no existe
    • ERR_DNS_NO_IMPLM: Se solicita una característica no implementada
    • ERR_DNS_REFUSED: El servidor se niega a proporcionarnos el servicio demandado
    campo3: Indefinido

En cuanto a la rutina, su prototipo es el siguiente:


void dns_alta(uint32 ip);

La función de esta rutina es indicar a la capa DNS qué servidor de nombres debe utilizar para resolver las peticiones. Debe tratarse de una dirección alcanzable desde nuestra posición.


Implementación

La implementación del módulo DNS (Domain Name System) sigue las directrices proporcionadas en [RFC1034] y [RFC1035]. A pesar de que el DNS puede efectuar diversas traducciones, en la implantación actual sólo se utiliza su capacidad de gestión de RRs de tipo A (direcciones IP de 32 bits).

Lo que se ha programado es, realmente, un "resolver" que envía las peticiones que se le plantean directamente (con un formato específico, por supuesto) al servidor de nombres. Dado el diseño empleado resulta necesario, para un funcionamiento correcto, que el servidor de nombres que se elija (puede ser cualquiera) admita solicitudes recursivas.

Los mensajes ICMP, como "MSG_ICMP_DEST_UNREACHABLE", son ignorados, ya que se asume que el mecanismo de reintentos se hará cargo de cualquier posible error. A propósito de ello se ha elegido una temporización entre reenvíos de dos segundos y un número máximo de intentos de quince. Si en un momento dado la capa UDP tiene su control de flujo cerrado, las peticiones se mantendrán en espera hasta que éste se abra, comprobándolo de forma automática cada décima de segundo, aproximadamente.

Naturalmente, el módulo DNS admite la resolución diversas solicitudes de forma simultanea. Las respuestas a las mismas no se darán, dadas las características del sistema, necesariamente en el mismo orden. Es por ello por lo que se incluye un identificador en todos los mensajes desde y hacia este módulo.

La implementación afectuada admite respuestas DNS comprimidas, pero nunca comprimirá sus propias peticiones. No hay necesidad de ello, ya que se solicita la traducción de un único nombre jerárquico por datagrama.


Bibliografía


[RFC768]    RFC768: "User Datagram Protocol"
            Jon Postel
            Agosto 1.981

[RFC974]    RFC974: "MAIL ROUTING AND THE DOMAIN SYSTEM"
            Craig Partridge
            Enero 1.986

[RFC1034]   RFC1034: "Domain names - concepts and facilities"
            Paul Mockapetris
            Noviembre 1.987

[RFC1035]   RFC1035: "Domain names - implementation and
            specification"
            Paul Mockapetris
            Noviembre 1.987

[RFC1101]   RFC1101: "DNS encoding of network names and other
            types"
            Paul Mockapetris
            Abril 1.989

[RFC1123]   RFC1123:"Requirements for Internet Hosts --
            Application and Support"
            Robert Braden
            Octubre 1.989

[RFC1183]   RFC1183: "New DNS RR Definitions"
            Craig F. Everhart
            Louis A. Mamakos
            Robert Ullmann
            Paul Mockapetris
            Octubre 1.990

[RFC1383]   RFC1383: "An Experiment in DNS Based IP Routing"
            Christian Huitema
            Diciembre 1.992

[RFC1464]   RFC1464: "Using the Domain Name System To Store
            Arbitrary String Attributes"
            Rich Rosenbaum
            Mayo 1.993

[RFC1480]   RFC1480: "The US Domain"
            Ann Cooper
            Jon Postel
            Junio 1.993

[RFC1498]   RFC1498: "On the Naming and Binding of Network
            Destinations"
            Jerome H. Saltzer
            Agosto 1.993

[RFC1535]   RFC1535: "A Security Problem and Proposed Correction
            With Widely Deployed DNS Software"
            Ehud Gavron
            Octubre 1.993

[RFC1536]   RFC1536: "Common DNS Implementation Errors and
            Suggested Fixes"
            Anant Kumar
            Jon Postel
            Cliff Neuman
            Peter Danzig
            Steve Miller
            Octubre 1.993

[RFC1591]   RFC1591: "Domain Name System Structure and Delegation"
            Jon Postel
            Marzo 1.994

[RFC1611]   RFC1611: "DNS Server MIB Extensions"
            Rob Austein
            Jon Saperia
            Mayo 1.994

[RFC1612]   RFC1612: "DNS Resolver MIB Extensions"
            Rob Austein
            Jon Saperia
            Mayo 1.994

[RFC1664]   RFC1664: "Using the Internet DNS to Distribute RFC1327
            Mail Address Mapping Tables"
            Claudio Allocchio
            Antonio Blasco Bonito
            Bruce Cole
            Silvia Giordano
            Robert Hagens
            Agosto 1.994

[RFC1706]   RFC1706: "DNS NSAP Resource Records"
            Bill Manning
            Richard Colella
            Octubre 1.994

[RFC1712]   RFC1712: "DNS Encoding of Geographical Location"
            Craig Farrell
            Mike Schulze
            Scott Pleitner
            Daniel Baldoni
            Noviembre 1.994

[RFC1713]   RFC1713: "Tools for DNS debugging"
            Artur Romao
            Noviembre 1.994

[RFC1788]   RFC1788: "ICMP Domain Name Messages"
            William Allen Simpson
            Abril 1.995


[RFC1794]   RFC1794: "DNS Support for Load Balancing"
            Thomas P. Brisco
            Abril 1.995

[RFC1876]   RFC1876: "A Means for Expressing Location Information
            in the Domain Name System"
            Christopher Davis
            Paul Vixie
            Tim Goodwin
            Ian Dickinson
            Enero 1.996

[RFC1886]   RFC1886: "DNS Extensions to support IP version 6"
            Susan Thomson
            Christian Huitema
            Diciembre 1.995

[RFC1912]   RFC1912: "Common DNS Operational and Configuration
            Errors"
            David Barr
            Febrero 1.996



Python Zope ©1996 jcea@jcea.es

Más información sobre los OpenBadges

Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS