Protocolo DNS

Instituto Tecnológico de Informática

Tecnicatura en Redes y Telecomunicaciones

Año 2010

Pablo Volpe

Nombre de Archivos:

Dossier_DNS.doc
Presentacion_DNS.ppt
Protocolo DNS
(Domain Name Service / System)
(Servicio / Sistema de Nombre de Dominio)

Introducción
Es un protocolo de la pila de protocolos TCP/IP, ubicado en la capa de aplicación del Modelo OSI
Su función principal es la de Resolver de nombres de dominio. Está definido en el RFC 1034 y RFC 1035
desde 1987.
Utiliza los puertos 53 UDP y 53 TCP.

Reseña histórica
DNS fue diseñado inicialmente, ante necesidad de recordar fácilmente los nombres de todos los
servidores conectados a Internet. Antes de la implementación de DNS, Stanford Research Institute,
utilizaba un archivo HOSTS para referenciar todos los nombres de dominios conocidos. Ante esto, en
1983 Paul Mockapetris desarrolló una primera versión de DNS (Definido en los RFCs 822 y 833),
evolucionando en 1987 hacia el DNS actual. En 1984 se desarrolló la primera versión de un DNS bajo
UNIX, al que se le denominó BIND.

Ubicación de DNS en la pila de protocolos TCP/IP

Teórico con respecto a la funcionalidad de DNS

El servicio de nombres de dominio, es una base de datos distribuida, con información que se usa para
traducir los nombres de dominio, fáciles de recordar y usar por las personas, en direcciones IP que es la
forma en la que las máquinas pueden encontrarse en Internet. Dicha información se almacena en forma de
Registros (RR)

Nombres de dominio

El DNS basa su funcionamiento en un espacio de nombres que responde a una arquitectura jerárquica que
se asemeja a la estructura jerárquica de los sistemas de archivos de UNIX, la cual se representa con un
árbol invertido. El tope de esta jerarquía se representa por un punto “.” y cada nodo del árbol, en general,
representa una partición de la base de datos. Cada una de estas particiones es llamada dominio, los cuales
pueden a su vez ser divididos en subdomains subdominios.

Un nombre de dominio consiste en dos o mas etiquetas separadas por puntos cuando se las escribe en
forma de texto. Por ejemplo, www.google.com.uy o maps.google.com

A la etiqueta ubicada más a la derecha se donomina Dominio de Nivel Superior (TLD). Ej.: .uy en
www.google.com.uy o .com en maps.google.com
Existen TLD de dos tipos:
Territoriales (ccTLD - Country Code Top Level Domain): .uy - .ar - .br
Globales ( gTLD - Global Top Leve Domain): .com - .net - .tv - .org - .gub - .mil

Cada etiqueta a la izquierda especifica una subdivisión o subdominio.

El último nivel es denominado “Host Name”, que es el nombre de un host conformado por una sola
"palabra" (formada por letras, números y guiones). Ej. "www".

Fully Qualified Host Name (FQHN): Es el “nombre completo” de un host. Está formado por el hostname,
seguido de un punto y su correspondiente nombre de dominio. Por ejemplo, “maps.google.com“

En teoría, esta subdivisión puede tener hasta 127 niveles, y cada etiqueta contener hasta 63 caracteres,
pero restringido a que la longitud total del nombre del dominio no exceda los 255 caracteres, aunque en la
práctica los dominios son casi siempre mucho más cortos.

En el DNS no existe una base de datos central con toda la información de los hosts de Internet. Por el
contrario la información es distribuida entre cientos de servidores de nombres (name servers). Esto
permite controlar por segmentos toda la base de datos en general, logrando que la información de cada
uno de estos segmentos este disponible a través de toda la red utilizando un esquema cliente - servidor.
Los programas llamados Name Servers (servidores de nombres) forma la parte del servidor en el
mecanismo cliente - servidor de DNS. Los name servers contienen la información de un segmento de la
base de datos y la ponen a disposición de los clientes.
Los clientes son llamados Resolvers, los cuales son rutinas de librería que crean preguntas y las envían a
través de la red a los servidores.

El DNS se utiliza para distintos propósitos. Los más comunes son:

Resolución de nombres: Dado el nombre completo de un host obtener su dirección IP.
Resolución inversa de direcciones: Es el mecanismo inverso al anterior. Consiste en, dada una dirección
IP, obtener el nombre asociado a la misma.
Resolución de servidores de correo: Dado un nombre de dominio (por ejemplo gmail.com) obtener el
servidor a través del cual debe realizarse la entrega del correo electrónico (en este caso, gmail-smtp-
in.l.google.com).

Tipos de servidores.
Existen cuatro tipos diferentes de servidores de resolución de nombres:
Máster (maestro). Aloja los registros autoritarios de una zona, responde las peticiones de resolución de
nombres como servidor de autoridad y delega copias a los servidores esclavo.
Slave (esclavo). Responde a las peticiones de resolución de nombres como servidor de autoridad, pero la
información es distribuida por los servidores primarios. Se considera que como medida de seguridad, se
requiere al menos uno de estos, preferentemente independiente de la infraestructura del primario (red,
energia eléctrica y ubicación geográfica).
Caching-only (sólo de cache). Responde a las peticiones de resolución de nombres pero no es servidor de
autoridad, las respuestas las guarda en memoria por un período determinado.
Forwarding (de reenvío). Reenvia las peticiones a una lista de servidores de nombres.

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, "google.com.uy" es un subdominio de "com.uy", que a su vez lo es del TLD
"uy".
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 y se encuentran distribuidos en
229 sitios en todo el mundo.
A continuación se detallan cada uno de los Root Servers:
Root Server A
IPv4: 198.41.0.4
IPv6: 2001:503:ba3e::2:30
Nombre: ns.internic.net
Empresa: VeriSign
Ubicación: Distrbuido en 6
localidades (uso de unicast) Los
Angeles, New York, Frankfurt,
Hong Kong, Palo Alto, Ashburn
Software: BIND
Root Server D
IPv4: 128.8.10.90
Nombre: terp.umd.edu
Operador: University of
Maryland
Ubicación: Maryland
Software: BIND
Root Server G
IPv4: 192.112.36.4
Nombre: ns.nic.ddn.mil
Operador: Defense Information
Systems Agency
Ubicación: Distrbuido en 6
localidades (uso de unicast) en
Columbus, San Antonio,
Honolulu, Fussa, Stuttgart-
Vaihingen, Napoles.
Software: BIND
Root Server I
IPv4: 192.36.148.17
IPv6: 2001:7fe::53
Nombre: nic.nordu.net
Operador: Autonomica
Ubicación: Distrbuido en 36
localidades (uso de unicast):
Stockholm, Helsinki, Milan,
London, Geneva, Amsterdam,
Oslo, Bangkok, Hong Kong,
Root Server B
IPv4: 192.228.79.201
IPv6: 2001:478:65::53
Nombre: ns1.isi.edu
Empresa: USC-ISI
Ubicación: Marina Del Rey,
California, U.S.
Software: BIND
Root Server E
IPv4: 192.203.230.10
Nombre: ns.nasa.gov
Operador: NASA
Ubicación: Mountain View
Software: BIND
Root Server H
IPv4: 128.63.2.53
IPv6: 2001:500:1::803f:235
Nombre: aos.arl.army.mil
Operador: U.S. Army Research
Lab
Ubicación: Aberdeen Proving
Ground
Software: NSD
Root Server J
IPv4: 192.58.128.30
IPv6: 2001:503:C27::2:30
Operador: VeriSign, Inc.
Ubicación: Distrbuido en 70
localidades (uso de unicast):
Dulles, Ashburn, Miami,
Atlanta, Seattle, Chicago, New
York, Honolulu, Mountain
View, San Francisco, Dallas,
Root Server C
IPv4: 192.33.4.12
Nombre: c.psi.net
Empresa: Cogent
Communications
Ubicación: Distrbuido en 6
localidades (uso de unicast):
Herndon, Los Angeles, New
York, Chicago, Frankfurt,
Madrid.
Software: BIND
Root Server F
IPv4: 192.5.5.241
IPv6: 2001:500:2f::f
Nombre: ns.isc.org
Operador: Internet Systems
Consortium
Ubicación: Distrbuido en 49
localidades (uso de unicast):
Ottawa, Palo Alto, San Jose,
New York, San Francisco,
Madrid, Hong Kong, Los
Angeles, Roma, Auckland, Sao
Paulo, Beijing, Seoul, Moscow,
Taipei, Dubai, Paris, Singapore,
Brisbane, Toronto, Monterrey,
Lisbon, Johannesburg, Tel Aviv,
Jakarta, Munich, Osaka, Prague,
Amsterdam, Barcelona, Nairobi,
Chennai, London, Santiago de
Chile, Dhaka, Karachi, Torino,
Chicago, Buenos Aires, Caracas,
Oslo, Panama, Quito, Kuala
Lumpur, Suva, Cairo, Atlanta,
Podgorica, St. Maarten.
Software: BIND 9
Brussels, Frankfurt, Ankara,
Bucharest, Chicago,
Washington, Tokyo, Kuala
Lumpur, Palo Alto, Jakarta,
Wellington, Johannesburg,
Perth, San Francisco, Singapore,
Miami, Ashburn, Mumbai,
Beijing, Manila, Doha,
Colombo, Vienna, Paris, Taipei,
Porto Alegre, Yerevan.
Software: BIND
Root Server L
IPv4: 199.7.83.42
IPv6: 2001:500:3::42
Operador: ICANN
Ubicación: Distrbuido en 28
localidades (uso de unicast):
Ankara, Atlanta, Brisbane, Cape
Town, Chicago, Crete,
Copenhagen, Culpeper,
Dammam, Denver, El Segundo,
Istanbul, Jeddah, Johannesburg,
Lyon, Marseille, Melbourne,
Miami, Paris, Perth,
Philadelphia, Prague, Riyadh,
San Jose, Santiago de Chile,
Sydney, Toronto.
Software: NSD
Amsterdam, London,
Stockholm, Tokyo, Seoul,
Beijing, Singapore, Dublin,
Kaunas, Nairobi, Montreal,
Perth, Sydney, Cairo, Cairo,
Warsaw, Brasilia, Sao Paulo,
Sofia, Prague, Johannesburg,
Toronto, Buenos Aires, Madrid,
Fribourg, Hong Kong, Turin,
Mumbai, Oslo, Brussels, Paris,
Helsinki, Frankfurt, Riga, Milan,
Rome, Lisbon, San Juan,
Edinburgh, Tallin, Taipei, New
York, Palo Alto, Anchorage,
Moscow, Manila, Kuala
Lumpur, Luxembourgo, Guam,
Vancouver, Wellington.
Software: BIND
Root Server K
IPv4: 193.0.14.129
IPv6: 2001:7fd::1
Operador: RIPE NCC
Ubicación: Distrbuido en 18
localidades (uso de unicast):
London, Amsterdam, Frankfurt,
Athens, Doha, Milan, Reykjavik,
Helsinki, Geneva, Poznan,
Budapest, Abu Dhabi, Tokyo,
Brisbane, Miami, Delhi,
Novosibirsk, Dar es Salaam.
Software: NSD
Root Server M
IPv4: 202.12.27.33
IPv6: 2001:dc3::35
Operador: WIDE Project
Ubicación: Distrbuido en 6
localidades (uso de unicast):
Tokyo, Seoul, Paris, San
Francisco.
Software: BIND
Tipos de resolución de nombres de dominio
Consulta Recursiva
Una consulta recursiva se realiza cuando el cliente consulta directamente un nombre al servidor DNS.

Las únicas respuestas posibles son el nombre completo o que no se ha podido encontrar. Para que suceda
esto último tiene que darse que esa dirección IP no está en la base de datos DNS y por tanto devuelve que
no la ha encontrado. Una consulta recursiva nunca se redirecciona a otro servidor DNS.
Consulta Iterativa

En las consultas (o resoluciones) iterativas, el servidor no tiene la información en sus datos locales, por lo
que busca un servidor raiz y repite el mismo proceso básico (consultar a un servidor remoto y seguir a la
siguiente referencia) hasta que obtiene la respuesta a la pregunta.
El proceso de resolución normal se da de la siguiente manera:
El servidor DNS A recibe una consulta recursiva desde el cliente.
El servidor DNS A envía una consulta iterativa al DNS B (Root Server).
El DNS B refiere a DNS A otro servidor de nombres, incluyendo al DNS C.
El servidor DNS A envía una consulta iterativa a DNS C.
El servidor DNS C refiere a DNS A otro servidor de nombres, incluyendo a DNS D.
El servidor DNS A envía una consulta iterativa a DNS D.
El servidor DNS D responde.
El servidor A regresa la respuesta al Cliente

Mecanismos de caché
Cada vez que un servidor de nombres envía una respuesta, lo hace adjuntando el tiempo de validez de la
misma (TTL o "tiempo de vida"). Esto posibilita que el receptor, antes la necesidad de volver a resolver la
misma consulta, pueda utilizar la información previamente obtenida en vez de realizar un nuevo
requerimiento.
Esta es la razón por la cual los cambios realizados en el DNS no se propagan instantáneamente a través
del sistema. Dependiendo de la naturaleza de los mismos (y de la configuración de cada servidor), la
propagación puede tardar desde algunos minutos hasta varios días.
Tipos de registro en un servidor de nombres
Un servidor de nombres puede almacenar distinta información. Para ello, en cada zona de autoridad
dispondrá de entradas de distinto tipo. Entre los más importantes se encuentran:
A (Address): Este registro se utiliza para traducir nombres de hosts del dominio en cuestión a direcciones
IP.
CNAME (Canonical Name): El nombre canónico es un alias para un host determinado. (No define una
dirección IP, sino un nuevo nombre.)
NS (Name Server): Especifica el servidor (o servidores) de nombres para un dominio.
MX (Mail Exchange): Define el servidor encargado de recibir el correo electrónico para el dominio.
PTR (Pointer): Especifica un "registro inverso", a la inversa del registro A, permitiendo la traducción de
direcciones IP a nombres.
TXT (Text): Permite asociar información adicional a un dominio. Esto se utiliza para otros fines, como el
almacenamiento de claves de cifrado, "DomainKeys" o "Sender Policy Framework".

Mensajes DNS

Un formato de mensaje DNS se utiliza para las consultas y respuestas de este protocolo. Este formato de
mensaje contiene cinco campos que ofrecen un lugar para la consulta planteada por el cliente, la respuesta
o respuestas proporcionadas por el servidor, y la información del encabezado que controla todo el
proceso. La tabla a continuación describe el formato DNS mensaje general, proporcionando un breve
resumen de cada una de sus campos y cómo se utilizan.

Header (Cabecera)
Contiene campos que describen el tipo de mensaje y aportan información importante al respecto.También
contiene los campos que indican el número de entradas en las otras secciones del mensaje.
Identificador:
Es un campo de 16 bits de identificación, generados por el dispositivo que crea el DNS. Este
identificador se copia en la respuesta correspondiente del servidor de nombres y se puede usar
para diferenciar respuestas cuando concurren múltiples consultas. Esto se utiliza en una forma
similar a cómo el identificador de campo se utiliza en muchos de los tipos de mensajes ICMP.

Banderas

Consulta / respuesta (QR) (1 bit)

Diferencia entre las consultas y respuestas. Se establece en 0 cuando la consulta se genera; cambiado a 1
cuando dicha consulta se cambia a una respuesta de un servidor de responder.

Código de operación (4 bits)

0 - QUERY - Consulta estandar
1 - IQUERY - Consulta inversa
2 - STATUS - Solicitud de estado del servidor
3 - Reservado
4 - NOTIFY - Notificación de transferencia de zona
5 – UPDATE

Respuesta Autoritativa(AA) (1 bit)

Flag de respuesta autoritativa. Si está activo en una respuesta, especifica que el servidor de nombres que
responde tiene autoridad para el nombre de dominio enviado en la consulta.
Truncamiento (TC) (1 bit):
Cuando se establece a 1, indica que el mensaje se ha truncado debido a su longitud que es más largo que
el máximo permitido para el tipo de mecanismo de transporte utilizado.
Recursividad (RD) (1bit):
Este bit indica al servidor de nombres que se pide resolución recursiva. El bit se copia en la respuesta.
Recursividad disponibles (AR) (1 bit):
Indica si el servidor de nombres soporta resolución recursiva.
Zero (Z) (3 bits)
Tres bits reservados a cero.
Código de respuesta (RCODE) (4 bits)
Del 0 al 5 se utilizan para DNS regulares (RFC 1035), mientras que del 6 - 10 se implementan en DNS
dinamicios (RFC 2136)
0 - NO ERROR - Sin errores
1 - FORMAT ERROR - Error de formato
2 - SERVER FAILURE - Falla del servidor
3 - NAME ERROR - El nombre no existe en el dominio
4 - NOT IMPLEMENTED - La consulta no es soportada por el servidor
5 - REFUSED - El servidor rechazó la consulta
6 - YX Domain - Existe un nombre cuando no debe.
7 - YX RR Set - Existe un conjunto de registros fuentes que no debería existir.
8 - NX RR Set - Un conjunto de registros fuentes debería existir.
9 - Not Auth - El servidor que recibe la consulta no está autorizado para la zona específica.
10 - Not Zone - el nombre especificado en el mensaje no está dentro de la zona especificada en el mensaje

Cuenta de preguntas (QDCOUNT) (2 bytes)

Indica el número de preguntas en la pregunta la sección del mensaje.

Respuesta Número de registros (ANCOUNT) (2 bytes)

Especifica el número de registros (RRs) en el campo Respuesta (Answer) del mensaje DNS.

Autoridad de Registro de Cuenta (NSCOUNT) (2 bytes)

Especifica el número de registros (RRs) en el campo Autoridad (Authority) del mensaje DNS

Adicional Número de registros (ARCOUNT) (2 bytes)

Especifica el número de registros (RRs) en el campo Adicional (Additional) del mensaje DNS.

Question (Pregunta)
Lleva uno o más "preguntas", es decir, las consultas de información que se envía a un servidor de
nombres DNS.

Las consultas DNS siempre contienen al menos una entrada en el campo “Question” que especifica lo que
el cliente en está tratando de averiguar.
Nombre de la pregunta (QNAME) (Tamaño variable):
Contiene el objeto, dominio o nombre de la zona que es objeto de la consulta, codificados usando la
notación estándar de nombre DNS.

Tipo de pregunta (QTYPE) (2 bytes)

1 - A - Dirección
2 - NS - Servidor de Nombre
5 - CNAME - Nombre canónico
6 - SOA - Inicio de Autoridad
12 - PTR - Puntero
15 - MX - Mail
16 - TXT - Texto

Clase de pregunta
1 - IN - Internet

Answer (Respuesta)
Campo lleva uno o varios registros que responden a la pregunta del campo “Question”

Authority (Autoridad)
Contiene uno o más registros que apunten a los servidores de nombres autorizados que se pueden utilizar
para continuar con el proceso de resolución.

Additional (Adicional)
Transmite uno o más registros que contienen información adicional relacionada con la consulta que no es
estrictamente necesario para responder a las preguntas (preguntas) en el mensaje.
Los campos Answer, Authority y Additional son los lugares en el mensaje, donde los servidores DNS
colocan los registros (RR) para ser enviado de vuelta a un cliente que haya realizado una solicitud. Cada
campo consta de cero o más registros, y en teoría, cualquier registro se puede colocar en cualquier
sección.

Nombre (Name) (Tamaño Variable)

Contiene el objeto, dominio o nombre de la zona al que el registro RR pertenece

Tipo (TYPE) (2 bytes)

Código correspondiente al registro RR
1 - A - Dirección
2 - NS - Servidor de Nombre
5 - CNAME - Nombre canónico
6 - SOA - Inicio de Autoridad
12 - PTR - Puntero
15 - MX - Mail
16 - TXT - Texto

Tiempo de vida (TTL) (4 bytes)

Especifica el número de segundos que el registro debe ser retenido en la memoria caché del dispositivo de
lectura del disco.

Resource Data Lenght (RDLenght) (2 bytes)

Indica el tamaño en bytes del campo RDATA

Resource Data (RDATA) (Tamaño Variable)

Datos correspóndientes al registro RR, el formato varía segun el tipo de RR
Demonios
Named
Named es un demonio (daemon en ingles) que implementa un servidor DNS (Domain Name System).Es
parte de BIND (Berkeley Internet Name Domain), una implementación de los protocolos del sistema de
nombres de dominio (DNS).

Archivos involucrados

Archivo de configuración de BIND - named.conf

Es el archivo de arranque, que es leído por el demonio named cuando arranca para saber a qué dominios
va a servir y dónde encuentra las tablas de máquinas y direcciones IP.

Named.conf es el archivo de configuración principal de DNS ya que contiene la

ubicación y parámetros de los demás archivos de configuración. Este archivo
contiene dos tipos de secciones:
Opciones " options ": Indica el directorio donde se encuentran otros archivos de
configuración y algunas otras opciones.
Zonas " zone ": Pueden existir varias zonas por archivo,estas zonas definen los
dominios (osmosislatina.com) y redes "networks" (192.168.1.0) sobre los que
semantiene información

Ubicación:

En RedHat
/etc/named.conf

En Debian
/etc/bind/named.conf

Archivos de zona
Los archivos de zona se suelen almacenar en el directorio /etc/bind/zones
(aunque no es obligatorio). Su escritura se realiza siguiendo la sintaxis adecuada
para los registros de recursos que se deseen incluir.
Si el archivo de zona es un archivo de zona directo, el nombre de dicho archivo
suele ser dominio.zone donde dominio es el nombre de la zona que se está
definiendo sin el punto final; si es un archivo de resolución inversa, el nombre del
archivo será direcciondered.in-addr.arpa donde direcciondered serán los octetos
de la Direccion de Red de las direcciones IP del dominio de manera invertida.
Directivas
Los archivos de configuración de Bind contienen además una serie de líneas o
directivas (a veces comentadas e ignoradas por el servidor, a veces
descomentadas y efectivas) donde se indican los parámetros de funcionamiento
del mismo. Las más importantes son:
directory
Con esta directiva se indica el directorio de trabajo de named. En él es donde
se almacena, entre otras cosas, los archivos de zona que copia del servidor
DNS primario (en el caso de que el servidor esté funcionando como servidor
secundario).
forwarders
En esta directiva se indican las direcciones IP de los servidores DNS a quien
consultará nuestro servidor en caso de no saber dar respuesta a una consulta.
zone
Estas directivas permiten declarar las zonas que tiene almacenadas el servidor.
Por defecto, el servidor cuenta con una serie de zonas que no se deben
modificar. En caso de querer añadir nuestras propias zonas, debemos hacerlo
manualmente al final del archivo. Se declaran de la siguiente forma:
zone "DOMINIO" {
type TIPO;
file "RUTA_ARCHIVO_ZONA";
masters { IP };
};

donde:
DOMINIO: se especifica el nombre de la zona que estemos definiendo. Se
escribe sin el punto final y entre comillas.
TIPO: se especifica master si es una zona de un servidor primario o slave si es
un servidor secundario.
RUTA_ARCHIVO_ZONA: indica la ruta completa hasta el archivo de zona que
contiene los datos relativos a la zona indicada en DOMINIO. Se escribe entre
comillas y solo se utiliza si el servidor es un servidor primario.
IP: especifica la dirección IP del servidor DNS primario del que solicitar una
transferencia de zona. Sólo se utiliza si el servidor es una servidor DNS
secundario.
Comandos utilizados

DIG
dig es una herramienta de linea de comandos disponible en prácticamente
cualquier distribución Linux (aunque también hay alguna versión para Windows)
que permite hacer consultas a un servidor DNS.
Permite comprobar tanto el mapeo de nombres a IPs como el mapeo inverso de
IPs a nombres, pero sólo sirve para Internet, ya que no mira en /etc/hosts (sólo
utiliza /etc/resolv.conf).

Su uso es:
dig opciones nombre tipo @servidor_dns

donde:
servidor_dns: nombre o IP del servidor DNS al que queremos dirigir nuestra
consulta, por ejemplo @dns1.nrc.ca. Si no especificamos este parámetro, dig
utilizará los servidores DNS listados en /etc/resolv.conf.
opciones: no es obligatorio utilizarlas. La más utilizada es +short que devuelve
una respuesta más corta o no devuelve nada si no encuentra respuesta. La
opción -x se utiliza para indicar a dig que queremos hacer una resolución
inversa.
nombre: es el nombre de dominio que se quiere resolver.
tipo: especifica el tipo de consulta. Valores posibles serían A (IP del servidor que
aloja al dominio; es la usada si no se especifica nada), NS (servidores DNS) o
MX (servidores de correo).

NSLOOKUP

nslookup es un programa utilizado para saber si el servidor DNS que tenemos

configurado está resolviendo correctamente los nombres de dominio y las IP. Se
utiliza con el comando nslookup, que funciona tanto en Windows como en
UNIX/Linux para obtener la dirección IP conociendo el nombre, y viceversa.
Su uso es
nslookup google.com
nslookup 200..40.0.83