Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización:
30 de Junio de 1.996 - Domingo
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:
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:
La traducción ha tenido éxito.
campo1: Identificador de la petición
campo2: Dirección IP resuelta
campo3: Indefinido
El DNS ha devuelto un error.
campo1: Identificador de la peticón
campo2: Código del error:
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
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
