Servicio DNS

Duración
8:00 H
Debian GNU/Linux
D7-A06 – Servicios de infraestructura de red en Linux
Servicio DNS
(Domain Name Service)
Ing. Ariel Alvarez Enríquez
Primera Parte

2
Servicios de infraestructura de red en Linux
Introducción,
implementación, Gestión y
configuraciones avanzadas
del servicio DNS.
Objetivo

3
 Consideraciones generales.
 Implementar el servicio de DNS.
 Gestionar el servicio de DNS.
 Asegurar el servicio de DNS.
Contenido

4
 ¿Qué es el servicio de DNS?
 Breve historia sobre DNS.
 Componentes y funciones de DNS.
 ¿Como DNS trabaja?
 El protocolo DNS.
 Localización de los recursos.
Consideraciones Generales

5
 Su uso principal es:
 La asignación de nombres de dominio a direcciones IP.
 La localización de los servidores de correo para cada
dominio.
¿Qué es el servicio de DNS?
DNS – (acrónimo de Domain Name System) es una
base de datos distribuida y jerárquica, que
almacena la información necesaria para los
nombres de dominio.
DF
 DNS – es una base-dato distribuida indexada
por nombres de dominios.

6
 Con el surgimiento de las redes e Internet:
 Nació de la necesidad de facilitar el acceso a los
servidores, a través de, Internet (como – algo más
fácil de recordar que una dirección IP).
 En 1984, Paul Mockapetris crea: El Sistema de
Nombre de Dominio (DNS).
 Su diseño se basó en la estructura jerárquica del
sistema de ficheros de Unix.
Breve historia sobre DNS
com
example
“ “
example.com
DNS
Database
/usr/local/bin
usr
local
/
Unix
File System

7
Componentes y funciones
Servidores y
Resolución de Nombre
Registro de NombresDNS Name Space
Arquitectura de
nombres jerárquicos
Reglas de nombres y
de estructuras de DNS
Especificaciones de
nombres de dominios
Estructura autoritativa
jerárquica
Jerarquía de dominios
TLD
Registro de dominios
de segundo-nivel
Administración de
zonas de DNS
Fichero Master
y resource records
Servidores, tipos,
roles y funciones
Proceso de resolución
y resolver
Mensajes de DNS,
formato y notificación
Sistema de Nombres de Dominio (DNS)
Componentes
Funciones

8
 El espacio de nombre de dominio de Internet.
 Delegación y autoridad.
 Las zonas.
 Los servidores de nombres.
 El resolver.
 La resolución.
 El cache de DNS.
 Mantenimiento de Zona.
¿Cómo trabaja DNS?

9
 Interpretaciones de la estructura.
 El espacio de nombre de dominio.
 Nombres de dominios.
 Dominios y sub-dominios.
 Resource Records (RRs).
 Registros de internet.
El espacio de nombre de dominio Internet

10
 Estructura Jerárquica del árbol (Dominio).
 El root del árbol es representado como un “.” .
 El TLD es dividido en dos tipos:
 Generic Top-Level Domains (gTLD):
(por ejemplo, .com, .edu, .net, .org, .mil, etc).
 Country Code Top-Level Domains (ccTLD):
(por ejemplo, .us, .ca, .cu, .uk, etc).
Interpretaciones de la estructura
Nota:
Country Code TLDs usa un estándar de dos caracteres – secuencia definida por la ISO 3166.
“.”
debian
cu
net
org
...
gov ca
desoft
...
gTLD
ccTLD
Root
cfr Sub-Domain cfr
.in-addr
arpa
.192
arpa
.200
...
SLD o
Domain
TLD
Root D
Sub-D

11
 Cada nombre de dominio es una ruta en un árbol
invertido llamado espacio de nombre de dominio
(domain name space).
Interpretaciones de la estructura (Cont.)
“.”
desoft
com
orgcu
oc cfr
...
dominio cu
dominio desoft.cu
sub-dominio cfr.desoft.cu
Ruta
Espacio de nombre
de dominio.
(Domain Name Space)
 Un dominio es simplemente un sub árbol (sub-tree)
del espacio de nombre de dominio.

12
 El nombre de dominio completo de cualquier nodo en
el árbol es la secuencia de label en la ruta desde ese
nodo al root (FQDN).
 Cada nodo tiene un text label (sin punto) que puede
ser de 63 caracteres de longitud.
 Un label nulo (longitud cero) es reservado para root.
“.”
desoft
com
orgcu
oc cfr
...
nodo cfr.desoft.cu
nodo desoft.cu
...
Formato:
FQDN (Fully Qualified Domain Name)
sld.tld → Parcial
O bien,...
cadena.cadena.cadena.... cadena.
e.j.→ ns.cfr.desoft.cu → Completo

13
 Resource Records (RRs).
 La data asociada con los nombres de dominio es
contenida en los resource records.
 Los resource records son divididos en clases:
(cada clase pertenece a un tipo de red o software).
 La clase Internet (IN) (cualquier red TCP/IP de internet).
 En una clase – hay varios tipos de records y se
corresponde con diferentes tipos de datos.
Nota:
Otras clases:
 La clase basada en el protocolo Chaosnet (es una vieja red de enorme significado histórico).
 La clase basada en el uso del software Heisod (esta es limitada mayormente para MIT).
cfr
Nodo sub-Dominio cfr.desoft.cu
ftp www
RR – www.cfr.desoft.cu
RR – ftp.cfr.desoft.cu
Nodo Dominio desoft.cu
desoft
Resource Records
Espacio de nombres y dominios
Rutas

14
Registros de Internet
 Relación entre organizaciones individuales.
RFC editor IANA ICANN
gTLD com.
manager
gTLD biz.
manager
gTLD gh.
manager
RIPE
(Europe and
Middle East)
ARIN
(Norte
America)
APNIC
(Asia-Pacific)
LACNIC
(latin America
Including the
caribbean)
AfriNIC
(Africa and
Indian ocean
region)
Root name
servers
RIR : IP address and AS numbersSecond level domain
ISP1 ISP2
Company
1
Company
2
Company
3
Company
4
...
...

15
Registros de Internet (Cont.)
 RFC-editor – publica los estándares RFC.
 IANA – dedicada a preservar las funciones de
coordinación central de Internet.
(El registro TLD, un registro de asignación de direcciones IPv4 e
IPv6, Números asignados (AS Numbers).
 ICANN – formada para asumir responsabilidades por:
(Reparto del espacio de direcciones IP, la asignación de parámetros
de protocolos, la administración del sistema de nombres de
dominios y la administración del sistema de servidores root).
 Publica tres políticas fundamentales:
 Establecer de los nuevos registros de internet regional (RIR).
 Administración y delegación de ccTLD y gTLD.
 Un único root autoritativo para DNS.
Nota:
Home pages:
 RFC-editor: (http://www.rfc-editor.org/).
 IANA – (The Internet Assigned Numbers Authority) : (http://www.iana.org/).
 ICANN – (The Internet Corporation for Assigned Names and Numbers) : (http://www.icann.org/).
 RIR – (Regional Internet Registries)

16
 Registro de Internet Regional (RIR).
Nombre RIR Cobertura Web
APNIC Pacifico Asiático. www.apnic.net
ARIN Norte América, región Sur de África y parte del Caribe www.arin.net
LACNIC Suramérica, parte del Caribe. www.lacnic.net
RIPE Europa, Medio Este, región norte de África y parte de Asia. www.ripe.net
AfriNIC África. (Actualmente los registros africanos son
manejados por ARIN y RIPE).
www.afrinic.net

17
 intervalos de direcciones IPv4 para intranets.
10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255
 Asignación de direcciones IPv4 para (RIR).
024.0.0.0 – 024.255.255.255 – ARIN
041.0.0.0 – 041.255.255.255 – AfriNIC
058.0.0.0 – 061.255.255.255 – APNIC
062.0.0.0 – 062.255.255.255 – RIPE
063.0.0.0 – 076.255.255.255 – ARIN
080.0.0.0 – 091.255.255.255 – RIPE
124.0.0.0 – 126.255.255.255 – APNIC
189.0.0.0 – 190.255.255.255 – LACNIC
193.0.0.0 – 195.255.255.255 – RIPE
199.0.0.0 – 199.255.255.255 – ARIN
200.0.0.0 – 201.255.255.255 – LACNIC
202.0.0.0 – 203.255.255.255 – APNIC
204.0.0.0 – 209.255.255.255 – ARIN
210.0.0.0 – 211.255.255.255 – APNIC
212.0.0.0 – 213.255.255.255 – RIPE
216.0.0.0 – 216.255.255.255 – ARIN
217.0.0.0 – 217.255.255.255 – RIPE
218.0.0.0 – 222.255.255.255 – APNIC

18
 Delegación de control – permite, administración
descentralizada en el sistema de nombres de
dominio.
Delegación y autoridad
“.”
desoft
comorgcu
oc cfr
...
nodo cfr.desoft.cu
Administrada por cfr
nodo desoft.cu
Administrada por desoft
...
desoft.cu
delegada a desoft
Delegación
 Autoridad – una organización o persona
responsable de administrar las operaciones de
ese nodo.

19
 La zona – es parte del espacio de nombre de
dominio que es administrado por un servidor
de nombre particular.
e.j. Dominio – desoft.cu
Las zonas
oc
hab
cfr
“.”
desoft
cu
zona hab.desoft.cu
zona desoft.cu dominio cu
oc
hab
cfr
“.”
desoft
cu
zona desoft.cu
zona oc.desoft.cu
zona hab.desoft.cu
zona cfr.desoft.cu
dominio cu

20
Servidores de nombres
 Tipos de servidores y roles.
Servidores de Nombres Descripción
Master (Primary) Name
Servers
 Responde de forma autoritativa para la zona.
 Lee los ficheros de zona desde un sistema de fichero Local.
 Capas de transferir el fichero de zona a uno o mas servidores
secundarios.
Slave (Secondary) Name
Servers
 Responde de forma autoritativa para la zona.
 Obtiene sus fichero de zona por una zona de transferencia
desde el Master (Primary) Name Servers.
Roles Descripción
Caching Name Servers Suministra peticiones recursivas para clientes y salva los
resultados en cache.
Forwarding (Proxy)
Name Servers
Pasa todas la peticiones las cuales no tiene en cache a un
Caching Name Server.
Stealth (DMZ or Split)
Name Server
Un servidor de nombre en defensa perimetral, el cual separa los
servicios suministrados para usuarios internos y externos.
Authoritative-only Name
Server
Solo suministra respuestas autoritativas, es un zone master o un
zone slave, y no soporta peticiones recursivas.

21
El resolver
 Resolver – es la librería de software instalada
en cada PC usada para traducir una petición de
usuario o aplicación hacia un servidor de
nombre local.
Programa
Cliente Respuesta
Petición
Ficheros
de zona
Servidor de
Nombre
Cache
Resolver
Librerías
(Software)
e.j. Cliente – Telnet, FTP
Linked

22
La resolución
resolución – es el proceso de recuperación de
datos de los servidores de nombre desde el espacio
de nombre de dominio.
 Ofrecer sus datos desde las zonas para los cuales son autoritativo.
 Buscar datos a través del espacio de nombre de dominio para los
cuales ellos no son autoritativo.
DF
Resolver
A D
B
C
Petición
Respuesta
Petición
Referencia
Petición
Referencia
Petición
Respuesta

23
La resolución(Cont.)
 Hay tres tipos de peticiones (queries) definidas
para el proceso de resolución.
 Peticiones recursivas.
 Peticiones iterativas (o no recursivas).
 Peticiones inversas (reverse mapping).

24
Peticiones recursivas
 Hay tres posibles respuestas:
 Una respuesta acompañada por cualquier record CNAME, la
respuesta indicara si la data es autoritativa o no (cached).
 Un error – indicando que el dominio o host no existe, puede
contener un CNAME para este host.
 Un error temporal – indicando error en la red.
Nota:
Los servidores de nombre no son requeridos para soportar peticiones recursivas, y el resolver (u otro servidor
de nombre actuando recursivamente en beneficio de otro resolver) negocian el uso del servicio recursivo
usando bits en la cabecera de la petición.
Petición recursiva – es aquella en la el servidor de
nombre da una respuesta completa o (un error).
DF
Browser Resolver
PC
DNS Local
DNS
Root server
DNS
.com TLD
DNS
example.com
Petición
Petición
Respuesta
Referencia
Petición
Referencia
Petición
Respuesta
Cache
Ficheros
de zonawww.example.com

25
Peticiones iterativas (o no recursivas)
Petición iterativa – es aquella donde el servidor de
nombre da una respuesta parcial o (un error).
DF
 Hay tres posibles respuestas:
 Una respuesta acompañada por cualquier record CNAME, la
respuesta indicara si la data es autoritativa o no (cached).
 Un error – indicando que el dominio o host no existe, puede
contener un CNAME para este host.
 Un error temporal – indicando – error en la red.
 Una referencia – una lista de dos o más servidores de
nombres (y direcciones IP) para el dominio encuestado.
Nota:
 Los servidores de nombre tienen que soportar peticiones iterativas (o no recursivas).
 Respuesta → (Referencia) – pueden o no ser servidores de nombre autoritativo para el dominio final en la
petición. Una referencia es un método de respuesta normal usado por los servidores root y los servidores
TLD, ambos servidores solo soportan peticiones iterativas.

26
Peticiones iterativas (o no recursivas)(Cont.)
Browser Resolver
PC
DNS Local
DNS
Root server
DNS
.com TLD
DNS
example.com
Petición
Petición
Referencia
Referencia
Petición
Referencia
Petición
Respuesta
Cache
Ficheros
de zona
Lista
(de los servidores root)
 Petición iterativa.
www.example.com

27
Peticiones inversa
 e.j. (recursivo).
Petición inversa (reverse mapping) – es aquella que
retorna un nombre de host dado una dirección IP.
DF
En esencia – el proceso no usa una petición inversa, usa
peticiones recursiva o iterativa sobre el dominio especial
in-addr.arpa.
Nota:
 Históricamente, reverse IPv4 mapping no fue obligatorio. Muchos sistemas – (especialmente servidores de
correo) ahora lo usan para simplificar la seguridad y el chequeo de autenticación, así la propia
implementación y mantenimiento de reverse mapping es ahora una practica esencial.
 domain .ARPA - (Address and Routing Parameter Area).
Línea de
comando
Resolver
PC
DNS Local
DNS
Root server
192.in-addr.arpa
DNS
RIR (.168)
DNS
LIR (.250)
Petición
Petición
Respuesta
Referencia
Petición
Referencia
Petición
Respuesta
Cache
Ficheros
de zona
DNS
End-User (.15)
Petición
Respuesta
15.250.168.192.in-addr.arpa

28
El cache de DNS
Mecanismo Descripción
Caching Esta es una característica eficientemente esencial que reduce el
trafico de mensajes de DNS eliminando peticiones innecesarias para
los nombres resueltos recientemente.
Negative Caching Esta también posible que los servidores de DNS (to cache) registren
los resultados intentos de resolución de nombres insatisfactorio.
 Mecanismos de cache.
 Persistencia de los datos.
 Cada RR puede estar asociado con un intervalo de
tiempo “Time To Live” (TTL), que especifica cuanto
tiempo el record puede estar en la cache.
Nota:
El valor de este campo es controlado por el propietario del RR, quien puede adaptar este para las necesidades
especificas de cada tipo de RR.
Criterio - IMPORTANTE
 Un TTL pequeño ayuda asegurar que la data en sus zonas sea consistente a través de la red, debido a que
este incrementara la carga en sus servidores de nombre y alargará el tiempo de resolución para la
información de sus zonas.
 Un TTL grande acorta el promedio de tiempo que este toma para resolver la información en sus zonas
debido a que la data puede estar más tiempo en cache, el inconveniente es que su información será
inconsistente por mucho tiempo si usted cambia sus datos en los servidores de nombre.

29
Mantenimiento de zona
 Zona de transferencia.
 Notificación (NOTIFY).
 Zona de transferencia completa (AXFR) o
incremental (IXFR).
 Actualizaciones dinámicas.

30
Cambios en
los registros
de la zona
Master
Incremento
Zona de transferencia
 Proceso:
Nota:
La zona de transferencia permite eficiencia en las operaciones de DNS, pero también son una importante
fuente de amenazas.
Criterio - IMPORTANTE
 Un DNS Slave puede comprometerse si acepta actualizaciones de zona desde fuentes maliciosas. Asegure
que, como mínimo el servidor Slave solo acepte transferencia desde fuentes conocidas y confiables.
Zona de transferencia – proceso que permite
simplificar la operación de múltiples servidores.
Involucra la trasferencias de ficheros de zona desde un
servidor de nombres a otro (Master y Slave) usando las
características del protocolo DNS).
DF
Master Slave
Ficheros
de zona
Zona de Transferencia
Notificación1
2
AXFR o IXFR
Petición SOA
3
RR
SOA

31
Zona de transferencia(Cont.)
 Descripción del proceso.
Primero: (notificación – NOTIFY).
 La zona Master envía un mensaje NOTIFY a la zona Slave
siempre que la zona es cargada o actualizada (indicando
cambios en los records del dominio).
(NOTIFY – es controlado por las sentencias notify, olso-notify y
notify-source en las clausulas options o zone del fichero .conf)
Segundo: (Zona de transferencia AXFR o IXFR).
 El servidor Slave envía una petición al RR SOA del dominio por
el intervalo de refrescamiento. Si el número de serie es mayor
que el almacenado en el Slave, éste solicita una zona de
transferencia e indica si o no es capas de aceptar una (IXFR). Si
ambos soportan la característica, ésta toma lugar, de lo contrario
una (AXFR) ocurre – (por el puerto 53 TCP).
(por defecto – IXFR es solicitado a menos que sea configurado
por la sentencia request-ixfr en la clausula options o server del
fichero .conf)

32
Actualizaciones dinámicas
 Dos arquitecturas:
 Desde fuentes externas o aplicaciones – DDNS
(Dynamic DNS).
 Desde una base-dato.
 Desde fuentes externas o aplicaciones.
 Todos los RRs dentro de una zona existente pueden ser:
adicionados, cambiados o borrados con la excepción del RR SOA.
 Limitante – un nuevo dominio o zona no pueden ser adicionado o
borrado dinámicamente.
 Por defecto (DDNS) – deny from all host. Controlado por la
sentencia allow-update (con o sin TSIG/TKEY) y update-policy
(solamente con TSIG/TKEY) en las clausulas options o zone en el
fichero .conf.
 Herramientas: e.j. nsupdate – paquete bind-utils.

33
Actualizaciones dinámicas (Cont.)
 Desde una base-dato.
 Este método usa un gran parche (bind-dlz) que reemplaza todos
los ficheros de zona por una base-dato.
 Bind-dlz soporta (MySQL, PostgreSQL, BDB y OpenLDAP).
 Paquete Bind-dlz – (bind-dlz.sourceforge.net).
 Todas las peticiones de DNS, primero son dirigidas a la base-dato
donde los cambios sobre la zona de dato (nuevo, modificación o
borrado) son reflejados inmediatamente en la respuesta del
servidor.
 Inconveniente – el uso de cambios en tiempo-real pata los records
DNS sin realizar salvas conlleva a la propagación inmediata de
errores.

34
 Características – (operaciones del protocolo):
(e.j. peticiones y mantenimiento de zona).
 Por defecto → puerto 53 UDP y TCP, aunque puede
ser configurado para otro puerto.
En operaciones Normales:
 Por razones de rendimiento, las peticiones usan protocolo
UDP con un limite block-size de 512 bytes.
 Si la respuesta a una petición excede los 512 bytes, TCP
es negociado y usado.
 Las operaciones de mantenimiento de zona por razones de
fiabilidad usa TCP puerto 53 (por defecto).
En operaciones en las que uso de DNSSEC.
 Los volúmenes de respuesta de datos pueden
incrementarse considerablemente. Una característica
como EDNSO, es usada para negociar un bloque UDP de
tamaño mayor que 512 bytes (512-4096 bytes).
El protocolo DNS

35
 La sintaxis URL (Uniform Resource Locator).
Localización de los recursos
URL – permite especificar un recurso particular
dentro de un nombre de dominio suministrando
una estructura de directorio después de un
nombre.
DF
http://tux:xx123@www.example.com:80/cgi-bin/pix.php?Wedding03#Reception07
<scheme>
<user>
<password>
<host> <url-path>
<port>
<query> <fragment>
e.j.
http://tux:xx123@www.example.com:80/cgi-bin/dwww/.../Bv9ARM.ch01.html
Depende de la implementación de sitio

36
 Consideraciones generales.
 Implementar el servicio de DNS.
 Gestionar servicio DNS.
 Asegurar el servicio de DNS.
Contenido

37
 Instalar el servicio DNS.
 Controlar el servicio DNS.
 Antes de configurar el servicio DNS.
 Configurar el servicio DNS.
Implementar el servicio DNS

38
 Chequeamos los paquete necesarios.
Instalar el servicio DNS
# aptitude search bind9
p bind9 - Internet Domain Name Server
p bind9-doc - Documentation for BIND
p bind9-host - Version of 'host' bundled with BIND 9.X
p bind9utils - Utilities for BIND
p libbind9-60 - BIND9 Shared Library used by BIND
 instalamos los paquete seleccionados.
#aptitude install bind9 bind9-doc bin9utils
...
 Verificamos los paquete instalados.
# aptitude search bind9
i bind9 - Internet Domain Name Server
i bind9-doc - Documentation for BIND
i bind9-host - Version of 'host' bundled with BIND 9.X
i bind9utils - Utilities for BIND
i libbind9-60 - BIND9 Shared Library used by BIND

39
 Verificando los directorios.
Instalar el servicio DNS(Cont.)
# ls -l /etc/bind/ /etc/default/ /var/lib/ /usr/share/bind9/ /usr/share/doc/bind9-doc/
/etc/bind/:
bind.keys db.0 db.127 db.255 db.empty db.local db.root named.conf
named.conf.default-zones named.conf.local named.conf.options rndc.key zones.rfc1918
/etc/default/:
...
bind9
…
/var/lib/:
…
cache
bind
…
/usr/share/bind9/:
named.conf.options
/usr/share/doc/bind9-doc/:
arm misc changelog.Debian.gz changelog.gz copyright

40
 Lab-1: (Instalar el Servicio DNS)
 Utilice la vmware disponible para el ejercicio.
 Chequee la configuración de conectividad y de acceso
al repositorio.
Laboratorio

41
Controlar el servicio DNS
 Con el directorio init.d.
 Con el comando named.
 Con el comando kill.
 Chequear el estado del servicio y el socket.

42
Controlar el servicio DNS(Cont.)
 Con el directorio init.d (colocado – distribución).
(Directorio para la lista de scripts del sistema).
 Ruta absoluta – /etc/init.d/slapd.
 Comando service.
 Interfaz genérica invoke.rc.d.
# invoke.rc.d bind9 start
[ ok ] Starting domain name service...: bind9.
# invoke.rc.d bind9 stop
[....] Stopping domain name service...: bind9waiting for pid 3608 to die
. ok
# invoke.rc.d bind9 restart
[....] Stopping domain name service...: bind9waiting for pid 3522 to die
. ok
[ ok ] Starting domain name service...: bind9.

43
 Con el comando named.
#named
...
 Sin parámetros el comando carga la configuración por defecto del fichero named.conf.
 [-c config-file] – Usa el fichero config-file como el fichero de configuración en lugar de
named.conf.
 -p port – indica que escuche las peticiones por otro puerto, si no se especifica, por defecto
puerto 53.
 Vea man named → para más detalles.

44
 Con el comando kill.
(detener el servicio – proceso named.pid)
# kill `cat /var/run/named/named.pid`
(detener el servicio – si el fichero named.pid no existe)
# kill `pgrep named`

45
 Chequear el estado del servicio.
# chkconfig | grep bind9
bind9 on
# chkconfig -l | grep bind9
bind9 0:off 1:off 2:on 3:on 4:on 5:on 6:off
# sysv-rc-conf --list | grep bind9
bind9 0:off 1:off 2:on 3:on 4:on 5:on 6:off
# sysv-rv-conf
service 1 2 3 4 5 0 6 S
…
slapd [ ] [X] [X] [X] [X] [ ] [ ] [ ]
…
# invoke-rc.d bind9 status
[ ok ] slapd is running.
# invoke.rc.d bind9 status
[FAIL] bind9 is not running ... failed!
invoke-rc.d: initscript bind9, action "status" failed.

46
 Chequear el estado del socket.
# netstat -lpn --tcp | grep named
tcp 0 0 192.168.1.4:53 0.0.0.0:* LISTEN 2346/named
tcp 0 0 10.160.1.34:53 0.0.0.0:* LISTEN 2346/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 2346/named
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 2346/named
tcp6 0 0 :::53 :::* LISTEN 2346/named
tcp6 0 0 ::1:953 :::* LISTEN 2346/named

47
 Lab-2: (Ejecutar las herramientas de control y
chequear el estado del servicio DNS)
 Verifique la existencia de las herramientas de control y
chequeo del servicio DNS.
 Ejecute las herramientas de control y chequeo.
 Analice variantes.
Laboratorio

48
Antes de configurar el servicio DNS
 Escenario.
 El directorio de configuración.
 Formato del fichero de zona.
 Resource records.

49
Escenario
 El nombre de dominio a usar: example.com.
 La zona tiene dos servidores de nombre: uno es
hospedado en el dominio interno ns1.example.com y el
otro en el dominio externo ns2.example.net.
 La subred interna usa 192.168.1.0/24.
 Dos servidores correo: uno en el dominio interno
mail.example.com y el otro (Backup) en el dominio
externo mail.example.net.
 Un servidor web hospedado en el dominio interno y
es accedido como www.example.com.
 Un servidor FTP con el nombre ftp.example.com pero
publicado por ftp.example.net.
 Un host adicional llamado tux.example.com.

50
El directorio de configuración
 Directorio actual:
# ls /etc/bind/ | sort
bind.keys
db.0
db.127
db.255
db.empty
db.local
db.root
named.conf
named.conf.default-zones
named.conf.local
named.conf.options
rndc.key
zones.rfc1918
Ficheros de zona
Fichero de configuración
Fichero de configuración (include)

51
Formato del fichero de zona
 Tiene tres tipos de entradas:
 Comentarios: arrancan con (;) y termina al final de la línea.
 Directivas: comienzan con $ y son usadas para controlar los
procesos de los ficheros de zona.
 Resource Records: son usados para definir las características,
propiedades, o entidades contenidas dentro del dominio.
(Cubren una línea o múltiples líneas encerradas entre paréntesis).
 Directivas:
 La directiva $TTL: define el valor Time to Live (TTL) por defecto
para la zona o dominio (obligatoria).
Sintaxis:
$TTL time-in-seconds
$TTL 2d
$TTL 172800
e.j.

52
Formato del fichero de zona (Cont.)
 La directiva $ORIGIN: define el nombre de dominio de la zona
(opcional).
Sintaxis:
$ORIGIN domain-name
$ORIGIN example.com.
; RRs desde aquí se agregara example.com.
e.j.
 La directiva $INCLUDE: permite incluir un fichero externo con
directivas y RRs adicionales.
Sintaxis:
$INCLUDE filename [domain-name]
$ORIGIN example.com.
; RRs desde aquí se agregara example.com.
e.j.

53
name ttl class rr name-server e-mail sn refresh retry expiry min
@ IN SOA ns1.example.com. hostmaster.example.com. (
2014010100 ; sn = serial number
3h ; refresh time
15m ; retry = update retry
3w ; expiry
3h ; min = minimum
)
e.j.
 Resource records: (Los más utilizados)
 El RR Start of Authority (SOA): describe las características
global de la zona o dominio, debe aparecer como primer record en
fichero de zona (solo uno y es obligatorio).
Sintaxis:
 sn → yyyymmddss (yyyy – año, mm – mes, dd – día, ss – número secuencial) –
identifica y se incrementa si hay cambios o actualizaciones de zona.
 refresh time → (#h) – indica si el valor es alcanzado, que el slave server para la zona
intentara y leerá el RR SOA desde la zona máster. Si (sn(m)>sn(s)) una zona de
transferencia es inicializada (valores típicos – 3 a 24h).

54
 retry → (#m) – define el intervalo si el Slave falla para hacer contacto con la zona
máster durante un ciclo de refrescamiento (valores típicos – 10 a 60min).
 expiry → (#w) – define el tiempo después del cual los records de la zona no serán más
autorizados. El Slave contactara la zona máster, de ser posible los contadores retry y
expiry serán inicializados (valores típicos – 1 a 3 semanas).
 min → (#h) – el periodo de tiempo que las respuestas negativas puedan estar
registradas en cache por el Slave (valores típicos – 1 a 3h).
 El RR Name Server (SN): define los RRs SN que son
autoritativos para la zona o dominio (dos o más – pueden referirse
a este dominio o un dominio externo y son obligatorios).
Sintaxis:
name ttl class rr name
; Los resource records servidores de nombres para el dominio
; el primer servidor de nombre para el dominio interno
IN NS ns1.example.com.
; el segundo servidor de nombre es externo a esta zona (dominio)
IN NS ns2.example.net.
e.j.

55
 El RR mail exchange (MX): define los servidores mail para la
zona (0 o más – pueden referirse a este dominio o un dominio
externo y son opcionales).
Sintaxis:
name ttl class rr preference name
; Los resource records servidores mail para el dominio
; el primer servidor mail para el dominio interno
3w IN MX 10 mail.example.com.
; el segundo servidor de nombre es externo a esta zona (dominio)
IN MX 20 mail.example.net.
e.j.
 preference → indica la preferencia relativa o prioridad del servidor mail (rango de
valores – 0 a 65535) – menor valor mayor preferencia (típico 10).
 El RR address (A): define la direccion IPv4 de todos los host o
(servicios) que existen en la zona cuales son requeridos para ser
visibles públicamente (es opcional).
Sintaxis:
name ttl class rr ipv4

56
ns1 IN A 192.168.1.4
mail IN A 192.168.1.2
www IN A 192.168.1.5
tux IN A 192.168.1.10
e.j.
 El RR CNAME: define un RR alias para un host (o servicio)
existente definido por un RR A (0 o más – pueden definirse para la
zona y son opcionales).
Sintaxis:
name ttl class rr canonical-name
(Asignar varias direcciones IP aun mismo servidor)
www IN A 192.168.1.5
IN A 192.168.1.7
IN A 192.168.1.8
e.j.
ftp IN CNAME ftp.example.net.e.j.

57
 Son comúnmente usados para asignar nombres de servicios a un
host existente, esto puede lograse también con varios RR A.
srv-ftp IN A 192.168.1.6
ftp IN CNAME srv-ftp.example.com
e.j.
Tenga PRESENTE (para – RR CNAME)
 Generalmente solo hay dos casos (para los cuales no hay
alternativas disponible):
 Primero: Cuando el host real está en un dominio externo
(ftp.example.com es un alias de ftp.example.net).
 Segundo: Cuando un usuario solicita una dirección a un
sitio web usando www.example.com o justo example.com.
; define un IP que resuelve para example.com
IN A 192.168.254.7
; alias www.example.com para example.com
www IN CNAME example.com.
e.j.
srv-ftp IN A 192.168.1.6
ftp IN A 192.168.1.6
e.j.

58
 El RR PTR: define una dirección IPv4 para un host particular en el
dominio o zona (0 o más – pueden definirse para la zona, pero
solo uno por nombre de host y son opcionales).
Sintaxis:
name ttl class rr name
4 IN PTR ns1.example.com.
2 IN PTR mail.example.com.
5 IN PTR www.example.com.
10 IN PTR tux.example.com.
e.j.
 El RR SRV: son relativamente usados para descubrir servicios
sobre un host (0 o más – pueden definirse para la zona y son
opcionales).
Sintaxis:
_Service._Protocol.domain name [TTL] IN SRV Priority Weight Port
Target-computer.
_http._tcp.www.company.com IN SRV 10 1 80 server1.company.com.
IN SRV 10 3 88 server2.company.com.
e.j.

59
Descripción de los campos:
 Service – especifica el nombre del servicio (LDAP, HTTP, otros).
 Protocol – especifica el protocolo (TCP o UDP).
 domain – record para el dominio www.example.com.
 Priority – determina la prioridad de acceso (ambos records
tienen la misma prioridad 10), el cliente contactara cada uno de
ellos aleatoriamente.
 Weight – indica que los servidores deben ser contactado
aleatoriamente, pero si un número grande de conexiones tiene
lugar, el 25% deben ser echas con servidor1 y un 75% con el
servidor2 (un valor de 0 – Los balanceo de carga no son echo).
 Port – especifica el puerto por el cual el servidor está corriendo.
 Target-computer – especifica el nombre de la computadora en
la cual el servicio está corriendo, si un punto es es colocado el
servicio no es suministrado.

60
Configurar el servicio DNS
 Configurar un Master DNS Server.
 Configurar un Slave DNS Server.
 Configurar un Caching-only DNS Server.
 Configurar un Forwarding (Proxy) Name Server.
 Configurar un Authoritative-only DNS Server.

61
Configurar un Master DNS Server
 Funcionalidades a suministrar:
 Máster para la zona example.com.
 Servicio de caching para otros dominios.
 Fichero de zona: (named.conf.default-zones)
(Máster para la zona example.com)
// clausula zone - master para example.com
zone "example.com" in {
type master;
file "master/master.example.com";
allow-update { none; };
};
// resolución inversa para example.com
zone "1.168.192.IN-ADDR.ARPA" in {
type master;
file "192.168.1.rev";
allow-update {none;};
};
e.j.

62
Configurar un Master DNS Server (Cont.)
 Fichero de zona: (named.conf.options)
(Servicio de caching para otros dominios)
// clausula options : configuración global
options {
directory “/var/named”;
version “No esta actualmente disponibles”;
allow-transfer { 192.168.1.2; };
recursion yes;
};
e.j.
 La sentencia version (para seguridad) evita el hacking conocido como weaknesses si la
versión esta publicada.
 Deshabilitar la zona de transferencia excepto para la Slave en el example.net.
 Opcional – recuerde que el comportamiento de Bind por defecto es recursivo .

63
Configurar un Master DNS Server (Cont.)
 Una alternativa:
(deshabilitar las transferencias de zona en la clausula
options y selectivamente habilitarla en la clausula zone
requerida)
...
options {
...
allow-transfer { none; };
...
}
...
...
allow-transfer { 192.168.1.2; };
...
};
e.j.

64
Configurar un Slave DNS Server
 Slave para la zona example.com y máster para la zona
exanple.net.
 Fichero de zona: (named.conf.default-zones)
(Slave para la zona example.com y master para la zona
example.net)
// clausula zone - slave para example.com
type slave;
file "slave/slave.example.com";
masters (192.168.1.4;);
allow-notify { 192.168.1.4; };
};
e.j.

65
Configurar un Slave DNS Server
// clausula zone - máster para example.net
zone "example.net" in{
type master;
file "master/master.example.net";
};
// resolución inversa para example.net
zone "1.16.172.IN-ADDR.ARPA" IN {
type slave;
file "slave.172.16.1.rev";
masters { 172.16.1.4; };
};
e.j.

66
Configurar un Slave DNS Server (Cont.)
options {
allow-transfer { “none”; };
recursion yes;
};
e.j.
 La sentencia version (para seguridad) evita el hacking conocido como weaknesses si la
versión esta publicada.
 Deshabilitar todas las zona de transferencia.
 Opcional – recuerde que el comportamiento de Bind por defecto es recursivo .

67
Configurar un Caching-only DNS Server
 No es máster ni slave para ninguno dominio y soporta
peticiones recursivas para la zona root.
 Peticiones recursivas para resolvers u otros DNS actuando
en favor de otros resolvers.
options {
recursion yes;
};
e.j.
 Opcional – recuerde que el comportamiento de Bind por defecto es recursivo.

68
Configurar un Forwarding Name Server.
 No es máster ni slave para ninguno dominio.
 No suministra peticiones recursivas.
 Re-direcciona todas la peticiones a un DNS remoto.
(Servicio de caching y redirección para otros dominios)
options {
forwarders { 10.0.0.1; 10.0.0.2; };
forward only;
recursion no;
};
e.j.
 Deshabilitar el suministro de peticiones recursivas.
 Habilitar la redirección.

69
Configurar un Forwarding Name Server.
 Una alternativa:
(deshabilitar la redirección de la clausula options y
selectivamente habilitarla en la clausula zone requerida)
// usar la redirección en la clausula zone
zone "example.net" in {
type forward;
forwarders { 10.0.0.3; };
forward only;
};
e.j.

70
Configurar - Authoritative-only DNS Server
 Máster para la zona example.com.
 No suministra servicio de caching para otros dominios.
 No suministra peticiones recursivas para resolvers u otros
DNS actuando en favor de otros resolvers.
 El servidor es optimizado para maximo rendimiento.
(Máster para la zona example.com)
// clausula zone - master para example.com
type master;
file "master/master.example.com";
};
e.j.

71
Configurar - Authoritative-only DNS Server
// resolución inversa para example.com
zone "1.168.192.IN-ADDR.ARPA" in {
type master;
file "192.168.1.rev";
};
e.j.
(Sin caching y recursividad para otros dominios)
options {
recursion no;
};
e.j.
 Deshabilitar el suministro de peticiones recursivas.

72
 Lab-3: (Configurar el Servicio DNS)
 Habilite dos vmware.
 Configurar el servicio de DNS según el escenario.
Laboratorio

Servicio DNS

Más contenido relacionado

Similar a Servicio DNS

Servicio DNS