1 Sistemas de nombres planos y jerárquicos
2 El servicio DNS
3 Espacio de nombres de dominio
4 Dominios
4.1 Genéricos
4.2 Los dominios geográficos
4.3 El dominio .arpa
4.4 Dominios reservados
5 Gestión administrativa del DNS
6 Whois
7 La delegación de dominios
8 La zona
9 Funcionamiento DNS
10 Cómo funcionan los reenviadores
11 Clasificación de los servidores de nombres
12 Cómo se almacenan y mantienen los datos DNS
13 Qué son los registros de recursos y los tipos de registro
13.1 El registro A
13.2 El registro PTR
13.3 El registro SOA
14 DNS dinámico (DDNS)
15 Instalacion y configuracion de DNS en Debian
En esta unidad de trabajo, aprenderás cómo resolver nombres de host mediante
DNS.
1 Sistemas de nombres planos y jerárquicos
Cuando hablamos de sistemas de nombres nos referimos a los
registros que relacionan nombres, pseudónimos o alias con unas
direcciones IP.
Es mucho más fácil recordar un nombre que una sucesión de
números. También es más fiable, ya que la dirección IP puede
cambiar, pero no así el nombre.
Hace años, en 1982, las páginas web no existían y los servidores eran
tan pocos que TODOS los host tenían la lista de nombres de dominio
completa y la actualizaban diariamente. Se trataba de un sistema de
nombres plano. [No existía ningún tipo de agrupamiento].
El sistema de nombres plano se almacenaba en un archivo /etc/hosts
en GNU/Linux
Ahora se hace imposible manejar los más de 50.000 nombres nuevos
diarios y, por ello, se utiliza un sistema de gestión de forma
distribuida (en millones de servidores DNS) y jerárquica. Este sistema
se denomina de nombres jerárquicos.
2 El servicio DNS
El servicio DNS proporciona un mecanismo de traducción de nombres
de dominio a direcciones IP únicas para localizar el servidor donde
reside un sitio web.
DNS permite la localización de equipos y servicios
Está definido en los RFC 1034 y 1035.
Las RFC (Peticiones de comentarios) son un conjunto de documentos
que sirven de referencia para la comunidad de Internet, que
describen, especifican y asisten en la implementación,
estandarización y discusión de la mayoría de las normas, los
estándares, las tecnologías y los protocolos relacionados con Internet
y las redes en general.
La base de datos de DNS es distribuida, es decir, su información está
almacenada en varias máquinas (servidores de nombres). De hecho,
la base de datos de DNS sigue una estructura jerárquica, donde cada
nivel tiene uno o varios dominios. Existe un nodo raíz identificado por
un “.”, del que cuelgan varios TLD (Top Level Domain) [dominios de
primer nivel o dominios de nivel superior] como com, edu, org, es,
etc. De los TLD cuelgan a su vez otros dominios.
Cuando se especifica un nombre de dominio completo, es decir el
nombre de un dominio con los de sus predecesores en el árbol
separados y finalizando por un punto, se obtiene su nombre de
dominio completamente cualificado (FQDN)[Fully Qualified Domain
Name]. Por ejemplo: [Link] (tiene tres niveles)
El dominio es, pues, cada uno de los subárboles que integran el árbol
o espacio de nombres de dominio.
A los servidores de nombres se les pueden realizar preguntas y para
ello se usan programas (Clientes DNS) que dialogan con los
servidores en base a unas reglas (protocolo DNS).
Lemon, Orange son el nombre que se asigna a un ordenador cuando
lo configuramos.
El nombre de dominio al que pertenecen: [Link].
Nombre completo: [Link]. ó [Link].
Los dominios pueden organizarse en zonas, que son áreas discretas o
contiguas del espacio de nombres de dominio.
Los datos de la asignación entre nombres y direcciones IP de todos
los equipos de una zona se almacenan en un archivo de base de
datos de zonas, en un servidor de nombres DNS.
La mayor parte del software de comunicación de redes, como los
programas de correo electrónico y los exploradores Web, emplean
DNS para localizar servidores y resolver el nombre descriptivo de un
equipo en su dirección IP, o buscar la asignación correspondiente.
3 Espacio de nombres de dominio
El espacio de nombres de dominio es el conjunto de nombres que se
pueden utilizar para identificar máquinas o servicios de una red.
Cada dominio se divide en subdominios:
[Link]…dominio
Por ejemplo, “[Link]” es un subdominio de “es”
[Link]
Se pueden usar nombres que tengan como máximo 127 niveles
Los nodos se identifican mediante nombres de 1 a 63 caracteres
El FQDN no debe exceder los 255 caracteres.
Cada nivel delega autoridad en los niveles inferiores
Los dominios pueden ser absolutos (llegan hasta la raíz) [se terminan
los nombres con un punto] o relativos (no llegan hasta la raíz).
4 Dominios
4.1 Genéricos
TLD, Top level domains.-. Dominios de primer nivel o dominios de
nivel superior
TLD Descripción
com Agrupa organizaciones
comerciales
edu Reúne organizaciones educativas
universitarias
net Para organizaciones dedicadas a
Internet y a las
telecomunicaciones
org Reúne organizaciones no
comerciales
gov Agrupa organizaciones
gubernamentales de Estados
Unidos
int Para el uso de organizaciones
internacionales
El ICANN es el organismo encargado de la gestión de los dominios raíz
y TLD. Su web:
[Link]
4.2 Los dominios geográficos
Existen también dominios de primer nivel que designan zonas
geográficas es para España, fr para Francia, etc.
Puede ocurrir que los dominios geográficos de primer nivel
contengan a su vez alguno de los dominios genéricos. Estos dominios
serían de segundo nivel ([Link], [Link], etc).
La gestión de cada dominio es independiente. Es decir, existe una
entidad que gestiona el dominio .es se llama [Link]
[Link] ; [Link]
4.3 El dominio .arpa
El dominio .arpa se utiliza para obtener el nombre completo (FQDN)
de una dirección IP. En este caso, las entradas tienen este aspecto:
[Link].[Link]. Esta es la entrada que se debe buscar
para obtener el nombre de dominio de la dirección IP [Link].
es lo que se conoce como resolución inversa.
4.4 Dominios reservados
En el RFC 2606 se propuso definir una serie de dominios de primer
nivel como reservados.
Estos dominios no cuelgan de la raíz; sin embargo, están reservados
en el sentido de que nunca se van a asignar a nadie.
La razón para hacer esto es la de usar dominios inexistentes a la hora
de realizar distintas pruebas en el servicio DNS. En concreto, se han
definido cuatro dominios reservados:
.localhost, .invalid, .example,.test
5 Gestión administrativa del DNS
Registrar un dominio consiste en “reservar” el nombre durante un
tiempo (normalmente durante un año) para poder crear subdominios
y asociar el nombre y/o los subdominios con direcciones IP o con la
información que se considere oportuna.
Registro de dominios (registry): ICANN, una vez que ha creado un TLD
cede el control técnico y burocrático a una institución. Esa institución
es el registro de dominios. El registro se encarga de mantener en
funcionamiento los servidores DNS asociados a ese dominio de
primer nivel. El registro, por lo tanto, es la entidad que técnicamente
da de alta y de baja los dominios de segundo nivel que estén bajo él.
Para los dominios genéricos ICANN nombra a una entidad como
registro durante un periodo de tiempo. En el caso de los geográficos,
ICANN normalmente cede el control indefinidamente a la entidad que
determine el gobierno de ese país.
Registrador de dominios (registrar): normalmente el registro no
atiende directamente a los usuarios que quieren comprar un dominio
sino que lo hacen a través de intermediarios. La tarea de atender a
los usuarios, como si de un mercado minorista se tratara, es de los
registradores de dominio. Estos atienden la petición del cliente,
comprueban que es correcta, reciben el pago y, entonces solicitan la
petición en nombre del cliente al registro de dominios
correspondiente, para lo cual deben abonar una tasa. En ocasiones,
este proceso se repite dos veces y, por tanto, existen registradores
que atienden a otros registradores.
Las personas, empresas u organizaciones, denominadas registrantes
(registrant), pueden registrar nombres de dominio de segundo nivel
(por ejemplo, “[Link]”, …)
Debe tenerse en cuenta que existen muchos registradores pero que
estos deben estar acreditados, ya sea por ICANN o por el registro que
le corresponda (por ejemplo, [Link]).
La acreditación garantiza que no se trata de un registrador “pirata”.
Cada registrador es libre de poner un precio y, de hecho, puede haber
grandes diferencias.
Normalmente, aunque no siempre, al comprar un dominio el
registrador nos ofrece gratuitamente la opción de gestionar los
servidores DNS de nuestro dominio de segundo nivel; no obstante,
también podemos gestionar los servidores DNS nosotros mismos.
Finalmente, es importante tener en cuenta que la propiedad del
dominio de segundo nivel es, en todo caso, del usuario registrante y
nunca del registrador. De hecho, el usuario podría decidir cambiar de
registrador si este le ofrece mejores servicios.
Caso Práctico: Registro de un dominio en Acens
Acceder a la página web de Acens ([Link])
Verificar la disponibilidad del dominio
Selección del nombre de dominio. Ver tarifas.
Proporciona datos de contacto y facturación
6 Whois
Whois es una base de datos distribuida que nos informa de los datos
de un dominio DNS. [Solo del segundo nivel]. Esta base de datos
puede ser usada para obtener, entre otros datos, información sobre el
usuario registrante de un determinado dominio, el registrador que usa
o el listado de los servidores de nombres.
7 La delegación de dominios
Se trata de una cesión de autoridad, por parte del dominio padre,
sobre alguno de sus subdominios y que se puede retomar cuando se
considere oportuno.
La delegación consiste en que la organización que administra un
dominio cede la administración de uno, varios o todos sus
subdominios a otras organizaciones. Como ya se ha explicado, la
ICANN administra el dominio raíz y delega la administración de los
dominios TLD en otras organizaciones. Cada una de estas
organizaciones (por ejemplo, [Link] para el dominio “es”) puede
delegar la administración de los dominios de segundo nivel en otras
(por ejemplo, [Link] delega la administración del dominio “[Link]”
en la Universidad Politécnica de Madrid). A su vez, cada organización
puede delegar la administración de sus subdominios en otras
organizaciones y así sucesivamente (por ejemplo, la universidad
Politécnica de Madrid puede delegar la administración del dominio
“[Link]” en la Facultad de Informática).
La división de un dominio en subdominios no implica siempre ceder
su delegación (por ejemplo, la UPM de Madrid puede crear los
subdominios “[Link]” y “[Link]”, encargarse de la
administración del subdominio “[Link]”, y delegar solo la
administración del dominio “[Link]”). Además, si una organización
delega un subdominio en otra, no tiene por qué informar a “su
superior” (la UPM no tiene por qué informar a [Link] de que ha
delegado el dominio “[Link]”).
La organización que administra un dominio es responsable de los
nombres usados en ese dominio, de las direcciones IP asociadas a
ellos y, del funcionamiento y mantenimiento de los servidores de
nombres que almacenan esta información.
Una vez que se ha producido la delegación, el dominio padre ya no
tiene que conocer datos sobre el dominio hijo EXCEPTO la lista de
servidores DNS de este último
Si el dominio padre no diera la información sobre esta lista de
servidores DNS, sería imposible resolver ningún nombre del dominio
hijo dado que no se sabe a qué servidores DNS debo preguntar.
8 La zona
Los servidores DNS, también llamados servidores de nombres,
mantienen información de una parte del espacio de nombres de
dominio que se conoce como zona.
Una zona puede albergar los registros de recursos para un dominio o
los registros de recursos para varios dominios. Una zona puede alojar
más de un dominio sólo si los dominios son contiguos; es decir, están
conectados mediante una relación primario-secundaria directa.
Cuando un servidor de nombres contiene una zona se dice que es
autorizado (authoritative) para esa zona.
Las zonas se almacenan en ficheros de texto o en base de datos,
dependiendo del tipo de servidor usado y de cómo se configure. Su
formato está definido en la RFC 1035.
Si un servidor de nombres de dominio DNS contiene los registros de
recursos para dicha zona, será autoritario. Para ello se utilizan los
registros de recursos SOA y NS.
Cada zona puede tener uno o más servidores de nombres de dominio
autoritarios, si bien uno será primario y el resto, secundarios o caché.
El servidor de raíz DNS hospeda la
zona raíz representada por un punto
( . ). La zona raíz contiene una
delegación a una zona del siguiente
nivel de la jerarquía, la zona com. La
delegación de la zona raíz indica al
servidor de raíz DNS que, para
encontrar la zona com, debe ponerse
en contacto con el servidor Com. De
la misma manera, la delegación de
la zona com le indica al servidor
Com que, para encontrar la zona
[Link], debe ponerse en
contacto con el servidor Contoso
9 Funcionamiento DNS
En el sistema DNS existen dos tipos de ordenadores:
Ordenadores finales o clientes: únicamente hacen consultas a
servidores DNS.
Se trata del PC de clase o de nuestra casa, e incluso podría tratarse
de un servidor de ficheros o de impresión siempre que no esté
configurado como servidor DNS.
Servidores DNS: realizan dos tareas. La primera es la de responder a
las consultas que realicen los clientes y la otra la de encargarse de
buscar algún dato desconocido, como pueda ser la dirección IP de un
determinado servidor web.
El proceso, es sencillo: cuando nosotros, desde nuestro ordenador,
abrimos la página web de [Link] el cliente DNS que
reside en nuestro ordenador (llamado resolver) hace una consulta al
servidor DNS que nosotros tengamos configurado (ya sea
estáticamente o mediante DHCP). Si el servidor DNS conoce ese dato,
se lo suministrará al cliente de forma directa.
Si el servidor DNS no lo conoce, tendrá que buscar ese dato, para lo
cual partiendo de la raíz del árbol irá recorriendo el mismo hasta dar
con uno de los servidores DNS de la zona indicada.
La consulta que ha realizado el cliente al servidor DNS del ISP se
denomina recursiva pues obliga al servidor DNS a buscar la
respuesta en beneficio del cliente. El tipo de consultas que hace el
servidor DNS del ISP (en las que se comporta como cliente) a los otros
servidores se denomina iterativa.
Las consultas recursivas son las mejores que puede hacer un cliente y
las peores que puede recibir un servidor DNS. Esto es así porque el
cliente hace una consulta y permanece cómodamente esperando
mientras que el servidor es el que tiene que recorrer todo el árbol
DNS hasta encontrar la respuesta.
La única respuesta aceptable a una consulta recursiva es la respuesta
completa o una que indique que el nombre no se pudo resolver.
Una consulta recursiva no puede redirigirse a otro servidor DNS.
Las consultas recursivas pueden ser iniciadas por un cliente DNS o
por un servidor DNS que se configuren como reenviadores
Ninguno de los servidores de la zona raíz acepta consultas recursivas.
El conjunto de direcciones IP de los 13 servidores raíz está
almacenado en un fichero que forma parte de la instalación estándar
de cualquier DNS. Este fichero contiene la lista de servidores DNS
para llegar al “.” Gracias a este fichero podremos instalar un servidor
DNS que funcione. No obstante, la lista de servidores raíz puede
cambiar cada cierto tiempo. Periódicamente deberíamos
descargarnos la lista actualizada de
[Link] e instalarla en nuestro
servidor DNS.
Si configuras un servidor DNS para una empresa, es preferible que no
acepte consultas recursivas realizadas desde ordenadores que no
pertenecen a la red de esa empresa.
10 Cómo funcionan los reenviadores
Los servidores de nombres que no son reenviadores pueden
configurarse para utilizar reenviadores. Los servidores DNS pueden
configurarse con la dirección de uno o varios reenviadores.
11 Clasificación de los servidores de nombres
Los servidores de nombres se pueden clasificar en los tipos
siguientes:
Servidor primario (maestro): obtiene la información de sus
zonas, de sus archivos locales. Todas las modificaciones sobre
una zona, como añadir dominios, se llevan a cabo en el servidor
primario.
Atenderá directamente a las peticiones de resolución de
direcciones pertenecientes a su zona y reenviará a servidores
DNS externos las peticiones del resto de direcciones de
Internet.
Servidor secundario (esclavo): contiene una copia de solo
lectura de los archivos de zona, ya que la información se
encuentra en otro servidor, por lo general primario, con
autoridad sobre esas zonas.
Permanecerá sincronizado con el maestro. Se utilizan para
repartir las peticiones entre varios servidores aunque las
modificaciones solo se realicen en el maestro. En redes locales
salvo por razones de disponibilidad, es raro que exista la
necesidad de tener dos servidores DNS ya que con uno será
suficiente.
Servidor caché: En este modo de funcionamiento, nuestro
servidor se comporta como si fuera un auténtico servidor DNS
para nuestra red local aunque realmente no sea un servidor
DNS propiamente dicho. Cuando recibe una petición de DNS por
parte de un cliente de nuestra red, la trasladará a un DNS
maestro que puede estar en nuestra red o fuera, almacenará en
una memoria caché la respuesta y a la vez la comunicará a
quien hizo la petición. Si un segundo cliente vuelve a realizar la
misma petición, como nuestro servidor tiene la respuesta
almacenada en su memoria caché, responderá inmediatamente
sin tener que cursar la petición a ningún servidor DNS de
Internet.
Disponer de un servidor caché DNS en nuestra red local aumenta la
velocidad de la conexión a Internet pues cuando navegamos por
diferentes lugares, continuamente se están realizando peticiones
DNS. Si nuestro caché DNS almacena la gran mayoría de peticiones
que se realizan desde la red local, las respuestas de los clientes se
satisfarán prácticamente de forma instantánea proporcionando al
usuario una sensación de velocidad en la conexión.
12 Cómo se almacenan y mantienen los datos DNS
Un archivo de zona es el archivo del disco duro local del servidor DNS
que contiene toda la información de configuración para una zona y los
registros de recursos contenidos en ella.
13 Qué son los registros de recursos y los tipos de registro
Los registros de recursos describen la información del dominio DNS.
El formato de cada registro de recursos (RR):
Propietario: nombre de la máquina o dominio DNS al que pertenece el
recurso. Puede contener el símbolo @, que representa el nombre de
la zona descrita.
Ejemplos:
[Link], [Link].[Link]
TTL (Time To Live): Tiempo de vida en segundos que puede estar el
registro en la caché, expresado en días (d), horas (h), minutos (m) y
segundos (s) antes de ser descartado. El cero (0) no se almacena en
caché. Se trata de un campo opcional.
Se puede definir un tiempo global que se aplica a todos los registros
de una zona.
Clase: Familia de protocolos en uso indicados por IN (de Internet) y
que representa una red TCP/IP
Tipo: varía en función del campo clase (SOA, NS, A,PTR...)
RDATA: información específica del tipo de recurso. Por ejemplo, para
un registro de clase IN y tipo A, este campo especifica una dirección
IP.
13.1 El registro A
Un registro A representa un equipo o dispositivo en la red.
Los registros A son los más comunes y los registros DNS que se
utilizan con más frecuencia.
Un registro A resuelve un nombre de host en una dirección IP.
13.2 El registro PTR
Un registro PTR se utiliza para buscar el nombre DNS que
corresponde a una dirección IP.
El registro PTR se encuentra sólo en la zona de búsqueda
inversa.
Los registros PTR resuelven una dirección IP en un nombre de
host.
13.3 El registro SOA
Un registro de recursos SOA [Start Of Authority](inicio de
autoridad) es el primero registro de una zona y define una serie de
opciones generales de la misma.
Identifica el servidor de nombres DNS principal de la zona.
Identifica la dirección de correo electrónico del administrador
responsable de la zona.
Un registro de recursos SOA especifica la información necesaria
para la replicación (como el número de serie, el intervalo de
actualización, el intervalo de reintento y los valores de caducidad de
la zona).
MName.- Nombre FQDN del servidor de nombres maestro del
dominio.
Ejemplo: [Link]
Contacto.- Correo de la persona responsable del dominio. Es
parecido a una dirección de correo electrónico normal, a excepción
que la arroba se remplaza con un punto. Ejemplo: [Link]
Número de serie (serial).-
Indica la versión del archivo de zona, y debe ser incrementado
cada vez que el archivo se modifique.
Los servidores secundarios consultan el registro SOA para
realizar transferencias de zona. Si ha cambiado, entonces se realiza la
transferencia de zona.
Una práctica muy común es utilizar la fecha en el formato
aaaammdd y agregarle dos dígitos más para los cambios que se
hacen al archivo en el mismo día.
Ejemplo 2011112204
Actualización
Tiempo que esperan los servidores esclavos para preguntar al
servidor maestro si hay cambios en la zona.
La RFC 1912 recomienda valores entre 1200 y 43200 segundos
(12 horas) dependiendo de la frecuencia de cambios en los archivos
de zona.
Reintentos (retry)
Si la transferencia de zona ha fallado, indica el tiempo que
espera el servidor secundario antes de volver a intentarlo.
Valores inferiores al tiempo de actualización.
Caducidad (expire)
Determina el tiempo que el servidor esclavo puede estar
intentando contactar con el maestro para ver si hay cambios de zona.
Si el tiempo expira, el servidor esclavo considera que algo ha
pasado y se declara como no autorizado para la zona, y por lo tanto,
no responde a preguntas sobre esa zona.
La RFC 1912 recomienda valores entre 2 y 4 semanas.
TTL negativo (Time To Live)
Tiempo mínimo que se almacenan las respuestas negativas
sobre esa zona.
Diferente al TTL de los RR
[Link]. IN SOA [Link]. [Link].(
1; número de serie
604800; tiempo de refresco
86400; Tiempo de reintento
2419200; tiempo de expiración
604800); TTL negativo
Todos estos valores se pueden indicar en segundos o utilizando
letras para representar a las unidades de tiempo. Por ejemplo, para
especificar un intervalo de tiempo de una semana (Week), dos días
(Day), cinco horas (Hour) y diez minutos (Minute) se escribe
1W2D5H10M
14 DNS dinámico (DDNS)
Las siglas DDNS se refieren al concepto Sistema Dinámico de
Nombres de Dominio, un mecanismo que permite la asignación de un
nombre de dominio o una máquina con dirección IP dinámica.
A menudo el proveedor de Internet proporciona una IP pública
dinámica a nuestro ordenador (es decir. cambia cada vez que nos
conectamos). De esta forma se impide que se transforme en un
servidor DNS. Sin embargo, con un DNS dinámico se puede configurar
un sitio web doméstico sin necesidad de utilizar un hosting externo
siempre y cuando se mantenga activo el servidor durante las 24
horas del día.
15 Instalación y configuración de Dns en
Debian
Nos vamos con cd al directorio /etc/bind cd /etc/bind como vemos en
la siguiente pantalla
Hacemos un ls –l y vemos todos los archivos de configuración del
servidor
Hacemos una copia de los archivos [Link] y db.127
cp [Link] [Link]
cp db.127 [Link]
Abrimos el archivo [Link] con nano
Y obtenemos lo siguiente
En el forwarders donde aparece [Link];[Link] lo dejamos
solo con [Link] como aparece en la siguiente pantalla.
Guardamos y salimos
Modificamos el archivo /etc/bind/[Link] con nano
/etc/bind/[Link] y lo dejamos de la siguiente forma
Después hacemos named-checkconf para ver posibles errores
Comprobamos que no hay ningún error
Nos vamos al fichero [Link] y lo editamos con nano como
vemos en la figura siguiente
En este fichero cambiamos todos los localhost por el nombre de
nuestro dominio y decimos donde está cada dominio
Ponemos el primer dominio como nuestro dominio asi como su
dirección ip después ponemos el dns y su dirección ip y luego el
primer pc con su dirección ip los tres van a tener la misma dirección
ip. Luego vamos a poner un segundo pc con una dirección ip que va a
ser una unidad mayor que las anteriores como vemos en la figura
siguiente
Para que quede bien como en la figura anterior utilizamos el
tabulador y nunca los espacios sino no funciona y ponemos todos los
puntos al final de cada dominio
Ahora vamos a hacer lo mismo para la zona inversa. Vamos a declarar
direcciones ip indicando a que dominios pertenecen. En este caso
editamos con nano el archivo [Link] y vemos lo siguiente
Cambiamos localhost por el nombre de nuestro dominio como vemos
en la pantalla siguiente
Escribimos lo siguiente
Y guardamos. Para comprobar que estos dos ficheros están bien
escribimos lo siguiente para la zonadirecta:
Named-checkzone [Link] /etc/bind/[Link]
Y comprobamos que es correcto al menos de sintaxis
El archivo /etc/[Link] ha de quedar de la siguiente forma
Reiniciamos el servidor con /etc/init.d/bind9 restart
Vemos que reinicia correctamente
Ahora podemos hacer las primeras pruebas con nslookup. Por ejemplo
hacemos nslookup [Link] y nos aparece
Probamos con nslookup [Link] y aparece
Probamos con el pc2 nslookup [Link] y nos aparece
Probamos ahora con la zona inversa
Probamos con la ip del cliente nslookup [Link]
Vamos aver ahora otro comando que es el dig y el nombre de dominio
en nuestro caso
dig [Link]
Y vemos que nos devuelve bien la zona directa como la inversa
Configuración del dns desde cliente debian.
La tarjeta de red del cliente eth0 ha de ser estatica por lo que el
fichero /etc/network/interfaces ha de quedar asi
Editamos el fichero /etc/[Link] y lo dejamos de la siguiente forma
Ahora ya podemos hacer consultas a nuestro servidor dns
Hacemos un nslookup a nuestro servidor dns con nslookup [Link]
y nos aparece
Probamos con el pc2 con nslookup [Link] y nos aparece
Vamos a probar que funcione a la inversa. Ponemos nslookup
[Link]
Probamos con un dominio como el dns como nslookup [Link]
nos aparece
Por último probamos a ver si encuentra el pc2 con nslookup
[Link]