Simulación DNS
Con esta práctica veremos el protocolo DNS en acción y como simular el
funcionamiento de los Servidores de Dominios reales. DNS es mucho más complejo
que el siguiente ejemplo, pero éste debería ser suficiente para comprender los
fundamentos.
DNS es un servicio de directorio simple (como las antiguas guías telefónicas);
proporciona la dirección IP correspondiente a un nombre de Dominio y vice versa. Por
ejemplo, el nombre www.google.es está asociado a la dirección IP 216.58.211.228.
El ‘com’ es el llamado TLD (Top-Level Domain), ‘google’ es el “Second-Level Domain”
(SLD) and ‘www’ es el nombre de la máquina en ese Dominio. Los nombres DNS
pueden ser más complejos.
Los nombres son jerárquicos y de esa forma también los Servidores DNS. La base de
Datos que está detrás del servicio está distribuida entre estos servidores a través del
mundo, podemos verlo enhttp://www.root-servers.org.
En lo alto de la jerarquía hay 13 Servidores Raíz (en realidad no son máquinas
individuales, sino granjas de servidores). Estos tienen la información para alcanzar a los
servidores TLD, quienes a su vez tienen la información para alcanzar a los servidores
SLD y así.
Los llamados “Authoritative Servers” (Servidores Acreditados) conocen la información
exacta sobre la relación entre nombre/dirección en una zona. Un servidor raíz no
conocería la respuesta a la pregunta sobre un nombre o dirección en particular, el sólo
trasmite (pasa) la pregunta hacia un Servidor más acreditado. Pero cuando la pregunta
es resuelta satisfactoriamente, el servidor DNS puede cachear el dato de tal forma que
la próxima vez puede responder directamente al cliente.
La Base de Datos del DNS consiste en Registros de Recursos (Resource Records – RRs),
que están guardados en ficheros de zona en los servidores. Cada servidor es
responsable de una zona la cual es una parte de la totalidad del árbol DNS. Los ficheros
de zona empiezan con el registro SOA (Start of Authority), el cual contiene los
parámetros de la zona: el servidor de nombres primario, el email del administrador, el
número de serie para monitorizar (rastrear) las modificaciones y los parámetros de
tiempo para la sincronización de los otros servidores DNS (hay un mínimo de dos DNS
servers independientes para cada zona dada).
El registro NS proporciona el nombre del servidor DNS primario de la zona.
El registro MX (Mail eXchanger) guarda el nombre del servidor de correo del dominio.
El registro A guarda el par nombre/dirección de un nombre de dominio. En IPv6 este es
el registro AAAA, pero el propósito es el mismo.
Hay un comando con el mismo nombre en Windows y GNU/Linux, que puede usarse
para comprobar una pregunta DNS. Este comando es nslookup, el cual también tiene
un modo interactivo. Primero comprobaremos esto en un ordenador real luego lo
haremos con Packet Tracer.
Poner en marcha un CLI en Windows o un terminal en GNU/Linux o MacOs, y escribir:
“nslookup www.cisco.com”.
La salida muestra la dirección del servidor. En este caso 8.8.8.8. Este es el servidor Dns
de google, que son las DNS que están configuradas en mi ordenador. Después
aparecen las “Non-authoritative answer” que significa que la respuesta no viene
directamente de los servidores DNS de cisco.com. También podemos ver que el
servidor Web tiene algunos pseudónimos (canonical name). En algunos SO pueden
aparecer su dirección IPv6.
Ahora vamos a comprobar el modo interactivo del comando nslookup escribiendo el
comando y presionando Enter. Si escribimos un nombre de dominio, funciona de la
misma forma que si lo escribiésemos en la línea de comandos, pero en este modo
tenemos más opciones. Introduciendo “help” podemos ver muchos subcomandos. Por
ejemplo, podemos cambiar el servidor al que preguntar con el comando
“server ip_address”, o cambiar el tipo de pregunta.
Sin embargo, aunque hemos utilizado el comando “nslookup”, en GNU/LINUX y MacOs
el comando que se usa es “dig”. Aunque se puede usar “nslookup”, éste no está
completamente implementado.
Un ejemplo con “dig” sería:
Si nos fijamos tiene la misma información que “nslookup”: AUTHORITY 0 (la respuesta
no viene de los servidores DNS de cisco.com), los Canonical Names (CNAME) y más
información.
Estamos en la situación de que el servidor que nos da la dirección es un servidor que la
tiene “cacheada”. Pero queremos conocer la dirección IP real de un host. En este caso
el servidor necesita sólo saber una cosa: donde encontrar un servidor de nombres raíz,
ya que usando esta información podemos encontrar recursivamente el servidor
acreditado (Authoritative Server). Pero, ¿dónde podemos conseguir la IP de un
servidor raíz?
Para ello realizaremos el proceso con el comando “nslookup” y el “dig”.
Con “nslookup” en modo interactivo tecleamos “root”, y se selecciona “a.root-
servers.net” como el servidor por defecto. Ahora, preguntamos por otro sitio, por
ejemplo la página web de una universidad de Hungría: “www.bme.hu”. Esta vez
obtenemos una lista que contiene los servidores que proporcionan la zona “hu” (con
más precisión lo que obtenemos es la zona “hu.”, ya que el punto de partida es
siempre la zona raíz, identificada por el “.”, pero no es necesario indicarlo en este
caso).
Puede ocurrir que el servidor raíz no conozca la zona (aunque esto no es cierto):
En este caso debemos cambiar de servidor raíz, es mejor conocer la IP del A.ROOT-
SERVERS.NET y usarla para poder preguntarle.
Ahora no usaremos el comando “server” sin parámetros, sino que le pondremos la IP
del servidor raíz DNS A: “server 198.41.0.4”.
Probemos con el primer servidor DNS que aparece para hungría (a.hu –
193.239.148.1). Luego repetimos la pregunta: “www.bme.hu”.
Ya hemos obtenido el servidor de nombres para la zona “bme.hu” (ns.bme.hu). Si
ponemos como servidor el “152.66.116.1” y repetimos la pregunta (query), nos
debería dar la dirección IP requerida: 152.66.115.203 (del modo interactivo salimos
con “exit”).
Podemos comprobar que esa es la IP del servidor donde está alojada la página web
haciendo ping www.bme.hu y debe salir la misma IP de Servidor Web.
‘hu’ es el llamado TLD (Top-Level Domain), que nos lo proporciona un Servidor DNS
raíz (A.ROOT-SERVERS.NET). Los DNS que nos proporciona son: “a.hu”, “b.hu”, “c.hu”,
etc.
‘bme’ es el “Second-Level Domain” (SLD), que nos lo proporciona uno de los
anteriores. En nuestro caso, “a.hu”.
‘www’ es el nombre de la máquina en ese Dominio. Cuya IP nos la proporciona
“ns.bme.hu” (esta es la DNS del ISP), máquina que nos la ha dado “a.hu”.
Así, siguiendo los datos que nos dan los servidores, podemos encontrar la información
que necesitamos y podemos “cachear” los datos para futuras referencias. También
podemos ver que la respuesta a nuestra pregunta incluye la dirección IPv6, esto es
importante porque pronto el direccionamiento IPv6 y el DNS deben estar preparados
para ello.
Como curiosidad la página web es la siguiente.
Si ponemos la IP del Servidor Web en el navegador no sale la página.
Esto se produce porque el servidor no está dedicado a la página web en cuestión, sino
que tiene alojadas varias webs. Por lo que necesita además analizar la url para darnos
la web de un directorio específico.
Otra forma de ver toda la información es usar una web como www.ip-tracker.org y
añadir “/locator/ip-lookup.php?=bme.hu”. Saldrán muchos datos, como las IPv4, IPv6,
las DNS del ISP, continente, país, ciudad, etc.
En esta misma web podemos obtener mucha más información. Si nos vamos a “Whois
Lookup” y pones la IPv4 o IPv6 podremos ver la fecha de creación del dominio, cuando
se renovó, las personas de contacto, etc.
Por último intentaremos responder a la siguiente pregunta: ¿Cuál es la dirección IP de
un servidor de correos responsable para el dominio http://www.cisco.com?
En otras palabras, a qué servidor necesitamos conectarnos cuando queremos mandar
un correo destinado a
[email protected]. Para hacer esto necesitamos para la
pregunta (query) al tipo MX (Mail eXchanger) en nslookup, ya que ese tipo de registro
es el que guarda el nombre del servidor de correos de ese dominio:
Preguntaremos a las DNS públicas de Google. Luego pondremos el tipo de pregunta a
MX. Podemos hacerlo de dos formas: set querytype=MX o ‘q=MX’. Después de poner
es dominio cisco.com, obtendremos las máquinas MX. Si queremos saber la IP de una
de ellas debemos poner el tipo de pregunta a “A” (set q=A)y preguntar por el nombre
de la máquina.
Si hacemos lo anterior (el camino de las DNS hasta la IP del servidor web con dig
(Domain Internet Groper): en un terminal escribir “dig”, saldrán todos los servidores
root (raíz).
El campo AUTHORITY sale a 0 porque no es una respuesta Autoritativa.
Si queremos preguntar a uno de estos servidores por Hungría (hu):
dig @a.root-servers.net hu
Sale en AUTHORITY: 7, es decir 7 servidores Autorizativos, con sus nombres e IP’s.
Continuemos preguntando la zona “bme.hu” al servidor a.hu
Y nos salen los tres de antes como AUTHORITY. Preguntemos a ns.bme.hu por
www.bme.hu.
Apareciendo de nuevo nuestro registro A con la IP 152.66.115.203.
Para comprobar el registro de correo de cisco.com, ponemos:
Y si queremos saber la IP:
Como vemos en la imagen anterior, si a dig no se le indica el tipo de registro toma la
opción “A”.
Ahora, vamos a ver cómo podemos similar en Packet Tracer. Usaremos una topología
en la que hay un Servidor DNS raíz (a.root), uno de los servidores encargados
(authoritative) de la zona ‘.com’ (com.root), uno de los servidores DNS de cisco.com
(dns.cisco.com) y un servidor DNS de un ISP ficticio (dns.isp.com). Se configurará un
client DSL que alcanzará Internet a través del router del ISP y podremos examinar el
flujo de paquetes de las preguntas DNS (queries).
La topología es la siguiente:
Primero crearemos Internet. Para ello crearemos un “cluster”, un cluster es la
agrupación de elementos de Packet Tracert. En nuestro caso, el cluster tendrá un
router 2811 (al que llamaremos core – núcleo en inglés) con dos adaptadores WIC-2T
que tienen dos puertos series para WAN cada uno (total 4 puertos WAN). Cerraremos
las ranuras libres con un NM-Cover y dos WIC-Cover.
Primero pondremos nuestro router 2811 y le cambiamos el nombre y el nombre a
mostrar a “core”.
Después entramos en el modo gráfico y lo paramos para poder ponerle las dos tarjetas
WIC-2T y las cubiertas.
Quedando como en la imagen siguiente (y lo encendemos).
Para “simular” nuestro internet no necesitamos más que ese router, Con el crearemos
un Cluster. Lo primero es seleccionar el Router y luego, en la zona amarilla de la parte
de arriba pulsar “New Cluster”.
Cuando lo haya hecho, le damos doble click en el nombre y lo llamamos Internet.
Cogeremos tres router 2811, los pondremos alrededor de Internet, les pondremos dos
puertos WAN WIC-2T y los llamaremos de izquierda a derecha “router_a”,
“router_com” y “router_cisco.com”. Estos serán los routers de la raíz A (A.ROOT-
SERVERS.NET), el del TLD “.com” y el de la zona SLD “cisco.com”. Recordad que los
nombres se ponen con el comando “hostname”.
Conectemos los routers a Internet y creemos las redes de cada uno de ellos:
Para el router_a conectaremos su adaptador serial0/0/0 con internet mediante el
router que hay dentro del cluster por la interfaz serial0/0/0. A esa red la llamaremos
200.0.0.0/30, de tal forma que vamos a utilizar subredes. En este caso el router_a
tendrá la IP 200.0.0.1/30 y internet estará conectado al interfaz indicado que tendrá la
IP 200.0.0.2/30. El clock rate será 2000000.
Primero pondremos los cables.
Después haremos la configuración de los routers. En el CLI del “router_a”.
router_a>enable
router_a#conf term
router_a (config)#inter s0/0/0
router_a (config-if)#ip add 200.0.0.1 255.255.255.252
router_a (config-if)#clock rate 2000000
router_a (config-if)#no shut
router_a (config-if)#exit
router_a (config)#
Vamos a fijarnos en dos cosas. Primero el comando “clock rate 2000000”, parece que
devuelve un error, pero si vamos a la configuración gráfica, aparece la velocidad que
hemos puesto.
Segundo hemos creado una subred ya que la máscara es “255.255.255.252” que se
traduce en “11111111.11111111.11111111.11111100”, si contamos los “unos”son 30
por eso el “/30” de la red.
Si nos fijamos en el último octeto de la IP es “1”, pasado a binario sería “000000001”.
Como la máscara sólo coge los seis primeros bits de ese octeto, éste se dividiría en
“000000” y “01”. Por lo tanto en binario estaríamos en la subred: 200 => 128 + 64 + 8
(pesos en binario que se usan) => 11001000, el segundo octeto es cero 00000000, el
tercer octeto es cero 00000000 y del último que sólo cogemos 6 bits 000000. De esta
forma estamos en la red 110010000000000000000000000000, equipo 01.
Vamos a configurar el router del Cluster Internet. Damos click en el Cluster, se abre y
se ve el router. Nos vamos al CLI y configuramos como siempre.
core>enable
core#conf ter
core (config)#int s0/0/0
core (config-if)#ip add 200.0.0.2 255.255.255.252
core (config-if)#clock rate 2000000
core (config-if)#no shut
core (config-if)#exit
core (config)#
Cerramos el CLI y para salir del Cluster pinchamos en la parte de arriba “Back”.
De esta forma configuramos la red entre el router_a e Internet.
Las siguientes configuraciones serán:
router_com con Internet:
Interfaz s0/0/0 IP 200.0.0.5/30
Internet s0/0/1 IP 200.0.0.6/30
clock rate 2000000
router_cisco.com con Internet:
Interfaz s0/0/0 IP 200.0.0.9/30
Internet s0/1/0 IP 200.0.0.10/30
clock rate 2000000
Podemos comprobar si todo va bien haciendo ping a las IP’s de los routers. Al principio
fallarán, pero activando el RIP funcionará.
Sólo pondremos el ejemplo de RIP en el router_a, pero hay que hacerlo en todos los
Routers.
router_a#conf term
router_a (config)#router rip
router_a (config-router)#version 2
router_a (config-router)#network 200.0.0.0
router_a (config-router)#exit
router_a (config)#exit
router_a#
Ahora pondremos el router del ISP. Usaremos un 1841, que le pondremos un interfaz
WIC-2T.
Configuraremos:
El router se llamará “isp”, su interfaz s0/0/0 tendrá la IP 200.0.0.13/30 y se
conectará al “core” por la interfaz s0/1/1 con la IP 200.0.0.14/30.
Configuraremos el servidor “a.root”
Interfaz fa0
IP 198.41.0.4/29
GW 198.41.0.1/29
router_a
Interfaz fa0/0
IP 198.41.0.1
Añadir a RIP la red 198.41.0.0
Configuraremos el servidor com.root.
com.root
Interfaz fa0
IP 195.55.83.30/29
GW 195.55.83.25
router_com
Interfaz fa0/0
IP 195.55.83.30/29 195.55.83.25/29
Añadir a RIP la red 195.55.83.0
Configuraremos la zona “cisco.com”.
dns.cisco.com
Adaptador fa0
IP 173.37.146.41/29
GW 173.37.146.46
www.cisco.com
Adaptador fa0
IP 104.87.23.222/29
GW 104.87.23.217
router_cisco.com
Adaptador fa0/0
IP 173.37.146.46/29
Adaptador fa0/1
IP 104.87.23.217/29
RIP 173.37.0.0
RIP 104.0.0.0
Configuraremos en el router del isp la infraestructura que habíamos cresado en la
práctica anterior (SOHO). Lo único es que la página web no está en nuestro ISP, sino en
la zona de “cisco”.
dns.isp.com
Adaptador fa0
IP 213.46.246.54/29
GW 213.46.246.49
Router isp
Adaptador fa0/0
IP 213.46.246.49/29
Adaptador s0/0/0
IP 200.0.0.13/30
Adaptador fa0/1
IP 200.0.0.17/30
RIPv2
Network 200.0.0.0
Network 213.46.246.0
Antes de configurar el DHCP, vamos a fijarnos en la subred. El adaptador fa0/1 tiene la
IP 200.0.0.17/30. Si nos fijamos la máscara tiene 30 bits, lo que hace una subred donde
lo que nos importa es el último octeto del que nos quedamos con seis bits de máscara
y dos bits de hosts.
Como la IP termina en 17, tenemos en binario 000100 01, la subred
xxxxxxxx.xxxxxxxx.xxxxxxxx.000100 00 y este es el equipo 1. Por lo que la subred será
200.0.0.16/30. Así que excluiremos la IP 200.0.0.17/30 y daremos direcciones de la red
200.0.0.16/30 (sólo podrá dar una IP, la 200.0.0.18/30).
DHCP
isp (config)#ip dhcp excluded-address 200.0.0.17
isp (config)#ip dhcp pool Internet_Users
isp (config-dhcp)#network 200.0.0.16 255.255.255.252
isp (config-dhcp)#default-router 200.0.0.17
isp (config-dhcp)#dns-server 213.46.246.54
isp (config-dhcp)#exit
El servidor DNS que dará será el servidor del isp.
Ya sólo queda poner el router de “casa” y el PC. El router de casa se conectará con el
isp por el interfaz fa0/0 mediante dhcp y con el PC tendrá IP por el interfaz fa0/1
(192.168.1.1/24). Recordar que tenemos que configurar la Access List y el NAT (manual
anterior). Además no nos complicaremos instalando un Switch en el router.
El PC se conectará a este interfaz y su IP la obtendrá por dhcp.
Router de casa (soho):
soho(config)#ip dhcp excluded-address 192.168.1.1
soho(config)#ip dhcp pool casa
soho(config-dhcp)#network 192.168.1.0 255.255.255.0
soho(config-dhcp)#default-router 192.168.1.1
soho(config-dhcp)#dns-server 213.46.246.54
soho(config-dhcp)#exit
Crear la Access List:
soho (config)# access-list 1 permit 192.168.1.0 0.0.0.255
soho (config)# ip nat inside source list 1 interface fa 0/0
Configurar el protocolo NAT para la LAN.
soho (config)# int fa 0/1
soho (config-if)# ip nat inside
Configurar el protocolo NAT para la WAN.
Home_rtr (config-if)# int fa 0/0
Home_rtr (config-if)# ip nat outside
Home_rtr (config-if)# end
Con esto ya está configurada la parte de nuestro isp y de casa.
Ya podemos empezar a configurar las DNS’s de los Servidores.
Empezaremos por el servidor DNS raíz “a.root”
De forma gráfica configuraremos su DNS como él mismo (127.0.0.1)
En services-> DNS introduciremos los siguientes registros (poner en “ON” el servicio):
com NS ns.com
ns.com A 195.55.83.30 (IP del servidor com.root)
ns.root A 198.41.0.4 (IP del servidor a.root)
root SOA Primary Server Name: ns.root
Mail Box: nstld.verisign-gvs.com
Minimum TTL: 86400
Refresh Time: 1800
Retry Time: 900
Expiry Time: 604800
root NS ns.root
Servidor com.root:
DNS Server: él mismo (127.0.0.1)
En services-> DNS introduciremos los siguientes registros (poner en “ON” el servicio):
cisco.com NS ns3.cisco.com
com SOA Primary Server Name: ns.com
Mail Box: nstld.verisign-gvs.com
Minimum TTL: 86400
Refresh Time: 1800
Retry Time: 900
Expiry Time: 604800
com NS ns.com
ns.com A 195.55.83.30 (IP del servidor com.root)
ns.root A 198.41.0.4 (IP del servidor a.root)
ns3.cisco.com A 173.37.146.41 (IP del servidor dns.cisco.com)
root NS ns.root
Servidor dns.cisco.com: DNS vacío.
En services-> DNS introduciremos los siguientes registros (poner en “ON” el servicio):
cisco.com SOA Primary Server Name: ns3.cisco.com
Mail Box: postmaster.cisco.com
Minimum TTL: 86400
Refresh Time: 1800
Retry Time: 900
Expiry Time: 604800
cisco.com NS ns3.cisco.com
ns.root A 198.41.0.4 (IP del servidor a.root)
ns3.cisco.com A 173.37.146.41 (IP del servidor dns.cisco.com)
root NS ns.root
www.cisco.com A 104.87.23.222 (IP del servidor http www.cisco.com)
Servidor dns.isp.com: DNS 198.41.0.4 (IP a.root)
En services-> DNS introduciremos los siguientes registros (poner en “ON” el servicio):
com NS ns.com
ns.com A 195.55.83.30 (IP del servidor com.root)
ns.root A 198.41.0.4 (IP del servidor a.root)
root NS ns.root
Podemos ver que este servidor no tiene la información que necesitamos para llegar a
www.cisco.com (la IP de su servidor web), pero tiene información del servidor raíz
(ROOT) y del servidor .com. En realidad, es suficiente para un servidor DNS Caché
saber la dirección sobre un servidor Raíz (ROOT), pero Packet Tracer no gestiona la
zona ‘.’ de forma precisa, así que hemos tenido que introducir este ‘truco’ (añadir el
servidor de TLD para los ‘.com’.
Vamos a realizar un query simple en el PC. Abrimos un Command Prompt y escribimos
‘nslookup www.cisco.com’. Probablemente la primera vez no funcione; si esto ocurre,
lo intentamos de nuevo. La respuesta debe ser una ‘non-authoritative’ y nos dará la
dirección del sitio web. El servidor que nos ha dado la respuesta es nuestro isp
(dns.isp.com).
Podemos deducir que nuestro servidor ha preguntado a los otros servidores la
información que desconocía, proporcionándonos la información y guardándola en su
cache para futuras referencias. En nuestro dns.isp.com, vamos a Services->DNS y
pulsamos el botón ‘DNS cache’ para ver la información guardada:
La próxima vez el servidor podrá responder inmediatamente sin preguntar a los
demás. En un laboratorio real, podríamos usar otras utilidades DNS que podrían
darnos el tiempo necesario para una pregunta (query). Por ejemplo, ‘dig’ (Domain
Internet Groper).
La primera vez siempre llevará más tiempo que las siguientes, ya que la respuesta
desde la máquina local (la máquina DNS del ISP) es mucha más rápida que una
pregunta recursiva (recursive query).
Antes de seguir repasemos algunos registros de nuestro servidor DNS: dns.isp.com.
Como podemos ver (figura anterior) tenemos registros NS y A. Por eso nuestro cache
Server sólo necesita saber el nombre del Servidor y su IP. El registro NS nos da el
nombre, el registro A nos da la IP. Desafortunadamente, Packet Tracer, no soporta el
orden de los registros, pero aún así es fácil de comprender.
Antes de continuar, vamos a limpiar la cache de todos los servidores DNS pulsando el
botón ‘clear cache’.
En modo simulación y dejamos en los ‘event filters’ (botón ‘edit filters’) la casilla de
DNS.
Volvamos a realizar el query (nslookup www.cisco.com) y observemos el paquete
generado por el PC.
La parte interesante está en la capa 4, donde podemos ver que el protocolo DNS usa
UDP por defecto (hay que resaltar que puede usar el protocolo TCP, pero UDP es más
normal). El puerto de destino es 53 que es el reservado para DNS, así que tenemos un
firewall tenemos que tener ese puerto abierto.
Transmitamos el paquete pulsando ‘Capture/Forward’ unas cuantas veces hasta que
alcance el DNS configurado. No debe sorprendernos que no conteste inmediatamente,
pero intentemos obtener información de otros servidores. En este ejemplo, empieza
con ‘com.root’ pero en la realidad debería comenzar con el servidor raíz (ROOT), en la
cima de la jerarquía, pero como se mencionó Packet Tracer no gestiona bien la zona ‘.’
Así que pulsando unas cuantas veces podemos ver que ‘com.root’ no sabe la
respuesta, así que pregunta a ‘dns.cisco.com´, que el servidor ‘Authoritative’ para el
Nombre de Domininio solicitado. Debe conocer la dirección IP para el Nombre de
Dominio dado - si no lo sabe, el nombre ‘no existe’. La respuesta vuelve al servidor
‘com.root’ y luego vuelve al servidor ‘dns.isp.com, y finalmente el PC la obtendrá y la
guardará en su cache DNS.
En un PC Windows real podríamos observar esto, mediante el comando ‘ipconfig
/displaydns’, y se podría borrar la información con el comando ‘ipconfig /flushdns’.
Con un poco de paciencia, podemos seguir toda la simulación:
Iniciamos el proceso con el comando ‘nslookup www.cisco.com’ y el primer paquete
capturado es: el paquete que ‘sale’ del PC es una pregunta DNS por el puerto 1026
hacia el puerto 53, por la IP 192.168.1.2 (IP del PC) a la IP 213.46.246.54 (IP del DNS de
su ISP). Con el DNS Query preguntando por la IP del servidor www.cisco.com
El Segundo paquete corresponde a nuestro router, donde se realiza la traslación NAT
realiza la translación. De esta forma ‘salimos’ a Internet con la IP del router
(200.0.0.18) con el mismo destino (IP de nuestro servidor DNS y la misma pregunta
DNS). Aquí, ya tenemos la ‘mezcla’ de protocolos. Estamos en IP, cambiamos de
direcciones con NAT, pero sigue llevando la pregunta DNS. Aunque ahora lo
importante es poder ‘salir’ a Internet. Más adelante nos saltaremos muchos paquetes
de este tipo para no distraernos demasiado de nuestro objetivo: el protocolo DNS.
La siguiente parte es pasar por el DSL, el cableado del ISP y la llegada al router de
nuestro ISP.
El router de nuestro ISP (IP 200.0.0.18) se encargará de mandar el paquete a su
servidor DNS (IP 213.46.246.54).
La pregunta por www.cico.com llega al Servidor DNS del ISP. El Servidor DNS no
conoce la respuesta y se la pasa a la zona ‘.com’ (IP 195.55.83.30) con la misma
pregunta sobre www.cisco.com. Hay que destacar que el puerto desde donde salió la
pregunta en el PC, se sigue manteniendo (Src Port: 1026).
Esta pregunta pasa del servidor DNS del isp (dns.isp.com) a su router (isp), de su router
(isp) a Internet (core), de Internet (core) al router de la zona ‘.com’ (router_com) y del
router_com a la máquina DNS de la zona ‘.com’.
Como el servidor de la zona ‘.com’ no sabe la IP del servidor web www.cisco.com,
lanza la pregunta al DNS que se encarga de la zona ‘cisco.com’(IP 173.37.146.41).
De la máquina DNS ‘com.root’ vuelve al router de su zona (router_com), del
‘router_com’ pasa a Internet (core), de Internet (core) al router de la zona de ‘cisco’
(router_cisco), el DNS de cisco recibe la pregunta y contesta con la dirección IP de
www.cisco.com al servidor DNS de la zona ‘.com’ (IP 195.55.83.30).
En la figura donde pone (Outbound PDU Details), podemos ver que la respuesta va del
puerto 53 al puerto original 1026.
Ahora la respuesta debe volver al DNS de nuestro ISP (que fue el que inició la
pregunta). Pasaremos por el router de cisco, por Internet (core) hacia el router de la
zona ‘.com’. En esta zona pasaremos por su router (com_root) que nos llevará al DNS
de la zona ‘.com’, que ‘cacheará’ la respuesta para futuras preguntas. Volveremos al
router de la zona ‘.com’ hacia Internet (core), para llegar al router del ISP. Éste nos
llevará a la máquina DNS del ISP.
El servidor DNS del ISP recibirá la respuesta la cual la ‘cacheará’ para futuras
preguntas.
En la figura anterior se puede ver la IP del Servidor WEB www.cisco.com, así del sitio
que viene la respuesta: ‘ns.com’.
Ahora la información pasará de vuelta desde el DNS del ISP, por el router del ISP, el
cableado del ISP, nuestro DSL y nuestro router de ‘casa’ (soho).
Por fin llegará la respuesta a nuestro PC, al puerto 1026 (elegido aleatoriamente)
desde el 53 de la máquina DNS de nuestro ISP (UDP usado por el protocolo DNS).
En nuestro ‘command prompt’ podemos ver todo el proceso. Preguntamos con el
comando ‘nslookup www.cisco.com’ y recibimos la respuesta. Como vemos el
comando es fácil, el proceso es un ‘poco’ más largo.
Podemos ver las caches de los servidores de la zona ‘.com’ y de nuestro ISP.
Como ya tenemos la IP del Servidor Web, podemos navegar
Recordar que el proceso conlleva un paso más, pero que Packet Tracer no lo gestiona
bien y aunque lo hemos implementado con efectos educativos de la realidad, en
nuestra simulador no se ha realizado. El proceso es que del ISP se pasa al Servidor DNS
de la zona ‘.com’ (ya que buscamos la IP de un .com – www.cisco.com), pero el ‘.com’
no lo conoce, preguntaría al Servidor ROOT (paso que Packet Tracer no implementa) y
de ahí iríamos preguntando hacia debajo de la jerarquía, ‘cacheando’ las respuestas y
pasándoselas a los demás Servidores DNS.
Por último examinaremos los registros que guarda un Servidor DNS. Exploraremos el
Servidor DNS de cisco (dns.cisco.com) ya que es el más completo.
La configuración comienza con el registro SOA (Start Of Authority). Este registro es el
que tienen más información, ya que define al dominio como el dueño del mismo. Los
campos que contiene son:
Name (nombre): contiene el nombre del dominio, en este caso es cisco.com ya que es
el nombre completo del mismo.
Primary Server Name: contiene el nombre del Servidor DNS primario o Maestro para el
dominio. El administrador los datos del dominio aquí, y de otro (secundario o esclavo)
que sincronizarán sus bases de datos a través de un proceso denominado ‘zone
transfer’. La sincronización es periódica y tenemos que especificar el tiempo.
Refresh Time: especifica en segundos cuando conectar el secundario con el primario
para la sincronización de datos.
Retry Time: Si la conexión falla, el servidor secundario debe intentarlo de nuevo. Aquí
se especifica el tiempo para intentarlo de nuevo.
Expiry Time: Si el servidor maestro todavía no se puede sincronizar si el tiempo de
reintento pasa, el servidor secundario no será un servidor ‘Authoritative’ nunca más.
Minimum TTl: especifica el tiempo durante el cual los datos del registro SOA pueden
ser ‘cacheados’ en la parte de los servidores DNS clientes. Su propósito es reducir el
número de preguntas (queries).
Mail Box: la dirección de correo electrónico del administrador principal del DNS,
aunque aquí no se puede usar el símbolo ‘@¡’, ya que está reservado para otros
propósitos en el fichero de zona, así que consideraremos el primer punto separador ‘.’
como el separador.
Los registros NS y A son los más simples y ya hemos visto su funcionamiento. Uno nos
da el nombre del Servidor de Nombres (NS) y el otro de su dirección IP (A).
Para resumir el funcionamiento de estos registros. Volveremos a revisar nuestro
ejercicio:
El Servidor DNS de nuestro ISP (del cual tenemos su IP en nuestro ordenador), no s
servirá par encontrar los dominios de los que queremos sus direcciones IP. Éste
Servidor tiene la siguiente configuración.
com NS ns.com
ns.com A 195.55.83.30 (IP del servidor com.root)
root NS ns.root
ns.root A 198.41.0.4 (IP del servidor a.root)
Hay que volver a destacar que, debido a que Packet Tracer no gestiona de forma
‘totalmente’ real, hemos tenido que poner tanto la información de la zona raíz como la
de la zona ‘.com’. En la realidad sólo tendría la zona raíz.
Más adelante conforme vayamos preguntando por URL’s él irá ´cacheando´la
información y no preguntaría a los demás servidores.
Como hemos dicho, en la realidad, este servidor que no sabe la respuesta, preguntaría
a un servidor raíz (ROOT) ya que conoce su NS (ns.root) y su A (198.41.0.4).
El Servidor Raíz (ROOT) al ver que es una URL de un ‘com’, mandaría la pregunta al
Servidor encargado de la zona ‘.com’. Ya que en su configuración tienen el registro
para la zona ‘.com’ (en realidad tendría más información sobre otras zonas: ‘.org’,
‘.net’, ‘.gov’, etc.)
com NS ns.com
ns.com A 195.55.83.30 (IP del servidor com.root)
El Servidor DNS para la zona ‘.com’ deberá preguntar a ns3.cisco.com, ya que la URL
era www.cisco.com. También este servidor tendría más información sobre otros
dominios ‘.com’
cisco.com NS ns3.cisco.com
com SOA Primary Server Name: ns.com
Mail Box: nstld.verisign-gvs.com
Minimum TTL: 86400
Refresh Time: 1800
Retry Time: 900
Expiry Time: 604800
com NS ns.com
ns.com A 195.55.83.30 (IP del servidor com.root)
ns.root A 198.41.0.4 (IP del servidor a.root)
ns3.cisco.com A 173.37.146.41 (IP del servidor dns.cisco.com)
root NS ns.root
Por fin el servidor DNS de cisco, tiene la información sobre la IP de la máquina donde
está www.cisco.com y podrá informar sobre esta IP.
cisco.com SOA Primary Server Name: ns3.cisco.com
Mail Box: postmaster.cisco.com
Minimum TTL: 86400
Refresh Time: 1800
Retry Time: 900
Expiry Time: 604800
cisco.com NS ns3.cisco.com
ns.root A 198.41.0.4 (IP del servidor a.root)
ns3.cisco.com A 173.37.146.41 (IP del servidor dns.cisco.com)
root NS ns.root
www.cisco.com A 104.87.23.222 (IP del servidor http www.cisco.com)
Toda está información retornará a los Servidores DNS, que a su vez la retornarán a los
servidores que les preguntaron y/o ‘cachearan’ la información para futuras preguntas
sobre las mismas URL’s.
Packet Tracer soporta más registros (RR), como el registro CNAME que define
sinónimos (aliases) para un dominio.
Por ejemplo, www.cisco.com podría alcanzarse con el nombre ftp.cisco.com. Esto
podría servir si tenemos un servidor FTP instalado en la misma máquina.
El protocolo DNS tiene mucha más cosas que aprender, pero desafortunadamente (por
ahora) Packet Tracer sólo soporta lo básico que hemos visto. De todas formas es un
buen punto de partida para aprender el protocolo DNS.
