Durante varios años, los alumnos que han realizado la práctica propuesta de configuración del DNS, nos han preguntado ¿y qué debo hacer para que mi dominio sea visible en Internet?
Los pasos son los mimos que hace la empresa a la que le solicitamos, por ejemplo, el dominio ‘miempresa.es’ cuando disponemos de un servidor configurado adecuadamente para resolver los nombre de este dominio.
Si recordamos, en la práctica se pide (resumiendo) configurar un servidor DNS (bind) para que resuelva un subdominio propio del ‘eps.ua.es’, pongamos de ejemplo el ‘alu.eps.ua.es’. Si el servidor de nombre de la EPS tiene la dirección IP 100.10.1.1 (me la he inventado), ¿qué pasos deberíamos ejecutar para que equipos ajenos a nuestra red pudieran resolver los nombre del dominio ‘alu.eps.ua.es’?
Vamos a ver si, entre todos, llegamos a la solución. Debemos indicar uno o más de los siguientes puntos:
- Configuración necesaria en el servidor del dominio ‘es’
- COnfiguración necesaria en el servidor del dominio ‘ua.es’
- Configuración necesaria en el servidor del dominio ‘eps.ua.es’
- Explicación del funcionamiento
Las aportaciones también pueden ser argumentaciones en contra, a favor o para completar las configuraciones y/o explicación de los compañeros.
19 replies on ““El enganche””
Según he realizado en la práctica, tendríamos que configurar los archivos named.conf correspondientes en cada uno de los servidores de dominio. Uno de ellos podría ser el que correspondería a eps.ua.es, al que habría que añadir los siguientes datos:
Zone “eps.ua.es” {
Type master;
File “/home/knoppix/bind/db.epsuaes”
};
El fichero db.epsuaes tendría que contener la información de las máquinas de ese dominio, con lineas de la forma:
;Direcciones de las maquinas de la subred
Virtual1 IN A 192.168.1.66
Tendríamos que repetir pasos de la forma similar en cada uno de los servidores dns “escalandolo” hacia arriba.
Enrique Barreto Ruiz
Intentando empezar desde arriba, he encontrado información sobre la configuración de los servidores DNS raíz, y me parece interesante compartirla:
En http://www.internic.net/zones/ y más concretamente en http://www.internic.net/zones/named.root encontramos los registros NS que asocian el dominio raíz (.) a los 13 servidores de nombres (etiquetados con las letras A..M), así como los registros A y AAA respectivos que asocian sus direcciones IPv4 e IPv6. Algunos de estos servidores están distribuidos en hasta 52 máquinas diferentes (ver http://www.root-servers.org/)
En http://www.internic.net/zones/root.zone están los registros NS que asocian el dominio ES. a 8 servidores de nombres que almacenan la información de dicho dominio:
ES. NS NS3.NIC.FR.
ES. NS SUN.REDIRIS.ES.
ES. NS SUNIC.SUNET.SE.
ES. NS NS.UU.NET.
ES. NS NS1.NIC.ES.
ES. NS NS-EXT.NIC.CL.
ES. NS NS1.CESCA.ES.
ES. NS NS2.NIC.ES.
Así como los respectivos registros A y AAAA:
NS3.NIC.FR. A 192.134.0.49
NS3.NIC.FR. AAAA 2001:660:3006:1:0:0:1:1
SUN.REDIRIS.ES. A 130.206.1.2
SUNIC.SUNET.SE. A 192.36.125.2
SUNIC.SUNET.SE. AAAA 2001:6B0:7:0:0:0:0:2
NS.UU.NET. A 137.39.1.3
NS1.NIC.ES. A 194.69.254.1
NS-EXT.NIC.CL. A 200.1.123.14
NS1.CESCA.ES. A 84.88.0.3
NS2.NIC.ES. A 193.146.142.168
Así pues, supongo que en el fichero de zona de estos 8 últimos servidores del dominio ‘es’ deberían aparecer los registros que asociaran el dominio UA.ES. al servidor que administre esa zona, por ejemplo:
UA.ES. NS NS1.UA.ES
…
NS1.UA.ES A 100.0.0.1
El servidor de UA.ES delegaría en el de EPS.UA.ES y éste de manera similar en ALU.EPS.UA.ES
Debo advertir que aún no he hecho la práctica, y por lo tanto no me he peleado aún con la configuración de DNS y es bastante posible que esté totalmente equivocado 🙁 pero aun así espero que os sirva por lo menos como apunte lo de la configuración de los servidores raíz
Un saludo
Con lo que dice Ignacio (#1), tendríamos que el servidor donde se insertan esos datos, realiza la resolución él y se presupone que tiene la autoridad de resolución.
Enrique (#2) va más encaminado (muy bien, de hecho) pero falta indicar dónde se introduce la información y, ¿alguien puede proponer un extracto del fichero de configuración de los equipos a tocar? Enrique ha comentado el punto 4 (explicación del funcionamiento). Falta que me digáis qué se introduce y en qué fichero de cada servidor de cada nivel. Los fichero de configuración son los mismos en todos los servidores, no os creáis que cambian con respecto a los que estáis usando en prácticas.
Para facilitar las cosas, supongamos lo siguiente:
Lo que llamo “el enganche” es que, una vez tenemos, por ejemplo, los dominios alu1.eps.ua.es y alu2.eps.ua.es correctamente configurados, ¿qué tendríamos que hacer para que los clientes de alu1 puedan resolver las peticiones de resolución del dominio alu2 (por ejemplo, mipc.alu2.eps.ua.es) sin tocar la base de datos de resolución del servidor del dominio alu1.eps.ua.es ya que la autoridad de resolución para alu2.eps.ua.es le compete a otro servidor?
Si respondemos a esta pregunta, también estamos resolviendo que cualquiera de Internet pueda resolver peticiones recursivas para alu2.eps.ua.es (suponiendo que eps.ua.es también esté “enganchado”)
Creo que te refieres a cómo hacer para resolver las direcciones de nombres que no corresponden al servidor que controla la zona alu1.eps.ua.es. Si es así, en la configuración del servidor, concretamente en el fichero “named.conf,options” tenemos que modificar la sección “forwarders” de esta forma:
forwarders{
xx.xx.xx.xx;
…
xx.xx.xx.xx;
};
Donde xx.xx.xx.xx representan las direcciones ip de los servidores de nivel superior que en este caso son los de la eps.
De esta forma cualquier petición que el servidor de la zona alu1 no pueda resolver las enviará hacia esos dns.
#4, no, eso es lo que se hace para que tu cliente que solicita a tu servidor la resolución de un dominio que éste no conoce, se pueda conseguir.
A lo que me refiero es a las peticiones de clientes de otros servidores distintos al tuyo para que pueda resolverse tu dominio desde esos clientes. Si queréis otro ejemplo más claro y que mencioné en clase:
Empresa pública que gestiona el dominio ‘.es‘, crea los dominios ‘ua.es‘ y ‘upv.es‘ (bajo petición). ¿Qué se debe hacer para que los clientes DNS, puedan resolver tanto el dominio ua.es como el upv.es? (Y sin que conozcan directamente la IP de los servidores de DNS de ambos dominios y le pregunten).
Enrique en #2 ha explicado muy bien el funcionamiento e, incluso, ha dada información de qué deben saber los distintos servidores. Lo que os pido ahora es que me digáis qué se pone exactamente (son 2 registros por dominio)
Cuando una aplicación (cliente) necesita resolver el nombre completo de un host envía un requerimiento al servidor de nombres configurado en el sistema . A partir de ese momento se desencadena el proceso de resolución del nombre:
1. El servidor de nombres inicial consulta a uno de los servidores raíz (cuya dirección IP debe conocer previamente).
2. Este devuelve el nombre del servidor a quien se le ha delegado la sub-zona.
3. El servidor inicial interroga al nuevo servidor.
4. El proceso se repite nuevamente a partir del punto 2 si es que se trata de una sub-zona delegada.
5. Al obtener el nombre del servidor con autoridad sobre la zona en cuestión, el servidor inicial lo interroga.
6. El servidor resuelve el nombre correspondiente, si este existe.
7. El servidor inicial informa al cliente el nombre resuelto.
Extraido de http://blog.smaldone.com.ar/2006/12/05/como-funciona-el-dns/
Entendido.
Para hacer lo que dices el servidor de nombres del dominio “.es” en el caso que propones debe incluir efectivamente 2 registros en el archivo que controla la zona “.es” por cada subdominio:
ua IN NS dns.ua.es.
upv IN NS dns.upv.es.
.
.
dns.ua.es. IN A xx.xx.xx.xx
dns.upv.es. IN A xx.xx.xx.xx
Los primeros dos le dicen al servidor que debe delegar en esos servidores para esos subdominios y los otros dos resuelven las direcciones para ellos.
De esta forma peticiones por alguno de los dos subdominios de “.es” que le lleguen al servidor son delegados a los servidores DNS que ahora controlarán cada subdominio.
Más claro en: http://www.zytrax.com/books/dns/ch9/delegate.html
Después de haberme peleado un poco con la práctica y habiendo llegado a que hay que resolver los nombres de ambos dominios ua, upv y que hay que dar las direcciones de ambos dominios para poder resolverlos, coincido con Eduardo Barambio.
Como el moderador ha asegurado que no es muy distinto de lo que hacemos en la práctica, yo había utilizado esto en mi práctica y me funciona correctamente, por lo tanto según lo hecho en la práctica también coincido con él en que hay que poner:
ua IN NS dns.ua.es.
upv IN NS dns.upv.es.
dns.ua.es. IN A xx.xx.xx.xx
dns.upv.es. IN A xx.xx.xx.xx
Bueno, el moderador no lo decía en el enunciado tal vez para que fuéramos nosotros los que identificáramos que es lo del “enganche”. En mi anterior comentario ya lo mencionaba cuando decía que el servidor “delega” el subdominio por debajo de la zona que controla.
Es decir, a eso se le llama delegación de la completa responsabilidad de un subdominio a otro DNS.
#9 Exacto Eduardo. En clase vimos claramente cómo fluye la información de abajo hacia arriba cuando realizamos una consulta.
También hablamos de la delegación de autoridad, pero cuando vimos la configuración de un DNS, en ningún momento estudiamos como se realiza ésta y es importantísima en la arquitectura en árbol del DNS ya que es la que permite que los datos están descentralizados y la que garantiza el flujo de información visto en la resolución (tal y como se explicó en el comentario #2)
Esto es lo que quería que vierais y, lo más importante, que fuerais conscientes de que si quisierais que la configuración que hagáis en practicas estuviera dentro del engranaje del DNS (cuando está correctamente funcionando), lo que falta no lo tenéis que realizar vosotros, sino quien os delega la autoridad de la zona.
Es decir, la práctica , aunque resuelve dominios inventados, es una práctica completa.
Quería aportar lo que ocurrió la última vez que fallaron los servidores DNS de mayor nivel del dominio .es (los del ESNIC).
Para los que intentarán resolver una dirección .es desde fuera de españa, les sería imposible acceder. Para los que realizaran peticiones desde España (la mayoría), seguramente no tendrían demasiados problemas, al menos para lugares de frecuente visita entre los internautas. Esto es debido a que los ISP que daban acceso a esos usuarios, disponian de sus propios DNS, en cuyas cache se encontrarían las ocurrencias nombre-IP más habituales.
Hola,
Aunque no está enlazado con el tema de la delegación de autoridad en DNS, si tiene que ver con servidores DNS y quería lanzar una pregunta en este blog…
Si accedeis en el navegador a http://realacademiaespañola.es/ funciona!, si os fijais no pone nada como “espanyola” o “espanola”, sino escrito correctamente, “española”
La pregunta es… por qué funciona? cómo? que pasos tiene que dar un administrador del servidor de DNS para configurar este tipo de dominios?
Más ejemplos:
日本語.jp, 読ませ大賞.jp
©.com
stockholms.läns.museum
عربي.com
Ahi queda
Saludos
Gracias por el comentario Juan (#12). Muy interesante el apunte y es algo que comentamos en clase. Hablamos sobre los nuevos dominios este tipo de carácteres (además de los acentuados).
Quién se anima y busca la solución.
Un dominio multilingüe es aquel dominio que dispone de acentos y caracteres comunes de las lenguas derivadas del latín (castellano, catalán, gallego, francés, etc…). Dichos caracteres son à, á, è, é, í, ï, ò, ó, ú, ü, ñ, ç, l·l.
IDN (Nombre de Dominio Internacionalizado), Acrónimo procedente del inglés cuyo significado es, Internationalized Domain Name (IDN). Se trata del estándar que permite codificar caracteres internacionales en el DNS.
La codificación ACE permite incorporar caracteres internacionalizados en aplicaciones diseñadas para trabajar solamente con caracteres ASCII. El principal uso de la codificación ACE es incorporar dominios con caracteres internacionales en el DNS. Así un dominio como “cdmón.es” se codifica en ACE como “xn--cdmn-sqa.es”.
Configuración de un Servidor de Nombres para un dominio IDN:
Instrucciones generales
La configuración de un servidor de nombres para responder por un dominio IDN no difiere mayormente de la necesaria para un dominio no IDN. Sólo se agrega un paso adicional, que consiste en conocer la codificación ACE del dominio IDN en cuestión.
Por ejemplo, para el dominio IDN ñandú.cl, la codificación IDN es xn--and-6ma2c.cl y es éste último dominio es el que se utiliza en la configuración y diagnóstico.
Existen herramientas que permiten conocer la codificación ACE para un dominio IDN, por ejemplo aquí: http://www.nic.cl/cgi-bin/idntool.pl
BIND
Configuración de un primario:
Los pasos para configurar un primario para un dominio IDN son:
1. Obtener la codificación ACE para el dominio
2. Agregar en la configuración de BIND (archivo named.conf), las siguientes instrucciones recomendadas:
// Configuración dominio ñandú.cl
zone “xn--and-6ma2c.cl” {
type master;
file “master/ñandú.cl.zone”;
allow-transfer {
none;
};
};
Configuración de un secundario
Los pasos para configurar un secundario para un dominio IDN son:
1. Obtener la codificación ACE para el dominio
2. Agregar en la configuración de BIND (archivo named.conf), las siguientes instrucciones recomendadas:
// Esclavo para dominio ñandú.cl
zone “xn--and-6ma2c.cl” {
type slave;
file “slaves/ñandú.cl.zone”;
masters {
ip.del.mae.stro;
};
allow-transfer {
none;
};
};
Datos obtenidos de varias fuentes.
Como mi compañero comenta esto es debido a los dominios multilingües,
los cuales en la barra de direcciones figura de
forma correcta lo único es que hay que hacer es una conversión. ejemplo:
“cañadespaña.es” a “xn--caadespaa-m6ag.es”
Todo esto es debido a IDN(Nombre de dominio internacionalizado):
Los nombres de dominio internacionalizados (IDN) son direcciones Web
escritas en su propio idioma. Hasta ahora, los clientes de correo
electrónico y los navegadores no admitían nombres de dominio
internacionalizados.
Por ejemplo, el IDN eñe.org, quedaría: xn--ee-zja.org
Bind:
zone “xn--ee-zja.org” {
type master;
file “eñe.org”;
};
El contenido del fichero de zona eñe.org no difiere de otro dominio cualquiera:
$TTL 172800 ; 2 days
@ IN SOA ns1.example.com. hostmaster.example.com. (
2008102804 ; serial number YYYYMMDDNN
36000 ; refresh R10 hours
7200 ; retry 2 hours
1209600 ; expire 2 weeks
172800) ; min ttl 2 day
NS ns1.example.com
NS ns2.example.com
MX 10 mailhost.xn--ee-zja.org.
mailhost A 10.0.0.1
www A 10.0.0.2
Tinydns:
En el fichero data:
.xn--ee-zja.org::ns1.example.com
.xn--ee-zja.org::ns1.example.com
@xn--ee-zja.org:10.0.0.1:mailhost.xn--ee-zja.org:10
+www.xn--ee-zja.org:10.0.0.2
http://www.forosdelweb.com/archive/index.php/f-93-p-2.html
http://www.cdbarra.com/servidor-dns/dominios-multilingues.html
http://www.forosdelweb.com/f93/cuales-son-verdaderos-dominios-multilinguees-541224/
Voy a añadir un tema, aunque no tiene nada que ver con el propuesto, pero si con el DNS. Y es las diferencias entre el OpenDNS y el DNS. Ya que se dice que es mucho más rápido, y además, que casi todos los servidores DNS de los ISP no reflejan los cambios sino hasta varias horas, o días incluso, después de haberlos hecho, ignorando el valor TTL que nuestro DNS maneje.
OpenDNS es notablemente más rápido ya que manejan un cache grande, dando tiempos de respuesta muy buenos. Vale aclarar que OpenDNS si respeta los valores TTL que cada dominio haya definido. OpenDNS tiene varios datacenters distribuidos en USA y Europa balanceando la carga según la cercanía geográfica de los clientes, si alguno de estos queda fuera de linea el tráfico sea dirigido hacia otro datacenter, la posibilidad de que todo OpenDNS quede fuere parecen ser pocas.
OpenDNS ofrece un servicio de filtrado de sitios clasificados en 50 categorías y contra sitios de phishing, lo interesante es que la misma comunidad de OpenDNS son quienes van clasificando los sitios web. Se puede elegir entre varios filtros comunes o bien crear uno propio. En el siguiente enlace, nos informa de como usar OpenDNS: http://es.corank.com/tech/framed/guia-bsica-Dns-y-Opendns.
Entre las ventajas tiene el OpenDNS sobre DNS son:
– Detecta sitios fraudulentos.
-Tiene servidores más grandes (todo lo tiene en la cache propia), por lo cual no requiere solicitar páginas a otros servidores DNS, todo lo maneja internamente.
-Las peticiones a sus servidores (tienen en todo el mundo) son direccionadas inteligentemente al servidor que sea mas próximo a tu conexión.
-En caso de equivocaciones del tipo http://www.google.cm , corrige la dirección automáticamente.
El registro NS identifica a servidores DNS.
Se usa para dar la lista de servidores de la zona y para delegar subzonas a
otros servidores. Por ejemplo, los registros siguientes dan la lista de servidores
para la zona editorial.es:
Editorial.es. IN NS Servidor.editorial.es
IN NS Segundo.editorial.es
Supongamos que tenemos una subzona llamada andalucía y que queremos
delegar en un servidor llamado malaga.andalucia.editorial.es. Tenemos
que incluir los siguientes registros:
Andalucia.editorial.es IN NS Malaga.andalucia.editorial.es
Malaga.andalucia.editorial.es IN A 194.33.8.12
El registro de tipo A es necesario para evitar un bucle en el proceso de
resolución.
http://www.netpecos.org/docs/dns/dns.pdf
Aquí va lo que creo que es una solución al problema planteado sobre “el enganche”, haciendo una pequeña descripción sobre la arquitectura del DNS como apoyo.
Arquitectura del DNS
El sistema DNS funciona principalmente en base al protocolo UDP. Los requerimientos se realizan a través del puerto 53.
El sistema está estructurado en forma de “árbol“. Cada nodo del árbol está compuesto por un grupo de servidores que se encargan de resolver un conjunto de dominios (zona de autoridad). Un servidor puede delegar en otro (u otros) la autoridad sobre alguna de sus sub-zonas (esto es, algún subdominio de la zona sobre la que él tiene autoridad). Un subdominio puede verse como una especialización de un dominio de nivel anterior. Por ejemplo, “smaldone.com.ar” es un subdominio de “com.ar“, que a su vez lo es del TLD “ar“.
Los servidores con autoridad sobre los TLD son los llamados “root servers” (o “servidores raíz“) del sistema. Estos son fijos, ya que rara vez cambian, siendo actualmente 13.
Tomemos como ejemplo el dominio “com.ar“. Este dominio pertenece al TLD “ar“.
Los servidores con autoridad sobre el dominio “ar” son:
ns-ar.ripe.net
merapi.switch.ch
uucp-gw-1.pa.dec.com
uucp-gw-2.pa.dec.com
ns.uu.net
ns1.retina.ar
athea.ar
ctina.ar
En tanto que los servidores con autoridad sobre “com.ar” son:
merapi.switch.ch
relay1.mecon.gov.ar
ns.uu.net
ns1.retina.ar
athea.ar
ctina.ar
Podemos ver que ns.uu.net, ns1.retina.ar, athea.ar y ctina.ar tienen autoridad tanto sobre “com.ar” como sobre “ar“.
El proceso de resolución de nombres
Cuando una aplicación (cliente) necesita resolver un FQHN envía un requerimiento al servidor de nombres configurado en el sistema (normalmente, el provisto por el ISP). A partir de entonces se desencadena el proceso de resolución del nombre:
1.El servidor de nombres inicial consulta a uno de los servidores raíz (cuya dirección IP debe conocer previamente).
2.Este devuelve el nombre del servidor a quien se le ha delegado la sub-zona.
3.El servidor inicial interroga al nuevo servidor.
4.El proceso se repite nuevamente a partir del punto 2 si es que se trata de una sub-zona delegada.
5.Al obtener el nombre del servidor con autoridad sobre la zona en cuestión, el servidor inicial lo interroga.
6.El servidor resuelve el nombre correspondiente, si este existe.
7.El servidor inicial informa al cliente el nombre resuelto.
Ilustremos esto con un ejemplo concreto. Supongamos que el navegador necesita resolver el nombre “blog.smaldone.com.ar“.
1.El sistema tiene configurado el servidor de nombres 200.49.156.3 (perteneciente al proveedor argentino Fibertel). Por lo tanto envía a éste el requerimiento de resolver “blog.smaldone.com.ar“.
2.El servidor de 200.49.156.3 envía la consulta root server 198.41.0.4.
3.198.41.0.4 le informa que el servidor con autoridad sobre “ar” es athea.ar, cuya dirección IP es 200.16.98.2. (En realidad, informa la lista de todos los servidores con tal autoridad, pero para simplificar el ejemplo tomaremos solamente uno.)
4.200.49.156.3 envía nuevamente el requerimiento a athea.ar (el cual, recordemos, también tiene autoridad sobre “com.ar“).
5.athea.ar responde que la autoridad sobre smaldone.com.ar la tiene ns1.mydomain.com cuya dirección IP es 64.94.117.213.
6.200.49.156.3 envía ahora la consulta a ns1.mydomain.com.
7.ns1.mydomain.com informa que la dirección IP de “blog.smaldone.com.ar” es 208.97.175.41.
8.Finalmente, 200.49.156.3 devuelve este resultado a la aplicación que originó la consulta.
Hola a todos, aquí os dejo lo que creo que es una posible solución al problema de “el enganche” pero con otro ejemplo, además de dar una pequea explicación de la arquitectura DNS como apoyo.
Arquitectura del DNS
El sistema DNS funciona principalmente en base al protocolo UDP. Los requerimientos se realizan a través del puerto 53.
El sistema está estructurado en forma de “árbol“. Cada nodo del árbol está compuesto por un grupo de servidores que se encargan de resolver un conjunto de dominios (zona de autoridad). Un servidor puede delegar en otro (u otros) la autoridad sobre alguna de sus sub-zonas (esto es, algún subdominio de la zona sobre la que él tiene autoridad). Un subdominio puede verse como una especialización de un dominio de nivel anterior. Por ejemplo, “smaldone.com.ar” es un subdominio de “com.ar“, que a su vez lo es del TLD “ar“.
El siguiente diagrama ilustra esto a través de un ejemplo:
Los servidores con autoridad sobre los TLD son los llamados “root servers” (o “servidores raíz“) del sistema. Estos son fijos, ya que rara vez cambian, siendo actualmente 13.
Tomemos como ejemplo el dominio “com.ar“. Este dominio pertenece al TLD “ar“.
Los servidores con autoridad sobre el dominio “ar” son:
ns-ar.ripe.net
merapi.switch.ch
uucp-gw-1.pa.dec.com
uucp-gw-2.pa.dec.com
ns.uu.net
ns1.retina.ar
athea.ar
ctina.ar
En tanto que los servidores con autoridad sobre “com.ar” son:
merapi.switch.ch
relay1.mecon.gov.ar
ns.uu.net
ns1.retina.ar
athea.ar
ctina.ar
Podemos ver que ns.uu.net, ns1.retina.ar, athea.ar y ctina.ar tienen autoridad tanto sobre “com.ar” como sobre “ar“.
El proceso de resolución de nombres
Cuando una aplicación (cliente) necesita resolver un FQHN envía un requerimiento al servidor de nombres configurado en el sistema (normalmente, el provisto por el ISP). A partir de entonces se desencadena el proceso de resolución del nombre:
1.El servidor de nombres inicial consulta a uno de los servidores raíz (cuya dirección IP debe conocer previamente).
2.Este devuelve el nombre del servidor a quien se le ha delegado la sub-zona.
3.El servidor inicial interroga al nuevo servidor.
4.El proceso se repite nuevamente a partir del punto 2 si es que se trata de una sub-zona delegada.
5.Al obtener el nombre del servidor con autoridad sobre la zona en cuestión, el servidor inicial lo interroga.
6.El servidor resuelve el nombre correspondiente, si este existe.
7.El servidor inicial informa al cliente el nombre resuelto.
Ilustremos esto con un ejemplo concreto. Supongamos que el navegador necesita resolver el nombre “blog.smaldone.com.ar“.
1.El sistema tiene configurado el servidor de nombres 200.49.156.3 (perteneciente al proveedor argentino Fibertel). Por lo tanto envía a éste el requerimiento de resolver “blog.smaldone.com.ar“.
2.El servidor de 200.49.156.3 envía la consulta root server 198.41.0.4.
3.198.41.0.4 le informa que el servidor con autoridad sobre “ar” es athea.ar, cuya dirección IP es 200.16.98.2. (En realidad, informa la lista de todos los servidores con tal autoridad, pero para simplificar el ejemplo tomaremos solamente uno.)
4.200.49.156.3 envía nuevamente el requerimiento a athea.ar (el cual, recordemos, también tiene autoridad sobre “com.ar“).
5.athea.ar responde que la autoridad sobre smaldone.com.ar la tiene ns1.mydomain.com cuya dirección IP es 64.94.117.213.
6.200.49.156.3 envía ahora la consulta a ns1.mydomain.com.
7.ns1.mydomain.com informa que la dirección IP de “blog.smaldone.com.ar” es 208.97.175.41.
8.Finalmente, 200.49.156.3 devuelve este resultado a la aplicación que originó la consulta.