2.2.5 El problema del agotamiento las direcciones IP
El número de redes en Internet se ha ido doblando aproximadamente cada año durante varios años. Sin embargo, el uso de las redes de clase A, B y C difiere mucho: la mayoría de las redes asignadas a finales de 1980 eran de clase B, y en 1990 se hizo evidente que, de continuar si la tendencia, el último número de red de clase B sería asignado en 1994. Por otro lado, las redes de clase C apenas se usaban.
La razón de esta tendencia era que la mayoría de los usuarios potenciales hallaban a las redes de clase B lo bastante grandes para sus necesidades previstas, ya que acomoda hasta 65534 hosts, mientras que un red de clase C, con un máximo de 254 hosts, restringe considerablemente el crecimiento potencial de hasta las redes pequeñas. Es más, la mayoría de las redes de clase B estaban asignadas a redes pequeñas. Hay un número relativamente pequeño de redes que necesiten 65,534 direcciones de hosts, pero muy pocas para las 254 sea un límite adecuado. En resumen, aunque las divisiones de clase A, B y C de las direcciones IP son lógicas y fáciles de usar(puesto que se producen a nivel de byte), en perspectiva no son las más prácticas, ya que las redes de clase C son demasiado pequeñas para la mayoría de las organizaciones mientras son demasiado grandes para ser bien aprovechadas por nadie excepto por las organizaciones más grandes.
Tabla - uso de las direcciones de red IP entre 1990 y 1994 muestra el uso de las direcciones de red IP entre 1990 y 1994.
Tabla: uso de las direcciones de red IP entre 1990 y 1994. - netinfo/ip_network_allocations.95Jan del FTP rs.internic.net
Algunos aspectos de esta tabla requieren explicación.
Assigned(asignado)
La cantidad de números de red en uso. Las cantidades de la clase C son algo imprecisas, puesto que no incluyen muchas redes de clase C en Europa que se destinaron a RIPE, y fueron asignadas posteriormente, aunque aún están registradas como parte de RIPE.
Allocated(reservado)
Incluye todas las redes asignadas y adicionalmente, aquellas redes que han sido reservadas bien por IANA(por ejemplo, todas las 63 redes de clase A) o que IANA ha sido destinado a registros nacionales que posteriormente podrán asignarlas. Por ejemplo, IANA reservó 64,783 redes de clase C en agosto de 1992, y 65,959 en julio de 1993.
Nota: Según IANA, el estado de un red es asignado o reservado, pero esta tabla trata el estado reservado como un superconjunto del asignado; el porcentaje real se puede calcular restando de 100 el porcentaje reservado para determinar cuánto espacio "libre" queda.
Otra forma de ver estos datos es examinar la proporción del espacio de direcciones que ha sido usado: las cantidades de la tabla no muestran, por ejemplo, que el espacio de direcciones de clase A es tan grande como el de las clases B y C combinados, o que teóricamente una sola red de clase A puede tener tantos host como 66,000 redes de clase C. Figura - Uso del espacio de direcciones IP muestra el uso del espacio de direcciones desde este punto de vista. El gráfico representa un espacio de direcciones de 32 bits, es decir, 4,294,967,296 direcciones. Las direcciones de clase A, B y C se dividen del modo siguiente:
Assigned(asignado)
La porción del espacio de direcciones localizadas en redes asignadas. La cantidad real es en realidad mucho menor, puesto que es probable que cada red tenga bastante espacio libre, pero como este espacio no se puede utilizar fuera de la organización que controla la red, debe considerarse como espacio efectivo.
Se muestra en porciones resaltadas: el área resultante de unir todas las porciones representa la proporción del espacio de direcciones IP en uso.
Allocated(reservado)
La porción del espacio de direcciones que se halla en redes que reservadas pero no asignadas más la porción de espacio perdida en números como el 0 de las redes de clase A y el 127(loopback).
El espacio reservado se muestra con porciones sombreadas.
Unallocated(no reservado)
El resto del espacio de las clases A, B, C está libre; se muestra con una porción sin sombrear. Las porciones de las clases A, B, C se muestran con bordes progresivamente más finos. La clase A comienza a las 3 en punto y se mueve en sentido anti-horario hacia las clases B y C.
Class D(clase D)
Una decimosexta parte del espacio total es absorbido por las direcciones de multicast de clase D. Se consideran direcciones en uso por lo que la porción correspondiente aparece resaltada.
Class E(clase E)
La decimosexta parte restante del espacio de direcciones: IANA ha reservado esa parte, correspondiente a las direcciones IP con los cuatro bits de orden superior puestos a uno.
Figura: Uso del espacio de direcciones
Si se examina Tabla - Uso de las direcciones IP entre 1990 y 1994 se verá que es de 1990, el número de redes asignadas de clase B se ha ido incrementado a una tasa mucho más baja que el número total de redes asignadas y que el agotamiento previsto de los números de clase B. La razón es que la política del InterNIC sobre la concesión de números de red cambió en desde 1990 para preservar el espacio de direcciones existente, en particular para frenar el agotamiento del espacio de direcciones de clase B. Las nuevas políticas se pueden resumir en:
* La mitad superior del espacio de direcciones de clase A se reserva indefinidamente para tener la posibilidad de usarlo en la transición a un nuevo sistema de numeración.
* Las redes de clase B sólo se asignan a organizaciones que puedan probar claramente que las necesitan. Lo mismo ocurre, por supuesto, con las direcciones de clase A. Los requerimientos para las redes de clase B son que la organización solicitante
o Tenga un esquema de subnetting con más de 32 subredes dentro de su red operativa
y
o Tenga más de 4096 hosts
Cualquier solicitud de una red de clase A se trataría considerando estrictamente el caso particular.
* A las organizaciones que no satisfacen los requerimientos para una red de clase B se les asigna un bloque de redes e clase C numeradas consecutivamente.
* La mitad inferior del espacio de direcciones de clase C(números de red del 192.0.0 al 223.255.245) se divide en 8 bloques que se para las autoridades regionales están reservadas del siguiente modo:
192.0.0 - 193.255.255
Multi-regional
194.0.0 - 195.255.255
Europa
196.0.0 - 197.255.255
Otros
198.0.0 - 199.255.255
Norte América
200.0.0 - 201.255.255
Centro y Sur América
202.0.0 - 203.255.255
Borde del Pacífico
204.0.0 - 205.255.255
Otros
206.0.0 - 207.255.255
Otros
Los rangos definidos como "otros" se utilizan donde hace falta flexibilidad por encima de las limitaciones de las fronteras regionales. El rango definido como "multi-regional" incluye las redes de clase C que habían sido asignadas antes de que se adoptase este nuevo esquema. El InterNIC asignó 192 redes, y 193 habían sido previamente reservadas para el RIPE en Europa.
La mitad superior del espacio de direcciones de clase C(208.0.0 a 223.255.255) permanece sin asignar y sin reservar.
* En las organizaciones que tienen una serie de números de clase C, el rango asignado contiene números de red contiguos a nivel de bit y el número de redes de ese rango es una potencia de dos. Es decir, todas las direcciones IP en ese rango tienen un prefijo común, y cada dirección con ese prefijo está a su vez dentro del rango. Por ejemplo, a una organización europea que requiera 1500 direcciones IP se le asignarían 8 números de red de clase C(2048 direcciones IP) del espacio reservado para redes europeas (194.0.0 a 195.255.255) y el primero de estos números de red sería divisible por ocho. Un rango de direcciones que se adecuase a esta regla sería el 194.32.136 - 194.32.143, en cuyo caso contendría todas las direcciones IP con el prefijo de 21 bits 194.32.136, o '110000100010000010001'.
El número máximo de números de red asignados contiguamente es 64, correspondiente a un prefijo de 18 bits. Una organización que requiera más de 4096 direcciones pero menos de 16,384 puede solicitar tanto una clase B como un rango de direcciones de clase C. En general, el número de clases C asignadas es el mínimo necesario para proporcionar la cantidad requerida de direcciones IP a la organización partiendo de una previsión sobre el plazo de los dos años siguientes. Sin embargo, en algunos casos, una organización puede solicitar múltiples redes que sean tratadas por separado. Por ejemplo, a una organización con 600 hosts se le asignarían normalmente 4 redes de clase C. No obstante, si esos hosts estuvieran distribuidos a lo largo de 10 LANs en anillo con testigo con entre 50 y 70 hosts por LAN, tal esquema de direcciones causaría graves problemas, ya que la organización tendría que encontrar 10 subredes dentro de un rango de direcciones locales de 10 bits. Esto significaría que al menos alguna de las LAN tendría una máscara de subred de 255.255.255.192, que sólo permite 62 hosts por LAN. La intención de las reglas no es forzar a la organización a que tenga un complicado sistema de subredes, así que la organización debería solicitar 10 números de clase C diferentes, uno para cada LAN.
Las reglas actuales se pueden encontrar en el RFC 1466 - Directrices para la gestión del espacio de direcciones IP. Las razones de las reglas de distribución de los números de red de clase C quedarán patentes en la próxima sección. Usar números de clase C de esta forma ha frenado el problema del agotamiento de las direcciones de clase B, pero no es una solución definitiva a las limitaciones de espacio inherentes a IP. La solución a largo plazo se discute en IP: La próxima generación(IPng).
2.2.6 Redes privadas
Otro enfoque de la conservación del espacio de direcciones IP se describe en el RFC 1597 - Distribución de direcciones para redes privadas. En pocas palabras, relaja la regla de que las direcciones IP han de ser unívocas globalmente al reservar parte del espacio de direcciones para redes que se usan exclusivamente dentro de una sola organización y que no requieren conectividad IP con Internet. Hay tres rangos de direcciones que IANA ha reservado con este propósito:
* 10 Una sola red de clase A
* 16 redes clase B contiguas del 172.16 al 172.31
* 256 redes clase C contiguas del 192.168.0 al 192.168.255
Cualquier organización puede usar cualquier dirección en estos rangos si no hace referencia a ninguna otra organización. Sin embargo, debido a que estas direcciones no son unívocas a nivel global, no pueden ser direccionadas por hosts de otras organizaciones y no están definidas para los "routers" externos. Se supone que los "routers" de una red que no usa direcciones privadas, particularmente aquellos operados por proveedores de servicios de Internet, han de desechar toda información de encaminamiento relativa a estas direcciones. Los "router" de una organización que utiliza direcciones privadas deberían limitar todas las referencias a direcciones privadas a los enlaces internos; no deberían hacer públicas las rutas a direcciones privadas ni enviar datagramas IP con estar direcciones a los "routers" externos. Los hosts que sólo tienen una dirección IP privada carecen de conexión IP con Internet. Esto puede ser deseable y a lo mejor puede ser una razón para emplear direcccionamiento privado. Toda la conectividad con host externos de Internet la deben proporcionar pasarelas de aplicación.
2.2.7 CIDR("Classless Inter-Domain Routing"
El uso de un rango de direcciones de clase C en vez de una sola de clase B acarrea un gran problema: cada red ha de ser direccionada por separado. El encaminamiento IP estándar sólo comprende las clases A, B y C. Dentro de cada uno de estos tipos de red, se puede usar "subnetting" para proporcionar mejor granularidad del espacio de direcciones en cada red, pero no hay forma de especificar que existe una relación real entre múltiples redes de clase C. El resultado de esto se denomina el problema de la explosión de la tabla de encaminamiento: una red de clase B de 3000 host requiere una entrada en la tabla de encaminamiento para cada "router" troncal, pero si la misma red se direccionase como un rango de redes de clase C, requeriría 16 entradas.
La solución a este problema es un método llamado CIDR("Classless Inter-Domain Routing"
. El CIDR es un protocolo propuesto como estándar con status electivo.
El CIDR no encamina de acuerdo a la clase del número de red(de ahí el término "classless": sin clase) sino sólo según los bits de orden superior de la dirección IP, que se denominan prefijo IP. Cada entrada de encaminamiento CIDR contiene una dirección IP de 32 bits y una máscara de red de 32 bits, que en conjunto dan la longitud y valor del prefijo IP. Esto se puede representar como <dir_IP máscara_red. Por ejemplo, <194.0.0.0 254.0.0.0 representa el prefijo de 7 bits B'1100001'. CIDR maneja el encaminamiento para un grupo de redes con un prefijo común con una sola entrada de encaminamiento. Esta es la razón por la que múltiples números de red de clase C asignados a una sola organización tienen un prefijo común. Al proceso de combinar múltiples redes en una sola entrada se le llama agregación de direcciones o reducción de direcciones. También se le llama supernetting poque el encaminamiento se basa en máscaras de red más cortas que la máscara de red natural de la dirección IP, en contraste con el subnetting, donde las máscaras de red son más largas que la máscara natural.
A diferencia de las máscaras de subred, que normalmente son contiguas pero pueden tener una parte local no contigua, las máscaras de superred son siempre contiguas
Si se representan las direcciones IP con una árbol que muestre la topología de encaminamiento, donde cada hoja del árbol significa un grupo de redes que se consideran como una sola unidad(llamada dominio de encaminamiento) y el esquema de direccionamiento IP se elige de modo que cada bifurcación del árbol corresponda a un incremento en la longitud del prefijo IP, entonces el CIDR permite realizar la agregación de direcciones muy eficientemente. Por ejemplo, si un "router" en Norteamérica encamina todo el tráfico europeo a través de un único enlace, entonces una sola entrada de encaminamiento para <194.0.0.0 254.0.0.0 incluye el grupo de direcciones de redes de clase C asignadas a Europa como se describe más arriba. Esta única entrada toma el lugar de todas las entradas de los números de red asignados, que son un máximo de 2exp17, o 131,072. En el extremo europeo del enlace, hay entradas de encaminamiento con prefijos más largos que mapean la topología de la red europea, pero esta información de encaminamiento no hace falta en el extremo americano. La filosofía de CIDR es "la mejor aproximación es la que tiene más aciertos", de modo que si los US necesitan hacer una excepción para un rango de direcciones, como por ejemplo las 64 redes <195.1.64.0 255.555.192.0, necesita sólo una entrada adicional, que en la tala de encaminamiento se superpone a otras entradas más generales(más cortas) de las redes que contiene. De este ejemplo se hace evidente que a medida que aumenta el uso del espacio de direcciones IP, particularmente de las de clase C, los beneficios de CIDR aumentan por igual, siempre que la asignación de direcciones siga la topología de la red. El estado actual del espacio de direcciones IP no sigue este esquema ya que el desarrollo de CIDR fue posterior. Sin embargo, se están asignando nuevas direcciones de clase C de tal modo que sean compatibles con CIDR, lo que debería tener el efecto de aliviar el problema de la explosión de las tablas de encaminamiento a corto plazo. A largo plazo, puede que sea necesaria una reestructuración del espacio de direcciones IP siguiendo pautas topológicas. Esto supondría tener que renumerar un gran número de redes, implicando un enorme trabajo de implementación, por lo que se trataría de un proceso gradual
Asumir que la topología de encaminamiento se puede representar con un simple árbol es un exceso de simplificación; aunque la mayoría de los dominios de encaminamiento tienen un sólo enlace que proporciona acceso al resto de Internet, hay también muchos dominios con enlaces múltiples. Los dominios de encaminamiento de estos dos tipos se llaman "single-homed"(unipuerto) y "multi-homed"(multipuerto). Es más, la topología no es estática. No sólo se unen nuevas organizaciones a un ritmo creciente, sino que las ya existentes pueden cambiar partes de su topología, por ejemplo, si cambian de proveedor de servicios por razones comerciales o de otra índole. Aunque estos casos complican la implementación práctica del encaminamiento basado en CIDR y reducen la eficiencia de la agregación de direcciones que se puede conseguir, la estrategia no deja de ser válida.
Las políticas actuales para la distribución de direcciones de Internet y las suposiciones en las que se basan se describen en el RFC 1518 - Una arquitectura para la distribución de direcciones IP con CIDR. Se pueden resumir en:
* La asignación de direcciones IP refleja la topología física de la red y no de la organización; las restricciones organizacionales y administrativas no deberían usarse en la asignación de direcciones IP cuando no se ajusten a la topología de la red.
* En general, la topología de la red seguirá de cerca los límites continentales y nacionales, y por tanto las direcciones IP se deberían asignar partiendo de esta base.
* Habrá un número relativamente pequeño de redes que transportarán una elevada cantidad de tráfico entre dominios de encaminamiento y que estarán conectadas de modo no jerárquico, traspasando los límites nacionales. Estas redes se denominan TRDst("Transit Routing Domains"
. Cada TRD tendrá un prefijo IP unívoco. En general, los TRDs no se organizarán jerárquicamente. Sin embargo, cuando un TRD se halle por completo dentro de los límites contientales, su prefijo IP debería ser una extensión del prefijo IP continental.
* Habrá organizaciones con enlaces a otras organizaciones que son para su uso privado y que no transportarán tráfico dirigido a otros dominios(tráfico de tránsito). Estas conexiones privadas no tienen un efecto significativo sobre la topología de red y pueden ser ignoradas.
* La gran mayoría de los dominios de encaminamiento serán single-homed. Es decir, estarán conectadas a un sólo TDR. Se les debería asignar direcciones que comiencen por el prefijo IP de ese TRD. Por tanto, todas las direcciones de los dominios "single-homed" conectados a un TDR se pueden agregar en una sola entrada de la tabla de encaminamiento para todos los dominios externos a ese TRD.
Nota: Esto implica que si una organización cambia su proveedor de servicios de Internet, debería cambiar todas sus direcciones IP. Esto no es lo habitual, pero es probable que la difusión de CIDR lo convierta en una práctica mucho más común.
* Hay una serie de esquemas de asignación de direcciones que se pueden usar con dominios "multi-homed". Algunos son:
o El uso de un único prefijo IP para el dominio. Los "routers" externos deben tener una entrada para la organización que se halla parcial o totalmente fuera de la jerarquía normal. Donde un dominio sea "multi-homed", pero todos los TRDs conectados estén topológicamente cerca, sería apropiado que el prefijo IP del dominio incluyese los bits comunes a todos los TRDs conectados. Por ejemplo, si todos los TRDs estuvieran totalmente dentro de los Estados Unidos, un prefijo IP indicando exclusivamente un dominio de Norteamérica sería lo adecuado.
o El uso de un prefijo IP para cada TRD conectado, con hosts en el dominio que tengan direcciones IP que contengan el prefijo del TRD más apropiado. La organización da la impresión de ser un conjunto de dominios de encaminamiento.
o Asignar un prefijo IP de uno de los TRDs conectados. Este TRD se convierte en un TRD por defecto para el dominio, aunque otros dominios pueden encaminar explícitamente sus mensajes por uno de los TRDs alternativos.
o El uso de prefijos IP para referirse a conjuntos de dominios "multi-homed" con conexiones a TRDs. Por ejemplo, puede haber un prefijo IP que se refiera a dominios "single-homed" conectados a la red A, uno que se refiera a dominios "single-homed" conectados a la red B y uno para los dominios conectados a A y a B.
* Cada uno de estos esquemas tiene sus ventajas, desventajas y efectos colaterales. Por ejemplo, el primero tiende a generar un tráfico interno en el dominio receptor más cercano al host fuente superior al generado por el segundo esquema, aumentando recursos de red consumidos en la organización receptora.
Debido a que los dominios "multi-homed" varían mucho en su carácter y ninguno de los esquemas anteriores parece apropiado para todos, no existe una política que sea la mejor, y el RFC 1518 no especifica ninguna regla para elegir entre ellas.
2.2.7.1 Implementación de CIDR
La implementación de CIDR en Internet se basa fundamentalmente en BGP("Border Gateway Protocol", versión 4) (ver BGP-4("Border Gateway Protocol", versión 4)). En el futuro CIDR también se implementará con una variante del estándar ISO IDRP, ISO 10747("Inter-Domain Routing Protocol"
, llamado IDRP para IP, que está estrechamente relacionado con BGP-4.
La estrategia de implementación, descrita en el RFC 1520 - Intercambiando información de encaminamiento a través de las fronteras de los proveedores en el entorno CIDR, implica un proceso por fases a través de la jerarquía de encaminamiento, empezando por los "routers" troncales. Los proveedores de servicios de red se dividen en cuatro tipos:
Tipo 1
Aquellos que no pueden emplear ningún IDRP.
Tipo 2
Aquellos que usan IDRP por defecto pero que requieren rutas explícitas para una proporción considerable de los números IP de red asignados.
Tipo 3
Aquellos que usan IDRP por defecto y añaden además un pequeño número de rutas explícitas.
Tipo 4
Aquellos que ejecutan IDRP utilizando sólo rutas por defecto.
La implementación de CIDR implica una primera fase por medio de los proveedores de tipo 0, luego los de tipo 2 y finalmente los de tipo 3. CIDR ya se ha instituido ampliamente en troncales y más de 9000 rutas se han reemplazado por aproximadamente 2000 rutas CIDR.
2.2.7.2 Referencias
* RFC 1467 - Difusión de CIDR en Internet
* RFC 1517 - Condiciones de aplicabilidad de CIDR
* RFC 1518 - Una arquitectura para la distribución de direcciones IP con CIDR
* RFC 1519 - CIDR: asignación de direcciones y estrategia de agregación
* RFC 1520 -Intercambiando información de encaminamiento a través de las fronteras de los proveedores en el entorno CIDR
2.2.8 DNS("Domain Name System"
El protocolo DNS es un protocolo estándar (STD 13). Su status es recomendado. Es descrito en:
* RFC 1034 - Nombres de dominio - conceptos y servicios
* RFC 1035 - Nombres de dominio - implementación y especificación
Las configuraciones iniciales de Internet requerían que los usuarios emplearan sólo direcciones IP numéricas. Esto evolucionó hacia el uso de nombres de host simbólicos muy rápidamente. Por ejemplo, en vez de escribir TELNET 128.12.7.14, se podría escribir TELNET eduvm9, y eduvm9 se traduciría de alguna forma a la dirección IP 128.12.7.14. Esto introduce el problema de mantener la correspondencia entre direcciones IP y nombres de máquina de alto nivel de forma coordinada y centralizada.
Inicialmente, el NIC("Network Information Center"
mantenía el mapeado de nombres a direcciones en un sólo fichero(HOSTS.TXT) que todos los hosts obtenían vía FTP. Se denominó espacio de nombres plano.
Debido al crecimiento explosivo del número de hosts, este mecanismo se volvió demasiado tosco(considerar el trabajo necesario sólo para añadir un host a Internet) y fue sustituido por un nuevo concepto: DNS("Domain Name System"
. Los hosts pueden seguir usando un espacio de nombres local plano(el fichero HOSTS.LOCAL) en vez o además del DNS, pero fuera de redes pequeñas, el DNS es prácticamente esencial. El DNS permite que un programa ejecutándose en un host le haga a otro host el mapeo de un nombre simbólico de nivel superior a una dirección IP, sin que sea necesario que cada host tenga una base de datos completa de los nombres simbólicos y las direcciones IP.
En el resto de esta sección examinaremos cómo funciona el DNS desde el punto de vista del usuario. Ver DNS("Domain Name System"
para más detalles sobre la implementación y los tipos de datos almacenados en DNS.
2.2.8.1 El espacio de nombres jerárquico
Consideremos la estructura interna de una gran organización. Como el jefe no lo puede hacer todo, la organización tendrá que partirse seguramente en divisiones, cada una de ellas autónoma dentro de ciertos límites. Específicamente, el ejecutivo a cargo de una división tiene autoridad para tomar decisiones sin requerir el permiso de su jefe.
Los nombres de dominio se forman de modo similar, y con frecuencia reflejarán la delegación jerárquica de autoridades usada para asignarlos. Por ejemplo, considerar el nombre
lcs.mit.edu
Aquí, lcs.mit.edu es el nombre de dominio de nivel inferior, un subdominio de mit.edu, que a su vez es un subdominio de edu("education"
, conocido como dominio raíz. También podemos representar este forma de asignar nombres con un árbol jerárquico,(ver Figura - Espacio de nombres jerárquico).
Figura: Espacio de nombres jerárquico - Esta figura muestra la cadena de autoridades en la asignación de nombres de dominio. Este árbol es sólo una fracción mínima del espacio de nombres real.
Figura - Los dominios genéricos de la cima muestra algunos de los dominios de la cima. El dominio único que se halla sobre la cima no tiene nombre y se le conoce como dominio raíz. La estructura completa se explica en las siguientes secciones.
2.2.8.2 FQDNs("Fully Qualified Domain Names"
Cuando se usa el DNS, es común trabajar con sólo una parte de la jerarquía de dominios, por ejemplo el dominio ral.ibm.com. El DNS proporciona un método sencillo para minimizar la cantidad de caracteres a escribir en estos casos. Si el nombre de dominio termina en un punto(por ejemplo wtscpok.itsc.pok.ibm.com.) se asume que está completo. Es lo que se llama un FQDN("Fully Qualified Domain Name"
o nombre absoluto de dominio. Si, sin embargo, no termina en punto,(por ejemplo wtscpok.itsc) estará incompleto y procesador de nombres del DNS, como se verá más abajo, podrá completarlo, por ejemplo, añadiendo un sufijo como .pok.ibm.com al nombre de dominio. Las reglas para hacer esto dependen de la implementación y son configurables localmente.
2.2.8.3 Dominios genéricos
A los tres dominios de la cima se les llama dominios genéricos u organizacionales.
Nombre de dominio
Significado
edu
Instituciones educativas
gov
Instituciones gubernamentales
com
Organizaciones comerciales
mil
Grupos militares
net
Redes
int
Organizaciones internacionales
org
Otras organizaciones
Figura: Los dominios genéricos de la cima
Puesto que Internet comenzó en los Estados Unidos, la estructura del espacio de nombres jerárquico tenía inicialmente sólo organizaciones estadounidenses en la cima de la jerarquía, y sigue siendo cierto que gran parte de las organizaciones de la cima de la jerarquía son estadounidenses. Sin embargo, sólo los dominios .gov y .mil están restringidos a los US.
2.2.8.4 Dominios de países
Además hay dominios de nivel de cima para cada uno de los códigos internacionales de dos caracteres ISO 3166 para países(de ae para los Emiratos Árabes Unidos a zw para Zimbabwe). Se les conoce como dominios de países o dominios geográficos. Muchos países tienen sus propios dominios de segundo nivel por debajo, paralelamente a los dominios genéricos. Por ejemplo, en el Reino Unido, los dominios equivalentes a .com y .edu son .co.uk y .ac.uk("ac" es la abreviatura de "academic"
. Está también el dominio .us, organizado geográficamente por estados(por ejemplo, .ny.us se refiere al estado de New York). Ver el RFC 1480 para una descripción detallada del dominio .us.
2.2.8.5 Mapeando nombres de dominio a direcciones IP
El mapeado de nombres a direcciones, proceso denominado resolución de nombres de dominio, lo proporcionan sistemas independientes cooperativos, llamados servidores de nombres. Un servidor de nombres es un programa servidor que responde a peticiones de un cliente llamado procesador de nombres.
Cada procesador de nombres está configurado con el nombre del servidor que va a usar(y posiblemente una lista de servidores alternativos con los que contactar si el servidor primario no está disponible). Figura - Resolución de nombres de dominio muestra esquemáticamente cómo un programa utiliza un procesador de nombres para convertir el nombre de un host en una dirección IP. El usuario proporciona el nombre de un host, y al programa de usuario emplea una rutina de librería, llamada stub, para comunicarse con un servidor de nombres que resuelve el nombre del host en una dirección IP y se la devuelve al stub, que a su vez lo devuelve al programa principal. El servidor de nombres pude obtener la respuesta de su caché de nombres, su propia base de datos o cualquier otro servidor de nombres.
Figura: Resolución de nombres de dominio
2.2.8.6 Mapeando direcciones IP a nombres de dominio - Consultas con punteros
El DNS suministra el mapeado de nombres simbólicos a direcciones IP y vice versa. Mientras que en principio es algo sencillo buscar en la base de datos una dirección IP, dado su nombre simbólico, el proceso inverso no se puede hacer respetando la jerarquía. Por este motivo, existe otro espacio de nombres para el mapeado inverso. Se halla en el dominio in-addr.arpa ("arpa" porque Internet era originalmente la red de ARPA). Como las direcciones IP suelen escribirse en formato decimal con puntos, hay una capa de dominios para cada jerarquía. Sin embargo, debido a que los nombres de dominio tienen primero la parte menos significativa del nombre y el formato decimal con puntos los bytes más significativos primero, la dirección decimal se muestra en orden inverso. Por ejemplo, el dominio del DNS correspondiente a la dirección IP 129.34.139.30 es 30.139.34.129.in-addr.arpa. Dada una dirección IP, el DNS puede utilizarse para encontrar el nombre del host que sea su pareja. Una consulta de nombre de dominio para encontrar los nombres del host asociado a una dirección IP se llama "consulta con puntero".
2.2.8.7 Otros usos para el DNS
EL DNS está designado para ser capaz de almacenar una gran cantidad de información. Una de las más importantes es información del intercambio de correo, usada para el encaminamiento del correo electrónico. Esto aporta dos servicios: transparencia al reencaminar el correo a un host distinto del especificado y la implementación de pasarelas de correo, que pueden recibir correo electrónico y redirigirlo usando un protocolo diferente de aquel con el que lo reciben. Para más detalles, remitirse a SMTP y el DNS.
2.2.8.8 Referencias
Para más detalles sobre la implementación del DNS y el formato de mensajes entre servidores de nombres, ver DNS("Domain Name System"
. Los siguientes RFCs definen el estándar de DNS y la información que almacena.
* RFC 1032 - Guía de administrador de DNS
* RFC 1033 - Guía de las operaciones de administrador de DNS
* RFC 1034 - Nombres de dominio - Conceptos y servicios
* RFC 1035 - Nombres de dominio - Implementación y especificación
* RFC 1101 - Codificación DNS de nombres de red y de otros tipos
* RFC 1183 - Nuevas definiciones del DNS RR
* RFC 1706 - Registros de recursos DNS NSAP
Parte 4 prontoo