Desarrollo de un Servidor Proxy de DNS para Mitigar el

Problema de Enumeracin de Zona en DNSSEC-Edicin nica

Title Desarrollo de un Servidor Proxy de DNS para Mitigar el

Problema de Enumeracin de Zona en DNSSEC-Edicin
nica

Authors Mario Anbal Cruz Hernndez

Afiliacin ITESM-Campus Monterrey

Fecha de 2007-05-01
publicacin

Item type Tesis de Maestra

Downloaded 9-mar-2017 12:48:21

Link to item http://hdl.handle.net/11285/567719

Desarrollo de un Servidor Proxy de DNS para mitigar el
problema de Enumeraci
on de Zona en DNSSEC

por

Ing. Mario Anbal Cruz Hern

andez

Tesis

Presentada al Programa de Graduados de la

Escuela de Tecnologas de Informaci

on y Electr
onica

como requisito parcial para obtener el grado academico de

Maestro en Ciencias

especialidad en

Tecnologa Inform
atica

Instituto Tecnol
ogico y de Estudios Superiores de Monterrey

Campus Monterrey

Mayo de 2007
Instituto Tecnol
ogico y de Estudios Superiores de Monterrey
Campus Monterrey

Escuela de Tecnologas de Informaci

on y Electr
onica
Programa de Graduados

Los miembros del comite de tesis recomendamos que la presente tesis de Mario Anbal Cruz
Hernandez sea aceptada como requisito parcial para obtener el grado academico de
Maestro en Ciencias, especialidad en:

Tecnologa Inform
atica

Comit
e de tesis:

M.C. Alejandro Parra Briones

Asesor de la tesis

M.C. Gustavo Lozano Ibarra Dr. Juan Arturo Nolazco Flores

Sinodal Sinodal

Dr. Graciano Dieck Assad

Director del Programa de Graduados

Mayo de 2007
Dedicada a la familia Cruz Hern
andez
Agradecimientos

Quiero agradecer sinceramente al ITESM Campus Monterrey por haberme apoyado en

el financiamiento de mis estudios profesionales y de maestra y por contribuir en mi formacion
personal, academica y profesional.

A Alejandro Parra Briones, por haberme ayudado en la investigacion y realizacion de esta

tesis, y por la gran cantidad de ense
nanzas que me dej
o a nivel escolar, profesional y personal.

A Gustavo Lozano Ibarra y al personal de NIC Mexico por haber colaborado enorme-
mente con su experiencia y conocimientos para la realizacion de este trabajo y por haberme
facilitado la infraestructura necesaria para poder realizarlo.

A Juan Arturo Nolazco Flores por su contribuci

on, opiniones y recomendaciones a esta
tesis.

A todas las personas, familiares, amigos y a mi novia por todo el apoyo moral otorgado
durante el tiempo de realizacion de este trabajo. Sin ellos, la realizacion de este trabajo no
habra sido posible.

Mario Anbal Cruz Herna

ndez

Instituto Tecnologico y de Estudios Superiores de Monterrey

Mayo 2007

v
 Desarrollo de un Servidor Proxy de DNS para mitigar el
problema de Enumeraci
on de Zona en DNSSEC

Mario Anbal Cruz Hernandez, M.C.

Instituto Tecnologico y de Estudios Superiores de Monterrey, 2007

Asesor de la tesis: M.C. Alejandro Parra Briones

El servicio de DNS y su correcto funcionamiento son considerados de gran importancia

para las comunicaciones que tiene lugar en Internet. La seguridad de dicho servicio no fue una
prioridad durante su desarrollo, por lo que terceros explotaron las vulnerabilidades existentes.
A raz de eso se desarrollaron extensiones de seguridad al servicio, denominadas en su conjunto
DNSSEC, y que se bajan en la criptografa de llave p ublica para que la entidad que reciba
la informaci on de DNS pueda confirmar el origen de la misma y calificarla como fidedigna
o falsificada. Aun as la especificaci
on actual de DNSSEC cuenta con una serie de fallas de
seguridad detectadas que han impedido a las organizaciones implementarlo en sus servidores
de DNS actuales. Una de estas fallas es la enumeraci on de zona, que permite a un individuo que
tenga la posibilidad de solicitar respuestas autenticadas con DNSSEC a un servidor de DNS
autoritativo, conocer todos los nombres de dominio y registros de DNS existentes dentro de la
zona administrada por ese servidor a traves del registro NSEC que fue incorporado al conjunto
de registros de DNS cuando se finalizo el desarrollo de la especificaci on de DNSSEC. Con el
fin de mitigar este problema la IETF cre o la tecnica conocida como firmado en lnea (online
signing), que consiste en la modificaci on del registro NSEC y su posterior firma digital con
el fin de ocultar los dominios validos existentes en la zona y que al mismo tiempo el paquete
pueda ser verificado, lo que es muy demandante en terminos computacionales para el servidor
de DNS que aplica dicha tecnica. El presente trabajo contempla la creaci on de un servidor
Proxy (intermedio) que aplique la tecnica de firmado en lnea para mitigar la enumeraci on de
zona y al mismo tiempo libere al servidor de la carga computacional que implica modificar
y firmar registros al momento que son solicitados por un usuario. El prototipo desarrollado
demostr o en ambientes de prueba y de producci on pasar las pruebas de cadena de confianza y
al mismo tiempo mitigar la enumeraci on de zona. Adem as con el uso de un tarjeta de firmado
digital, el Proxy pudo dirigir las operaciones de firmado a dicha tarjeta en lugar de utilizar
el procesador de la m aquina que lo ejecuta eliminando de este u ltimo la carga computacional
relacionada a las firmas digitales.
Indice general

Agradecimientos V

Resumen VI

Indice de cuadros IX

Indice de figuras X

Captulo 1. Introducci
on 1

Captulo 2. Marco Te orico 5

2.1. Sistema de Nombres de Dominio . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1. Historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.2. Descripci
on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Tipos de Servidores de Nombres . . . . . . . . . . . . . . . . . . . . . 8
2.1.4. Registros de Datos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.5. Estructura de los Mensajes de DNS . . . . . . . . . . . . . . . . . . . 11
2.1.6. Zonas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.1.7. Problemas de Seguridad . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2. DNS Security (DNSSEC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.1. Conceptos B asicos de Criptografa de Llave P ublica . . . . . . . . . . 16
2.2.2. Descripci
on de DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2.3. Registro DNSKEY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2.4. Registro RRSIG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.2.5. Registro NSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.6. Registro DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.7. Bits de Encabezado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2.8. Ordenamiento Can onico de Nombres de Dominio . . . . . . . . . . . . 29
2.3. Enumeraci on de Zona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.4. Soluciones Emergentes al Problema de Enumeraci on de Zona . . . . . . . . . 33
2.4.1. Registro NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.2. Firmado en Lnea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Captulo 3. Definici
on del Problema 38

vii
Captulo 4. Soluci on Propuesta 40
4.1. Antecedentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2. Metodologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3. Configuracion de Servidor de DNS Autoritativo . . . . . . . . . . . . . . . . . 46
4.4. An alisis del trafico generado y recibido por el servidor autoritativo. . . . . . . 48
4.5. Definicion de Plataforma y Lenguaje de Programaci on . . . . . . . . . . . . . 50
4.6. Seleccion de Bibliotecas de DNS . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.7. Desarrollo del Servidor Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.8. Construccion de Ambiente de Pruebas . . . . . . . . . . . . . . . . . . . . . . 63
4.8.1. Ambiente de Pruebas - Proceso Iterativo . . . . . . . . . . . . . . . . . 63
4.8.2. Ambiente de Pruebas - Proceso Recursivo . . . . . . . . . . . . . . . . 65
4.8.3. Problema con Funciones Absolutas . . . . . . . . . . . . . . . . . . . . 68
4.8.4. Ambiente de Pruebas - Rendimiento . . . . . . . . . . . . . . . . . . . 71
4.9. An alisis de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

Captulo 5. Recomendaciones e Investigaciones Futuras 81

Captulo 6. Conclusiones 83

Bibliografa 84

Ap
endice A. Archivo de Zona Utilizado en Servidor Autoritativo 86
A.1. Archivo de Zona sin Firmar zone.test . . . . . . . . . . . . . . . . . . . . . 86
A.2. Archivo de Zona Firmado zone.test.signed . . . . . . . . . . . . . . . . . . 87

Ap
endice B. Archivo de Configuraci
on de Servidor Autoritativo 91

Ap
endice C. Paquetes de Respuesta de DNS 93
C.1. Paquete de Respuesta sin DNSSEC . . . . . . . . . . . . . . . . . . . . . . . . 93
C.2. Paquete de Respuesta con DNSSEC . . . . . . . . . . . . . . . . . . . . . . . 93

Ap
endice D. Librera LDNS 95

Ap
endice E. Registros NSEC Generados por el Servidor Proxy 99

Ap
endice F. Archivos de Configuraci on para Servidor Recursivo 101
F.1. Archivo named.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
F.2. Archivo root.hint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Ap
endice G. Archivos de Configuraci on para Servidor Raz 103
G.1. Archivo named.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
G.2. Archivo root.zone.signed . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

Vita 107

viii
Indice de cuadros

2.1. Estructura de un RR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2. Ejemplos de RR de tipos A, MX y NS . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Estructura de un Paquete de DNS . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4. Encabezado de un Paquete de DNS . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Ejemplo de RR de tipo DNSKEY . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.6. Ejemplo de RR de tipo RRSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.7. Ejemplo de RR de tipo NSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.8. Ejemplo de RR de tipo DS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.9. Enumeracion de Zona . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.10. RDATA de registro NSEC3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.11. RDATA de registro NSEC3PARAM . . . . . . . . . . . . . . . . . . . . . . . 35

4.1. Envo de Diferente N

umero de Registros NSEC . . . . . . . . . . . . . . . . . 58
4.2. Informaci on de BIND 9 provista por dnsperf . . . . . . . . . . . . . . . . . . 72
4.3. Velocidades en Operaciones RSA de 1024 Bits . . . . . . . . . . . . . . . . . . 75
4.4. Tiempos de Espera para Respuestas con DNSSEC . . . . . . . . . . . . . . . 78
4.5. Velocidad en Peticiones x Segundo del Servidor Proxy . . . . . . . . . . . . . 79
4.6. Utilizaci
on del Procesador en Pruebas con dnsperf . . . . . . . . . . . . . . . 79

E.1. Registros NSEC generados por el servidor Proxy . . . . . . . . . . . . . . . . 99

E.2. Registros NSEC generados por el servidor Proxy . . . . . . . . . . . . . . . . 100

ix
Indice de figuras

1.1. Uso de un servidor Proxy para filtrado de informaci

on . . . . . . . . . . . . . 4

2.1. Estructura Jer arquica DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.2. Procesos Recursivo e Iterativo de Peticion de Nombres . . . . . . . . . . . . . 9
2.3. Ataque de Hombre en Medio . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4. Ejemplo de Criptografa de Llave P
ublica . . . . . . . . . . . . . . . . . . . . 16
2.5. Firmado de Mensajes con Llave Privada . . . . . . . . . . . . . . . . . . . . . 18
2.6. Verificacion de Mensajes Firmados . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7. Tipos de almacenamiento de llaves privadas recomendados . . . . . . . . . . . 21
2.8. Inclusi
on de firmas en paquetes de DNSSEC . . . . . . . . . . . . . . . . . . . 22
2.9. Respuesta de DNS con bit de AD . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.1. Paquete de Respuesta de DNSProxy . . . . . . . . . . . . . . . . . . . . . . . 43

4.2. Lectura de Paquete de Respuesta de DNS con Ethereal . . . . . . . . . . . . . 50
4.3. Paquete de Respuesta con DNSSEC en Ethereal . . . . . . . . . . . . . . . . 51
4.4. Arquitectura de Proceso Iterativo . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.5. Paquete de Respuesta del Servidor Proxy . . . . . . . . . . . . . . . . . . . . 65
4.6. Arquitectura de Proceso Recursivo . . . . . . . . . . . . . . . . . . . . . . . . 67
4.7. Paquete de Respuesta del Servidor Recursivo . . . . . . . . . . . . . . . . . . 68
4.8. Arquitectura para Delegacion de Zona . . . . . . . . . . . . . . . . . . . . . . 69
4.9. Paquete de Respuesta en Ambiente de Producci on . . . . . . . . . . . . . . . 71
4.10. Tarjeta de Firmado Digital Niagara 2100B . . . . . . . . . . . . . . . . . . . . 73
4.11. Utilizaci
on del CPU en Pruebas con dnsperf . . . . . . . . . . . . . . . . . . 76
4.12. Utilizaci
on del CPU en Pruebas con dnsperf y Tarjeta Niagara . . . . . . . . 77
4.13. Comparativo de Rendimientos en el Servidor Proxy . . . . . . . . . . . . . . . 79

x
Captulo 1

Introducci
on

El incremento contin uo de usuarios de Internet a partir de la decada de los 90, acom-

panado del crecimiento de la capacidad de transmision de las redes de comunicaciones, ha
significado un aumento en la dependencia que se tiene hacia el sistema de nombres de dominio
(DNS) para la correcta operacion por parte de los usuarios de los servicios que se ofrecen en
Internet. La posibilidad de relacionar nombres con direcciones IP (de 32 bits en su version 4,
128 para la version 6), ha facilitado por mucho la experiencia de los usuarios de Internet con
diversos servicios como Web, correo electronico, mensajera instantanea, etc., puesto que es
mas sencillo recordar nombres que secuencias de n umeros [1]. Dichos nombres pueden ser de
empresas, personas, gobiernos de pases, etc., que las personas pueden reconocer m as facil-
mente que una secuencia de n umeros.

Adem as de permitir a los usuarios acceder de manera sencilla a la informaci

on contenida
en Internet, el servicio de DNS permite que dicha informaci on este disponible para todos los
usuarios de la red en el mundo [1]. Al publicar un recurso (documento, foto, sonido, video)
en la Internet, se puede acceder a este con solo conocer el nombre asociado a la direccion
IP de la computadora que lo contiene, y en caso de el servidor de DNS no cuente con dicha
informaci
on puede obtenerla buscando en otros servidores de DNS hasta dar con la asociaci on
del nombre solicitado con la correspondiente direccion IP.

Creada en 1984 por Paul Mockapetris, la especificacion del servicio de DNS (RFCs 882
y 883) describe al servicio como una base de datos distribuida que almacenara los nombres
de hosts (computadoras) y su correspondiente direccion IP, sustituyendo de esta manera a
los archivos de nombres de hosts (hosts.txt) locales a cada computadora y que contenan la
informacion de dicho mapeo [8].

A pesar de todos los beneficios que proporciona el sistema de nombres de dominio,

el dar seguridad y certeza a los usuarios y proveedores sobre la informaci on proporcionada
mediante dicho servicio no fue parte primordial de la especificacion original de DNS. En los
90s cuando el uso del archivo hosts.txt se volvio inviable y el uso de servidores de DNS
aumento considerablemente, se detectaron las siguientes fallas de seguridad en dicho servicio
[8]:

La naturaleza del servicio de DNS lo hace propenso a ataques de negacion de servicio

1
 (DoS), ya que el tama no de las peticiones es mucho menor comparado con el tama
no
de las respuestas que enva el servidor de DNS.

No existe forma de verificar que las entradas (relaci on nombre con direccion IP) son
legtimas ya que no existe un sistema de autenticaci
on para las mismas.

La comunicaci on entre clientes y servidores de DNS no esta protegida, permitiendo a

un intruso interceptarlas y crear peticiones y respuestas propias mientras estas estan en
marcha.

No existe autenticaci
on para servidores de DNS, por lo que un tercero podra hacerse
pasar por un servidor de DNS valido y redirigir las peticiones de los clientes a computa-
doras de su propiedad.

A raz de estos descubrimientos, los intentos de ataque contra este servicio se incremen-
taron y muchos lograron fructificar como el ataque ocurrido en 1997 realizado por Eugene
Kashpureff. En dicho ataque Kashpureff rediriga a los usuarios del sitio Web de Network
Solutions a un sitio Web de su autora [7]. En 1993, en una reunion de la IETF (Internet
Engineering Task Force) celebrada en Houston, se inicio el trabajo en una especificaci on del
servicio de DNS que involucrara a la seguridad como una caracterstica principal del mismo
[8]. Ataques como el de Kashpureff lograron acelerar el proceso de creacion de la especificaci
on
para que incluso ahora este disponible para servidores de DNS de naturaleza abierta como
BIND.

Los requerimientos principales para la nueva especificaci

on de DNS, denominada DNSSEC
(DNS Security), abarcan la integridad de los datos y la autenticaci on del origen de los mismos.
Dicha especificacion no incluye la encriptacion de los datos que por naturaleza son p ublicos
y la autenticaci on entre clientes y servidores previo al intercambio de mensajes, esto u lti-
mo para hacerlo compatible con los servidores que implementan el servicio de DNS con la
especificaci
on original [8]. La especificaci
on de DNSSEC implica el uso de mecanismos crip-
tograficos de llave p
ublica para el firmado de la informaci on contenida en cada servidor de
DNS. El firmado consiste en utilizar una funcion de hash sobre la informaci on contenida en
los archivos del servidor para obtener un valor que debera ser identico al pasar la informacion
a otro servidor o de lo contrario se considerar a que la informacion ha sido alterada y por lo
tanto no es fidedigna [6]. De esta manera un cliente de DNS (resolver ) puede comprobar que
la informacion que recibe de una consulta proviene en efecto de un servidor legitimo de DNS.

A pesar de las ventajas provistas en materia de seguridad por DNSSEC, se han detectado
diversas fallas en la especificaci
on original que han impedido la implementaci
on de DNSSEC
a gran escala [10]:

1. La especificaci
on actual permite conocer todos los registros (nombres de dominio) dentro
de una zona (conjunto de nombres) al proporcionar los registros anterior y posterior al
nombre solicitado cuando dicho nombre no existe en el servidor de DNS. Un individuo

2
 podra enumerar todos los registros contenidos en el servidor de DNS (zone walking o
enumeracion de zona) y realizar ataques a ese servidor si es que contiene un registro del
nombre de dominio que quiera atacar.

2. Actualmente el intercambio de llaves (key rollover ) para comprobar la autenticidad de

los datos que un servidor de DNS ostenta se realiza en forma manual, requiriendo la
intervencion de los administradores de los servidores cada vez que las llaves se modi-
fiquen.

3. Es actualmente objeto de controversia la decisi on de que entidad (organizacion) se

encargara del firmado en los servidores de DNS de mayor jerarqua, los servidores raz.

4. No existe consenso en la manera que deben de proceder las aplicaciones que solicitan
informacion a servidores de DNS con DNSSEC implementado al recibir una respuesta
no valida.

Este trabajo de investigacion presenta una alternativa de solucion al primer problema

de DNSSEC descrito con anterioridad (enumeraci on de zona), mediante la construcci on de
un servidor Proxy que sirva de intermediario entre clientes de DNS y un servidor autoritativo
de DNS con DNSSEC implementado. El Proxy cumplira la funcion de filtrar la informaci on
que no se desea que sea publica para los clientes y que debido a la especificaci
on de DNSSEC,
el servidor autoritativo divulgara. Para lograr este fin, el servidor Proxy implementar a una
tecnica conocida como firmado en lnea, que fue propuesta como solucion al problema de
enumeraci on de zona, que implica modificar la informaci on contenida en los registros que son
devueltos al cliente, ademas de firmar digitalmente dichos registros antes de devolverlos. La
implementaci on del firmado en lnea en el servidor autoritativo de DNS, implica que dicho
servidor tendra que efectuar trabajo adicional para firmar las peticiones y ocultar la informa-
cion que pueda permitir a los clientes enumerar los registros de la zona.

La presente tesis analiza como con el uso de un servidor Proxy que implemente el pro-
cedimiento de firmado en lnea, apoyado de una tarjeta electronica equipada con su propio
procesador y que se utilice exclusivamente para firmar digitalmente la informaci on modifi-
cada por el Proxy, se puede impedir la enumeraci on de zona, eliminando al mismo tiempo
del servidor autoritativo la carga computacional que implica realizar el firmado en lnea, ya
que el Proxy le provee de ese servicio. Adem as se analiza el impacto en cuanto a peticiones
resueltas por segundo provocado por tener un servidor Proxy filtrando (y firmando) informa-
ci
on que va dirigida los clientes. Esto puede observarse en la figura 1.1, donde se explica el
funcionamiento general del servidor Proxy. En un primer punto el cliente enva su peticion
al servidor Proxy, la cual es redirigida al servidor autoritativo para que la responda como
cualquier peticion normal de DNS. El servidor autoritativo devuelve la respuesta al Proxy y
es en este momento cuando el Proxy act ua, modificando el paquete original si dicho paquete
contiene registros que permitan enumerar la zona. La computadora donde el Proxy se ejecu-
ta, tambien contiene la tarjeta electronica que permite al CPU de la computadora delegar

3
las operaciones de firmado digital al procesador de dicha tarjeta. Finalmente el paquete ya
firmado y modificado es devuelto al cliente, que asume la respuesta como proveniente de un
servidor autoritativo. Cabe aclarar que la comunicaci on entre el cliente, el Proxy y los servi-
dores autoritativos sera a traves del intercambio de datagramas (UDP), tal y como ocurre
con la mayora de las implementaciones de DNS que existen en la actualidad.

Figura 1.1: Uso de un servidor Proxy para filtrado de informaci

on

En las siguientes secciones se incluye el marco te orico necesario para la investigacion y

posteriormente se define el problema a tratar en la investigacion, para despues abordar la
solucion propuesta al mismo, incluyendo los resultados obtenidos al aplicar dicha solucion.
Finalmente se incluyen recomendaciones para futuros trabajos en esta area y se enumeran las
conclusiones a las que se llegaron durante la realizacion de este trabajo.

4
Captulo 2

Marco Te
orico

En esta secci
on se describe el sistema de nombres de dominio DNS para posteriormente
presentar la especificaci
on DNSSEC y los problemas asociados a la misma, haciendo enfasis
en el problema de enumeraci on de zona, finalmente se describen las soluciones existentes y en
desarrollo a dicho problema.

2.1. Sistema de Nombres de Dominio

El Sistema de Nombres de Dominio es en s una base de datos distribuida, donde se alma-
cenan y asocian muchos tipos de informacion, pero que predominan los datos donde se asocian
direcciones IP a nombres de dominio de Internet como por ejemplo, la direccion 192.168.2.170
se asocia con el nombre de dominio ejemplo.com., as los usuarios que introduzcan en sus
programas de aplicacion (navegadores de Internet, clientes de correo electronico, etc.,) dicho
nombre, seran redirigidos con la ayuda de un servidor de DNS a la m aquina que tenga asig-
nada dicha direccion IP [1].

2.1.1. Historia
En los a
nos 70, la red que fue antesala de la Internet, ARPAnet gozo de un crecimiento
moderado que le permitio satisfacer las necesidades de los usuarios sin requerir grandes in-
versiones de esfuerzo para asegurar su escalabilidad.

En ese entonces ya se contaba con un sistema de nombres de dominio, dicho sistema

era local a cada computadora y consista en un archivo de texto (hosts.txt) que contena
relaciones de direccion numerica y nombre de dominio para cada computadora conectada a la
ARPAnet. Dicho archivo era actualizado por el Stanford Research Institute (SRI) mediante su
Network Information Center (NIC). El uso de un archivo local a cada m aquina para mapear
nombres de dominio con direcciones IP era justificado ya que en ese entonces el n umero de
computadoras conectadas a la ARPAnet era reducido. Pero conforme el n umero de computa-
doras conectadas que demandaban contar con un nombre de dominio para ser identificados
con mayor facilidad aumento, el tama no del archivo se incremento y las constantes modifica-
ciones realizadas a dicho archivo obligaron a los usuarios a actualizar con frecuencia su propia

5
versi
on del archivo hosts.txt para esta al da [1].

Una solucion escalable era demandada para los problemas que representaba el estar
moviendo constantemente un archivo que creca exponencialmente a medida de que ARPAnet
fue adoptando el modelo TCP/IP como esquema de direccionamiento. Problemas de consis-
tencia del archivo (diferencias entre versiones) y de colisi
on de nombres (nombres de do-
minio repetidos para diferentes direcciones IP) provocaron que las entidades de gobierno de
ARPAnet empezaran a trabajar por una solucion que permitiera una administracion local de
la informacion referente al mapeo de nombres con direcciones pero que al mismo tiempo las
actualizaciones fueran disponibles globalmente. En dichos trabajos iniciados por las autori-
dades, se describieron las cualidades que debera de tener el nuevo sistema, principalmente
la de estar basado en una estructura jerarquica para asegurar que los nombres de dominio
utilizados sean u
nicos [1].

En 1984, Paul Mockapetris del Information Sciences Institute de la USC dise no la ar-
quitectura del DNS como lo conocemos actualmente. En los documentos RFC 882 y 883,
el describe la estructura jerarquica del sistema de nombres, parte central del mismo. Pos-
teriormente se hicieron revisiones a la especificacion de DNS original y se incluyeron dichas
modificaciones en los documentos RFC 1034 y 1035, que con el transcurso del tiempo tam-
bien han sido modificados para incluir aspectos que no se tomaron en cuenta en las primeras
especificaciones como los mecanismos de actualizacion, seguridad, etc., por ejemplo el RFC
3425 que actualiza s olamente del RFC 1035 la secci on 6.4 que se refiere a las peticiones in-
versas de DNS (preguntas para obtener el nombre de dominio de la m aquina para la que ya
se conoce la direccion IP correspondiente) [1][14].

2.1.2. Descripci
on
Como se mencion o anteriormente, el sistema de nombres de dominio DNS es una base
de datos distribuida donde se almacena la informaci on de los equipos conectados a la red que
cuentan con un nombre de dominio propio para que puedan ser identificados con facilidad.
Se ha utilizado a lo largo de este escrito la palabra servicio para referirse al DNS, debido
a que este sistema funciona a traves de un esquema cliente - servidor, donde la computa-
dora que tenga asignado el rol de servidor, ejecutar a un programa denominado servidor de
nombres que sera el encargado de proporcionar a la computadora que tiene el rol de cliente,
la relaci
on direccion IP - nombre de dominio cuando la computadora cliente le enve una
peticion a traves de programas denominados resolvers. Los resolvers tambien se encargan
de recibir las respuestas del servidor y hacerlas disponibles para las aplicaciones locales de
los clientes como navegadores de Web o programas que reciban y enven correo electronico [1].

Adem as de los resolvers y los servidores de nombres, la informaci

on intercambiada entre
servidores y clientes en forma de peticiones y respuestas constituye una de las tres partes
fundamentales del sistema de nombres. Dicha informaci on es conocida como registro y en

6
cada registro se localiza la direccion IP con su correspondiente nombre de dominio [9].

Los registros de DNS se encuentran organizados de manera jer arquica, de manera similar
a la estructura de datos conocida como arbol binario de b usqueda, pero los nodos existentes
en dicho arbol pueden contar con m as de 2 ramificaciones. Cada nodo cuenta con una etique-
ta de texto que identifica el nodo con respecto a su nodo padre, mientras que el nodo raz
(root) tiene el caracter . (punto) como etiqueta de texto. Cada nodo representa una particion
del conjunto de dominios y puede ser dividido en subdominios especficos para ese dominio [1].

En la figura 2.1 [1][9], se observa la estructura de datos jer

arquica utilizada por el servicio
de DNS, teniendo en el nodo raz al caracter punto y si uno desciende el arbol hasta llegar a
un nodo hoja, se puede formar un nombre de dominio completo. Por ejemplo, si se desciende
por el
arbol por el nodo hijo del nodo raz y marcado con la palabra com, posteriormente se
desciende por el nodo hijo example y finalmente se llega al nodo hoja www, formando as el
nombre de dominio www.example.com., notese el punto al final del nombre de dominio para
denotar el nodo raz.

Figura 2.1: Estructura Jer

arquica DNS

En la actualidad, organizaciones privadas y p ublicas poseen y mantienen conjuntos de

subdominios de nombres que pueden ser utilizados por las mismas organizaciones para fa-
cilitar el acceso a los productos y servicios que ofrecen o tambien las organizaciones pueden
rentar o vender dichos nombres a particulares. Cabe recalcar que la administracion del nodo
raz y de sus hijos directos (edu, gov, com, mil, etc.) recae en los Network Information Cen-
ters, ninguna otra organizacion puede administrar dichos nodos del arbol.

Se hablo anteriormente de manera general de los servidores de nombres y clientes (re-

7
solvers) como componentes principales del servicio de DNS, ahora se profundizara en los tipos
de servidores nombres, tipos de registros de nombres de dominio, estructura de las peticiones
de informacion (preguntas y respuestas) y las agrupaciones de la informacion para facilitar
la administracion de la misma (zonas). Tambien se presenta informaci
on sobre los problemas
de seguridad que aquejan al servicio en su especificaci
on original.

2.1.3. Tipos de Servidores de Nombres

Los servidores de nombres pueden que no posean la informaci on que los clientes les
solicitan sobre ciertos dominios, por lo que pueden contar con la funcionalidad de preguntar
por dicha informaci on a servidores de nombres ubicados en un nivel superior del arbol de
dominio antes presentado, estos a su vez podran preguntar a servidores que s cuentan con la
informacion o dar ellos mismos una respuesta al cliente sobre la existencia (o no existencia)
de dicho dominio en sus registros. Estas funciones clasifican a los servidores de nombres en
recursivos y autoritativos respectivamente:
Servidores Recursivos: Se les denomina as a este tipo de servidores porque utilizan
la resoluci
on recursiva, proceso que consiste en enviar peticiones recursivas a servidores
de nombres para encontrar informaci on sobre un dominio que el servidor recursivo no
posee [1]. Las peticiones del servidor recursivo son realizadas al servidor de dominio raz
y posteriormente van descendiendo el arbol de dominios hasta topar con el servidor de
dominio que si tiene la respuesta a la peticion del cliente (ver figura 2.2).

Servidores Autoritativos: Estos servidores realizan el proceso iterativo, en el cual el

servidor devuelve la respuesta m as completa sobre los dominios que dichos servidores
poseen (administran). Solo existe una respuesta para cada peticion y no se realizan
preguntas adicionales a otros servidores si el servidor no cuenta con la informaci on
solicitada [1]. En este ultimo caso, el servidor devolvera al cliente informaci
on que le
podra servir para localizar al servidor que s tiene la respuesta a su peticion. Estos
servidores se encargan de administrar conjuntos de nombres de dominio ubicados en
niveles inferiores del
arbol de nombres de dominio (ver figura 2.1), por lo que son de
vital importancia para el funcionamiento correcto de la Internet y por consiguiente tam-
bien son frecuente blanco de ataques.

En la figura 2.2 [1], se observa un ejemplo de una peticion realizada por un cliente que
desea conocer la direccion IP del dominio girigiri.gbrmpa.gov.au (etapa 1). Dicha peticion
es recibida por el servidor recursivo que al no contar con la informaci on pregunta al servidor
de DNS raz (etapa 2) por la direccion IP del dominio solicitado por el cliente. El servidor
raz le responde (etapa 3) con la direccion IP del servidor que ubicado en el segundo nivel
de la jerarqua que tiene autoridad sobre el dominio au. Al recibir esa respuesta, el servidor
recursivo repite el proceso de preguntar a un servidor autoritativo, en este caso au por la
direccion IP del dominio solicitado (etapa 4). El servidor autoritativo da la mejor respues-
ta al proporcionar la direccion IP del servidor que administra el dominio gov ubicado en el

8
tercer nivel de la jerarqua (etapa 5). En las etapas posteriores se sigue el mismo esquema
de peticiones y respuestas utilizado con los servidores autoritativos, hasta que se llega con
el servidor que administra el dominio gbrmpa y que tiene autoridad para dar informaci on de
los dominios ubicados en el nivel inmediato inferior, en este caso el dominio girigiri. Final-
mente la informaci on es devuelta al servidor recursivo quien a su vez devuelve el resultado
obtenido al cliente. Como se observa, en una peticion a un servidor recursivo, se combinan
los procesos recursivo e iterativo.

Figura 2.2: Procesos Recursivo e Iterativo de Peticion de Nombres

2.1.4. Registros de Datos

Como se explico con anterioridad el DNS puede verse como una base de datos, donde
los registros de datos denominados Resource Records (RR) para el servicio de DNS contienen
la informacion (direcciones IP) que requieren los clientes para poder acceder a los servicios
de Internet [9]. En una base de datos conformada por renglones y columnas, los registros de
datos son los renglones, mientras que las columnas seran los elementos que conforman cada
uno de los registros.

9
 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
NAME
TYPE
CLASS
TTL
RDLENGTH
RDATA

Cuadro 2.1: Estructura de un RR

En el cuadro 2.1 [15], se pueden apreciar los campos que componen la estructura de un
RR. Las longitudes de dichos campos se miden en bits, que es la unidad de datos utilizada
para expresar el tama no de los campos de los RR que van includos en los paquetes de datos
que se envan y se reciben para el servicio de DNS. Dicha estructura se describe a continuaci
on
[9][15]:

NAME: Tambien conocido como Owner Name, este es el nombre del dominio al que
pertenece el RR.

TYPE: Campo de 16 bits que denota el tipo de RR. Los tipos de registros se refieren
los recursos y servicios asociados a un nombre de dominio. Los tipos de registro que
existen desde la primera especificaci
on de DNS son los siguientes y son solicitados con
mayor frecuencia por los clientes son los siguientes:

A: Tipo de registro que indica que se incluye la direccion IP versi

on 4 del nombre
de dominio correspondiente.
AAAA: Igual que el tipo A, pero la direccion IP que se enva esta formateada en
su versi
on 6.
NS: Tipo de registro que indica que el nombre de dominio corresponde a un servi-
dor de nombres autoritativo.
CNAME: Identifica al nombre de dominio como un nombre canonico para un
alias. Los nombres canonicos representan nombres calificados para funcionar como
nombres de dominios ya que respetan reglas de tama no m
aximo para los nombres
de dominio (255 caracteres, 63 caracteres entre cada caracter . para las etiquetas)
y adem as respetan las reglas de uso del caracter . como la de incluirlo siempre al
final de cada nombre de dominio.
SOA: Identifica al nombre de dominio como el inicio de una zona de autoridad.
MX: Tipo de registro que indica que el nombre de dominio corresponde a un
servidor de correo electronico.

CLASS: Valor de 16 bits que indica la familia de protocolos a la que corresponde

el RR. Para esta investigacion la familia de protocolos utilizada es la familia IN, que
corresponde a los protocolos existentes en la Internet.

10
 NAME TTL CLASS TYPE RDATA
itesm.mx. 3600 IN A 200.34.200.229
google.com. 10800 IN MX 10 smtp1.google.com.
yahoo.com. 172800 IN NS ns1.yahoo.com.

Cuadro 2.2: Ejemplos de RR de tipos A, MX y NS

TTL: Entero de 32 bits con signo que especifica el intervalo de tiempo que el RR
sera almacenado en el cache del servidor antes de que la informaci on tenga que ser
consultada de nuevo. La utilidad de este campo radica en que los servidores de nombres
pueden almacenar en el cache informaci on de los nombres de dominio m as solicitados
y as atender de una manera m as rapida a los clientes ya que no se ejecutara ning
un
proceso iterativo y recursivo porque la informacion esta disponible.

RDLENGTH: Entero de 16 bits que indica la longitud del campo RDATA que contiene
la informaci
on relativa al nombre de dominio. Por lo general los resolvers no desplie-
gan este campo al presentar la informaci
on obtenida del servidor sino que se salta de
inmediato a presentar el campo RDATA.

RDATA: Campo que contiene una cadena de caracteres de longitud variable que des-
cribe al recurso. Los datos de este campo se formatean de diferente manera de acuerdo
al tipo y clase del RR. Para registros A y AAAA, aqu se incluira la direccion IP co-
rrespondiente al nombre de dominio ubicado en el campo de Owner Name.

El cuadro 2.2 presenta ejemplos de RR de tipos MX, NS y A de dominios conocidos.

Observese que en el caso de los RR de tipo NS y MX, no se devuelve una direccion IP como
el tipo A, sino que se devuelve el nombre de dominio al que se refiere el tipo de RR solicitado.
Estos registros se consultaron utilizando la herramienta dig que viene instalada por default
en el sistema operativo Linux en sus versiones recientes. Tecleando el comando mas el nombre
del dominio y el tipo de registro a buscar (dig dominio RRTYPE), se obtuvieron los RR del
cuadro 2.2.

2.1.5. Estructura de los Mensajes de DNS

El servicio de DNS se encuentra ubicado en la capa de aplicacion de los modelos OSI
y TCP/IP, al igual que el servicio de Web (HTTP), de correo electronico (SMTP) y trans-
ferencia de archivos (FTP). La informacion y las peticiones para este servicio se envan por
el puerto 53 del protocolo UDP, por lo tanto este servicio no esta orientado a la conexi on,
por lo que si el mensaje de respuesta a una peticion llega a perderse en el trayecto por la
red de comunicaciones, el cliente debe enviar de nuevo la pregunta al servidor para esperar
la respuesta de nuevo.

11
 En la especificacion original de DNS realizada por Paul Mockapetris, se definio tam-
bien la estructura de los mensajes (paquetes de informacion) que seran intercambiados entre
clientes y servidores. Se especificaron los campos que contendran los paquetes de informaci
on
y el tama no de los mismos se fijo a un m aximo de 512 bytes, que es el tamano m aximo per-
mitido para un datagrama (denominacion del paquete de informaci on del protocolo UDP) [15].

HEADER
QUESTION
ANSWER
AUTHORITY
ADDITIONAL

Cuadro 2.3: Estructura de un Paquete de DNS

En el cuadro 2.3 [15], se observa la estructura de un paquete de DNS, dicha estructura es

la misma para los paquetes de preguntas y de respuestas, pero en los paquetes de preguntas,
solo se incluyen las secciones del encabezado y la seccion de pregunta que contiene el nombre
del dominio por el que se esta solicitando informaci on al servidor de DNS. Un paquete de
respuesta incluye adem as de las dos secciones que se incluyen con el paquete de pregunta,
al menos una de las secciones posteriores, ya sea la de respuesta (si es que la b usqueda fue
exitosa) o las secciones autoritativa y adicional en el caso de que la b
usqueda no haya trado
resultados.

Una cabecera de un paquete de DNS ya sea de peticion o de respuesta, incluye campos

que contienen informaci on importante para poder identificar un paquete de peticion con su
correspondiente respuesta, tambien la informaci on de los campos es utilizada por los servi-
dores para realizar un proceso de b usqueda de la informaci on de acuerdo a la solicitud hecha
por el cliente si les es posible. En el cuadro 2.4 [15], se incluyen los elementos que conforman
la cabecera de un paquete de DNS [15].

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
ID
QD OPCODE AA TC RD RA Z RCODE
QDCOUNT
ANCOUNT
NSCOUNT
ARCOUNT

Cuadro 2.4: Encabezado de un Paquete de DNS

12
Los campos de la cabecera se definen a continuaci
on [15]:

ID: Un identificador de 16 bits asignado por el programa que creo la peticion. El servidor
que genere la respuesta a esa peticion anadira el mismo valor de ID al entregar el RR
al cliente, con el fin de que el cliente pueda identificar la respuesta correspondiente a
cada pregunta que hizo al servidor.

QR: Este campo cuenta con un bit que especifica si el paquete corresponde a una
pregunta (valor del bit es 0) o de una respuesta (valor del bit es 1).

OPCODE: Este es un campo de 4 bits que especifica el tipo de peticion de un mensaje

de DNS. El valor es colocado por el creador de la peticion y es copiado en el mensaje de
respuesta. Para esta investigacion, s
olo se manejar
an peticiones estandares, por lo que
el valor de OPCODE utilizado sera de 0.

AA: Campo de un bit que indica si el servidor que responde tiene autoridad sobre el
dominio por el que se pregunto (valor del bit es 1 para servidores autoritativos).

TC: Campo de un bit que indica si el mensaje fue truncado debido a que sobrepasa el
tama
no permitido en unidades de datos para ser transmitido en la red (valor del bit es
1).

RD: Campo de un bit, que encendido indica que se desea que el servidor que recibe
la peticion realice un proceso recursivo de b usqueda a otros servidores para obtener la
informaci on solicitada por el cliente. El cliente se encarga de colocar el valor de este bit
en el paquete de pregunta y dicho valor es copiado en el paquete de respuesta.

RA: Campo de un bit que es encendido o apagado en el paquete de respuesta por el

servidor de nombres. Denota en caso de que el valor del bit sea 1 que la respuesta provino
de un proceso recursivo y que dicho proceso esta disponible para futuras b usquedas.

Z: Campo reservado para uso futuro. Tiene el valor de 0 para los dos tipos de paquetes.

RCODE: Campo de 4 bits similar al campo OPCODE, pero este se utiliza para denotar
el tipo de respuesta recibida. Para esta investigacion el valor del campo sera de 0 para
denotar que no hubo error en la respuesta y la busqueda fue exitosa, o de 3 para denotar
que no hubo error en la respuesta pero no se obtuvieron resultados en la b usqueda.

QDCOUNT: Campo de 16 bits que contiene un entero sin signo que especifica el
n
umero de entradas (RRs) en la secci
on de preguntas.

ANCOUNT: Campo de 16 bits que contiene un entero sin signo que especifica el
n
umero de entradas (RRs) en la secci
on de respuestas.

NSCOUNT: Campo de 16 bits que contiene un entero sin signo que especifica el
n
umero de entradas (RRs) en la secci
on autoritativa.

13
 ARCOUNT: Campo de 16 bits que contiene un entero sin signo que especifica el
n
umero de entradas (RRs) en la secci
on adicional.

La secciones de pregunta, respuesta, autoritativa y adicional, estan formadas de RRs

que tienen el formato mencionado con anterioridad. Los servidores deben incluir al menos una
de las tres u
ltimas secciones y opcionalmente pueden incluir las demas para proporcionar al
cliente una mayor informaci on sobre el nombre de dominio por el que pregunto. Por ejemplo,
un registro SOA ir a incluido en la secci
on autoritativa cuando un servidor autoritativo res-
ponda a una peticion para la cual no encontro respuesta, para asegurar al cliente que dicho
servidor tiene autoridad sobre la zona y desconoce el nombre de dominio preguntado.

2.1.6. Zonas
En la terminologa de DNS, existen las Zonas, que representan un conjunto de nombres
de dominio administrados por un servidor de DNS que tiene autoridad sobre ellos. La ventaja
de agrupar grupos de dominios en zonas radica en que el conjunto de dominios puede ser
manejado como una sola unidad que puede ser delegada a una organizacion para su mejor ad-
ministracion, por ejemplo, todos los nombres de dominio que esten ubicados debajo del nodo
itesm.mx. seran administrados por el Instituto Tecnologico de Monterrey. Dichos dominios
pueden ser mty.itesm.mx., chs.itesm.mx., etc. Para este caso, la zona sera denominada
como itesm.mx. [1].

La zona contiene los nombres de los dominios contenidos dentro del dominio utilizado
para nombrar a la zona. Inclusive si los nombres de dominio no han sido asignados a un RR,
estos nombres son agregados a la zona para tenerlos reservados para uso futuro [1]. La zona
dentro del servidor de DNS se presenta en un archivo de texto que contiene todos los RR que
la zona contiene.

2.1.7. Problemas de Seguridad

Como se mencion o con anterioridad, el principal problema de seguridad de la especifi-
cacion original de DNS es la falta de protecci
on que existe en la comunicaci
on entre clientes y
servidores. Al ser un servicio basado en datagramas, un intruso podra capturar los paquetes
dirigidos al servidor de nombres (complemente legibles para el por la naturaleza p ublica del
DNS), y proporcionar a los clientes respuestas forjadas por el mismo. Este ataque a la seguri-
dad es una forma de ataque de hombre en medio, ya que la comunicaci on entre dos entidades
es interceptada y posiblemente alterada por un tercero.

En la figura 2.3, puede observarse como funciona un ataque de hombre en medio para
el caso del servicio de DNS (otros servicios tambien pueden ser afectados si no existe auten-
ticaci
on entre clientes y servidores). El atacante se hace pasar por el servidor de DNS y el

14
 Figura 2.3: Ataque de Hombre en Medio

cliente dirige erroneamente sus paquetes de pregunta a la computadora de este en lugar de

dirigirlos al servidor de DNS legtimo. El atacante puede leer dichos paquetes y reenviarlos al
servidor de DNS como si fueran peticiones suyas, por lo que el servidor de DNS le contestara al
atacante y no al cliente original. El atacante puede entonces leer o modificar la respuesta antes
de enviarla al cliente original para que este siga creyendo que esta interactuando realmente
con el servidor de DNS y las respuestas son legtimas.

En la especificaci
on original de DNS no era posible constatar la veracidad de la informa-
ci
on intercambiada, por lo que la IETF plante o extensiones de seguridad al servicio original
que sirvieran para asegurar la veracidad de la informaci on que se recibe de los servidores y
clientes de DNS.

2.2. DNS Security (DNSSEC)

Los problemas de seguridad anteriormente mencionados en el servicio de DNS, hicieron
inminente un replanteo de los procesos de envo de respuestas a los clientes para garantizar
a estos que la informaci on devuelta realmente proviene de servidores de DNS autenticos y
no de servidores ap ocrifos o de paquetes de informacion forjados por un atacante. La crip-
tografa de llave p
ublica fue incorporada al servicio de DNS para firmar los registros con la
estampa del servidor de DNS, de manera que un cliente puede comprobar que al recibir un
RR realmente proviene de un servidor de DNS legtimo verificando la firma que acompa na
al RR. La especificaci on de DNSSEC incorpora los conceptos de criptografa de llave p
ublica
para el firmado de los RR. Dichos conceptos seran expuestos a continuaci on para facilitar el
entendimiento de los procesos de firmado sobre los registros.

15
2.2.1. Conceptos B
asicos de Criptografa de Llave P
ublica
A la criptografa de llave publica se le conoce como criptografa asimetrica, donde los
individuos que deseen cifrar informaci on cuentan con dos llaves, una privada y la otra publica,
a diferencia del cifrado simetrico, donde se utiliza la misma llave para cifrar y descifrar. Con
el cifrado asimetrico, el individuo conserva su llave privada como secreta mientras que la llave
publica la pone a disposicion de los individuos que quieran enviarle mensajes cifrados a el. La
llave publica es entonces utilizada para cifrar mensajes que solo el poseedor de la llave privada
correspondiente podra descifrar. Esto puede observarse en la figura 2.4 [5], donde suponiendo
que Jane quiere enviarle un mensaje cifrado a John, har a uso de la llave p
ublica de John para
cifrar el mensaje antes de transmitirlo, dicho mensaje s olo podra ser descifrado por la llave
privada de John en cuanto este lo reciba [5].

Figura 2.4: Ejemplo de Criptografa de Llave P

ublica

La ventaja de utilizar 2 llaves para el proceso de cifrado y el proceso inverso, radica

en la administracion de las mismas. Los individuos que deseen cifrar mensajes a un tercero
solamente necesitan la llave publica de este, que esta disponible para todos los que deseen
utilizarla. La llave privada no requiere ser transmitida a otros individuos como ocurra con
el esquema simetrico, esquema que comprometa la llave de cifrado si esta era interceptada
mientras se transmita. Adicionalmente, no es posible derivar la llave privada de la llave p
ubli-
ca aunque esten relacionadas matem aticamente.

Para la generacion de llaves tanto privadas como p

ublicas existen diversos algoritmos
matem
aticos que demandan mayor capacidad de procesamiento que los algortimos que gene-

16
ran llaves simetricas por el simple hecho de generar dos llaves en lugar de una sola. Al final, las
llaves son valores numericos generadas por los algoritmos, donde dependiendo de su longitud,
pueden ser m as faciles o m
as difciles de adivinar por parte de un individuo ajeno a estas. Por
lo general los algoritmos manejan tama nos de 1024 bits para las llaves que generan y si se
cuenta con la capacidad de procesamiento adecuada, este tama no debera de incrementarse
para dificultar los ataques contra las llaves.

Dentro de los principales algoritmos para la generacion de llaves privadas y llaves p

ublicas
se destacan los siguientes:

1. Diffie-Hellman

2. ElGamal

3. DSA (Digital Signature Algorithm)

4. RSA (Iniciales de los apellidos de los creadores de este algoritmo: Ron Rivest, Adi
Shamir y Leonard Adleman)

En este trabajo de investigacion el algoritmo a utilizar para la generacion de llaves sera el

algoritmo RSA de 1024 bits de tama no para las llaves para asegurar la compatibilidad con el
formato de las llaves utilizadas en el servidor Proxy y en el servidor de DNS autoritativo. En
dicho algoritmo, la llave publica consta de 2 componentes numericos, un entero no negativo
n que es el modulo y e, un exponente p ublico que es un entero no negativo tambien. Ambos
valores numericos son utilizados en conjunto en formulas matem aticas de cuya resultado se
obtienen las llaves privadas y publicas, ofreciendo la seguridad suficiente de que es practica-
mente imposible derivar la llave privada si se cuenta s olo con la llave p
ublica [11].

Las llaves privadas y las llaves p

ublicas tambien pueden utilizarse para firmar informaci
on
digitalmente, es decir, pueden usarse para agregar a los mensajes una firma que consiste en
generar con la llave privada y una funcion de hash (funcion que genera un resumen de una
cadena de bits que reciben como entrada) una secuencia de texto que se a nade al mensaje
y que con la llave p ublica correspondiente otra persona pueda comprobar la procedencia del
mensaje. Para firmar el mensaje y comprobar la identidad del que firma se deben de seguir
los siguientes pasos (ver figuras 2.5 y 2.6) [5]:

1. Hacer pasar el texto del mensaje por la funcion de hash para producir una cadena de
mnimo 128 bits que sirva como resumen de la informaci
on contenida en el mensaje. La
funcion de hash genera una cadena de bits que resumen la informaci
on contenida. Los
algoritmos a utilizar para generar dicho resumen pueden ser MD2, MD4, MD5, que son
de 128 bits o el algoritmo SHA-1 que es de 160 bits. No es posible recuperar el texto
original a partir del resumen.

2. Utilizar la llave privada de manera inversa al proceso de encriptacion descrito ante-

riormente, es decir ahora la llave privada se utiliza para encriptar la cadena de bits

17
 de resumen. La cadena resultante es anexada al mensaje. Dicha cadena es la firma del
autor del mensaje.

3. Finalmente el mensaje se enva al destinatario. El destinatario al recibirlo, ejecuta una

funcion de hash sobre el cuerpo del mensaje que se envi o como texto plano (sin en-
criptar). A su vez, el destinatario aplica la llave p
ublica del remitente a la firma para
desencriptarla para obtener el valor de hash que el autor agreg o a su mensaje (antes de
encriptarlo).

4. Si la cadena de la funcion de hash que se obtuvo del texto del mensaje coincide en su
totalidad con la cadena del hash que se obtuvo de la firma, se confirma la identidad del
remitente. Si dichas cadenas no son iguales el mensaje puede considerarse como alterado
y a su vez como ap ocrifo.

Figura 2.5: Firmado de Mensajes con Llave Privada

Este esquema de firmado de mensajes, es utilizado para firmar los registros de DNS.
Dicha firma es devuelta en un RR de tipo RRSIG. La firma va includa en la secci on de
RDATA. Los demas elementos como el Owner Name, TTL, y RDATA adicionales se incluyen
en ese registro tambien para identificar cual es el texto que se esta firmando.

2.2.2. Descripci
on de DNSSEC
Las extensiones de seguridad al servicio de DNS (DNSSEC) a naden elementos impor-
tantes de la seguridad como lo son la autenticaci
on de las fuentes de la informaci
on y la inte-
gridad de los datos provistos por dichas fuentes. Dichas extensiones de seguridad ya haban
sido descritas en el RFC 2035 pero por la dificultad de escalar esas extensiones al servicio de

18
 Figura 2.6: Verificacion de Mensajes Firmados

DNS existente en Internet, tuvieron que hacerse modificaciones al documento original para
que dicha escalabilidad pudiera lograrse, dichas modificaciones, se describen a detalle en los
documentos RFC 4033, RFC 4034 y RFC 4035 [2].

DNSSEC incorpora nuevos conceptos a la especificaci on original de DNS. La mayora de

dichos conceptos involucran el uso de llaves privadas para firmar registros [2]:

Cadena de Autenticaci on: Conjunto de RRs (RRsets), es decir, RRs del mismo tipo
que aparecen consecutivamente en un mensaje de DNS, en este caso de tipo DNSKEY y
DS, estos RRsets contienen tanto llaves como informaci on firmada respectivamente. En
esta cadena de autenticacion, las llaves p
ublicas contenidas en los RR de tipo DNSKEY
se utilizan para validar los registros DS (Delegation Signer ) que contienen resulta-
dos de funciones hash aplicadas sobre otros RR de tipo DNSKEY. La verificacion con
llaves p
ublicas pertenecientes a unos nombres de dominio de los registros que contienen
res
umenes de llaves p ublicas de nombres de dominio en niveles inferiores va creando
la cadena de autenticacion con lo que se obtiene certeza de que todos los nombres de
dominio contienen las llaves correctas para ser firmados con estas.

Llave de Autenticaci on: Se refiere a la llave p

ublica que se le proporciona al resolver
para que realice la autenticaci
on de los datos. El resolver realiza el mismo proceso que
se realiza con la cadena de autenticacion. Utiliza la llave publica para verificar que la
llave incluida en el RR de tipo DNSKEY corresponde al resumen de dicha llave incluido
en RR de tipo DS.

Llave para Firmado de Llaves - KSK: Llave privada utilizada para firmar las llaves
de autenticaci
on para una zona dada. Esta llave es utilizada para firmar las llaves de

19
 firmado de zonas (ZSK). Tanto la KSK como ZSK pueden tener el mismo valor ya que
DNSSEC no distingue entre tipos de llave de autenticacion, sin embargo, el periodo de
validez de la KSK puede diferir del de la ZSK, siendo el de la KSK por lo regular mas
amplio.

Zona Firmada: Una zona cuyos RRsets estan firmados y contienen registros de tipo
DNSKEY, RRSIG, NSEC y DS correctamente construidos.

Llave para Firmado de Zonas - ZSK: Llave de autenticaci on que corresponde a la

llave privada usada para firmar una zona. Esta llave sera parte de las llaves de auten-
ticaci
on donde tambien se encuentra la KSK correspondiente, pero su uso y su ciclo de
vida (tiempo de validez) seran diferentes. La ZSK es modificada con mayor regularidad
que la KSK.

Integrando los conceptos de llaves mencionados anteriormente, la especificaci

on de DNSSEC
proporciona adem as de los mecanismos de autenticacion y de integridad de datos, mecanis-
mos que autentican la negaci on de la existencia de registros de DNS, es decir que si cierto
registro por el que se pregunto no existe dentro de los registros de zona del servidor, se le
proporcionara al resolver una prueba fidedigna de que dichos registros no se encuentran en
dicho servidor. Los mecanismos que proporcionan este servicio son los siguientes [2]:

Inclusi
on de 4 nuevos tipos de registros, que son el registro RRSIG (Resource Record
Signature), DNSKEY (DNS Public Key), DS (Delegation Signer ) y NSEC (Next Secure
Domain).

Agrega 2 nuevos bits al encabezado original de DNS, CD (Checking Disabled ) y AD

(Authenticated Data).

Debido a que se incrementa el tama no de los datos a ser devueltos al cliente, el tama
no
del paquete de respuesta de DNS se amplio de los 512 bytes originales a los 4096 bytes
para poder acompa nar los registros de sus correspondientes firmas.

Con la ayuda de los mecanismos provistos por DNSSEC, se pueden asociar firmas di-
gitales a los RRsets para que los resolvers puedan validar la identidad del servidor que los
devuelve como respuesta a una peticion. Las firmas digitales son almacenadas en el regis-
tro RRSIG que acompa nan a cada RRset que se firma. Puede enviarse m as de un RRSIG
para cada RRset, en estos casos los RRSIG contienen firmas resultantes de la aplicaci on de
diferentes algoritmos matem aticos. Cabe resaltar que la llave ZSK utilizada para firmar la
zona, esta asociada a esa zona u
nicamente, no a los servidores autoritativos que administran
la zona, debido a que estos servidores pueden tener m as zonas que administrar. Las llaves
KSK y ZSK deben permanecer en su condici on de llaves privadas en lugares seguros y de
preferencia estos lugares no deben de poderse acceder desde la red [2].

20
 La figura 2.7, se muestran los dos tipos de almacenamiento de llaves privadas recomenda-
dos por el RFC 4461. El tipo de almacenamiento optimo es que el se realiza en servidores que
no tienen acceso a Internet, por consiguiente el riesgo de que la KSK y la ZSK sean robadas
a traves de dicha red desaparece. Dicho modo de almacenamiento tiene como desventaja que
todas las actualizaciones a las llaves privadas y por consiguiente a los archivos de zona, deben
de ser realizadas directamente sobre la computadora que los contenga. En el caso de que se
desee contar con actualizacion din amica de las llaves, el RFC 4461 recomienda habilitar el
acceso a Internet para el servidor que contiene las llaves, permitiendose la conexi on desde el
servidor a la red pero no viceversa. Con esta configuraci on (ver figura 2.7), se logran actua-
lizar los archivos de zona que esten dispersos en la red y se protege a los archivos de llaves
privadas del acceso de terceros a la carpeta donde se almacenan, ya que su actualizacion en
el servidor principal sigue siendo manual. Para que el segundo metodo sea exitoso se debe
de contar con mecanismos de seguridad que encripten el contenido de las llaves para que un
tercero no pueda apoderarse de ellas mientras son transmitidas [12].

Figura 2.7: Tipos de almacenamiento de llaves privadas recomendados

21
 El registro DNSKEY es hasta la fecha, el u nico medio valido para distribuir llaves p
ubli-
cas a los clientes que deseen verificar la autenticidad de la informaci on del servidor. Estos
clientes pueden asegurar que las llaves que usan son las correctas al crear cadenas de auten-
ticaci
on con las llaves que les fueron proporcionadas y el resumen que se enva en el registro
DS [2].

Para proveer al cliente de una negacion de existencia de registros que pueda ser validada
por este, se utiliza el registro NSEC, que igualmente va firmado (acompa nado de un RRSIG)
y que devuelve como respuesta informaci on referente al espacio que debera de ocupar en la
zona el dominio preguntado, es decir, proporciona informaci on del sucesor y del predecesor de
dicho dominio para asegurar al cliente que el dominio por el que se pregunto no existe. Dicho
registro requiere que los nombres de dominio esten ordenados de acuerdo a forma canonica [2].

Cabe aclarar que a pesar de estas modificaciones, la estructura general del paquete de
DNSSEC, se mantiene igual a la que se muestra en el cuadro 2.3 que corresponde a la estruc-
tura original de paquetes de DNS. Los paquetes de DNSSEC siguen incluyen un campo de
encabezado, el campo de pregunta, el campo de respuesta, el campo autoritativo y el campo
adicional. Los cambios mas radicales se dan en la estructura de los registros, especficamente
en la secci
on de RDATA (ver cuadro 2.1) de los mismos, cuyo tama no debio de ser incremen-
tado para poder acomodar la informaci on que se le proporciona al cliente para su validacion.

Figura 2.8: Inclusion de firmas en paquetes de DNSSEC

En la figura 2.8 puede observarse como se envan los registros de datos en DNSSEC.
A pesar de que el formato se mantiene igual al original de DNS, si el usuario lo solicita, un
registro RRSIG que contiene la firma digital de toda la informaci
on contenida en el registro de
datos (Owner Name, tipo, clase, TTL y RDATA) es colocado por el servidor inmediatamente

22
despues del registro de datos antes mencionado. La inclusion de esta firma es la principal
diferencia entre los paquetes de DNS y los de DNSSEC.

DNSSEC mantiene como p ublica la naturaleza de los datos, es decir, no se incluye en

la especificaci
on alg
un metodo de encriptacion de la informaci on contenida en los RR, para
continuar siendo conforme a la especificaci on original de DNS donde toda la informaci on de
los RR esta disponible para quien la solicite. Tampoco dicha especificaci on provee mecanis-
mos de defensa contra ataques de negacion de servicio, algo a lo que se es vulnerable desde la
especificaci
on original, por lo que medidas externas no especificadas deben ser implementadas
para contrarrestar estos ataques a la disponibilidad del servicio. El otro problema de DNSSEC
radica en que permite enumerar todos los registros contenidos en la zona realizando m ultiples
peticiones por registros NSEC. Se incluye m as informacion referente a este problema en la
secci
on dedicada al problema de enumeraci on de zona [2].

2.2.3. Registro DNSKEY

El registro DNSKEY almacena las llaves p ublicas que se utilizan para el proceso de au-
tenticaci
on de la informacion de los RR. Los registros firmados en la zona son propiamente
los registros autoritativos que proporcionan informaci on relevante de la misma, como el re-
gistro SOA. Con la ayuda de las llaves insertadas en el RR de tipo DNSKEY, un resolver
puede usarlas para validar la informacion que viene firmada y autenticar el origen. El registro
DNSKEY s olo debe de utilizar llaves p
ublicas que correspondan a llaves privadas utilizadas
para firmar la zona. Las llaves que no cumplan con dicho requisito no deberan ser incluidas [4].

Como peculiaridad, este registro es independiente del campo de clase y no tiene requeri-
mientos especiales para valores de TTL. El registro esta formado de un campo de banderas de
longitud de 2 octetos (2 bytes), 1 octeto para el campo de protocolo, 1 octeto para el campo
donde se indica el algoritmo matem atico utilizado para generar la llave y finalmente el campo
donde va incluida la llave p
ublica en s [4].

La descripci
on de los campos que componen a este registro se incluye a continuaci
on [4]:

En el campo de banderas, el bit que ocupa la septima posicion corresponde a la bandera

de la llave de la zona. Si dicho bit esta encendido, indica que el RR de tipo DNSKEY
posee una llave de zona y el Owner Name de esa llave de zona corresponde al nombre
de la zona. Si dicho bit esta apagado entonces la llave incluida no puede ser utilizada
para validar registros del tipo RRSIG que acompa nan a los RRsets. El bit 15 de este
campo de banderas representa si esta encendido que el registro DNSKEY cuenta con
una llave que se utiliza como punto de acceso seguro. Los demas bits de este campo
no se utilizan a
un por lo que mantiene su calidad de reservados y su valor en todos los
casos debe ser de 0.

El campo de protocolo debe de tener el valor de 3 siempre, si no todo el RR sera con-

23
 siderado como invalido.

El campo del algoritmo identifica al algoritmo matem atico de criptografa de llave p

ubli-
ca utilizado para generar la llave. Dicho algoritmo puede ser de tipo DSA/SHA-1, Curva
Elptica, RSA/SHA-1, etc.

El campo de llave p ublica almacena el valor de la llave. El formato de esta llave

esta definido por el algoritmo utilizado para obtenerla.

En el cuadro 2.5 se observa un ejemplo de registro de tipo DNSKEY, siguiendo el forma-

to general de los RR, pero respetando los campos definidos para este nuevo tipo de registro.
Se incluyen primeramente el Owner Name, el TTL, la clase y el tipo de registro (DNSKEY),
para posteriormente incluir el valor del campo de banderas (256) con el valor del bit 7 encen-
dido. El valor de 3 corresponde al campo de protocolo y el valor 5 que le sigue indica que el
algoritmo utilizado para generar la llave es el algoritmo RSA/SHA-1. Finalmente se incluye
la llave p
ublica codificada en base 64.

test. 86400 IN DNSKEY 256 3 5 AQPbMtIGS6XTiAEky8eltx1Hk7cJxl

+EMBcwX4q9Ho/PmRJIb+RFpBfEYNq0
WXrqSGndC980/YVZcd0zjJdeOWWzWC
NpAbqaky0bbeMxdbMHXlG/puthKAnH
3qDM3z8P3KrmrhjqYfN5rSdMyEgE1B
iwDLo4P7zK4qbiyeCe bPGbQQ==

Cuadro 2.5: Ejemplo de RR de tipo DNSKEY

2.2.4. Registro RRSIG

El registro RRSIG es utilizado por los resolvers para validar la informaci
on contenida en
los RRsets que los preceden en los mensajes devueltos por los servidores. Las firmas digitales
son almacenadas dentro de los registros RRSIG. Dicho registro incluye tambien informaci on
legible sobre el nombre, clase y tipo de registro que se esta firmando. Tambien se incluye
informacion similar a la que acompa na al registro DNSKEY como lo es informaci on sobre el
algoritmo, el tiempo de validez de la firma, el nombre de dominio del servidor que firma y
un identificador de llave que permite relacionar esa firma con su correspondiente DNSKEY [4].

Es obligatorio firmar todos los nombres autoritativos de una zona, que generalmente
estan escritos en su forma canonica. El valor del campo de clase para este registro es el tipo
de registro que se esta firmando. Igualmente, el valor del campo de TTL debe ser igual al
valor de TTL original del registro firmado [4].

24
 El registro RRSIG esta conformado por 8 campos. El primer campo consta de dos octe-
tos que indican el tipo de registro que se esta firmando, le sigue un campo de 1 octeto que
indica el algoritmo matem atico utilizado para generar la firma, a este campo le sigue uno
de 1 octeto donde se indica el numero de etiquetas (nodos del arbol de dominios) que tiene
el Owner Name del registro RRSIG. El siguiente campo abarca 4 octetos, ah se incluye el
valor de TTL que debe de coincidir con el del registro que se esta firmando. Los dos cam-
pos siguientes incluyen la fecha de expiracion y de incepci on, de 4 octetos cada una, con
dichas fechas los resolvers pueden determinar la validez de las llaves [4]. Finalmente los ulti-
mos 3 campos lo conforman el identificador de la llave, el nombre del que firma y la firma en s.

Los campos se describen a continuaci

on [4]:

El campo del tipo de registro cubierto identifica el RRTYPE del registro que se esta fir-
mando.

El campo del algoritmo contiene un valor numerico con el que se identifica al algoritmo
matematico utilizado para crear la firma. Dicho algoritmo puede ser de tipo DSA/SHA-
1, Curva Elptica, RSA/SHA-1, etc.

El campo de las etiquetas especifica el n

umero de etiquetas utilizadas en el Owner Name
del RR firmado, que es el mismo que aparece en el campo del Owner Name del RRSIG.
Si una etiqueta cuenta solo con el caracter * que denota un wildcard, dicha etiqueta
no es contada en la cifra de este campo.

Se incluye el campo del TTL original del RR firmado con el fin de que el RR firmado
pueda autenticarse aunque el servidor decremente el valor de TTL del registro original.

Los campos de fecha de expiracion y de incepci on se utilizan para calcular el periodo

de validez de la llave. La llave no debe de ser utilizada para verificar firmas si dicha
operacion se realiza antes de la fecha de incepci
on o despues de la fecha de expiracion.

El campo del identificador de llave tiene un valor numerico que relaciona al RRSIG con
su DNSKEY correspondiente. En casos que existan muchas firmas y muchas llaves, el
uso de este campo es vital para poder utilizar la llave adecuada con cada firma.

El campo del nombre del que firma debe de coincidir con el Owner Name del registro
DNSKEY. Debe de contener el nombre de la zona que cubre el conjunto de registros
firmados.

El campo de la firma contiene el valor obtenido con un algoritmo matem atico, siguiendo
el esquema de firmado de la figura 2.5. Los datos que se firman incluyen el Owner Name,
la clase, el tipo de registro cubierto y demas elementos del RDATA del registro RRSIG.

En el cuadro 2.6 se muestra un ejemplo de registro de tipo RRSIG. Se observa el valor

de Owner Name que debe de coincidir con el valor del registro NSEC que se firma. En la

25
parte de RDATA como primer elemento esta el tipo de registro firmado, un NSEC, el numero
5 que le sigue indica que el algoritmo matem atico utilizado es RSA/SHA1. Posteriormente
se indica que el n umero de etiquetas a firmar es de 1. El TTL que se incluye es igual al
TTL original del registro que se firma. En los siguientes 2 campos se encuentran las fechas
de expiracion e incepci
on respectivamente en formato YYYY:MM:DD:HH:mm:SS (a no, mes,
da, hora, minuto y segundo). Posteriormente a este campo va el campo donde se identifica
al que esta firmando el RR, en este caso, se incluye el Owner Name de la zona. Finalmente
se incluye la firma, en formato de base 64.

test. 1200 IN RRSIG NSEC 5 1 1200 20070209163058

20070110163058 32402 test. CO0ueslsSuKJtTKWqFzgRef1b5c9KFK5f8AOG
ZlI+ud1uhHlgzLRGkrlETQGgnEacilOqx3oGoiBDsOlcZTJLTCW+Xu8zKOq5eF9
4wMr3gRzn20xalVNwtWTFMRAF1/neofQfglqwfqxNOrGoVdFLRVlYRVYRKdW
4CwfXNw0j60=

Cuadro 2.6: Ejemplo de RR de tipo RRSIG

2.2.5. Registro NSEC

El registro NSEC se utiliza para proporcionar al cliente una negacion firmad del registro
solicitado cuando este no esta contenido en los archivos de zona. En dicho registro se incluye
el Owner Name autoritativo existente en la zona que va colocado despues del nombre de
dominio solicitado por el usuario (el siguiente dominio valido). En un archivo de zona, el
conjunto de registros NSEC permite formar una cadena de los Owner Names autoritativos
que existen en la zona [4].

Al igual que el registro DNSKEY, el registro NSEC es independiente del valor que tenga
el campo de clase. El valor del campo TTL debe de coincidir con el valor de TTL mnimo
declarado para el registro SOA. La estructura del RDATA de este registro consta de s olo 2
campos, el campo del siguiente Owner Name valido y el campo donde se indica de que tipo
o tipos de registros cubre el nombre de dominio contenido en el campo que le precede [4].

El campo del siguiente dominio contiene el siguiente Owner Name valido en su forma
canonica. El u
ltimo NSEC tendr a en este campo el Owner Name de la zona, identico a como
aparece en el SOA, para indicar que se ha llegado al final de la enumeraci
on de los nombres de
la zona. En el campo de tipos de registros se incluyen todos los RRTYPE que esten relaciona-
dos directamente con el nombre de dominio del campo del siguiente dominio. En este campo
se incluyen los RRTYPE en forma de bloques que contienen los 8 bits menos significativos
de los 16 bits que componen un espacio de RRTYPE, tal como se representan los demas RR.
Los RRTYPE se ordenan de forma ascendente de acuerdo al valor numerico del octeto que
representa a cada RRTYPE [4].

26
 En el cuadro 2.7 se observa un registro NSEC donde se puede notar que el campo del
siguiente dominio valido es el nombre de dominio c.test. y que corresponde a registros de
tipo A, RRSIG y el propio NSEC. Se observa que como el Owner Name incluye el nombre de
dominio a.test., que es el predecesor directo al nombre de dominio solicitado por el usuario
y que se le devuelve para comprobarle que no existe ning
un registro entre a.test. y c.test..
Es decir, si un usuario preguntara por el dominio b.test., este RR sera devuelto.

a.test. 3600 IN NSEC c.test. A RRSIG NSEC

Cuadro 2.7: Ejemplo de RR de tipo NSEC

2.2.6. Registro DS
El registro DS esta relacionado directamente con un registro DNSKEY al participar en
conjunto con este tipo de registro en el proceso de autenticacion. Dentro del registro DS se
almacena un identificador de llave, el numero de algoritmo matem atico utilizado y un re-
sumen de la llave contenida en el registro DNSKEY al que se hace referencia. Al autenticar
un registro DS, el resolver puede autenticar tambien el registro DNSKEY al que el registro
DS se refiere [4].

El registro DS y su correspondiente registro DNSKEY comparten informaci on referente

al Owner Name, pero su colocacion en la zonas del servidor varia. Este registro tambien es
independiente del valor de clase que se le asigne y no tiene requisitos especiales para un valor
especfico de TTL [4].

La seccion de RDATA para el registro DS contiene el campo del identificador de la llave

(2 octetos), el campo donde va colocado un identificador numerico del algoritmo matem atico
(1 octeto), el campo que identifica el tipo de resumen que se incluye (1 octeto) y el campo de
resumen de longitud variable [4].

Los campos se describen a continuaci

on [4]:

El campo de identificador de llave (Key Tag) contiene el identificador de la llave del

registro DNSKEY referido por el registro DS. Dicho valor de identificador esta en el
mismo formato que el campo del identificador de llave contenido en el registro RRSIG.

Al igual que en los RR anteriormente presentados, el campo del algoritmo contiene

un numero que identifica al algoritmo matem
atico utilizado para generar el registro
DNSKEY.

El campo de tipo de resumen, se indica el n umero del algoritmo matem atico utilizado
para obtener el resumen de la llave que se incluye en el campo siguiente.

27
 El registro DS incluye un resumen de la llave a la que se refiere y que esta contenida
en un registro DNSKEY. El resumen de dicha llave se obtiene concatenando la forma
canonica del Owner Name del registro DNSKEY con el RDATA del mismo registro.
Se aplica el algoritmo matematico para resumir dicha concatenacion y esta a su vez es
a
nadida en el campo de resumen. Generalmente el algoritmo utilizado es SHA-1 que
produce un resumen de longitud de 20 caracteres.

La peculiaridad de este registro radica en que es la base para generar la cadena de au-
tenticaci
on que permite autenticar todos los RR que esten firmados en una zona, por ello es
importante que la llave referida en el registro DS sea una llave de zona. Tambien en el registro
DNSKEY referido por el registro DS debe indicarse que la llave es de zona al prender el bit 7,
de lo contrario dicha llave no sera utilizada en el proceso de validaci
on de registros firmados [4].

En el cuadro 2.8 se muestra une ejemplo de registro DS. Como Owner Name se tiene el
nombre de dominio que identifica a la zona, as mismo, los campos del RDATA se refieren a
un registro DNSKEY que corresponde a esa misma zona y que contiene la llave de zona.

test. 3591 IN DS 57870 5 1 E6951F911D36A850B79

FCA1E4E60B03E4A2F0
C79

Cuadro 2.8: Ejemplo de RR de tipo DS

2.2.7. Bits de Encabezado

La especificaci
on DNSSEC incorpora dos bits al encabezado original de paquetes de
respuesta de DNS. El bit CD y el bit AD [3]:
El bit de CD permite a los resolvers desactivar la validaci on de firmas para una peticion
en particular del lado del servidor. Dicho bit debe de ser copiado del paquete de pre-
gunta al paquete de respuesta por los servidores. Con dicho bit encendido, el resolver
indica a los servidores de nombres que no desea que realicen la autenticaci on de los RR
involucrados en el paquete de respuesta, y que dicha autenticaci on la realizara el mismo
resolver localmente. Al notar el bit de CD encendido, los servidores de nombres envan
al resolver los registros sin ser verificados, ya sera cuesti
on del resolver rechazarlos si
no pasan exitosamente por su proceso de verificacion.

El bit de AD es encendido por los servidores de nombres s olo cuando han comproba-
do que las firmas de todos los RR contenidos en la respuesta son validas. Tambien se
verifica que las pruebas de no existencia en los registros NSEC sean validas para poder
encender dicho bit.

28
 Con respecto al bit de CD, puede ser utilizado por los resolvers para acelerar el tiempo
de respuesta cuando hace peticiones a un servidor recursivo y este u ltimo ya no valida las
respuestas obtenidas de los servidores autoritativos, pero el resolver debe de tener los medios
para validar dicha informacion, si no se estara exponiendo a recibir respuestas falsas que ni
siquiera cuentan con una validacion previa por el servidor autoritativo [3].

Cabe recalcar, que el resolver no debe de confiar abiertamente en la respuesta del servi-
dor que provenga con el bit AD encendido, el resolver debe comprobar por el mismo la validez
de la informacion utilizando sus propios mecanismos de autenticaci on. El bit de AD indica
solamente que se ha comprobado la cadena de confianza cuando un servidor recursivo va
solicitando informacion a los servidores autoritativos, lo que significa que dicho servidor ha
comprobado el origen de la informaci on, pero el resolver tambien debe de hacerlo para com-
probar que el paquete no ha sido falsificado [3].

En los paquetes de pregunta, existe el bit DO que el usuario utiliza para solicitar una
respuesta autenticada (registros acompa nados de firmas digitales). Si dicho bit no se enciende
por el resolver que formulo la pregunta, el servidor de nombres debera retirar del paquete de
respuesta todos los registros autenticados que no tengan que ver con la peticion [3].

En la figura 2.9 puede observarse la informaci on de un paquete de respuesta cuyo bit de

AD ha sido encendido, lo que significa que los RR firmados han sido validados por el servi-
dor que recibi o la peticion. Para este ejemplo, el servidor recursivo recibio la peticion por el
registro A del dominio a.test., y en dicha peticion el bit DO va encendido, por lo que se le
solicita al servidor recursivo que recibe la informaci on validar la misma utilizando las llaves
p
ublicas que el servidor autoritativo al que se le pregunta por el nombre de dominio provee.
Al validar dicha informaci on, el servidor recursivo devuelve el paquete de respuesta con el bit
AD encendido.

2.2.8. Ordenamiento Can

onico de Nombres de Dominio
La especificaci
on de DNSSEC demanda emplear un sistema de ordenamiento de nombres
de dominio para prop osito de la operacion correcta de los servidores de DNS. Dicho esquema
de ordenamiento es requerido para que registros como NSEC proporcionen informaci on co-
rrecta y la autenticacion pueda ser realizada sin problemas. En el ordenamiento de nombres,
las letras mayusculas son tratadas como si fueran letras min usculas, es decir, que el nombre
de dominio es tratado como si estuviera en su forma canonica [4].

El ordenamiento canonico, implica empezar a ordenar desde la etiqueta mas significativa

(mas a la derecha) y en caso de empate entre dichas etiquetas, proceder a la siguiente hasta
llegar a la etiqueta de mas a la izquierda que es la menos significativa. Esto se expone a
continuacion con el siguiente grupo de nombres de dominio ordenados alfabeticamente de
acuerdo a su forma canonica [4]:

29
 Figura 2.9: Respuesta de DNS con bit de AD

1. test.

2. b.test.

3. lmlmlm.b.test.

4. Z.b.test.

5. zaBC.b.test.

6. z.test.

2.3. Enumeraci
on de Zona
Como se mencion o con anterioridad, la especificaci
on de DNSSEC permite a cualquier
usuario de Internet conocer todos los nombres de dominio de una zona siguiendo la cadena

30
formada por registros NSEC que contienen al predecesor y al sucesor. A este problema se le
denomina enumeraci on de zona o Zone Walking. A continuaci on se presenta un ejemplo de
como podra realizarse la enumeracion de zona al preguntar por registros no existentes que
har
a que el servidor de nombres con DNSSEC implementado devuelva un registro NSEC para
demostrar que no existe el registro solicitado (ver cuadro 2.9):

1. Supongamos que la zona tiene como nombre el dominio test. y dentro de esa zona
se crean los dominios a.test., c.test., e.test. y ns.test., asignados cada uno a
diferente tipo de RR.

2. Un cliente que desconoce dichos registros de zona, pregunta por el registro b.test.
y por consiguiente recibe un registro NSEC donde se lista el dominio valido anterior
(predecesor) y el siguiente dominio valido (sucesor). En dicho registro NSEC el cliente
recibira el nombre de dominio a.test. como el predecesor y el dominio c.test. como
el sucesor.

3. El cliente ya conoce dos dominios validos que de acuerdo al orden canonico iran coloca-
dos uno inmediatamente despues del otro. Preguntara entonces por un dominio ubica-
do canonicamente despues del dominio valido c.test. para obtener un nuevo registro
NSEC en caso de que el dominio preguntado no exista.

4. Si el cliente pregunta por el dominio d.test., el cliente recibira como siguiente do-
minio valido el nombre de dominio e.test.. Si genera entonces una peticion por un
nombre de dominio ubicado entre e.test. y ns.test., conocer a a este u
ltimo regis-
tro. Finalmente si pregunta por un registro que se coloque despues de ns.test., se le
devolvera como siguiente dominio valido el nombre de zona test., por lo que puede
concluir que habra llegado al final de la zona recorriendo efectivamente el camino que
incluye todos los registros ah contenidos a partir del dominio a.test..

5. El cliente entonces pregunta por un dominio que se encuentre entre el nombre de zona
y el primer dominio valido que obtuvo, el dominio a.test.. Al recibir este dominio
como el siguiente dominio valido el cliente concluye que ya ha recorrido toda la zona
completando la enumeraci on.

Pregunta Respuesta
b.test. a.test. 3600 IN NSEC c.test. A RRSIG NSEC
d.test. c.test. 3600 IN NSEC e.test. A RRSIG NSEC
f.test. e.test. 3600 IN NSEC ns.test. AAAA RRSIG NSEC
o.test. ns.test. 3600 IN NSEC test. A RRSIG NSEC
0.test test. 3600 IN NSEC a.test. NS SOA RRSIG NSEC DNSKEY

Cuadro 2.9: Enumeraci

on de Zona

31
 El servicio de DNS fue concebido con un servicio donde la informaci on estara disponible
para todo p ublico, por lo que el problema de enumeraci on de zona no fue considerado un
problema como tal. Sin embargo es necesario considerar que dicha enumeraci on de zonas
puede ser un precedente de un ataque contra la integridad o disponibilidad del servicio de
DNS, ya que se le permite al probable atacante identificar su objetivo. En el contorno de
polticas de seguridad, tambien existe discrepancia entre los diferentes Network Information
Centers que administran los dominios de pases sobre si la divulgacion de esta informaci on
viola dichas polticas. Existe una diferencia cualitativa entre divulgar informacion utilizando
mecanismos de pregunta y respuesta y divulgarla como una compilaci on. Dicha diferencia ha
llevado a frenar la implementaci on de DNSSEC pues las polticas de seguridad no permiten
la divulgacion de los nombres de la zona en forma de compilaci on [16].

Es en Europa donde se ha suscitado mayor controversia respecto a la enumeraci on de

zonas, por ejemplo, la posicion de DENIC, NIC encargado de administrar el dominio .de (Ale-
mania) con respecto a la divulgacion de los nombres de la zona indica que dicho problema de
DNSSEC viola el documento oficial de la rep ublica Alemana que trata sobre la protecci
on a
la informacion de la Federacion. Dicho documento es conocido como Germanys Federal Data
Protection Act, por lo que la implementaci on de DNSSEC en servidores de nombres sin esta
falla corregida puede ser considerada ilegal en ese pas [16].

La posicion de DENIC con respecto a la divulgacion de los archivos de zona esta disponible
en la siguiente URL:

http://www.denic.de/en/faqs/allgemeine faqs/index.html

En dicha pagina de Internet se indica que la difusion de informaci

on referente a los domi-
nios contenida en los archivos de zona viola la legislacion alemana respecto a la proteccion de
informaci
on confidencial, por tal motivo DENIC no proporciona a terceros dicha informaci on
en forma parcial o total de los archivos de zona, que mediante el registro NSEC es visible.
El documento oficial del gobierno aleman indica que la informaci on protegida no s
olo incluye
informaci
on relacionada con una entidad, sino tambien informaci on que pueda ser utilizada
para identificar a otras entidades, de ah que la informaci
on de una zona tenga que ser protegi-
da pues se refiere a otras entidades, en este caso servidores de nombres y permite identificarlos.

Nominet, el NIC que administra el dominio uk. correspondiente al Reino Unido, tambien
ha fijado una postura al respecto en la siguiente URL:

http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg00687.html

Nominet asegura que la enumeraci on de la zona les impide implementar DNSSEC en su

totalidad, mientras la especificaci
on de DNSSEC no sufra modificaciones. Nominet mantiene
su postura de no divulgar informaci on de la zona ya que la divulgacion de esta en forma de

32
compilaci
on viola las normas establecidas por la Union Europea acerca de derechos sobre la
informaci
on.

2.4. Soluciones Emergentes al Problema de Enumeraci

on de
Zona
Dada la imposibilidad de implementar DNSSEC por las cuestiones legales presentadas
anteriormente, surgieron 2 alternativas orientadas a proteger la informaci on confidencial de
la zona cuando se implementa DNSSEC. El objetivo de ambas alternativas es agilizar la im-
plementacion de DNSSEC en territorios donde no se ha podido implementar debido a los
problemas legales que conlleva la enumeraci on de zona. DNSSEC provee beneficios a la se-
guridad en materia de validaci on de la informacion contenida que no pueden ser pasados
por alto y que los ataques realizados con la especificaci
on original del servicio de DNS hacen
urgente su implementacion.

2.4.1. Registro NSEC3

Como alternativa para presentarle al cliente una verificacion autenticada de no existencia
de dominios y a su vez no divulgar informaci on de la zona, la IETF empez o a trabajar en un
nuevo registro que podra usarse en lugar del registro NSEC para negar la existencia de un
nombre de dominio y a su vez proteger de terceros la informaci on de la zona, dicho registro
es conocido como DNSSEC Hashed Authenticated Denial of Existence o NSEC3 debido a
que representa una actualizacion sobre el registro NSEC en materia de seguridad y puede
utilizarse en su lugar con servidores y clientes que manejen este registro. Dado que a un no
existe compatibilidad entre servidores que manejen NSEC3 y los que manejan solo NSEC,
los registros NSEC3 pueden ser considerados como inseguros por entidades y clientes de DNS
que no manejen dicho registro [13].

El registro NSEC3 al igual que el registro NSEC, lista los tipos de registros que corres-
ponden al Owner Name del paquete. La diferencia con el registro NSEC radica en que NSEC3
incluye un resumen producto de una funcion de hash del nombre dominio que representa al
siguiente dominio valido, en lugar de que dicho nombre vaya escrito en texto plano con en
NSEC. El conjunto de registros NSEC3 una zona permite formar la cadena de Owner Names
resumidos de toda la zona. Cabe recalcar que el ordenamiento se realiza de acuerdo al texto
producido por la funcion de resumen [13].

La proteccion contra la enumeraci

on de zona es provista por NSEC3 en los res umenes
que se generan de los textos conformados por los Owner Names originales que son a nadidos
al nombre de la zona. El registro NSEC3 tambien indica cual es la funcion de hash utilizada
para construir el resumen de la informaci
on [13].

33
 El Owner Name en un registro NSEC3 va escrito en forma de resumen, en base 32. Antes
de resumir dicho campo, se le agrega a el nombre de zona. El valor para este tipo de registro
es NN, tambien es independiente del campo de clase, pero dicha clase debe ser igual a la del
Owner Name que va resumido. El valor del campo de TTL debe ser el mismo al valor que
tenga el registro SOA en este mismo campo [13].

Los campos para este registro se definen a continuaci

on (cuadro 2.10) [13]:

El campo del algoritmo de resumen identifica al algoritmo matem atico utilizado para
generar el hash de la informaci
on que se va a presentar como resumida.

El campo de banderas es de 1 octeto de longitud y puede ser utilizado para indicar el

procesamiento que se realiz o sobre el registro. Hasta la u
ltima revisi
on de la especifi-
cacion solo existe la bandera Opt-Out definida que indica que el registro NSEC3 puede
cubrir delegaciones de nombres que no esten firmadas.

El campo de iteraciones define el n umero de veces adicionales que la funcion de hash se

ejecut
o sobre la informacion. A mayor n umero de iteraciones, mayor sera la proteccion
del resumen contra ataques de diccionario, pero el costo computacional se incrementa
para el servidor y el resolver a la hora de validar la informaci
on.

El campo de longitud del campo Salt define la longitud del campo referido que puede
oscilar entre 1 y 255 octetos.

El campo Salt es utilizado para agregarlo al Owner Name antes de aplicar la funcion
de hash para contrarrestar ataques de diccionario.

El campo de longitud de hash indica la longitud del campo del siguiente dominio (que
va resumido por la funcion de hash). Su valor oscila entre 1 y 255, refiriendose a la
longitud del campo del siguiente dominio valido.

El campo del siguiente dominio valido contiene el resumen del Owner Name ordenado
de acuerdo a su valor de hash. El valor va en formato binario. Dicho campo contiene el
valor de hash que sigue inmediatamente despues del Owner Name del registro NSEC3
dado. Si se trata del u
ltimo registro NSEC3 en la zona el valor corresponde al nombre de
zona. A diferencia del campo de Owner Name a este registro no se le agrega el nombre
de zona antes de calcular el resumen.

El campo de tipo de registros, identifica los valores de RRTYPE asociados al Owner

Name del registro NSEC3.

Paralelamente al registro NSEC3, se utiliza el registro NSEC3PARAM que contiene

parametros utilizados para calcular los valores del registro NSEC3 como el algoritmo de hash,
las banderas, iteraciones, etc. La presencia de un registro de este tipo indica a los servidores

34
 Hash Alg. Flags Iterations
Salt Length Salt
Hash Length Next Hashed Owner Name
Type Bit Maps

Cuadro 2.10: RDATA de registro NSEC3

autoritativos que pueden utilizarlo para generar las respuestas de no existencia. Si dicho re-
gistro esta presente en un servidor ubicado en el nodo mas alto de la zona con el campo de
banderas en 0, entonces los registros de la zona deberan de contar un registro NSEC3 que
utilice esos parametros [13].

Hash Alg. Flags Iterations

Salt Length Salt

Cuadro 2.11: RDATA de registro NSEC3PARAM

En el cuadro 2.11 [13], se observa la estructura del registro NSEC3PARAM, donde con-
tiene valores para par ametros de registros NSEC3. Dichos valores son los mismos a los ya
mencionados para el registro NSEC3. Actualmente la empresa Verisign termin o de de aplicar
pruebas piloto al prototipo de NSEC3 y la especificaci on fue liberada a principios de este
a
no. En el piloto, se manejan registros NSEC3 firmados para los dominios de alto nivel como
.com y .net.

2.4.2. Firmado en Lnea

El firmado en lnea se refiere a un procedimiento que puede ser implementado en servi-
dores autoritativos, consiste en construir registros NSEC al momento que son solicitados y
firmarlos para luego devolverlos al resolver, al contrario del proceso tradicional donde dichos
registros y firmas estan almacenados en un archivo de zona. Los registros NSEC generados
cubren un rango menor de nombres de dominio evitando proporcionar informaci on sobre nom-
bres validos en la zona [18].

El proceso de firmado en lnea requiere de la generacion de registros y de su posterior

firma para cada dominio que no exista en la zona. Dicho proceso demanda que en el campo
del siguiente dominio valido del registro NSEC, en lugar de insertar el valor que ira origi-
nalmente y que se refiere a un dominio existente en la zona, listar el nombre de dominio que
de acuerdo al orden canonico vaya colocado inmediatamente despues del dominio por el que
se pregunto. Caso contrario para el campo de Owner Name de dicho registro, donde dicho
nombre de domino es sustituido por el dominio que va colocado inmediatamente antes del

35
dominio por el que se pregunto. El registro NSEC generado entonces contendr a el sucesor y
predecesor directo del dominio que se ha catalogado como no existente, sin incluir los domi-
nios validos que lo precedan y sucedan [18].

A la par de generar un registro NSEC, se debe de generar el registro RRSIG correspon-

diente firmando con la llave de zona para demostrar que dicho registro no existe dentro de la
misma. Esto eleva el costo computacional ya que a la par de generar nombres de dominio al
momento de su peticion, el registro debe de pasar por el proceso de firmado mientras la peti-
ci
on esta siendo atendida. Esto tambien conlleva riesgos en seguridad al tener almacenadas
las llaves privadas en servidores p
ublicos, que regularmente son blanco de ataques, por lo que
se deben externas las medidas de seguridad para proteger dichas llaves [18].

Los metodos para la obtencion del sucesor y el predecesor inmediatos a un nombre de

dominio se han definido en el RFC 4471, a continuaci on se exponen las reglas para obtener
dichos valores [17]:

Obtenci
on del predecesor inmediato a un nombre de dominio:

1. Si el nombre de dominio N es igual al nombre de zona, se deben de colocar etiquetas

a la izquierda de N, que tengan la m axima longitud posible (63 octetos) y que
contengan solamente el caracter con valor ASCII m as grande posible (por ejemplo
0xff) hasta que N sea de la m
axima longitud posible (254 octetos). Si esta condici
on
no se cumple se procede al siguiente paso.
2. Si la etiqueta menos significativa de N (mas a la izquierda) consiste en un u nico
octeto que contenga el caracter con valor ASCII m as pequeno posible (por ejemplo
0x00), se debe de remover dicha etiqueta u
nicamente. Si esta condici
on no se cumple
se procede al siguiente paso.
3. Si la etiqueta menos significativa de N contiene un octeto en su posicion menos
significativa (m
as a la derecha) que tiene el valor ASCII m
as peque
no posible, se
debe de remover dicho octeto y proceder al paso 5.
4. Si no se cumplio ninguna de las condiciones anteriores, se debe de decrementar el
octeto de la etiqueta menos significativa y que ocupa la posicion menos significativa
en dicha etiqueta. Se deben de evitar valores que correspondan a letras may usculas
al efectuar dicha resta. Posteriormente, rellenar la etiqueta menos significativa con
octetos que tengan el valor ASCII m as grande posible hasta llegar al lmite del
tama no permitido para las etiquetas (63 octetos). Se debe de proceder al paso 5
despues de finalizar con las operaciones de esta etapa.
5. Agregar a la izquierda de N, etiquetas de la m
axima longitud posible que contengan
el caracter ASCII con el valor m as grande posible hasta que N tenga la m axima
longitud posible para un nombre dominio.

Obtenci
on del sucesor inmediato a un nombre de dominio:

36
 1. Si N es dos o mas octetos mas corto que la longitud m axima de un nombre de
dominio, agregar a la izquierda de N una etiqueta que contenga un u nico octeto
con el valor ASCII mas pequeno posible. Si esta condici
on no se cumple, se debe
de proceder al paso 2.
2. Si N es un octeto m as corto que la longitud maxima de un nombre de dominio
y la etiqueta menos significativa es uno o dos octetos m as corta que la longitud
maxima de una etiqueta, entonces se debe de agregar a la derecha de la etiqueta
un octeto con el valor ASCII m as peque
no posible. Si esta condici
on no se cumple
se debe de proceder al siguiente paso.
3. Se debe de incrementar el valor del octeto en la posicion menos significativa de
la etiqueta menos significativa cuyo valor sea menor al valor ASCII m as grande
posible, evitando obtener valores que correspondan a letras may usculas. Posterior-
mente se deben de remover los octetos a la izquierda del octeto que se acaba de
incrementar. Si todos los octetos de la etiqueta menos significativa tienen el valor
ASCII m as grande posible se debe de proceder al paso 4.
4. Se debe de remover la etiqueta menos significativa, y si N es ahora igual al nom-
bre de zona se termina el proceso, si no se procede a ir al paso 2 y repetir el mismo.

En caso de que los servidores de DNS no soporten el rango de caracteres ASCII, se puede
utilizar el rango LDH (Letter Digit Hyphen) que involucra el uso de caracteres alfanumericos
y del guion como u nicos caracteres validos, siendo el caracter - el del valor m
as peque
no y
el caracter z el del valor m
as grande [17].

Por ejemplo, para el caso del nombre de dominio b.test. se tendr

an los siguientes valores
como su predecesor y su sucesor respectivamente, utilizando el rango LDH y suponiendo que
el nombre de zona es test.:

Predecesor:
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.
zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.
azzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.
test.

Sucesor:
-.b.test.

El exito de este proceso se basa en la eficiencia de las funciones que obtiene el predecesor
y el sucesor del dominio no existente. Entre m as pequeno sea el rango de dominios cubiertos,
el n
umero de intentos necesarios para enumerar la zona crecer a hasta requerir un numero de
intentos igual al n umero de nombres posibles lo que disuadir a a los individuos que intentan
realizar dicho proceso.

37
Captulo 3

Definici
on del Problema

En el capitulo anterior se expuso a detalle el problema de la enumeraci on de zona en

servidores de DNS que tengan DNSSEC implementado. En dicho captulo se mencion o tam-
bien que el origen del problema es la divulgacion de dominios validos a traves del registros
NSEC para demostrar que el dominio por el que se acaba de preguntar no existe en la zona.
Dicho registro NSEC cubre un rango de dominios que abarca del dominio valido que canonica-
mente va colocado antes del dominio por el que se pregunto, y el siguiente dominio valido en
la zona, que canonicamente ira ordenado despues del dominio solicitado.

Se hablo tambien en el capitulo anterior sobre el procedimiento denominado firmado

en lnea. Dicho proceso es una alternativa de solucion al problema de enumeraci on de zona,
pero presenta una serie de inconvenientes que inclusive en el RFC 4470 que trata sobre este
procedimiento, se menciona que es preferible la utilizacion del registro NSEC3 sobre el uso de
firmado en lnea ya que ponen en riesgo la seguridad del servicio. Los inconvenientes se
nalados
en ese documento se refieren a la implementaci on del firmado en lnea directamente en los
servidores autoritativos [17]:

Los servidores requieren tener acceso a las llaves privadas para poder firmar los registros
generados. Si se puede acceder a esos servidores desde Internet, se deben de incrementar
las medidas de seguridad para evitar que dichas llaves puedan ser obtenidas por terceros.

La generacion de firmas digitales es muy demandante en terminos computacionales, por

lo que los servidores pueden ser vulnerables a ataques de negacion de servicio. Dichos
ataques pueden venir en la forma de peticiones continuas por registros no existentes
que hagan que el servidor agote sus recursos al firmar peticiones. Dicho problema existe
desde la especificaci
on de DNS original, pero con el firmado en lnea y DNSSEC dicho
riesgo se incrementan al incrementarse la carga computacional requerida para generar
paquetes de respuesta y enviarlos a los clientes.

Las funciones para la obtencion del sucesor y del predecesor (ver secci on 2.4.2), deno-
minadas tambien como funciones epsilon, son predecibles, por lo que el firmado en lnea
puede habilitar un ataque de texto plano sobre las llaves privadas. Los servidores deben
utilizar algoritmos criptograficos lo suficientemente resistentes a este tipo de ataques
para proteger dichas llaves.

38
 El registro NSEC3 (ver seccion 2.4.1), es otra solucion al problema de la enumeracion
de zona pero presenta el problema de la falta de compatibilidad con resolvers y servidores
que no manejen dicho registro, por lo que dichas entidades no consideraran una respuesta que
contenga un registro NSEC3 como valida aunque esta lo sea. A este problema se le agrega el
hecho de que apenas este ano fue liberada la especificaci
on de NSEC3, por lo a un no existe
una base importante de servidores que lo soporten [13].

Dados los inconvenientes que tienen las soluciones al problema de enumeraci on de zona
presentadas anteriormente, se opto por trabajar con la solucion de firmado en lnea ya que
puede funcionar con los servidores que existen actualmente y que en su mayora no estan
preparados para trabajar con el registro NSEC3 (aunque versiones posteriores puedan mane-
jarlo). El problema entonces, queda acotado a solucionar uno de los inconvenientes que se
presentaron para el firmado en lnea y al mismo tiempo atacar el problema de enumeraci on
de zona. Para el alcance de esta investigacion se trabajar
a en los problemas del incremento
en la carga computacional que se genera en los servidores que utilizan firmado en lnea y a
su vez en el problema de enumeraci on de zona.

El objetivo principal de este trabajo es construir un sistema que pueda impedir la enu-
meracion de zona valiendose del procedimiento de firmado en lnea, adem as dicho sistema
debera ocuparse exclusivamente de ejecutar el procedimiento de firmando en lnea a los pa-
quetes que lo requieran, liberando al servidor autoritativo de realizar dichas funciones y por
consiguiente retirando del servidor la carga computacional relacionada a la ejecuci
on de dicho
proceso.

Para lograr los objetivos mencionados, se propone la implementaci on de un servidor

Proxy de DNS que este ubicado entre el servidor autoritativo y sus clientes (resolvers o servi-
dores recursivos) y que ejecute el procedimiento de firmado en lnea para liberar de esa carga
al servidor autoritativo y al mismo tiempo impedir la enumeraci on de zona utilizando fun-
ciones epsilon que solo proporcionen sucesores y predecesores inmediatos. El servidor Proxy
se apoyara en la tarjeta electr
onica de firmado para liberar al procesador de la computadora
de dicha tarea y por consiguiente la carga computacional en el procesador principal se reduzca.

La solucion que se propone a su vez facilita la implementacion del filtrado en lnea en

servidores autoritativos, ya que al estar dicho proceso ejecut
andose en el Proxy en lugar de
ejecutarse en el servidor autoritativo, no se requiere modificar dicho servidor, solamente se
debe de asegurar que los mensajes dirigidos al servidor autoritativo, vayan ahora dirigidos al
servidor Proxy.

39
Captulo 4

Soluci
on Propuesta

La solucion propuesta abarca el desarrollo de un servidor Proxy que realice el procedi-

miento de firmado en lnea como un servicio para el servidor autoritativo que tendr a imple-
mentado DNSSEC y que de antemano se sabe que devolvera registros NSEC que contengan
rangos validos de dominios ubicados en la zona administrada por dicho servidor. Como se
expuso en la introducci on, el Proxy estara ubicado en medio de la comunicaci
on entre clientes
y servidores por lo que el cliente lo vera como un servidor autoritativo y el servidor autori-
tativo vera al Proxy como un resolver. Adem as del Proxy que modificara el contenido del
registro NSEC con funciones que obtengan el sucesor y predecesor inmediatos de acuerdo al
RFC 4471, la solucion tambien incluye el uso de una tarjeta electronica que sera utilizada
para firmar digitalmente la informaci on que sea modificada del registro NSEC para ocultar
los registros validos, creando as un registro RRSIG que sustituye al registro RRSIG original
s
olo en el caso de que el registro NSEC vaya acompa nado de una firma.

4.1. Antecedentes
El uso de servidores Proxy no es nuevo en el campo de las telecomunicaciones y las
tecnologas de informaci on. En la actualidad son utilizados para limitar la cantidad de servi-
cios de Internet a los que se puede acceder dentro de la red de una organizacion, ya que son
instalados en la frontera entre la red externa (Internet) y la interna (Intranet) y es con esta
configuracion que se asemejan a los firewalls, que son dispositivos que ejecutan un conjunto
de reglas sobre la comunicaci on que pasa a traves de ellos y que de acuerdo a dichas reglas
deciden que comunicaci on es permitida y cual esta prohibida. Otra configuraci on para los
servidores Proxy consiste en utilizarlos como enlace para los servidores que proveen alg un
servicio en Internet como el correo electronico o el Web, en este caso el Proxy recibe todas
las peticiones de los clientes y las redirecciona al servidor correspondiente, para que despues
el servidor enve al Proxy los mensajes de respuesta a la peticion solicitada y este a su vez
los enve a los clientes. En esta ultima configuracion, el Proxy puede servir tambien como
un balanceador de carga al repartir las peticiones a los servidores de manera equitativa para
evitar que alguno de ellos pueda colapsarse cuando la carga computacional recibida exceda
sus capacidades.

40
 Actualmente existe disponible un servidor Proxy dedicado exclusivamente al servicio de
DNS. El codigo fuente necesario para compilar y crear el programa ejecutable esta disponible
en la siguiente URL:
http://www.wolfermann.org/dnsproxy.html

Este Proxy recibe peticiones de DNS de los clientes y dependiendo el tipo de solicitud
(recursiva o iterativa) enva dichas peticiones a un servidor recursivo o al servidor autoritati-
vo que se le configuran de manera manual editando un archivo que contenga las direcciones
IP o nombres de dominio de dichos servidores. Este Proxy no modifica la informaci on que
contienen los paquetes pero sirve como base para observar el comportamiento que el Proxy
desarrollado en este trabajo debe de tener. La aplicacion DNSProxy fue escrita para sistemas
UNIX, por lo que un sistema como Linux puede compilarlo y ejecutarlo al estar basado en el
sistema UNIX. Este programa fue compilado y ejecutado en la distribucion Fedora Core en
su versi
on 5 del sistema Linux.

Para instalar ese servidor Proxy, hay que obtener el archivo dnsproxy-1.15.tar.gz que
se encuentra en la pagina de Internet antes mencionada. Posteriormente hay que descompri-
mir dicho archivo, esto puede hacerse desde la lnea de comandos tecleando la instruccion tar
-xzvf dnsproxy-1.15.tar.gz, que descomprime el contenido del archivo y lo almacena en
un folder de nombre dnsproxy-1.15. Si uno se posiciona ahora en dicha carpeta y ejecuta el
comando ./configure para crear el script de instalaci on, bastar a solo compilar los archivos
fuente para poder utilizar DNSPROXY. As al ejecutar posteriormente los comandos make y
make install, se compilar an los archivos fuente y se instalar an en el directorio principal de
comandos del sistema (la direccion fsica de ese directorio as como su nombre pueden variar
dependiendo de la distribucion de Linux utilizada).

Antes de ejecutar el Proxy, es necesario crear un archivo de configuraci

on que debera lla-
marse dnsproxy.conf y debera colocarse en el directorio /etc/ para que no sea necesario
indicarle al Proxy donde se localiza dicho archivo cada que se vaya a ejecutar. El archivo
debera de contener la siguiente informaci
on:
Informaci
on relativa al servidor autoritativo.
authoritative 127.0.0.1
authoritative-port 53001
authoritative-timeout 10

Informaci
on relativa al servidor recursivo.
recursive 127.0.0.1
recursive-port 53002
recursive-timeout 90

Informaci
on de la direccion y puerto donde el Proxy atendera peticiones.
listen 192.168.168.1
port 53

41
 Informaci
on de configuraci
on adicional.
chroot /var/empty
user nobody
internal 192.168.168.0/24
internal 127.0.0.1
statistics 3600

Las secciones 1 y 2 del archivo anterior deben de contener las direcciones IP reales de un
servidor autoritativo y uno recursivo (puede usarse la misma direccion en ambas), tambien
debe de incluir los puertos en los que dichos servidores escuchan peticiones, asi como tambien
un numero que representa la cantidad de segundos por las que el Proxy esperara por un
paquete de respuesta despues de haber transmitido una pregunta. La tercera secci on indica
la direccion IP de la m aquina local y el puerto por donde estara escuchando el Proxy las
peticiones. La comunicaci on entre el Proxy, los servidores y los clientes se realiza mediante
sockets de UDP, por lo que en ning un caso se establecera una conexi on entre el Proxy y
las demas entidades, ya que todo sera mediante el envo de datagramas. La secci on final del
archivo de configuraci on, incluye informacion sobre la posicion en el disco donde el Proxy se
ejecutar
a, la direccion IP de las redes de donde los clientes podran hacer peticiones y cada
cuantos segundos se imprimir an los resultados.

Para ejecutar el programa principal del Proxy, se teclea en la lnea de comandos dnsproxy
[-c /path/dnsproxy.conf]. En la figura 4.1 puede observarse una respuesta de DNSProxy,
la cual es identica a la de un servidor autoritativo ya que el paquete no es modificado, s olo es
transferido del servidor autoritativo al Proxy y de este al cliente. Para esta prueba, el servidor
autoritativo estuvo ejecut andose en la computadora con IP 200.34.22.15, puerto 5353, y el
Proxy se ejecut o en la computadora con IP 200.34.22.17 y atenda peticiones a traves del
puerto 53. Nota: Para utilizar puertos conocidos para el Proxy, o sea puertos que van nume-
rados del 0 al 1024 se requiere contar con privilegios de administrador para que el servidor
Proxy pueda ser ejecutado.

Para obtener la respuesta en la figura 4.1, el cliente solicit

o al Proxy de manera especfica
informaci
on sobre el dominio b.test, ejecutando la instruccion dig @200.34.22.17 b.test
+dnssec y recibio informaci
on que solo proporciona datos del servidor Proxy y no informaci on
que revele la identidad del servidor autoritativo.

4.2. Metodologa
Se presenta a continuaci
on la metodologa seguida para desarrollar el servidor Proxy que
realice el procedimiento de firmado en lnea para los servidores autoritativos. La metodologa
abarca desde el proceso de b usqueda de herramientas necesarias para construirlo hasta el
proceso de pruebas de funcionalidad y rendimiento necesario para evaluar el producto final:

42
 Figura 4.1: Paquete de Respuesta de DNSProxy

1. Configuracion de un servidor de DNS autoritativo.

Esta etapa incluye la instalaci

on de un servidor de DNS autoritativo y la realizacion
del proceso de configuracion para que DNSSEC este habilitado. Tambien incluye
la elaboracion de un archivo de zona y su correspondiente firmado para que el
servidor pueda devolver los registros RRSIG correspondientes a cada uno de los
registros de la zona en caso de que el cliente los solicite.

2. An
alisis del trafico generado y recibido por el servidor autoritativo.

Esta etapa incluye el an alisis de los paquetes de pregunta y respuesta que son
recibidos y generados por el servidor autoritativo respectivamente. Herramientas
de captura de paquetes de datos en la red son utilizadas para almacenar dicha in-
formacion en archivos que sirvan de referencia para comprobar posteriormente que
el Proxy en su primera etapa de construcci on no esta alterando el contenido de la
informacion en los paquetes y simplemente los transfiere a las partes involucradas.

43
3. Definicion de la plataforma y lenguaje de programaci
on utilizado para desarrollar el
servidor Proxy de DNS.

Selecci
on de plataforma y lenguaje que sea compatible con la mayora de las im-
plementaciones existentes para servidores de DNS. La plataforma y lenguaje selec-
cionados no deben ser un obstaculo para que el servidor Proxy pueda comunicarse
con el servidor autoritativo mencionado en puntos anteriores de la metodologa.

4. Selecci
on de bibliotecas con rutinas especficas aplicables al servicio de DNS para servir
de base en el desarrollo del servidor Proxy.

Las bibliotecas seleccionadas deben de funcionar con el lenguaje de programaci on

seleccionado y contener rutinas que faciliten la manipulacion de los paquetes de
datos y la informacion contenida en ellos. De preferencia dichas bibliotecas deben
ser de naturaleza abierta (c
odigo fuente disponible) por si es necesario realizar una
modificaci
on a estas para los fines de este trabajo de investigacion.

5. Desarrollo de servidor Proxy de DNS que no modifique informaci

on de los paquetes.

Desarrollo de un Proxy que reciba peticiones por el puerto 53 de la m aquina donde

estara ejecut
andose y las enve al servidor autoritativo sin modificar el paquete.
El Proxy entonces recibira del servidor autoritativo el paquete de respuesta y lo
transmitira de vuelta al cliente. El comportamiento del Proxy desarrollado debe
de ser muy semejante al de la aplicacion DNSProxy descrita con anterioridad.

6. Construccion de funciones epsilon para la obtencion de sucesor y predecesor inmediatos

al dominio solicitado.

Desarrollo de las funciones de acuerdo al RFC 4471, que tomen como argumento
el dominio solicitado y devuelvan el sucesor o predecesor inmediato, tal y como se
explica en el documento mencionado.

7. Modificacion del registro NSEC de los paquetes que lo incluyen con los valores obtenidos
de las funciones epsilon.

Sustituci
on del Owner Name del registro NSEC por el predecesor inmediato del do-
minio solicitado y sustituci
on del sucesor valido contenido en la secci
on de RDATA
por el sucesor inmediato de dicho dominio.

8. Construccion del registro RRSIG correspondiente al registro NSEC modificado.

Sustituci
on del RRSIG original en el paquete enviado por el servidor con un RRSIG
que contenga la firma sobre la informacion que se acaba de modificar del registro
NSEC. Solo el campo de firma y el Owner Name se modifican para este registro,
los demas campos mantienen los valores del registro anterior.

9. Construccion de ambiente de pruebas.

44
 Construccion de una arquitectura similar a la de la figura 1.1, donde este presente
un servidor autoritativo en conexi on con el Proxy para verificar funcionalidad
basica referente al firmado y la sustituci
on de valores del registro NSEC.
Construccion de una arquitectura que cuente con servidores recursivos, servidores
raz y servidores autoritativos como la de la figura 2.2 para validar la cadena de
confianza, es decir que la informaci on que firme el Proxy pueda ser validada por
un servidor recursivo que har a preguntas a los servidores autoritativos (el Proxy
estara colocado al frente de uno de ellos) para obtener una respuesta validada para
los clientes (bit de AD encendido en el encabezado del paquete de respuesta).
Instalaci
on de la tarjeta electronica de firmado en la computadora que albegar a al
Proxy. Esta estapa tambien incluye la configuraci on de la misma para que las
operaciones de firmado y verificacion sean realizadas por el procesador de la tarjeta.
Realizacion de pruebas de funcionalidad y rendimiento. Para las pruebas de fun-
cionalidad se comprobara que la autenticaci
on de los mensajes produce una cadena
de confianza que llega hasta la zona en la que se encuentra el servidor Proxy y el
servidor autoritativo al que sirve. Estas pruebas incluyen la validaci
on del rango
de dominios proporcionado por las funciones epsilon y la validaci on de la firma
digital del registro NSEC modificado. Las pruebas de rendimiento abarcan el envo
de paquetes al Proxy y realizar observaciones sobre la cantidad de peticiones que
el Proxy puede atender en el lapso de tiempo que dure dicho envo, con y sin la
ayuda de la tarjeta de firmado digital.

10. An
alisis de resultados.

Para las pruebas de funcionalidad se verifica que el bit de AD este encendido en

las pruebas que impliquen que el Proxy realiz o el procedimiento de firmado en
lnea. Tambien se verificara la bit
acora del servidor recursivo para corroborar que
la cadena de confianza ha sido validada con exito. Con estos resultados de las
pruebas se podra concluir que el Proxy ejecuta el procedimiento de firmado en
lnea correctamente.
Los resultados arrojados por las pruebas de rendimiento en forma de peticiones
respondidas por segundo, permitiran evaluar el desempeno Proxy con respecto al
desempeno real de un servidor autoritativo. Tambien se analizar
a el impacto del
empleo de la tarjeta de firmado en conjunto con las funciones del Proxy, dicho
impacto tambien sera medido en peticiones atendidas por segundo.

Las siguientes secciones en este captulo cubren los pasos mencionados en la metodologa.

45
4.3. Configuraci
on de Servidor de DNS Autoritativo
Para la primera etapa de la metodologa, se opto por utilizar el servidor BIND de DNS,
un servidor de DNS gratuito cuyo codigo fuente esta disponible, convirtiendolo en un servidor
de naturaleza abierta. La palabra BIND es la abreviaci on de Berkeley Internet Name Domain.
Este servidor ha sido uno de los mas utilizados en Internet, de hecho es el servidor de DNS
estandar de los sistemas UNIX, plataforma sobre la que fue desarrollado. Los orgenes de este
servidor datan desde la decada de los 80s, cuando fue desarrollado por una peticion de la
agencia DARPA (Defense Advanced Research Projects Agency) y posteriormente a mediados
de esa misma decada, empleados de DEC (Digital Equipment Corporation) se ocuparon del
desarrollo de este servidor. Uno de estos empleados, Paul Vixie se ocup o personalmente de
darle mantenimiento al servidor y colabor o en la fundacion de la organizacion ISC (Internet
Systems Consortium), organizacion que actualmente se encarga del mantenimiento de este
servidor.

BIND esta disponible en la siguiente URL, en su versi

on 9.4.0, que es la m
as reciente y
recomendada ya que fue desarrollada completamente desde cero al descubrirse serias fallas de
seguridad en las versiones 8.X y anteriores:
http://www.isc.org/index.pl?/sw/bind/

Para la instalaci
on de BIND se conto con el apoyo de NIC Mexico en materia de equipo
computacional y un asesora sobre la instalacion y configuraci
on del mismo. El equipo fa-
cilitado por NIC Mexico consta de computadoras que tienen instalado el sistema operativo
FreeBSD 6.1 que es un sistema basado en UNIX, por lo que BIND puede correr perfectamente
sobre dicho sistema ya que fue desarrollado para la segunda plataforma.

Para la instalaci
on de BIND 9, se opto por utilizar las facilidades que ofrece FreeBSD
para instalar programas mediante el uso de puertos, lo que permite contar con una versi on
completamente funcional del servidor BIND ejecutando comandos simples de compilaci on e
instalaci
on:
make search name=bind9

cd /usr/ports/net/bind9

make install

Con la anterior secuencia de comandos, se realiza la descarga del repositorio de puertos

de la versi
on 9 de BIND y se instala automaticamente como ocurre en los administradores de
paquetes (apt, yum, etc.) de otros sistemas operativos basados en UNIX como Linux.

Como siguiente paso, se generan las llaves KSK y ZSK, ya que el servidor instalado
manejara DNSSEC para que el Proxy a desarrollar pueda ser evaluado en materia de su
funcionamiento basico. La generacion de llaves se realiza de la siguiente manera:

46
 dnssec-keygen -a RSASHA1 -e -f KSK -b 2048 -n ZONE test.
Este comando genera la KSK de un tama no de 2048 bytes y adem as se le especifica a
la aplicacion que utilice el algoritmo RSASHA1 para generarla, adem as de la zona a la
que corresponde dicha llave. El tama no es mayor al de la ZSK y su tiempo de expiracion
tambien es mayor. Este comando produce dos archivos que contienen los componentes
publicos y privados necesarios para la criptografa de llave p
ublica. El nombre de los
archivos esta compuesto por el nombre de la zona (precedido por la letra K), seguido del
numero que identifica al algoritmo y finalmente el identificador de la llave. Por ejemplo
para este caso, el nombre del archivo sera Ktest.+005+30291 seguido de su extensi on,
que puede ser .private en caso de referirse a la llave privada y .key para la llave
publica.

dnssec-keygen -a RSASHA1 -e -b 1024 -n ZONE test.

Este comando genera la ZSK que se utiliza para producir registros RRSIG para acom-
panar a los registros de datos que lo requieran de acuerdo a la especificaci
on de DNSSEC.
El tama no es menor que el de la KSK, por eso se indica con la opcion -b que la llave
ocupe s olo 1024 bytes, el algoritmo es RSASHA1 y se indica tambien el nombre de la
zona que se firmara con la llave generada. Dicho nombre ir a incluido en cada RRSIG
en la seccion de RDATA. La ejecuci on de este comando tambien produce dos archivos
que contienen la llave privada y la llave publica respectivamente. El formato del nombre
de este archivo es el mismo que el formato producido al obtener la KSK, donde lo que
difiere es el valor obtenido como identificador de la llave. Para este ejemplo se crean los
archivos con nombre Ktest.+005+32402 y extensi on .key y .private.

Como segundo paso, se crea el archivo de zona que contendr

a todos los registros existentes
dentro de la misma. El apendice A en su secci on A.1 puede observarse el archivo de zona
utilizado para la computadora con IP 200.34.22.15 que contiene al servidor autoritativo. Dicha
zona no esta firmada pero ya tiene un registro DNSKEY agregado a la misma (necesario
para verificaciones), para realizar esto, se requiere concatenar el archivo de llave p ublica
ZSK (Ktest.+005+32402.key) al archivo de zona (zone.test). Esto se puede realizar con la
siguiente instruccion:
cat Ktest.+005+32402.key >> zone.test

Realizado lo u
ltimo, s
olo basta firmar la zona con el archivo que contiene la llave privada,
para esto se tiene que ejecutar el comando dnssec-signzone, adem as debe de hacerse refe-
rencia a la KSK y a la ZSK. Se presenta a continuaci on un ejemplo de como se ejecut o dicho
comando:
dnssec-signzone -o test. -k Ktest.+005+30291 zone.test Ktest.+005+32402

El comando anterior produce un archivo denominado zone.test.signed que contiene re-

gistros RRSIG que representan las firmas digitales para los registros de la zona. En el apendice

47
A.2 se incluye el archivo de zona firmado como referencia. En dicho archivo puede observarse
que se crearon registros NSEC que van colocados entre cada par de registros validos. Tambien
puede observarse que los registros ya estan ordenados de acuerdo a su correspondiente orden
canonico, dicho orden es realizado en automatico por dnssec-signzone, lo que permite tener
registros NSEC precisos.

Como siguiente paso se debe de configurar BIND para que se encargue de administrar la
zona que se acaba de crear y tambien hay que habilitar DNSSEC. Para esto se debe de editar
el archivo named.conf (ver apendice B), donde el parametro m
as importante lo constituye la
lnea dnssec-enable yes; que indica a BIND utilizar la implementaci on de DNSSEC, por
lo que se devolvera el registro RRSIG correspondiente a cada registro solicitado cuando el
cliente as lo desee.

Con la siguiente secci

on dentro del mismo archivo se indica que se desea administrar la
zona test. y se indica el nombre y la ruta del archivo que lo contiene:

zone test. {
type master;
file zone.test.signed;
allow-transfer { any; };
};

Finalmente para ejecutar el servidor, pero primero hay que tener certeza de que no existe
otro proceso de BIND ejecut andose actualmente, esto se puede hacer con la instruccion ps
-lx | grep named, y si algun proceso ya existiera solo hay que ejecutar el comando kill -9
seguido del n
umero de proceso (PID) que se obtuvo con el primer comando. De no existir un
proceso en ejecuci
on se puede ejecutar el siguiente comando que de acuerdo al contenido del
archivo named.conf (ver apendice B), habilitara a BIND en el puerto 5353:

named -c named.conf

Pueden realizar pruebas con el comando dig @127.0.0.1 -p 5353 seguido del nombre
de dominio para comprobar que BIND ya esta funcionando. Con la opcion +dnssec de dig,
el servidor debe devolver registros RRSIG ademas de los registros normales de datos.

4.4. Analisis del tr

afico generado y recibido por el servidor
autoritativo.
Como siguiente paso, se procedio a analizar el trafico proveniente de un servidor autori-
tativo para poder identificar el formato en el que la informaci on era recibida por los clientes.
Ya que el Proxy recibira la informacion en el mismo formato que la reciben los clientes, se

48
considero importante analizar los paquetes recibidos de un servidor autoritativo para iden-
tificar el lugar en el paquete de informaci
on que ocupaban las cabeceras, las secciones del
paquete (pregunta, autoritativa, adicional y respuesta), los datos contenidos en las mismas,
etc.

Para lograr esto, se utilizo la aplicacion conocida como Ethereal. Dicha aplicacion permite
realizar capturas de paquetes de informaci on en cada una de las interfaces que conectan a
la computadora que ejecuta Ethereal con redes de comunicaciones. Ethereal provee de un
ambiente gr afico para poder visualizar de una manera m as clara la informacion sobre los
paquetes recibidos, dicho ambiente permite visualizar las direcciones IP origen y destino
de los paquetes, as tambien el tama no en bytes de los mismos y el protocolo al que se
refiere. Tambien Ethereal permite obtener gr aficas que muestran la llegada de paquetes a la
interfaz seleccionada a traves del tiempo y tambien permite aplicar filtros sobre la informacion
para almacenar u nicamente los paquetes que tengan un destinatario en particular o que
correspondan a un tipo de protocolo seleccionado en los filtros. Ethereal puede ser obtenido
de la siguiente URL:
http://www.ethereal.com/download.html

Dicho programa fue instalado en un computadora con procesador Intel Celeron a 1.6 GHz
de velocidad con el sistema Linux instalado (distribucion Fedora Core 5). Ethereal fue instala-
do con el administrador de paquetes yum, ejecutando la instruccion yum install ethereal,
que instala el programa incluyendo el ambiente gr afico.

En la figura 4.2 puede observarse la ventana principal de Ethereal, que para ese ejemplo
fue configurado para capturar trafico de DNS que estuviera dirigido o proviniera de la interfaz
ethernet0 de la maquina que lo ejecutaba. Al estar capturando, la lista en la parte superior de
la ventana se va llenando con la informacion recabada de cada paquete. Tambien se observa
como al seleccionar uno de los paquetes, el valor de los bytes que lo componen es desplegado
en la parte inferior de la ventana. En la parte de en medio se presentan la informaci on del
paquete en lenguaje natural organizado en pesta nas. Se observa en dicha figura que se ha
seleccionado el protocolo DNS, pero tambien pueden seleccionarse otros que corresponden a
protocolos de capas inferiores del modelo TCP/IP, por ejemplo puede observa una pesta na
que contiene la informacion del paquete que corresponde unicamente al protocolo UDP, existe
otra que corresponde a la cabecera del protocolo IP y finalmente la pesta na superior contiene
informacion referente a la cabecera del marco de Ethernet que contiene el paquete.

En el apendice C, se incluye una recopilacion de la informaci

on obtenida con Ethereal
(ver figuras 4.2 y 4.3) de paquetes de respuesta del servidor autoritativo. El paquete de la
figura 4.2 corresponde a respuesta para la pregunta por el dominio b.test. sin la opci on de
presentar firmas dentro del paquete (sin DNSSEC). En la figura 4.3 se presenta la respuesta
del servidor autoritativo cuando se pregunta por el mismo dominio b.test, pero el paquete
s incluye firmas, por lo que puede apreciarse una diferencia de tama nos significativa ya que

49
 Figura 4.2: Lectura de Paquete de Respuesta de DNS con Ethereal

en la segunda respuesta se incluye un n

umero mayor de registros.

Los valores de los bytes presentados en el apendice C, fueron utilizados en la etapa de

desarrollo para comprobar que los valores en el arreglo de bytes recibidos por el Proxy en
los paquetes de pregunta, fueran los mismos a los capturados con Ethereal y as asegurar la
operacion correcta de la aplicacion en sus primeras etapas.

4.5. Definici
on de Plataforma y Lenguaje de Programaci
on
Para el desarrollo del servidor Proxy se opto por permanecer con la plataforma utilizada
por el servidor autoritativo (FreeBSD 6.1) debido a que ya ofrece el ambiente de desarrollo
del lenguaje C, elegido debido a que las aplicaciones desarrolladas para este lenguaje hacen
un uso m as eficiente de los recursos computacionales y los programas entregan respuestas con
mayor rapidez que en otros lenguajes, debido a esto, BIND y otras aplicaciones de servicios

50
 Figura 4.3: Paquete de Respuesta con DNSSEC en Ethereal

en Internet existentes en las plataformas UNIX fueron desarrollados en este lenguaje.

El lenguaje C ya provee de bibliotecas de sockets, estructuras que permiten la comuni-

cacion de procesos a traves de la red. Para este proyecto, la comunicaci
on se mantendr
a en
UDP utilizando el puerto 53 como enlace del Proxy con los clientes. Las bibliotecas que el
ambiente de C disponible en FreeBSD 6.1 ya provea para el uso de sockets en programas de
aplicacion son las siguientes:

sys/socket.h

netinet/in.h

La biblioteca sys/socket.h es la principal biblioteca en el lenguaje C para proveer el

uso de sockets de comunicaci on. En dicha biblioteca se define la estructura sockadrr que
permite crear y configurar los sockets de manera que se les puede asignar la direccion IP y
puerto donde los sockets estaran escuchando peticiones. Dicha biblioteca contiene metodos

51
para aceptar y recibir conexiones, as como para registrar en el sistema la asociaci
on del socket
con el puerto local de la maquina donde escucha peticiones. A continuaci on se presenta una
descripci
on de los metodos utilizados de la biblioteca sys/socket.h:

int socket(int domain, int type, int protocol):

Esta funcion crea un socket pero no lo asocia a un puerto a un. El valor entero que se
regresa corresponde a un descriptor de archivo que puede ser usado como par ametro
en llamadas a funciones que utilicen sockets. Esta funcion recibe como argumentos un
valor de dominio que corresponde al entorno en donde el socket se va a comunicar, para
este caso, el entorno es Internet. El otro argumento de la funcion es el tipo de socket
(orientado a conexion o datagrama) y finalmente se enva el valor que corresponde al
protocolo de comunicaci on que se desea utilizar, si dicho valor es 0, el socket creado
utiliza un protocolo apropiado de acuerdo al valor que se enva como tipo de socket.

int bind(int socket, const struct sockaddr *address, socklen t address len):
La funcion bind realiza la asignaci
on de la direccion y puerto a un socket creado con
la funcion socket(). El par ametro socket especifica el descriptor que se obtuvo de
la funcion socket(), el apuntador *address corresponde a la estructura en memoria
de tipo sockaddr que contiene informaci on de la direccion y el puerto donde el socket
escuchar a peticiones. Finalmente el par
ametro address len indica el tama no de la
estructura sockaddr apuntada por *address. Esta funcion regresa el valor de 0 si tuvo
exito, en caso contrario regresa un -1.

size t recvfrom(int socket, void *buffer, size t length, int flags, struct sock-
addr *address, socklen t *address len):
La funcion recvfrom() se utiliza para recibir mensajes en el socket ya sea de modo orien-
tado a conexion o mediante datagramas. Dicha funcion trabaja en modo bloqueante, es
decir, que el programa de aplicacion que la utilice se quedar a esperando hasta recibir
un mensaje en el socket y entonces procedera a ejecutar las instrucciones que siguen
despues de esta funcion. A esta funcion se le enva tambien el descriptor del socket como
parametro, pero tambien se le enva un apuntador a un buffer de datos, que consiste en
un espacio en memoria destinado a almacenar la informaci on recibida (datos enviados
en el paquete de UDP). Tambien se especifica la longitud en bytes del buffer de datos y
se proporciona a la funcion un registro de banderas donde se indica como se desea que
sea la operacion de recepcion. Para el servidor Proxy, no se especific o bandera alguna.
Los siguientes dos par ametros son el apuntador a la estructura que contiene la informa-
ci
on del socket y la longitud del espacio en memoria que dicha estructura ocupa. Esta
funcion regresa la longitud en bytes de la informaci on recibida y que es escrita en el
buffer de datos.

size t sendto(int socket, const void *message, size t length, int flags, const
struct sockaddr *dest addr, socklen t dest len):
Esta funcion se encarga de enviar el contenido del buffer de datos apuntado por message
a la direccion indicada por dest addr. Se le especifica a traves del par
ametro length

52
 el tama no en bytes de la informaci on que se desea enviar. Los demas parametros son
iguales a los utilizados en la funcion recvfrom(). Esta funcion regresa el tama no en
bytes de la informaci on enviada. No existe manera de comprobar si fue recibida con
exito si se estan utilizando datagramas ya que no los receptores no envan paquetes de
reconocimiento al recibir el mensaje.

La biblioteca netinet/in.h fue utilizada para especificar en la estructura del socket

parametros de la familia de Internet, que son la direccion IP y el puerto utilizado. Tambien
se opto por utilizar la estructura sockaddr in definida en esta biblioteca en lugar de la
estructura sockaddr, ya que esta estructura ya corresponde a la familia de Internet por lo
que la asignacion de parametros de direccion IP y puerto se hace de manera directa. Dicha
estructura debe de ser asignada a una estructura sockaddr para que pueda ser utilizada en
las funciones de la biblioteca socket.h. Dicha asignacion puede ser realizada de la siguiente
manera:
(struct sockaddr *)&address, donde address es un apuntador a una estructura de
tipo sockaddr in.

4.6. Selecci
on de Bibliotecas de DNS
Al inicio del proyecto ya se conoca sobre la existencia de bibliotecas del servidor BIND
para DNS en lenguaje C, pero tambien se conoca sobre la herramienta drill, que funciona
de una manera similar al comando dig en el sentido que permite realizar preguntas a servi-
dores de DNS por la existencia de registros correspondientes al nombre de dominio solicitado.
Los autores de la aplicacion drill, NLnet Labs, tambien crearon una serie de bibliotecas
denominadas ldns que tienen como objetivo facilitar el desarrollo de software de DNS.

La gente de NLnet Labs se ha enfocado al estudio de nuevas tecnologas para el mejo-

ramiento de las aplicaciones del servicio de DNS, por ejemplo, ellos han desarrollado un
servidor de nombres de naturaleza abierta como BIND denominado NSD, tambien han desa-
rrollado documentacion para apoyar a quienes desean migrar de DNS a DNSSEC, as tambien
se encuentran trabajando en solucionar problemas de compatibilidad de la versi on 6 de las
direcciones del protocolo IP con la versi
on 4 para que la migraci
on a la nueva versi
on sea m
as
sencilla.

El paquete de bibliotecas de ldns fue desarrollado en C, y en su versi on 1.1.0 ya in-

cluye soporte para poder desarrollar software del servicio de nombres que tambien maneje los
registros y procedimientos definidos en los documentos RFC de DNSSEC. El paquete ldns
sirvio para desarrollar drill, herramienta que al ser un resolver, esta preparada para recibir
registros firmados y los bits de encabezado incorporados con la liberacion de la especificaci
on
de DNSSEC.

53
 Debido a la compatibilidad con DNSSEC y a que ldns permite abstraer muchos pro-
cedimientos del servicio de DNS utilizando los m odulos ya definidos se opto por utilizar este
paquete de bibliotecas, adem as de que funciona en conjunto con libreras estandar de C para
realizar las firmas digitales como la librera libcrypto de OpenSSL que contiene la imple-
mentacion de los algoritmos de firmado m as comunes como el RSA y el DES.

La biblioteca ldns puede ser obtenida de estas direcciones (la versi on m

as actual es la
1.2.0 liberada en Abril de 2007, se trabajo con la versi
on anterior, la 1.1.0):

URL principal: http://www.nlnetlabs.nl/ldns/

URL descarga: http://www.nlnetlabs.nl/downloads/ldns-1.2.0.tar.gz

La instalacion se realiz
o tomando como base el codigo fuente de ldns, que se compil oe
instalo en la computadora que albegara al Proxy cuyo sistema operativo es FreeBSD con
kernel 6.1 como se mencion o anteriormente. Para la compilaci on e instalaci
on de dichos pa-
quetes de libreras se siguieron los siguientes pasos, que estan contenidos en el archivo README
includo dentro de la carpeta comprimida de ldns:

1. Descomprimir la carpeta con el comando tar -xvfz ldns-<VERSION>.tar.gz.

2. Posicionarse dentro de la carpeta con nombre ldns-<VERSION> con el comando cd.

3. Ejecutar el script de configuraci

on tecleando ./configure.

4. Ejecutar el script de compilaci

on tecleando make.

5. Instalar la librera en el sistema con la instruccion make install, esta instruccion re-
quiere que el usuario tenga privilegios de administrador.

Las siguiente secci

on describe el desarrollo del Proxy cubriendo los puntos del 5 al 8 de
la metodologa. En dicha secci
on se describe tambien las principales funciones de ldns que se
utilizaron para su desarrollo.

4.7. Desarrollo del Servidor Proxy

Como primer paso para el desarrollo del servidor Proxy, se opto por desarrollar una
aplicacion de tipo servidor que escuchara peticiones a traves del puerto 5353 de UDP con
la funcion recvfrom(). Las peticiones se le envan a la aplicacion con el comando dig o el
comando drill y dentro de la aplicacion se imprime el contenido del paquete recibido para
comprobar que la informaci on obtenida coincide con la informaci on que se obtuvo con ayuda
de la herramienta de captura de paquetes Ethereal. Las peticiones a la aplicacion se realizaban
de la siguiente manera:

54
 dig -p 5353 @127.0.0.1 <NOMBRE DE DOMINIO>

Dichas peticiones no eran atendidas por la aplicacion, por lo que el programa cliente
(dig o drill) reportaba que no exista un servidor de nombres que respondiera. Sin embargo
en la aplicacion servidor se pudo leer el contenido del paquete recibido, cabe aclarar que la
funcion recvfrom(), devuelve el contenido del paquete sin cabeceras de UDP o IP, por lo que
la informaci
on leda por la aplicacion corresponda a solo los bytes que componen el paquete
de pregunta de DNS.

Como se mencion o con anterioridad, ldns provee funciones y de estructuras de datos

que permiten manipular con un nivel de abstraccion mayor la informaci on de los paquetes
de DNS, as en lugar de manipular la informaci on en bytes, se puede utilizar una estructura
de datos conocida como ldns pkt que representa a un paquete de DNS con sus cabeceras,
registros y secciones como las contiene un paquete de DNS pero nos ofrece la facilidad de
editar cada uno de sus elementos introduciendo cadenas de caracteres o valores numericos,
incluso tambien nos permite manipular la lista de registros correspondiente a una secci on en
especfico sin alterar las demas. Dicha estructura tambien puede albergar registros RRSIG
y los nuevos campos de la cabecera de paquetes de DNS incorporados para DNSSEC. Por
esto u
ltimo, esta estructura fue elegida para contener el paquete de datos a modificar ya que
ofrece ese tipo de facilidades que con un arreglo de bytes no se tienen.

Para poder utilizar la estructura de datos de ldns pkt, se requiere emplear una funcion
de la biblioteca de ldns que convierte cadenas de caracteres (lo que se recibio en el buffer
a traves del socket) a la estructura mencionada anteriormente. Dicha funcion se describe a
continuacion:

ldns status ldns wire2pkt(ldns pkt **packet, const uint8 t *data, size t len):
Esta funcion se encarga de convertir una cadena de caracteres, en este caso una secuen-
cia apuntada por data y que es de len bytes de tama no. Se proporciona tambien la
referencia a la estructura de paquete en la que se desea se almacene la informaci on con-
tenida en los bytes recibidos. La funcion regresa un valor de estado reconocido por la
biblioteca ldns, donde s olo si el valor de estado es igual a LDNS STATUS OK se considera
que la operacion se realiz
o con exito.

Contando ya con la informaci on recibida del paquete de pregunta dentro de la estructura

de paquete de ldns, se procedio a utilizar la siguiente funcion que se encarga de transmitir el
paquete de pregunta a un servidor de DNS y dentro de esa misma funcion, tambien se recibe
el paquete de respuesta que es devuelto al final como resultado de la funcion. Para que esto
pueda realizarse, la aplicacion debe de contar con una estructura de tipo ldns resolver, que
como su nombre indica, representa a una aplicacion de tipo resolver que se encarga de hacer
la pregunta y de recibir la respuesta, tal y como lo hara un cliente de DNS. Dicha funcion se
describe a continuacion:

55
 ldns status ldns resolver send pkt(ldns pkt **answer, const ldns resolver *r,
const ldns pkt *query pkt):
Esta funcion realiza el proceso de enviar el paquete apuntado por query pkt y recibirlo
en una estructura de paquete de DNS apuntada por answer, para esto se utiliza el re-
solver r, que realiza las funciones de envo y recepci
on, por lo que no se requiere abrir
sockets explcitamente para comunicar la aplicacion con el servidor autoritativo ya que
la funcion lo hace de manera interna. La funcion tambien regresa un valor de estado y
solo si el estado es igual a LDNS STATUS OK se asume como exitosa la operacion. Esta
funcion realiza tres intentos para tratar de contactar al servidor, si esto no es posible,
la funcion deja de bloquear la aplicacion y permite que se realicen las operaciones que
le siguen.

Para ampliar la explicacion sobre el objeto resolver, dicho objeto debe de tener conocimien-
to de la direccion IP o del nombre de dominio del servidor al que estara dirigiendo las peti-
ciones de los clientes. Dicho valor se puede obtener de un archivo de texto que s olo contenga
la lnea nameserver <IP SERVIDOR>. Dicho archivo se nombro como server1.conf y para
acceder a el y crear el objeto resolver se puede utilizar la siguiente instruccion:

ldns status ldns resolver new frm file(ldns resolver **r, const char *filename):
Con esta funcion se le asigna al resolver apuntado por r que lea el contenido del archivo
apuntado por filename para obtener de ah el nombre de dominio o la IP del servidor
de DNS al que se conectara.

Ya con el paquete de respuesta dentro de una estructura ldns pkt, es posible emplear
otra funcion que realiza el proceso contrario a la funcion ldns wire2pkt, es decir, ahora de
una estructura de paquete de DNS, se convierte la informaci on a un paquete de bytes que
puede ser enviado a traves de un socket a la direccion del cliente por medio de la funcion
sendto de la librera de sockets descrita con anterioridad. Esto se realiza de la siguiente
manera:

ldns status ldns pkt2wire(uint8 t **dest, const ldns pkt *p, size t *size):
Esta funcion deposita el contenido de la estructura apuntada por p en el arreglo de
bytes referenciado por dest. Tambien se almacena en el espacio apuntado por size la
cantidad de bytes que contiene la cadena de caracteres dest. La funcion regresa un valor
de estado para indicar que la operacion si se realiz
o correctamente o existi
o alg
un error
en la transferencia.

Con esta ultima operacion completada con exito se procede a utilizar el metodo sendto
de la manera descrita anteriormente para enviar al cliente la respuesta a su peticion, pero al
contar el nuevo paquete con cabeceras de UDP y de IP correspondientes al Proxy y no al del
servidor autoritativo, se asegura que el Proxy cumple su cometido de servir de enrutador y a
la vez ocultar la identidad del servidor que responde. El programa fue modificado para que

56
se cicle escuchando peticiones y atendiendolas, una a la vez. Al estar en modo bloqueante, no
se realizaran otras acciones hasta que no se reciba un paquete de pregunta por el socket de
entrada.

Posteriormente se procedio a implementar las funciones epsilon para obtener el predece-

sor y el sucesor de un dominio dado. Dichas funciones estan basadas en el RFC 4471, donde se
menciona un metodo absoluto que garantiza que el rango de dominios obtenido por ellas cubre
solamente el dominio solicitado y no se cubre ning un dominio valido. En dicho documento
se menciona un metodo m as eficiente pero su uso es restrictivo a nombres de dominio que
excedan en 1 el valor de las etiquetas del nombre de zona. Una variante de este u
ltimo metodo
fue implementada despues de descubrir la problematica existente con el servidor BIND con el
metodo absoluto durante las pruebas de cadena de confianza realizadas con un servidor raz
y un servidor recursivo Proxy. La solucion final implementada conserva elementos de ambos
metodos. En secciones posteriores de este mismo captulo se expone a detalle la problematica
detectada [17].

Las modificaciones a los metodos absolutos para la obtenci

on del sucesor y del predecesor
son las siguientes [17]:

1. Se eliminan del nombre de dominio las etiquetas menos significativas que excedan del
n
umero de etiquetas del nombre de zona m as uno. Este es el nuevo primer paso para
ambos metodos.

2. El paso 1 del metodo para la obtencion del predecesor es eliminado ya que la existencia
del nombre de la zona nunca sera negada.

3. El paso 4 del metodo absoluto para obtener el predecesor (ver secci

on 2.4.2) s
olo es
requerido con nombres de dominio que solo excedan en una etiqueta el nombre de zona.

4. El paso 5 del metodo absoluto para obtener el predecesor es eliminado pues los nombres
de dominio solo tendr
an una etiqueta mas que las que tiene el nombre de zona.

5. El paso 1 del metodo absoluto para obtener el sucesor (ver secci on 2.4.2) fue eliminado
y en su lugar se procede directamente al paso 2, es decir se agregara siempre que sea
posible el caracter de valor menor en la posicion menos significativa de la etiqueta menos
significativa al nombre de dominio para obtener su sucesor.

Como modificaci on extra, se restringio el rango de caracteres validos a s

olo los caracteres
correspondientes a los n
umeros del 0 al 9 y las letras min
usculas de la a a la z. Se adopt
o al
0 como el caracter con menor valor permitido y a la z como el caracter con mayor permitido.
Esta modificacion responde al hecho de que caracteres no alfanumericos como el caracter -
no son aceptados para formular preguntas de DNS en aplicaciones como dig. A continuaci on
se presenta un ejemplo para el dominio b.test. para observar como afectan los cambios al
resultado final obtenido con las funciones de predecesor y sucesor:

57
 Predecesor:
azzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test.

Sucesor:
b0.test.

Las funciones epsilon fueron denominadas como previousDomain y nextDomain, estas

funciones reciben como argumentos dos apuntadores a arreglos de caracteres, uno de estos co-
rresponde al nombre de dominio solicitado por el usuario y el segundo corresponde al nombre
de zona, que es necesario para casos en que la eliminacion de caracteres del nombre de dominio
resulta en un nombre de dominio igual al nombre de zona, que se le devuelve al usuario de
inmediato. Ambas funciones almacenan el arreglo de caracteres del dominio obtenido (prede-
cesor y sucesor) en una estructura de tipo ldns rdf, dicha estructura conforma cada elemento
contenido en un registro de datos, por ejemplo el Owner Name y cada campo de informaci on
contenido en la seccion de RDATA esta representado en la estructura de paquetes de DNS
por una estructura ldns rdf, por tal motivo se devuelve una estructura de este tipo.

Ya con la obtencion de sucesor y predecesor lista, se procedio a modificar en los paquetes

de respuesta recibidos del servidor autoritativo los registros NSEC que pudieran presentarse
para as evitar la enumeraci on de zona. Cabe destacar que el paquete de respuesta puede
contener hasta 2 registros NSEC, uno para indicar cual es el primer dominio valido en la
zona y otro que proporciona el predecesor y sucesor validos al dominio solicitado. El primer
registro NSEC s olo es enviado en peticiones que no cubren un registro valido (el estado del
paquete es NXDOMAIN) y adem as la etiqueta que sigue al nombre de zona no corresponde
a la de un registro que no existe en la zona. Esto se expone a detalle en el cuadro 4.1, donde
el cliente pregunta por el registro b.test que no existe dentro de la zona, as que recibe 2
registros NSEC para indicarle el primer dominio valido y los dominios validos que rodean
al nombre de dominio solicitado. En el caso de que el cliente pregunta por un nodo hijo no
existente de un dominio valido, recibira solo el NSEC correspondiente al rango de dominios
validos donde ese dominio se ubicara, como el caso del dominio x.a.test de la figura 1, que
al no existir en la zona, el servidor autoritativo devuelve s olo el registro NSEC que lo ubica
dentro del rango que va desde a.test hasta c.test.

Pregunta Respuesta
b.test. test. 3600 IN NSEC a.test. A RRSIG NSEC
a.test. 3600 IN NSEC c.test. A RRSIG NSEC
x.a.test. a.test. 3600 IN NSEC c.test. A RRSIG NSEC

Cuadro 4.1: Envo de Diferente N

umero de Registros NSEC

Para poder editar el contenido del registro NSEC con los nuevos valores, primero se
deba diferenciar entre los paquetes con estado NXDOMAIN y los paquetes con estado NO-

58
ERROR, ambos pueden contener registros NSEC, pero s olo para el estado NXDOMAIN se
utilizar
a la funcion para obtener el predecesor del dominio solicitado, mientras que la funcion
para la obtencion del sucesor sera utilizada en todos los casos. Tambien cabe aclarar que
los registros NSEC pueden ir contenidos en las secciones de respuesta y autoritativa de un
paquete de DNS, pero s olo si el estado es de tipo NXDOMAIN, los paquetes ir an en la secci
on
autoritativa unicamente, para el estado NOERROR pueden ir ubicados en ambas secciones.

Primero se procedio a determinar si el estado del paquete es de tipo NXDOMAIN, esto

se puede hacer con la siguiente instruccion del codigo del Proxy:

ldns pkt rcode ldns pkt get rcode(const ldns pkt *p):
Esta funcion nos regresa el codigo de estado de un paquete de DNS, recibe como argu-
mento la estructura del propio paquete y nos devuelve un valor de estado, que si resulta
igual al valor de estado definido en la biblioteca de ldns como LDNS RCODE NXDOMAIN,
se tiene la certeza de que se esta tratando con un paquete de tipo NXDOMAIN que
tendra los registros NSEC en la seccion autoritativa u
nicamente.

Como siguiente paso se procede a ubicar la secci

on autoritativa y obtener la lista de
registros correspondiente donde se encuentra al menos un registro NSEC. Esto se logra con
la siguiente instruccion:

ldns rr list* ldns pkt authority(const ldns pkt *p):

Esta funcion nos devuelve un apuntador a una estructura ldns rr list que contendr
a la
lista de registros ubicados en la secci
on autoritativa.

A partir de esta funcion, se puede ejecutar sobre la estructura devuelta la instruccion

ldns rr list rr count(const ldns rr list *rr list) que devuelve un valor numerico
que corresponde al n umero de registros que componen la lista, as sera m
as facil recorrer
la lista utilizando ciclos y extrayendo un registro nuevo con cada iteracion para determinar
si el registro obtenido es un registro de tipo NSEC. La funci on utilizada para ese fin es la
siguiente:

ldns rr* ldns rr list rr(const ldns rr list *rr list, size t nr):
Esta funcion nos regresa el apuntador a una estructura de tipo ldns rr que representa
la estructura de un registro de DNS. La funcion requiere como argumentos un apun-
tador a la lista de registros que contiene el registro a extraer y un n
umero entero que
corresponde a la posicion de ese registro dentro de la lista.

Se puede utilizar la funcion ldns rr get type(const ldns rr *rr) pas andole como
par
ametro el registro obtenido para que nos devuelva un valor de tipo de registro reconocido
por ldns. Si dicho valor es igual al de la constante definida como LDNS RR TYPE NSEC, en-
tonces se asegura que el registro que se tiene representa un registro NSEC, cuyos valores de

59
Owner Name y primer campo de RDATA deben de ser modificados con los valores obtenidos
del predecesor y del sucesor.

Para la sustitucion de los nombres de dominio contenidos en el registro NSEC por los
nuevos valores se usaron las siguientes funciones:

ldns rdf* ldns rr owner(const ldns rr *rr):

Esta funcion proporciona un apuntador hacia la estructura que contiene el Owner Name
del registro. Recibe como parametro un apuntador a la estructura de dicho registro y
regresa un apuntador a una estructura ldns rdf que representa un elemento de datos
dentro del registro.

ldns rdf* ldns rr rdf(const ldns rr *rr, size t nr):

Esta funcion proporciona devuelve un apuntador hacia la estructura de tipo ldns rdf
que contiene un elemento de la secci on RDATA del registro apuntado por rr y que
de acuerdo al valor numerico proporcionado en el par ametro nr, nos proporcionara el
elemento colocado en la posicion nr de dicha secci
on. En el caso del registro NSEC, si la
posicion es 0, esta funcion devolvera el RDATA que corresponde al nombre de dominio
del sucesor.

ldns status ldns str2rdf dname(ldns rdf **rd, const char *str):
Esta funcion almacena una cadena de caracteres apuntada por str y que corresponde
a un nombre de dominio, en una estructura de tipo ldns rdf, y as poder utilizar esta
estructura para insertarla dentro de los paquetes.

void ldns rr set owner(ldns rr *rr, ldns rdf *owner):

Esta funcion sustituye la estructura ldns rdf original que se refiere al Owner Name del
registro, por la estructura del mismo tipo apuntada por owner, permitiendo as intro-
ducir el valor del predecesor obtenido con anterioridad.

ldns rdf* ldns rr set rdf(ldns rr *rr, const ldns rdf *f, size t position):
Esta funcion es utilizada para sustituir la estructura ldns rdf que corresponde a la sec-
ci
on de RDATA del paquete apuntado por rr y que va colocada en la posicion indicada
por el valor numerico de position.

Con estas funciones se pueden sustituir dentro del paquete de respuesta los valores de
sucesor y de predecesor por lo obtenidos con las funciones epsilon, ahora como siguiente paso,
es necesario firmar el registro modificado para que la cadena de confianza pueda llegar a vali-
darse. Esto ultimo solo en caso de que el usuario haya solicitado una respuesta validada (bit
DO encendido) y el paquete de respuesta que proviene del servidor autoritativo incluya regis-
tros RRSIG que correspondan a firmas de registros NSEC. Para determinar esto, el tipo de
registro a buscar reconocido por ldns es LDNS RR TYPE RRSIG, dicho registro siempre sucede
en la lista al registro NSEC que firma.

60
 Como se mencion o en el captulo 2, en la secci
on 2.2.1, para poder realizar el firmado
digital se requiere tener acceso a la llave privada, dicha llave privada corresponde a la llave
de zona ZSK y debe estar accesible para el Proxy para poder firmar con ella. Por lo expuesto
anteriormente, la llave privada de la zona fsicamente estara en la computadora que albergue
al proceso del servidor Proxy. Para este trabajo se asumi o que no existir
a un proceso de inter-
cambio de llaves entre la computadora que albergue al Proxy y la computadora que albergue
al servidor autoritativo.

Para poder leer el archivo que contiene la llave privada con la ayuda de la biblioteca
ldns se utilizo la siguiente funcion:

ldns status ldns key new frm fp(ldns key **k, FILE *fp):
Esta funcion almacena en una estructura de tipo ldns key, la llave privada leda del
archivo apuntado por fp. Para esta investigacion, el formato de la llave contenida en el
archivo corresponde al formato 1.2 y el algoritmo es el 5 (RSASHA1).

Ejecutando la funcion anterior, se cuenta entonces con un apuntador a una estructura

reconocida por ldns para manejar llaves privadas. Al utilizar ldns las libreras de OpenSSL
para sus operaciones de criptografa de llave p
ublica, se garantiza que el resultado de dichas
operaciones sera identico al que se hubiera obtenido directamente de esas libreras. Parti-
cularmente, un metodo utilizado dentro de la funcion de firmado de ldns es el metodo de
OpenSSL RSA Sign() que recibe dentro de sus argumentos el resumen (digest) de la infor-
macion a firmar as como un apuntador a una estructura de tipo RSA que contiene la llave
privada. El metodo de ldns para firmar digitalmente un registro y obtener como resultado
un registro RRSIG es el siguiente:

ldns rr list* ldns sign public(ldns rr list *rrset, ldns key list *keys):
Esta funcion devuelve un apuntador a una lista que contiene registros RRSIG que co-
rresponden a las firmas de los registros contenidos en la lista apuntada por rrset (para
el caso especfico del Proxy, dicha lista s
olo contena un registro NSEC). Se proporciona
tambien como argumento un apuntador a una estructura de tipo ldns key list que
contiene las llaves a ser utilizadas para firmar el registro (para este caso particular,
solamente se contaba con una sola llave, la ZSK).

Despues de realizar esta operacion, se pueden sobrescribir los valores del RRSIG original
que vena con el paquete enviado por el servidor autoritativo y sustituir los valores de Owner
Name (para colocar ah el nombre de dominio del predecesor si es que aplica) y obviamente
el valor de la firma de la nueva informaci on que se ubica en la ultima posicion de la secci
on
de RDATA del registro RRSIG.

Para la compilaci on del programa se requiere hacer referencia a las carpetas que con-
tienen los archivos de encabezados (.h) con la opci
on -I y los archivos de libreras (.o, .so y

61
.a) con la opcion -L. Los archivos de encabezados pueden obtenerse de la carpeta de ejemplos
que viene includa con el archivo comprimido de ldns, como caso especial, para obtener el
archivo de encabezados configure.h, se debe de ejecutar el comando ./configure dentro
de la carpeta examples del folder principal que se genero al descomprimir el archivo de ldns.
Las archivos de libreras se obtuvieron al compilar ldns (ver secci
on 4.6) y se ubican dentro
del folder lib de la carpeta principal.

El comando completo para compilar la aplicacion con sus opciones es el siguiente (el
archivo fuente se denomin
o dnsproxy.c y se ubica en la carpeta examples dentro del folder
principal de ldns):

gcc -I../include -g -O2 -Wall -I. -L../lib -lpcap -lldns -o dnsproxy dnsproxy.c
Opciones:

La opci
on -I../include indica que se desea que se incluyan los archivos de en-
cabezados localizados en la carpeta ldns que se encuentra dentro de la carpeta
include que se localiza al mismo nivel que la carpeta examples.
La opcion -g indica que se desea poder realizar labores de debuggeo sobre la apli-
cacion utilizando el comando gdb ./dnsproxy. Esto u ltimo fue u
til para detectar
errores dentro del ciclo de las operaciones del programa.
La opcion -O2 indica que se desea optimizar el codigo para una mejor ejecuci
on del
mismo. El 2 que sigue a la O corresponde a un valor n umero que indica el esfuerzo
que el procesador debe de invertir para optimizar el codigo.
La opci on -Wall indica que se desean habilitar las advertencias durante la compi-
lacion. Dichas advertencias pueden indicar que no se utilizan variables declaradas
o que se esta asignado un valor incorrecto como par ametro de una funcion.
La opci
on -I. se indica que se desea incluir el archivo config.h presente dentro
de la misma carpeta donde se encuentra el archivo fuente dnsproxy.c, la carpeta
examples.
La opci
on -L../lib se encarga de incluir en la compilacion las librerias ubicadas
dentro de la carpeta lib ubicada al mismo nivel de la carpeta examples.
Lo opcion -lpcap hace referencia a la librera del mismo nombre utilizada para
extraer informaci
on dentro de los paquetes recibidos.
La opci
on -lldns hace referencia a la aplicacion principal de ldns que fue instalada
con la ejecuci
on del comando make install para la ejecuci on de los metodos
contenidos en las libreras.
La opci on -o dnsproxy indica que se desea que el nombre del ejecutable de la
aplicacion sea el nombre de dnsproxy.

Para ejecutar el servidor Proxy, basta con escribir el nombre de la aplicacion seguido
del n
umero de puerto de UDP sobre el que se desea que el Proxy escuche peticiones. Por

62
ejemplo para escuchar peticiones en el puerto 53 basta con posicionarse en el folder examples
y ejecutar la siguiente instruccion:

./dnsproxy 53

Con esta ultima operacion se finaliza con el desarrollo del Proxy, en la secci
on siguiente
que cubre la ejecuci
on de pruebas de funcionalidad y rendimiento se mencionan las modifica-
ciones realizadas de acuerdo a los problemas localizados durante las pruebas.

4.8. Construcci
on de Ambiente de Pruebas
Para la construcci
on del ambiente de pruebas, se plante
o primero la idea de realizar prue-
bas de funcionalidad para despues realizar pruebas de rendimiento para el servidor Proxy. Las
pruebas de funcionalidad constan de evaluaciones al proceso iterativo y al proceso recursivo
para comprobar que los valores correctos de predecesor y sucesor son insertados dentro del
paquete y la firma que acompa na a la informaci
on modificada es la correcta, para esto u
ltimo
el proceso recursivo nos puede confirmar que la firma ha sido verificada con la ayuda del
bit de AD de la cabecera de los paquetes de DNSSEC. Para las pruebas de rendimiento se
registrar
a el tiempo y la carga computacional que experimenta el procesador al recibir un
n
umero determinado de peticiones por dominios existentes y no existentes en la zona y se
compararan los resultados obtenidos con que se obtienen al repetir la misma prueba sobre un
servidor autoritativo. La pruebas de rendimiento solo se realizaron para el proceso iterativo
e involucran el uso de la tarjeta de firmado.

4.8.1. Ambiente de Pruebas - Proceso Iterativo

Para construir el ambiente de pruebas para el proceso iterativo, se diseno una arquitec-
tura como la de la figura 1.1. El servidor autoritativo esta ubicado en la computadora con IP
200.34.22.15 y el servidor Proxy se coloco en la computadora con IP 200.34.22.17. En ambas
computadoras se deposito una copia de la llave privada con la que se firm o la zona test.
administrada por 200.34.22.15. El archivo server.conf indica al servidor Proxy preguntar
al servidor autoritativo en la maquina 200.34.22.15 para resolver los nombres solicitados por
los clientes.

En este caso, el proceso consistio en utilizar la configuraci

on que BIND descrita anterior-
mente para la computadora 200.34.22.15 y al estar las computadoras en la misma red, no se
requiri
o de una configuracion extra para que las m aquinas pudieran comunicarse entre s. En
la computadora .17 el servidor Proxy fue activado para comunicarse a traves del puerto 53
con la instruccion ./dnsproxy 53 (se requieren privilegios de administrador para utilizar este
puerto conocido). As, desde otra computadora instalada en la misma red, la 200.34.22.16, se
ejecutaron comandos dig para generar preguntas dirigidas al Proxy, preguntas referentes a

63
registros no existentes en el archivo de zona por lo que deberan de ser modificados y firma-
dos al momento de que el Proxy procese la solicitud. La figura 4.4 muestra la arquitectura
utilizada para estas pruebas, que no difiere de la utilizada en la figura 1.1.

Figura 4.4: Arquitectura de Proceso Iterativo

Ya con los servidores ejecutandose, se realizaron peticiones explcitas por dominios no

existentes en la zona al servidor Proxy para que el proceso de obtencion de sucesor y prede-
cesor se realizara para cada peticion. El apendice E presenta los resultados de las peticiones
realizadas al servidor Proxy. En la figura 4.5 puede observarse un paquete de respuesta para
la pregunta por el dominio noexiste.test.. En dicho paquete, se obtuvo el predecesor a
dicho dominio decrementando el caracter e y rellenando la etiqueta con el caracter que tiene
el maximo valor, la z. El sucesor se obtuvo agregando el caracter con el valor mnimo, el 0
a la derecha del caracter menos significativo de la etiqueta menos significativa. Tambien se
incluye un registro NSEC para indicar el primer registro presente en la zona que va despues
del nombre de zona, pero dicho registro tambien se oculto al usuario, en lugar se presenta
el caracter 0 (valor mnimo) como la etiqueta menos significativa representando al primer
dominio en la zona aunque en realidad el dominio 0.test. no existe dentro de ella. Final-
mente puede apreciarse el bit AA encendido en el paquete de respuesta, que confirma que la
respuesta provino de un servidor autoritativo.

Tambien en la figura 4.5 puede observarse que el identificador de llave del registro RRSIG
que corresponde al registro SOA y el identificador de las llaves de los registros RRSIG que fir-
man los registros NSEC son iguales, adem as de los valores de fecha de expiracion e incepci
on,
as tambien el nombre de la entidad que firma el registro se mantiene. Aunque dichos valores
no garantizan que el registro se haya firmado correctamente si sirven para identificar que se
ha aplicado la llave del servidor autoritativo sobre la informaci on contenida en los registros
NSEC. La verificacion de la informaci on se deja pendiente para efectuarse en el proceso re-
cursivo.

64
 Figura 4.5: Paquete de Respuesta del Servidor Proxy

4.8.2. Ambiente de Pruebas - Proceso Recursivo

Para construir el ambiente de pruebas correspondiente al proceso recursivo, se penso en
elaborar una arquitectura similar a la de la figura 2.2, que permita evaluar la cadena de
confianza que va desde el servidor raz hasta el servidor que corresponde a la zona donde se
desea localizar un dominio. Para eso se definen tres tipos de servidores:

Servidor Recursivo: A este servidor se le envan los paquetes de pregunta para que
a su vez, este inicie el proceso iterativo con el servidor raz y luego con el servidor
autoritativo de la zona test. para obtener los registros solicitados que corresponden
a los de dicha zona. Este servidor adem as debe realizar la verificacion de la cadena de
confianza, es decir validar la informaci on que es recibida de los otros servidores usando
el proceso de verificacion de firmas de la criptografa de clave p
ublica, ademas, en el caso
de los registros NSEC, debe de validar que el dominio solicitado este ubicado dentro
del rango de dominios que dicho registro indica. El servidor recursivo fue instalado en
la computadora con IP 200.34.22.56 y fue configurado para enviar todas sus preguntas

65
 al servidor raz.

Servidor Raz: Este servidor recibe primero las peticiones del servidor recursivo, y si
estas se refieren a un dominio de la zona test. enva al servidor recursivo la referen-
cia del servidor autoritativo de esa zona en una paquete de respuesta. Dicho paquete
puede contener firmas que el servidor recursivo verifica como primer paso para evaluar
toda la cadena de confianza. El servidor raz fue instalado en la computadora con IP
200.34.22.57 y en su configuraci
on se le indic
o que todas las peticiones por registros de
la zona test. fueran redirigidas al servidor Proxy y no al servidor autoritativo.

Servidor Autoritativo: Ese servidor administra los dominios bajo la zona test. y
al contar este con DNSSEC habilitado, puede devolver cada registro contenido acom-
panado de una firma que permita evaluar la cadena de confianza hasta esa zona. El
servidor autoritativo fue instalado en la m aquina con IP 200.34.22.59 y puerto 5353,
en la misma m aquina se ejecut
o el proceso del servidor Proxy con el puerto 53 y se le
asign
o el servidor autoritativo para poder construir el objeto resolver requerido para
poder enviar y recibir paquetes de DNS.

En la figura 4.6 puede observarse mejor la arquitectura desarrollada para este tipo de
proceso, donde lo que se buscaba era obtener una respuesta del servidor recursivo (paso
6), donde el bit de AD de la cabecera del paquete estuviera encendido confirmando que se
valid
o la cadena de confianza hasta la zona test., validando al mismo tiempo la funcionali-
dad del Proxy de modificar registros y firmarlos con la firma del servidor autoritativo.

En la figura 4.7 puede observarse un paquete de respuesta devuelto por el servidor

recursivo al cliente. Dicho paquete corresponde a la respuesta a la peticion por registros
que correspondan al nombre de dominio b.test.. Aqu es importante remarcar que la zona
test. utilizada en el servidor de la m aquina 200.34.22.59 es la misma que la utilizada para la
maquina 200.34.22.15 por lo que el registro b.test. no existe dentro de ella. Originalmente el
servidor autoritativo habra regresado dos registros NSEC, uno que indicara que el primer do-
minio existente en la zona es el dominio a.test. y otro que indicara que el dominio b.test.
se encontrara en caso de existir entre el dominio a.test. y el dominio c.test., pero al tener
al servidor raz haciendo referencia al Proxy, se asegura que todas las peticiones por dominios
de la zona test. pasen por el. Como se observa en la figura 4.7, los valores de sucesor y
predecesor fueron modificados por los obtenidos mediante el procedimiento descrito con ante-
rioridad, dichos valores son iguales a los obtenidos con el proceso iterativo (ver apendice E).
Tambien puede observarse que en la cabecera del paquete, aparecen como encendidos los bits
de RA y AD, donde el bit RA nos indica que el proceso utilizado para obtener la respuesta
fue un proceso recursivo, y el bit AD indica que pudo validarse la cadena de confianza hasta
la zona test., es decir, se verificaron las firmas generadas por el Proxy y el rango de dominios
generado por el mismo para el registro NSEC se acept o como correcto, lo que confirma la
prueba de funcionalidad basica como exitosa.

66
 Figura 4.6: Arquitectura de Proceso Recursivo

El apendice F muestra los archivos de configuraci on utilizados para el servidor recursi-

vo. Dichos archivos cumplen la funcion de indicarle al servidor recursivo donde se localiza el
servidor raz que tiene conocimiento de los dominios que se ubican debajo de el, en este caso
el dominio test. cumple esa condici on. Tambien se realiz
o una prueba referente al proceso
de delegacion en DNS, dicho proceso consiste en que el servidor autoritativo delega la respon-
sabilidad de la administracion de un dominio de su zona a otro servidor de nombres, para ello
en el archivo de zona para la zona test. se agreg o un nuevo registro de tipo NS que asigna la
administracion del dominio fabuloso.test. al servidor con IP 200.34.22.54 y nombre de do-
minio ns.fabuloso.test.. Esto u ltimo se realiza editando el archivo named.conf agregando
estos nuevos registros:

fabuloso IN NS ns.fabuloso.net
ns.fabuloso.test. IN A 200.34.22.54

Con lo anterior se indica al servidor autoritativo de la zona test. que para preguntas
relacionas al dominio fabuloso.test. pregunte directamente al servidor 200.34.22.54 y sea
este u
ltimo el que enve la respuesta. En este caso no existe una modificaci
on de los registros
NSEC que contenga el servidor delegado para ese subdominio ya que el mensaje de respuesta
es enviado por el servidor .54 directamente al servidor recursivo sin pasar por el servidor au-
toritativo test. y por consiguiente por el Proxy nunca recibe dicho paquete. Esto se observa

67
 Figura 4.7: Paquete de Respuesta del Servidor Recursivo

mas a detalle en la figura 4.8, donde el servidor autoritativo de la zona fabuloso.test. se

encarga de responder directamente al servidor recursivo. Esta u ltima prueba tena por ob-
jetivo observar el comportamiento del Proxy en una arquitectura similar a la que existe en
muchos niveles del arbol de dominios en Internet donde las delegaciones son algo com un ya
que la cantidad de dominios es muy grande como para que un s olo servidor administre todos.

4.8.3. Problema con Funciones Absolutas

Durante la primera fase de pruebas en el ambiente recursivo, se implementaron las fun-
ciones absolutas mencionadas en el marco teorico, ya que proporcionan un rango de dominios
mas reducido que el que se obtiene con el metodo alterno descrito en la metodologa. El
metodo absoluto fue probado haciendo preguntas al servidor recursivo, esperando recibir un
paquete con el bit AD encendido, pero en todos los casos que dicho metodo se utilizo, el
paquete de respuesta del servidor recursivo tena el estado de SERVFAIL, lo que indicaba que
una de las evaluaciones de la cadena de confianza, ya sea la verificacion de la firma o la veri-

68
 Figura 4.8: Arquitectura para Delegaci
on de Zona

ficacion del rango provisto en el registro NSEC modificado haba fallado.

Para encontrar la falla, se decidio investigar la bit

acora del servidor recursivo para revi-
sar si la verificacion del proceso de firmado fue exitosa y posteriormente verificar si la prueba
de no existencia para el registro NSEC tambien lo fue.

Se probo entonces el enviar una pregunta por el dominio b.test. al servidor recursivo
para verificar entonces el archivo de bit
acora dnssec.log que contena la informaci on de la
evaluacion de la cadena de confianza. Las lneas que nos indican que la verficaci
on de la firma
fue exitosa son las siguientes:

azzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test NSEC:
starting

azzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test NSEC:
attempting positive response validation

azzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test NSEC:
keyset with trust 7

azzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test NSEC:
verify rdataset: success

69
 azzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test NSEC:
marking as secure

Con lo anterior se asumi

o que el problema radicaba en el rango de de dominios provisto
por el registro NSEC y no en la firma contenida en el registro RRSIG que acompa naba a
ese registro NSEC. El archivo de bit acora contena las siguientes lneas con respecto a esa
verificacion:
b.test A: in authvalidated

b.test A: looking for relevant nsec

b.test A: nsec proves name exist (empty)

b.test A: resuming nsecvalidate

b.test A: nonexistence proof not found

El mensaje de nonexistence proof not found confirma que para el rango provisto
desde el predecesor de b.test. hasta el dominio 0.b.test. que es el sucesor directo es in-
correcto, ya que el mismo registro NSEC esta probando la existencia en la zona del registro
test., y eso ocurre debido al valor obtenido como sucesor directo, que aunque es el valor
correcto de acuerdo a la reglas del RFC 4471 y al orden canonico, demuestra la existencia del
dominio al presentar un sucesor cuyas etiquetas m as significativas (b.test.) son identicas
a las del nombre solicitado. Por tal motivo se opto por el metodo alterno propuesto en ese
mismo RFC que implica hacer una modificaci on en la etiqueta que va despues del corte de
zona para que dichos valores ya no sean iguales y entonces el dominio pueda ser aceptado
como un sucesor valido por el servidor autoritativo.

Adem as de las pruebas en el ambiente recursivo, el metodo alterno fue probado en un

ambiente de producci on, donde ahora el Proxy serva a la zona test.mx.. A pesar de que en
la prueba con el ambiente recursivo, el metodo alterno funciono sin problemas, si existieron
inconvenientes en las pruebas en el ambiente de producci on para los casos en que el dominio
preguntado excediera el n umero de etiquetas que representaban el corte de zona m as uno,
por lo que se opto por modificar el metodo para la obtencion del predecesor, ahora el paso 4
del metodo absoluto se aplicara para todos los casos, no importando si el nombre de dominio
excede el corte de zona mas uno. Por ejemplo para el dominio www.b.test.mx. dentro de la
zona test.mx., los valores para el sucesor y predecesor validos por el servidor en producci on
son los siguientes:
Predecesor:
azzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test.

Sucesor:
b0.test.

70
 Figura 4.9: Paquete de Respuesta en Ambiente de Producci
on

El cambio efectuado incrementa en uno el n umero de dominios cubiertos por el rango

propuesto al servidor recursivo, pero garantiza su funcionalidad gracias a que las etiquetas
que van despues del nombre de zona en el sucesor y el predecesor no son las mismas a las del
dominio solicitado lo que asegura una prueba de no existencia exitosa (ver figura 4.9).

4.8.4. Ambiente de Pruebas - Rendimiento

Para la realizacion de las pruebas de rendimiento, se utilizo la aplicacion conocida como
dnsperf, dicha aplicacion permite obtener informaci on sobre el rendimiento de los servidores
de DNS. La aplicacion dnsperf permite al usuario obtener el valor de peticiones contin uas
por segundo que un servidor autoritativo puede atender al enviar un n umero determinado de
peticiones a dicho servidor y medir cuando tiempo tarda el servidor en responder a cada una de
ellas. El conjunto de peticiones a ser enviadas al servidor por dnsperf puede ser obtenido de un
archivo que contenga los nombres de dominio por los que se va a preguntar. Al finalizar el envo
de las peticiones, dnsperf presenta informaci on condensada sobre la cantidad de paquetes

71
respondidos exitosamente, la cantidad de paquetes perdidos, la cantidad de paquetes que
presentaban informaci on erronea, el porcentaje de paquetes respondidos con exito, el tiempo
que duro la prueba y el par ametro mas importante, la cantidad de peticiones por segundo
que de acuerdo al tiempo y al n umero de peticiones enviadas, el servidor autoritativo puede
atender. Esta aplicacion esta disponible en la siguiente direccion de Internet:

ftp://ftp.nominum.com/pub/nominum/dnsperf/1.0.0.1/dnsperf-1.0.0.1-1.tar.gz

Queries Sent: 21560 queries

Queries completed: 21560 queries
Queries lost: 0 queries

Avg request size: 49 bytes

Avg response size: 104 bytes

Percentage completed: 100.00 %

Percentage lost: 0.00 %
Started at: Thu May 3 04:37:16 2007
Finished at: Thu May 3 04:37:17 2007
Ran for: 1.289705 seconds

Queries per second: 16717.001175 qps

Cuadro 4.2: Informaci

on de BIND 9 provista por dnsperf

El cuadro 4.2 presenta el contenido de los resultados de aplicar dnsperf a un servidor

BIND 9 configurado para ser autoritativo. A pesar de que se obtuvo un valor relativamente
alto de velocidad (16717 peticiones por segundo) para contestar las 21560 peticiones que se
hicieron, se debe de tomar en cuenta que dicho factor tambien es afectado por las caractersti-
cas fsicas de la m
aquina donde BIND es ejecutado, por lo que la capacidad del procesador y
la cantidad de memoria disponible para atender peticiones tendr an que ver en los resultados
obtenidos. Para poder obtener resultados como los que se presentan en el cuadro 4.2, se debe
de crear un archivo que contenga un nombre de dominio por lnea y conocer la direccion
IP y el puerto del servidor autoritativo. Este comando nos permite obtener los resultados
mostrados en el cuadro 4.2:

dnsperf -s 200.34.22.59 -p 5353 -d dnstest.txt

La opcion -s se utiliza para indicar la IP o nombre de dominio del servidor autori-

tativo.
La opci
on -p se utiliza para indicar el puerto donde el servidor autoritativo esta es-
cuchando peticiones.

72
 La opcion -d se utiliza para indicar a dnsperf donde se encuentra el archivo de
texto que contiene los nombres de dominio para que pueda armar las peticiones a
enviar al servidor autoritativo.

Si al comando anterior se le agrega la opci on -D, se indica que se requieren paquetes

con DNSSEC, lo que disminuye la velocidad de ese servidor a 12196.481010 peticiones por
segundo. Lo que significa que la capacidad del servidor disminuyo en casi 4000 peticiones por
segundo al devolver registros con firmas digitales.

Tomando en cuenta lo anterior, se procedio primero a instalar la tarjeta de firmado en

la computadora utilizada en el ambiente de pruebas autoritativo para verificar en un primer
punto que la computadora detecta dicha tarjeta y la reconoce como uno de sus mecanismos
(engines) que implementan algoritmos de firmado utilizados dentro de la biblioteca OpenSSL,
que es la biblioteca estandar de codigo libre para todo lo que se refiere a criptografa.

Figura 4.10: Tarjeta de Firmado Digital Niagara 2100B

La tarjeta elegida para firmar, es la tarjeta Niagara 2100B, la cual de acuerdo al fabri-
cante, la compana Interface Masters, cuenta con la siguientes caractersticas:
Procesador: Broadcom BCM5821

Velocidades de Transferencia:

73
 4000 transacciones RSA de 1024 bits por segundo.
3000 transacciones Diffie-Hellman por segundo.
470 Mbps en operaciones de Ipsec (3DES, HMAC-SHA-1).
600 Mbps en operaciones de ARC4.

SSL (Secure Socket Layer ) v 3.0: Operaciones de llaves privadas y p

ublicas de RSA
con llaves de 512, 768, 1024, 1536 y 2048 bits.

TLS (Transport Layer Security ): Procesamiento de llaves privadas y p

ublicas de
RSA con llaves de 512, 768, 1024, 1024, 1536 y 2048 bits.

Criptografa compatible con IETF IPSec y FIPS: Encriptacion y desencriptaci

on
3DES CBC a velocidad maxima.

IETF IKE: Generaci on de llaves para el algoritmo Diffie-Hellman de 768, 1024, 1536
y 2048 bits de tama no para el intercambio IKE. Generaci on de numeros aleatorios para
la generacion de llaves privadas.

PCI bus: 64 bits, 66 MHz.

Conectores: 2 Conectores PCI de tipo estandar y un conector PCI de perfil bajo.

Dimensiones de conectores: Bus PCI de 64 bits universal, 2.5 x 6.5.

Software: FreeBSD 4.2, Linux, Windows 2000, VxWorks.

La pagina del fabricante proporciona m

as informaci
on al respecto de esta tarjeta. Esta
se localiza en la siguiente URL:

http://www.interfacemasters.com/productpages/2100B.html

La tarjeta (ver figura 4.9), se conecto a uno de los puertos PCI libres de la computa-
dora, y fue detectada de inmediato por el sistema operativo (FreeBSD 6.1) y tambien por
la versi
on de OpenSSL instalada en la m aquina, la versi
on 0.9.7. Esto pudo comprobarse al
ejecutar el comando openssl engine cuyo texto de salida menciona al engine cryptodev
como disponible para la realizacion de operaciones RSA y Diffie-Hellman. De hecho pudo
observarse la diferencia en velocidades de ejecuci
on de operaciones RSA de 1024 bits en dos
maquinas diferentes con la tarjeta instalada en una de ellas, esto ultimo se logro al ejecutar
el comando openssl speed rsa1024.

El cuadro 4.3 presenta los resultados encontrados para las velocidades en operaciones
RSA por segundo, ya sean de firma o verificacion. La computadora con IP 200.34.22.17 tena
instalada la tarjeta de firmado ya que fue utilizada para las pruebas del proceso iterativo.
Se observa una diferencia bastante grande entre la capacidad de dicha computadora con la

74
 IP Computadora Firma Verificaci
on Firmas/s Verificaciones/s
200.34.22.17 0.0001s 0.0000s 6990.1 57803.4
200.34.22.59 0.0042s 0.0002s 240.1 4511.8

Cuadro 4.3: Velocidades en Operaciones RSA de 1024 Bits

computadora con IP 200.34.22.59 que se utilizo para las pruebas del proceso recursivo, lo que
indica que la tarjeta ya estaba siendo considerada por OpenSSL en la m aquina .17 y con esto
se supuso que las aplicaciones que hicieran uso de algoritmos presentes en OpenSSL y que
fueran soportados por la tarjeta de firmado, optaran por utilizar dicha tarjeta en lugar de
hacer uso del procesador de la computadora.

Ejecutando ahora dnsperf en la computadora 200.34.22.17 para evaluar el desempe no

del proxy con un n umero variable de peticiones a firmar, pudo observarse mientras duraba la
prueba que el procesador de la computadora y no el de la tarjeta estaba siendo utilizado para
las operaciones de firma. Esto puede observarse en la figura 4.11, donde con el comando top
se monitorearon los procesos activos y la utilizaci
on del procesador, esta llega a ser de casi el
50 %, cuestion que no debera de ocurrir ya que en las pruebas con openssl speed, la tarjeta
si se hizo cargo de las operaciones RSA.

Con esta situacion, se opt

o por modificar el codigo del servidor Proxy para que indicarle
explcitamente el engine de cryptodev en sus operaciones de firmado con el algoritmo RSA,
para ello, el programa fue modificado utilizando funciones existentes dentro del codigo fuente
de la aplicacion openssl speed que sirven para indicarle al sistema, el engine que se desea
utilizar para las operaciones de OpenSSL. Dichas funciones requieren importar la cabecera
openssl/engine.h:

static ENGINE* try load engine(BIO *err, const char *engine, int debug)
Esta funcion es utilizada para cargar un engine en especfico, cuyo nombre se propor-
ciona en el espacio de bytes apuntado por engine.

ENGINE *setup engine(BIO *err, const char *engine, int debug)

Esta funcion es utilizada para configurar el engine que se desea utilizar y cuyo nombre
se localiza en el espacio apuntado por engine. Internamente esta funcion ejecuta la
funcion ENGINE set default() que asigna el engine deseado al algoritmo que se indica
como par ametro de esta funcion, as que durante toda la ejecuci
on del Proxy, el engine
de cryptodev sera utilizado para firmar.

Estas funciones deben ser ejecutadas previo al ciclo infinito que realiza el Proxy para es-
cuchar peticiones. Tambien la compilaci
on resulta afectada, ya que se deben de agregar ahora
las opciones -lssl y -lcrypto para hacer referencia a las librera de OpenSSL que no se
haban utilizado con anterioridad (ldns s
olo importa las que requiere para firmar). Tambien

75
 Figura 4.11: Utilizaci
on del CPU en Pruebas con dnsperf

es necesario hacer referencia con la opci on -I a la ubicacion de los archivos libcrypto.a y

libssl.a y as es posible lograr que el Proxy utilice la tarjeta en lugar de utilizar el proce-
sador en las operaciones de firmado. Esto puede apreciarse en la figura 4.12, que muestra la
utilizaci
on del servidor para una prueba con dnsperf sobre el Proxy con DNSSEC habilitado.
En esa figura puede observarse que el uso del CPU para la aplicacion dnsproxy sobrepasa
apenas el 3 %, adem as se indica que el estado del proceso es el estado crydev, lo que confirma
que la tarjeta esta siendo utilizada ya que se esta haciendo referencia al engine seleccionado.
En esta imagen tambien se observa un valor de inoperancia del procesador de la computadora
del 97.4 %, reafirmando que el procesador no esta interviniendo en dichas operaciones.

En la siguiente secci
on se presentan los resultados obtenidos y un an
alisis del compor-
tamiento del Proxy durante el proceso iterativo.

76
 Figura 4.12: Utilizaci
on del CPU en Pruebas con dnsperf y Tarjeta Niagara

4.9. An
alisis de Resultados
Previo a la ejecuci on de dnsperf se utilizo la informaci
on provista por el comando dig
para verificar cuando es el tiempo de espera agregado por el Proxy a lo que ya se tena que
esperar por una respuesta del servidor autoritativo. Las peticiones se efectuaron desde la
computadora con IP 200.34.22.16 hacia la computadora 200.34.22.17 que contiene al Proxy, y
desde la computadora .16 hacia la computadora con IP 200.34.22.15 que es la que contiene al
servidor autoritativo y en todos los casos se solicitaron peticiones firmadas (con DNSSEC).
Como se observa en el cuadro 4.4, el Proxy a nade uns 8 ms de retraso sin importar el numero
de etiquetas que el dominio contenga, ya que las etiquetas son eliminadas hasta que el do-
minio solicitad queda de un tama no que es igual al del corte de zona m as uno. Para el caso
de dominios que si existen en la zona, el tiempo de espera se reduce al mitad pues nada mas
hay que calcular un valor de sucesor ya que el predecesor no es modificado. En estas pruebas
no se utilizo la tarjeta de firmado por un problema descrito m as adelante.

77
 Dominio Servidor Proxy Servidor Autoritativo
a.test. 4 ms 0 ms
c.test. 4 ms 0 ms
www.c.test. 8 ms 0 ms
b.test. 8 ms 0 ms
www.b.test. 8 ms 0 ms
noexiste.test. 8 ms 0 ms
www.noexiste.test. 8 ms 0 ms
www.noexiste.noexiste.test. 8 ms 0 ms
algunsitionoexiste.test. 8 ms 0 ms
www.algunsitionoexiste.test. 8 ms 0 ms

Cuadro 4.4: Tiempos de Espera para Respuestas con DNSSEC

Para las pruebas de rendimiento en el ambiente iterativo se utilizaron los siguientes

dominios que fueron colocados en el archivo ledo por dnsperf. Este patron de dominios fue
repetido en el mismo archivo hasta lograr la cantidad de dominios deseada y al ser enviados
directamente a un servidor autoritativo, ninguno de ellos fue almacenado en la memoria
cache del servidor:

a.test. NSEC

b.test. A

c.test. NSEC

d.test. MX

e.test. MX

f.test. MX

g.test. MX

h.test. MX

azzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test. A

babbbbbzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test. A

nszzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test. A

babbbbbzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzztzzzzzzzzzzzz.test. A

nszzzzzzzzzzzzz44zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test. A

nstzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test. A

78
 Se repitieron estos dominios en el archivo de prueba hasta tener 1000, 2000, 4000 y 6000
lneas de nombres de dominio para hacerle preguntas al servidor Proxy. Dichas pruebas se
efectuaron utilizando la tarjeta y sin ella a manera de comprobar la efectividad de utilizar el
Proxy en conjunto con la tarjeta, puesto que ya se haba verificado con la ayuda del comando
top que el procesador no era utilizado mientras se realizaban las firmas.

N
umero de Peticiones
Uso de Tarjeta 1000 2000 4000 6000
Si 77.831424 77.850649 77.796348 77.816101
No 142.464267 142.461659 142.483455 142.359447

Cuadro 4.5: Velocidad en Peticiones x Segundo del Servidor Proxy

Figura 4.13: Comparativo de Rendimientos en el Servidor Proxy

Numero de Peticiones
Uso de Tarjeta 1000 2000 4000 6000
Si 1.66 % 1.83 % 2.50 % 3.08 %
No 36.85 % 46.91 % 65.09 % 79.23 %

Cuadro 4.6: Utilizaci

on del Procesador en Pruebas con dnsperf

El cuadro 4.5 presenta los resultados de las pruebas de rendimiento realizadas con
dnsperf. En dicho cuadro se observa que con el uso de la tarjeta el servidor Proxy bajo su

79
rendimiento casi a la mitad, a pesar que con el comando top se poda visualizar que la uti-
lizacion del servidor apenas y sobrepasaba el 3 %. Esto hizo deducir que la tarjeta no estaba
funcionando de la manera adecuada ya que a pesar de haber seleccionado bien el engine,
la velocidad de atencion de paquetes disminuyo a la mitad (ver figura 4.13). De acuerdo
al cuadro 4.6, las utilizaciones en el procesador se mantuvieron bajas cuando se efectu o la
prueba en el ambiente iterativo utilizando la tarjeta de firmado. Las causas de este fen omeno
pueden ser diversas, por ejemplo puede deberse a la versi on de los drivers de la tarjeta o que
el bus de datos interno no este transmitiendo la informaci on con rapidez entre el procesador
de la tarjeta y el de la m
aquina. Esto u ltimo se confirm
o al realizar una prueba simple donde
la funcion de firmando RSA sign() se repitiera un n umero de veces igual al del n umero de
peticiones utilizado en las pruebas, y que con el comando time se pudo obtener el tiempo
total que tom o en ejecutar la funcion ese numero de veces. En dicho programa tambien se
ejecutaron las funciones para que el engine cryptodev sea utilizado en lugar del procesador
para las operaciones de firmado, y a un as se obtuvo un valor bajo, 138.69 firmas por segundo
(con el procesador de la computadora resultaron ser 250 firmas por segundo), muy diferente a
lo expresado por el comando openssl speed, lo que confirm o las suposiciones de que el error
se originaba en la tarjeta y no en el software que la utiliza.

Para los resultados presentados en el cuadro 4.5, se utiliz

ounicamente por falta de tiem-
po la heurstica provista por el comando top para conocer la utilizacion de los procesos activos
en la computadora. Un an alisis m
as completo de lo que ocurren el nucleo del procesador para
determinar el porcentaje real de la utilizaci on del Proxy con y sin tarjeta puede ser requerido
en dado caso que se deseen establecer lmites a la utilizaci on deba de tener el Proxy al uti-
lizar la tarjeta o para conocer la utilizaci
on real del mismo separando de ese porcentaje lo que
corresponde a la interacci on del proceso con el sistema operativo de la maquina que lo ejecuta.

A un as el Proxy tiene un rendimiento aceptable para pruebas con peticiones donde no

se solicitan firmas, pudiendo resolver hasta 3538.324179 peticiones por segundo, superando el
n
umero de peticiones por segundo promedio que los servidores de NIC Mexico reciben (2000
peticiones por segundo). El problema del rendimiento con la tarjeta de firmado queda como
una opci on a resolver para una siguiente investigacion. Se aborda m
as este tema en el captulo
5 que se refiere al aprendizaje adquirido y a las recomendaciones para futuras investigaciones.

80
Captulo 5

Recomendaciones e Investigaciones Futuras

El desarrollo del servidor Proxy ayudo a comprender las principales funciones que reali-
zan los servidores de DNS cuando habilitan DNSSEC. Durante la realizacion de este servidor
Proxy se descubrieron anomalas con respecto a los tiempos de respuesta para paquetes que
requeran firmas y que utilizaban la tarjeta, as tambien se descubri
o que las funciones que
obtenan el mejor rango (el m as peque
no) de los sucesores y predecesores no permitan que
un servidor recursivo comprobara en su totalidad la cadena de confianza puesto que tomaba
dicho rango como incorrecto. Estas dos anomalas pueden servir de base para futuras inves-
tigaciones que mejoren el rendimiento del servidor Proxy.

La principal area de oportunidad observada se encuentra en la utilizacion de la tarje-

ta. Un an alisis del hardware y software para ubicar cu ales son los controladores adecuados
que pueden hacer que la tarjeta funcione al ritmo que el usuario desee no excediendo su
maxima capacidad. Se recomienda la inspecci on del codigo fuente de la librera de OpenSSL,
particularmente de los archivos fuente del programa openssl speed de donde se extrajeron
fragmentos de codigo que sirvieron para que el Proxy hiciera uso de la tarjeta de firmado pero
a
un as la tarjeta no respondio como lo informaba la salida del comando antes mencionado
para operaciones RSA de 1024 bits con el engine de cryptodev.

Este trabajo abord o el uso de sockets de UDP para comunicar procesos, pero las fun-
ciones utilizadas para dicho fin solo permitan comunicar un proceso a la vez, por lo que en
un ambiente congestionado el Proxy no sera capaz de responder a un n umero de ello, por
lo que se sugiere la utilizaci
on de tecnicas de programacion que permitan el procesamiento
simult
aneo de peticiones. Una de estas tecnicas son los threads, que constituyen segmentos
de los programas que pueden ser ejecutados de manera simult anea, por ello se sugiere la
exploraci
on de esta alternativa para observar si el rendimiento en paquetes contestados por
segundo puede incrementarse cuando se soportan m as peticiones. Tambien durante el tiem-
po de ejecucion pudo observarse un incremento en la cantidad de memoria utilizada por el
Proxy, a pesar de que se utilizaron funciones provistas por ldns para liberar de la memoria las
estructuras de datos correspondientes a dicho paquete de bibliotecas, un an alisis exhaustivo
de la memoria utilizada por el programa en tiempo de ejecuci on puede revelar la causa y
proporcionar mejoras en el rendimiento total del programa.

81
 Justo antes de la finalizacion de esta investigacion, el servidor Proxy fue colocado en
un ambiente de producci on donde usuarios de este ambiente, externaran sus opiniones sobre
el funcionamiento del servidor. Sus opiniones seran de vital importancia para detectar otras
areas de oportunidad que puedan mejorar el desempe no del servidor Proxy.

82
Captulo 6

Conclusiones

Como se expuso en el marco te orico, los problemas de seguridad del servicio de DNS son
un grave riesgo para las comunicaciones que tienen lugar en Internet, de ah surge la necesi-
dad por desarrollar un producto que este orientado a mitigar uno de los tantos problemas de
seguridad que el servicio actual y las extensiones de seguridad (DNSSEC) tienen que afrontar.

La solucion propuesta demostr o ser capaz de mitigar el problema de la enumeraci on de

zona al ocultar registros validos proporcionados por el servidor autoritativo en el registro
NSEC y al mismo tiempo firmar los registros que se generen de este tipo para pasar las eva-
luaciones de cadena de confianza hechas por servidores recursivos. Adem as los resultados de
las pruebas preliminares en ambiente de producci on fueron satisfactorios en materia de fun-
cionalidad, lo que demuestra que en este aspecto se cumplieron los objetivos en su totalidad.

En el
ambito del rendimiento, se pudo demostrar que con la ayuda de la tarjeta de firma-
do, el procesador de la computadora que contiene al Proxy queda practicamente libre de toda
carga que tenga que ver con la utilizaci
on de algoritmos de firmado (RSA en el caso particular
del Proxy) para generar registros RRSIG correspondientes a los registros NSEC, liberando al
mismo tiempo al servidor autoritativo de efectuar dicho proceso que eventualmente consumira
sus recursos si las peticiones son constantes. Es evidente que una investigacion adicional es
necesaria para solucionar el problema del tiempo de respuesta de la tarjeta, pero qued o de-
mostrado que el problema radica en el controlador del hardware, no en el software que hace
uso de ella.

Esta tesis puede servir de base para la implementacion de sistemas que permitan habili-
tar DNSSEC en regiones donde el problema de enumeraci on de zona ha hecho imposible que
las extensiones de seguridad del servicio de DNS se implementen. El producto desarrollado
en esta investigacion formara parte de los proyectos de investigacion de NIC Mexico como
parte de las alternativas al registro NSEC3 que la empresa propone para poder implementar
DNSSEC y al mismo tiempo mitigar la enumeraci on de zona.

83
Bibliografa

[1] P. Albitz and C. Liu. DNS and BIND. OReilly, Sebastopol, USA, third edition edition,
1998.

[2] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. DNS Security Introduc-
tion and Requirements RFC 4033. tools.ietf.org/html/rfc4033, Network Working
Group, 2005.

[3] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Protocol Modifications

for the DNS Security Extensions RFC 4035. tools.ietf.org/html/rfc4035, Network
Working Group, 2005.

[4] R. Arends, R. Austein, M. Larson, D. Massey, and S. Rose. Resource Records for the
DNS Security Extensions RFC 4034. tools.ietf.org/html/rfc4034, Network Working
Group, 2005.

[5] J. Ramrez Carre

no. Impacto en el desempe
no de servidores recursivos que implementan
DNSSEC. Instituto Tecnologico y de Estudios Superiores de Monterrey, Monterrey,
Mexico, primera edici
on edition, 2007.

[6] D. Davidowicz and P. Vixie. Securing the domain name system.

0-proquest.umi.com.millenium.itesm.mx, Network Magazine, 2000.

[7] R. Farrow. Locking Up DNS Troubles. 0-proquest.umi.com.millenium.itesm.mx,

Network Magazine, 2000.

[8] C. Fetzer, G. Pfeifer, and T. Jim. Enhancing

DNS Security using the SSL Trust Infrastructure.
0-ieeexplore.ieee.org.millenium.itesm.mx/iel5/10372/32975/01544774.pdf,
IEEE, 2005.

[9] G. Lozano Ibarra. Detecci on de trafico an

omalo en servidores autoritativos del DNS me-
diante sistemas de reglas y clasificadores bayesianos. Instituto Tecnologico y de Estudios
Superiores de Monterrey, Monterrey, Mexico, primera edicion edition, 2006.

[10] G. Lozano Ibarra. DNSSEC Trial Mexico. docs.nicmxlabs.org.mx/dnssec/, NIC MX,

2006.

[11] B. Kaliski and J. Staddon. PKCS #1: RSA Cryptography Specifications Version 2.1.
www.rsa.com/rsalabs/node.asp?id=2125, RSA Laboratories, 2002.

84
[12] O. Kolkman and R. Gieben. DNSSEC Operational Practices RFC 4641.
tools.ietf.org/html/rfc4641, Network Working Group, 2006.

[13] B. Laurie, G. Sisson, R. Arends, and D. Blacka. DNSSEC Hashed Authenticated Denial of
Existence. www.ietf.org/internet-drafts/draft-ietf-dnsext-nsec3-10.txt, Net-
work Working Group, 2007.

[14] D. Lawrence. Obsoleting IQUERY RFC 3425. www.ietf.org/rfc/rfc3425.txt, Net-

work Working Group, 2002.

[15] P. Mockapetris. Domain Names - Implementation and Specification RFC 1035.

www.rfc-editor.org/rfc/rfc1035.txt, NetWork Working Group, 1987.

[16] M. Sanz. DNSSEC and the Zone Enumeration.

www.denic.de/media/pdf/dokumente/zone-enumeration.pdf, DENIC, 2004.

[17] G. Sisson and B. Laurie. Derivation of DNS Name Predecessor and Successor RFC 4471.
www.ietf.org/rfc/rfc4471.txt, Network Working Group, 2006.

[18] S. Weiler and J. Ihren. Minimally Covering NSEC Records and DNSSEC On-line Signing
RFC 4470. tools.ietf.org/html/draft-ietf-dnsext-dnssec-online-signing-01,
Network Working Group, 2006.

85
Ap
endice A

Archivo de Zona Utilizado en Servidor Autoritativo

A continuaci
on se presenta el archivo de zona asignado al servidor autoritativa, dicha
zona corresponde al dominio test.. Se presenta el contenido del archivo previo a la realizaci
on
del firmado de zona y posteriormente se presenta el archivo de la zona ya firmada.

A.1. Archivo de Zona sin Firmar zone.test

$TTL 86400
@ IN SOA ns.test. glozano.nic.mx. (
1 ;serial number
3600 ;refresh time
900 ;retry time
604800 ;expire time
1200 ) ;minimum time
NS ns.test.

ns.test. A 200.34.22.15

a A 192.168.1.1
c A 192.168.1.2
g NS g.com.
h A 192.168.1.4
o AAAA 2000::1
r NS r.com.
z TXT RR de la Z
test. IN DNSKEY 256 3 5 AQPbMtIGS6XTiAEky8eltx1Hk7cJxl+EMBcwX4q9Ho/
PmRJIb+RFpBfE YNq0WXrqSGndC980/YVZcd0zjJdeOWWzWCNpAbqaky0bbeMxdbMHX
lG/ puthKAnH3qDM3z8P3KrmrhjqYfN5rSdMyEgE1BiwDLo4P7zK4qbiyeCe bPGbQQ
==

86
A.2. Archivo de Zona Firmado zone.test.signed
test. 86400 IN SOA ns.test. glozano.nic.mx. (
1 ;serial number
3600 ;refresh time
900 ;retry time
604800 ;expire time
1200 ) ;minimum time
86400 RRSIG SOA 5 1 86400 20070209163058 (
20070110163058 32402 test.
Oz7ZO9Ejg/2NOOASfOxjRP73AYG8Rr6Y/TXk
dtQfBqZfc90WWSmorbRmL+Po1vFCFyZ5lBB4
P849gMyc6xzjJxwlZdVehGbhKtYefku5kTVX
iDtd6yeCZAvitZB42JiPwylOofStPEWSngD7
XAp19+w7ItU92iWI7XEd0fKFXXg= )
86400 NS ns.test.
86400 RRSIG NS 5 1 86400 20070209163058 (
20070110163058 32402 test.
iU+Glh8Mnjuytx9vCTyL2rql070NqA2udvkI
gmfhP/IvkCXqX1/KDS248WgT5NOsLb5/P0H+
MU9jNn+puE8S8t4r5T1mH8zELpAeORJP7iqt
2fYaT9++mER3WX6cq2DJFtFaFW0G1POF/T4h
K/gcM5L46e3ahQvg9hlTc0ybW6A= )
1200 NSEC a.test. NS SOA RRSIG NSEC DNSKEY
1200 RRSIG NSEC 5 1 1200 20070209163058 (
20070110163058 32402 test.
oIwSHxaJlDtlgxSyu7xHSiIEHgdoukwMVtud
DT1TxN0WBVAWzFpSxw5U1/a2mtUXMHo352cD
0DUqOZT9mLRVqJP+IgOF0XzSn24aWGcTQux2
AHhhm4trG4X5/K4r2UytE5cmKtIw0hwFtv01
ONljCGtvORqyrk6LAs7rJHxI26E= )
86400 DNSKEY 256 3 5 (
AQPbMtIGS6XTiAEky8eltx1Hk7cJxl+EMBcw
X4q9Ho/PmRJIb+RFpBfEYNq0WXrqSGndC980
/YVZcd0zjJdeOWWzWCNpAbqaky0bbeMxdbMH
XlG/puthKAnH3qDM3z8P3KrmrhjqYfN5rSdM
yEgE1BiwDLo4P7zK4qbiyeCebPGbQQ==
) ; key id = 32402
86400 RRSIG DNSKEY 5 1 86400 20070209163058 (
20070110163058 32402 test.
AYRh22dU2E62efdh879K9jwQB5fHcref3Q+0
mmOzjC9AgECjKXeUvcXtO0pVOnQya7y7KBlM
ttRO9HsMOAYlV5zbmxzhh2iauntAHOQ5LH8n

87
 Q5Q+onreh2A7wcDLw/CFGLVvgHZdlDaJE4lV
1VSzW1id2xa6STEwyKwbE2+vVXc= )
a.test. 86400 IN A 192.168.1.1
86400 RRSIG A 5 2 86400 20070209163058 (
20070110163058 32402 test.
mYwXj9Me0ri0vIW6BfgW/eo4Jk7l5YICd8ql
WRxr4jqT2B6CqcZtbLJqIzQ32qMiZX+DmTqp
fDhMqHxlJDj4ho2NY5DrdzBQpXNDtXEfdFoj
nToHkz2b5mxg3bYJepBIU2stHJh92vXmAeoy
dsnnKDSmhUmMCjkCVb1FcjwxtbA= )
1200 NSEC c.test. A RRSIG NSEC
1200 RRSIG NSEC 5 2 1200 20070209163058 (
20070110163058 32402 test.
tM5Ol+BcCCCkaH3P0intUoEove8XuyCI+8oe
6/89sdqyeR2tg6BB85XwlE/fbgJFiN1RZ9Mg
qH9k3/qHt450vyKigTEjQtDI9WRVHh+bHrI1
h6NW79d9+vQI14WS9boaCnZwa77tI+fzkv2m
n2J5DKvrHVJxAXLrljnHtfW05C8= )
c.test. 86400 IN A 192.168.1.2
86400 RRSIG A 5 2 86400 20070209163058 (
20070110163058 32402 test.
uuMKDRlZe6NpUt3pK+XRimtukqyiqlv5oiXz
Rm+1tKgnEKbRZL1VHG/zgY+uEr+ZexXoAvnX
0P1AvXV2zFkwy2KA8h2FcLu7YiXuJORYznW/
cZPt8Xyg6OqB9kFYRem3j2JzVcwCbwsPOnsH
gvZJ44ZtaoG4B8kJJK/jNzfRcLs= )
1200 NSEC g.test. A RRSIG NSEC
1200 RRSIG NSEC 5 2 1200 20070209163058 (
20070110163058 32402 test.
NELDohf5rKZmGcApVNyhqbSXt3TQtxe76Ch2
MtmZtl9t+2CBX1UzBvw2GokrtwMXLzUOytHN
iL6JW1bHm+DMOvzdCXi6gzZcxBWuzY0Z9s19
RT6hlDZXUrpco9vZYh2jZkG1RsfwLaQWO3H1
AG3r/d2o5JHorDjZyjnZTBIwchg= )
g.test. 86400 IN NS g.com.
1200 NSEC h.test. NS RRSIG NSEC
1200 RRSIG NSEC 5 2 1200 20070209163058 (
20070110163058 32402 test.
EiseuN3Py1xJfRahSPUp2VwUl45I4OMC/huK
F1uLgsUPhpyohTw2pEcbmYSym8IV0bjndcTO
QceLd/TeJ3Z7wRG7ReDAWVcBjrW8fGcQ3191
YGbuk46kW+2b6dUQSSZHXUWdiZOOQ7mvNJr7

88
 iZWynr3jIUXcgIzfP+slqlrb5Tw= )
h.test. 86400 IN A 192.168.1.4
86400 RRSIG A 5 2 86400 20070209163058 (
20070110163058 32402 test.
rYS1AqqYNwIKUtGLBVRHUorjY08Vl6lFHWsX
yS3/jP7UmlOSHxQSoutmjdiHp6uHHFrL6kDR
JSWRlA8tscnX11XmJclKRiQ1WWLR98yMAcZI
G32eObKLNpmeUXCalVWgG8IPHqTnGZe0jyiX
BWPUd7oAVwZUIUJnE74sI0iYop8= )
1200 NSEC ns.test. A RRSIG NSEC
1200 RRSIG NSEC 5 2 1200 20070209163058 (
20070110163058 32402 test.
tUaurSEZofmOqkdJHumij40wehLeeM4KIisj
oVDg5+jAq0p7SQ6xpyNsKyOENP36pexf5YWD
AgYDwFJb+sDQsYAt/c4YkfLhh/VDApIEjCYL
B5xsiYZ30B5amRrMRGGLFVRIklS2ggQvN0YE
CQKxEXd/SIUrfOaefySxaH1lhew= )
ns.test. 86400 IN A 200.34.22.15
86400 RRSIG A 5 2 86400 20070209163058 (
20070110163058 32402 test.
jumnCB68WENx5MFlTiNis7Taie8EQFNew+jw
5ZfwUK2WB1ywjV9nzGLqt51BzpdhIzwzkk3W
mvkKcr8HL7/NLIksRgxAwjZRG8AwyJU9phbR
R5JNDEt3M+ZYsjncvVo/4k4ixfNwvFAcgPaC
QUJLUpkdlfesBDg2BiwnlCR9pJ4= )
1200 NSEC o.test. A RRSIG NSEC
1200 RRSIG NSEC 5 2 1200 20070209163058 (
20070110163058 32402 test.
ZTiVq3Rk4xIz4L+RM8Fkns0it+fCnJhyCwwJ
HsEi0P95Ioy2OwLu6wcgdZOKrBMuIOZgshbi
S2WyRLIoVW2QOoazGZfkGEa+1laY0gEtrG+a
XQkNVggUvdwczkw4snEeZcYZHVNRFQCttImJ
1kdNMab1CE9RcXyKHn8XAG6gI/0= )
o.test. 86400 IN AAAA 2000::1
86400 RRSIG AAAA 5 2 86400 20070209163058 (
20070110163058 32402 test.
1uRWnapCW67xbfJ3513e8IL4/80ggTnm+Q7x
6/x8tYgyqvSG1c29udtoi0zlYBhRpByzX2P9
0VhediViXp3dJGsPxLPvqMk9cCVACmBq5xy1
xmuwYkHZq+DiiqC6KlMveQpLycjLyEtl/bM2
Mwb79PeWV8WE5YtzSHocG2RqTDk= )
1200 NSEC r.test. AAAA RRSIG NSEC

89
 1200 RRSIG NSEC 5 2 1200 20070209163058 (
20070110163058 32402 test.
TJPtfnqDKumaLnTCbfIlF6Pog5DCVWbAH0ty
gsJPyZRYR5JbGtwkghJGTyet9igkUTRcLfbd
pZ+h9Xj3EtJZEfjGRjU6kNPn6OlL0lfp11g9
6+06d/sspCxe/1eJlAYL+sEUhew9IEL4Ac0Y
G7KkyoeAPpdhzy9YwqLIYwWscqg= )
r.test. 86400 IN NS r.com.
1200 NSEC z.test. NS RRSIG NSEC
1200 RRSIG NSEC 5 2 1200 20070209163058 (
20070110163058 32402 test.
wQxVjljXCo4GAlELhuIZCxIT0NPZm3XXkQ80
BndOj3Yueqnn9JyPWTePvnYP/7U1VbyDLN1+
zcaCxW69+2E7hHk3t6L0130aM3h3S4lCidZH
j8YxE3VwV+o1eR739E8QkGbcDe64PmFY1vP9
PzpUuzi/iEitn5ew1Z3JqYp3K5s= )
z.test. 86400 IN TXT RR de la Z
86400 RRSIG TXT 5 2 86400 20070209163058 (
20070110163058 32402 test.
PhxiL62hhGTewQGFaZq5xYxjS5DFUhaupkVH
egPRxKaf+Ci7ILBBE1Pd5WSHSoAtCqrlCE3a
rpbivfIJfpOKK3eHpt3LGy8ZJRFXJ/yJrWhO
aC0lrl2hlDnCr9LaJSuhTW35ORd7N6t/90KF
2VPPIxdUnuczhl2gxU50G3/nbrQ= )
1200 NSEC test. TXT RRSIG NSEC
1200 RRSIG NSEC 5 2 1200 20070209163058 (
20070110163058 32402 test.
glMQdGo2Ean0hXvs8/VZblY8TSpL28QpLIOy
J9Bry50aqAi4xHldueEkEQZotMMwTqe0XDHd
SF2Pi5lbzzzF+Rgxza+qQx/VpAtk1Nz3Rejm
Wjgqxysos1ir+jmfbXil+kfW0ygg5pGuOprw
qg/mkXUmGSgoxGquFs2XQQLtlMg= )

90
Ap
endice B

Archivo de Configuraci
on de Servidor Autoritativo

Se presenta el archivo de configuracion named.conf que contiene la secuencia que con-

figura al servidor autoritativo para que utilice DNSSEC.

options {
;Se configura el servidor como autoritativo
recursion no;
;IP y puerto donde el servidor escucha peticiones
listen-on port 5353 { 200.34.22.15; };
;Directorio donde se ubica el archivo de zona
directory /dns/dnssec;
;Se habilita DNSSEC
dnssec-enable yes;
query-source address 200.34.22.15;
notify-source 200.34.22.15;
transfer-source 200.34.22.15;
};

key rndc-key {
algorithm hmac-md5;
secret LC3Pvq5a4YHcAjgr4gqbuA==;
};

logging {
channel logs { file /dns/dnssec/logs/xfers.log; };
category xfer-in {logs;};
category xfer-out {logs;};
};

controls {
inet 200.34.22.15 port 1951
allow { 200.34.22.15; } keys { rndc-key; };
};

zone test. {

91
 type master;
;Nombre del archivo de zona firmado
file zone.test.signed;
allow-transfer { any; };
};

92
Ap
endice C

Paquetes de Respuesta de DNS

Se presentan a continuaci on los valores de los bytes que componen a 2 paquetes de

respuesta de DNS capturados con la herramienta Ethereal. Ambos paquetes corresponden a
respuestas con estado NXDOMAIN cuyo campo de pregunta es el mismo, pero en el segundo
paquete responde a una solicitud explcita del cliente por una respuesta que contenga registros
RRSIG para que el pueda validar la informaci on contenida. En ambos casos se pregunto al
servidor por el registro b.test. no existente en la zona test..

C.1. Paquete de Respuesta sin DNSSEC

0000 00 12 3f f8 96 b4 00 13 72 4e 74 4a 08 00 45 00 ..?.....rNtJ..E.
0010 00 69 44 ea 00 00 40 11 78 70 c8 22 16 0f c8 22 .iD...@.xp....
0020 16 d6 14 e9 80 0c 00 55 f6 7b 54 a5 85 03 00 01 .......U.{T.....
0030 00 00 00 01 00 00 01 62 04 74 65 73 74 00 00 01 .......b.test...
0040 00 01 c0 0e 00 06 00 01 00 00 04 b0 00 29 02 6e .............).n
0050 73 c0 0e 07 67 6c 6f 7a 61 6e 6f 03 6e 69 63 02 s...glozano.nic.
0060 6d 78 00 00 00 00 01 00 00 0e 10 00 00 03 84 00 mx..............
0070 09 3a 80 00 00 04 b0 .:.....

C.2. Paquete de Respuesta con DNSSEC

0000 00 12 3f f8 96 b4 00 13 72 4e 74 4a 08 00 45 00 ..?.....rNtJ..E.
0010 02 99 44 eb 00 00 40 11 76 3f c8 22 16 0f c8 22 ..D...@.v?....
0020 16 d6 14 e9 80 0c 02 85 75 ff cc 72 85 03 00 01 ........u..r....
0030 00 00 00 06 00 01 01 62 04 74 65 73 74 00 00 01 .......b.test...
0040 00 01 c0 0e 00 06 00 01 00 00 04 b0 00 29 02 6e .............).n
0050 73 c0 0e 07 67 6c 6f 7a 61 6e 6f 03 6e 69 63 02 s...glozano.nic.
0060 6d 78 00 00 00 00 01 00 00 0e 10 00 00 03 84 00 mx..............
0070 09 3a 80 00 00 04 b0 c0 0e 00 2e 00 01 00 00 04 .:..............
0080 b0 00 98 00 06 05 01 00 01 51 80 45 cc a1 c2 45 .........Q.E...E
0090 a5 14 c2 7e 92 04 74 65 73 74 00 3b 3e d9 3b d1 ...~..test.;>.;.
00a0 23 83 fd 8d 38 e0 12 7c ec 63 44 fe f7 01 81 bc #...8..|.cD.....

93
00b0 46 be 98 fd 35 e4 76 d4 1f 06 a6 5f 73 dd 16 59 F...5.v.... s..Y
00c0 29 a8 ad b4 66 2f e3 e8 d6 f1 42 17 26 79 94 10 )...f/....B.&y..
00d0 78 3f ce 3d 80 cc 9c eb 1c e3 27 1c 25 65 d5 5e x?.=....... %e.^
00e0 84 66 e1 2a d6 1e 7e 4b b9 91 35 57 88 3b 5d eb .f.*..~K..5W.;].
00f0 27 82 64 0b e2 b5 90 78 d8 98 8f c3 29 4e a1 f4 .d....x....)N..
0100 ad 3c 45 92 9e 00 fb 5c 0a 75 f7 ec 3b 22 d5 3d .<E....\.u..;.=
0110 da 25 88 ed 71 1d d1 f2 85 5d 78 c0 6b 00 2f 00 . %..q....]x.k./.
0120 01 00 00 04 b0 00 11 01 61 04 74 65 73 74 00 00 ........a.test..
0130 07 22 00 00 00 00 03 80 c0 ff 00 2e 00 01 00 00 ...............
0140 04 b0 00 98 00 2f 05 01 00 00 04 b0 45 cc a1 c2 ...../......E...
0150 45 a5 14 c2 7e 92 04 74 65 73 74 00 a0 8c 12 1f E...~..test.....
0160 16 89 94 3b 65 83 14 b2 bb bc 47 4a 22 04 1e 07 ...;e.....GJ...
0170 68 ba 4c 0c 56 db 9d 0d 3d 53 c4 dd 16 05 50 16 h.L.V...=S....P.
0180 cc 5a 52 c7 0e 54 d7 f6 b6 9a d5 17 30 7a 37 e7 .ZR..T......0z7.
0190 67 03 d0 35 2a 39 94 fd 98 b4 55 a8 93 fe 22 03 g..5*9....U....
01a0 85 d1 7c d2 9f 6e 1a 58 67 13 42 ec 76 00 78 61 ..|..n.Xg.B.v.xa
01b0 9b 8b 6b 1b 85 f9 fc ae 2b d9 4c ad 13 97 26 2a ..k.....+.L...&*
01c0 d2 30 d2 1c 05 b6 fd 35 38 d9 63 08 6b 6f 39 1a .0.....58.c.ko9.
01d0 b2 ae 4e 8b 02 ce eb 24 7c 48 db a1 c0 fd 00 2f ..N....$|H...../
01e0 00 01 00 00 04 b0 00 10 01 63 04 74 65 73 74 00 .........c.test.
01f0 00 06 40 00 00 00 00 03 c0 fd 00 2e 00 01 00 00 ..@.............
0200 04 b0 00 98 00 2f 05 02 00 00 04 b0 45 cc a1 c2 ...../......E...
0210 45 a5 14 c2 7e 92 04 74 65 73 74 00 b4 ce 4e 97 E...~..test...N.
0220 e0 5c 08 20 a4 68 7d cf d2 29 ed 52 81 28 bd ef .\. .h}..).R.(..
0230 17 bb 20 88 fb ca 1e eb ff 3d b1 da b2 79 1d ad .. ......=...y..
0240 83 a0 41 f3 95 f0 94 4f df 6e 02 45 88 dd 51 67 ..A....O.n.E..Qg
0250 d3 20 a8 7f 64 df fa 87 b7 8e 74 bf 22 a2 81 31 . ..d.....t...1
0260 23 42 d0 c8 f5 64 55 1e 1f 9b 1e b2 35 87 a3 56 #B...dU.....5..V
0270 ef d7 7d fa f4 08 d7 85 92 f5 ba 1a 0a 76 70 6b ..}..........vpk
0280 be ed 23 e7 f3 92 fd a6 9f 62 79 0c ab eb 1d 52 ..#......by....R
0290 71 01 72 eb 96 39 c7 b5 f5 b4 e4 2f 00 00 29 10 q.r..9...../..).
02a0 00 00 00 80 00 00 00 .......

94
Ap
endice D

Librera LDNS

La librera LDNS contienen rutinas especficas para el procesamiento de paquetes de

DNS. Dichas libreras estan escritas en lenguaje C y dentro de las principales rutinas desta-
can las que permiten crear paquetes de pregunta recibiendo como argumento el nombre de
dominio solicitado, igualmente existen funciones que permiten ejecutar un proceso resolver
para enviar y recibir solicitudes de un servidor de DNS. Las libreras de LDNS tambien estan
dise
nadas para soportar DNSSEC, por lo se apoyan en las libreras de OpenSSL para las
funciones de firmado y verificacion de paquetes. Otras funciones utilizadas para este trabajo
incluyen las que permite modificar informaci on de los paquetes y realizar una inspecci
on de
los mismos para buscar registros especficos.

La documentaci
on esta disponible en lnea en la pagina del proyecto ldns:
http://www.nlnetlabs.nl/ldns/doc/globals.html
A continuaci
on se enuncian las rutinas utilizadas para este proyecto as como una breve
descripci
on de cada una de ellas:
ldns status ldns resolver new frm file(ldns resolver** r, const char* filename)
Configura un resolver utilizando un archivo de configuracion. El apuntador al nombre
del archivo puede ser nulo y en ese caso se utiliza el archivo /etc/resolv.conf.

void ldns resolver set port(ldns resolver* r, uint16 t p)

Asigna el puerto que el resolver debe de utilizar.

ldns status ldns key new frm fp(ldns key** k, FILE* fp)
Crea una nueva llave privada bas
andose en el contenido del archivo apuntado por fp.

ldns status ldns wire2pkt(ldns pkt** packet, const uint8 t* data, size t len)
Convierte la informaci
on en el arreglo de bytes de tipo uint8 t al formato de paquete
de DNS.

ldns status ldns resolver send pkt(ldns pkt** answer, const ldns resolver*
r, const ldns pkt* query pkt)
Enva el paquete dado al servidor de nombres indicado por el resolver.

ldns pkt rcode ldns pkt get rcode(const ldns pkt* p)

Devuelve el codigo de respuesta (RCODE) del paquete de DNS.

95
ldns rr list* ldns pkt question(const ldns pkt* p)
Devuelve la secci
on de pregunta del paquete de DNS.

size t ldns rr list rr count(const ldns rr list* rr list)

Regresa el n
umero de registros existentes en la estructura ldns rr list dada.

ldns rr* ldns rr list rr(const ldns rr list* rr list, size t nr)
Regresa un registro especfico contenido en una estructura ldns rr list dada.

ldns rdf* ldns rr owner(const ldns rr* rr)

Regresa el Owner Name de un registro de DNS.

void ldns dname2canonical(const ldns rdf* rdf )

Convierte un nombre de dominio a su forma canonica (en min
usculas).

char* ldns rdf2str(const ldns rdf* rdf )

Convierte la informaci
on contenida en la secci
on RDATA de un registro en una cadena
de caracteres.

ldns rr list* ldns pkt authority(const ldns pkt* p) Devuelve la secci

on autorita-
tiva de un paquete de DNS.

ldns rr type ldns rr get type(const ldns rr* rr)

Obtiene el valor de tipo para un registro de DNS.

void ldns resolver set dnssec(ldns resolver* r, bool b)

Configura el resolver para que utilice DNSSEC en sus paquetes de pregunta.

ldns pkt* ldns resolver query(const ldns resolver* r, const ldns rdf* name,
ldns rr type type, ldns rr class class, uint16 t flags)
Enva un paquete de pregunta a un servidor de nombres.

int ldns rr compare(const ldns rr* rr1, const ldns rr* rr2)
Compara el contenido de dos registros de DNS bas
andose en su orden canonico.

bool ldns rr list push rr list(ldns rr list* rr list, const ldns rr list* push list)
Concatena una lista de registros con otra.

void ldns pkt set section count(ldns pkt* p, ldns pkt section s, uint16 t x)
Modifica el n
umero de registros por secci
on ubicado en la cabecera del paquete de DNS
de acuerdo al valor de x.

void ldns pkt set authority(ldns pkt* p, ldns rr list* rr)

Modifica la secci
on autoritativa de un paquete de DNS sustituyendo los registros por
los contenidos en la lista de registros proporcionada.

int ldns dname compare(const ldns rdf* dname1, const ldns rdf* dname2)
Compara dos nombres de dominio de acuerdo a su orden canonico.

96
ldns rdf* ldns dname new frm str(const char* str)
Crea una estructura de tipo ldns rdf que representa un nombre de dominio a partir
de la cadena de caracteres proporcionada.

ldns rdf* ldns rr rdf(const ldns rr* rr, size t nr)

Devuelve el elemento de la secci
on RDATA referido por el n
umero nr.

ldns status ldns str2rdf dname(ldns rdf** rd, const char* str)
Convierte una cadena de caracteres a una estructura de tipo ldns rdf que representa
un nombre de dominio.

ldns rdf* ldns rr set rdf(ldns rr* rr, const ldns rdf* f, size t position)
Coloca una estructura de tipo ldns rdf en la secci
on de RDATA del registro apuntado
por rr.

void ldns rr set owner(ldns rr* rr, ldns rdf* owner)

Modifica el Owner Name de un registro de DNS con el contenido de la restructura de
tipo ldns rdf que se le asigna como par
ametro.

ldns key list* ldns key list new()

Crea una nueva lista encadenada que contiene llaves utilizadas para firma registros.

ldns rdf* ldns rr rrsig signame(const ldns rr* r)

Devuelve el nombre de la entidad que firma tal cual como aparece en el registro RRSIG
proporcionado como par ametro.

void ldns key set pubkey owner(ldns key* k, ldns rdf* r)

Asigna la identidad del due
no de la llave p
ublica a la llave referida.

void ldns key set inception(ldns key* k, uint32 t i)

Asigna la fecha de incepci
on para las firmas realizadas con la llave referida.

uint32 t ldns rdf2native int32(const ldns rdf* rd)

Devuelve la conversion a entero de 32 bits del dato contenido en la estructura de tipo
ldns rdf referencia.

void ldns key set expiration(ldns key* k, uint32 t i)

Asigna la fecha de expiracion para las firmas realizadas con la llave referida.

bool ldns key list push key(ldns key list* key list, ldns key* key)
Inserta una llave a una lista de llaves referenciada.

ldns rr list* ldns rr list new()

Crea una nueva lista que contendr
a registros de DNS.

bool ldns rr list push rr(ldns rr list* rr list, const ldns rr* rr)
Inserta un registro de datos en una lista de registros dada.

97
ldns rr list* ldns sign public(ldns rr list* rrset, ldns key list* keys)
Firma el contenido de la lista apuntada por rrset utilizando las llaves contenidas en la
lista keys.

ldns status ldns pkt2wire(uint8 t** dest, const ldns pkt* p, size t* size)
Convierte el paquete de DNS a su representaci
on en arreglo de caracteres (bytes).

void ldns pkt free(ldns pkt* packet)

Libera de memoria el contenido de la estructura ldns pkt free que hace referencia a
un paquete de DNS.

98
Ap
endice E

Registros NSEC Generados por el Servidor Proxy

A continuaci
on se presentan los registros NSEC generados por el servidor Proxy durante
las pruebas del proceso iterativo. El servidor Proxy se ejecuto en la computadora con IP
200.34.22.17 y el servidor autoritativo en la computadora 200.34.22.15. Las peticiones se
realizaron desde la computadora con IP 200.34.22.16 y estaba dirigidas al servidor Proxy. La
zona del servidor autorativo es la zona test. presentada en el apendice A.

Pregunta: dig @200.34.22.17 b.test +dnssec

test. 1200 IN NSEC 0.test. NS SOA RRSIG NSEC DNSKEY
azzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test.
1200 IN NSEC b0.test. A RRSIG NSEC

Pregunta: dig @200.34.22.17 www.b.test +dnssec

test. 1200 IN NSEC 0.test. NS SOA RRSIG NSEC DNSKEY
b.test. 1200 IN NSEC b0.test. A RRSIG NSEC

Pregunta: dig @200.34.22.17 noexiste.test +dnssec

test. 1200 IN NSEC 0.test. NS SOA RRSIG NSEC DNSKEY
noexistdzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test.
1200 IN NSEC noexiste0.test. A RRSIG NSEC

Pregunta: dig @200.34.22.17 www.noexiste.test +dnssec

test. 1200 IN NSEC 0.test. NS SOA RRSIG NSEC DNSKEY
noexiste.test. 1200 IN NSEC noexiste0.test. A RRSIG NSEC

Cuadro E.1: Registros NSEC generados por el servidor Proxy

99
 Pregunta: dig @200.34.22.17 a.test mx +dnssec
a.test. 1200 IN NSEC a0.test. A RRSIG NSEC

Pregunta: dig @200.34.22.17 noexiste.a.test +dnssec

test. 1200 IN NSEC 0.test. NS SOA RRSIG NSEC DNSKEY
a.test. 1200 IN NSEC a0.test. A RRSIG NSEC

Pregunta: dig @200.34.22.17 0.test +dnssec

test. 1200 IN NSEC 0.test. NS SOA RRSIG NSEC DNSKEY
\)zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test.
1200 IN NSEC 00.test. NS SOA RRSIG NSEC DNSKEY

Pregunta: dig @200.34.22.17 9.test +dnssec

test. 1200 IN NSEC 0.test. NS SOA RRSIG NSEC DNSKEY
8zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz.test.
1200 IN NSEC 90.test. NS SOA RRSIG NSEC DNSKEY

Pregunta: dig @200.34.22.17 www.0.test +dnssec

test. 1200 IN NSEC 0.test. NS SOA RRSIG NSEC DNSKEY
0.test. 1200 IN NSEC 00.test. NS SOA RRSIG NSEC DNSKEY

Cuadro E.2: Registros NSEC generados por el servidor Proxy

100
Ap
endice F

Archivos de Configuraci
on para Servidor Recursivo

El siguiente apendice presenta el contenido del archivo named.conf utilizado para confi-
gurar el servidor recursivo para el proceso del mismo nombre y tambien se presenta el archivo
root.hint para indicarle a dicho servidor donde se localiza el servidor raz.

F.1. Archivo named.conf

options {
;IP donde el servidor escucha peticiones
listen-on { 200.34.22.56; };
;Directorio donde se ubica el archivo de zona
directory /named/zones;
;Se habilita DNSSEC
dnssec-enable yes;
;Se configura el servidor como recursivo
recursion yes;
};

logging {
channel dnssec log {
file dnssec.log size 20m;
;Se habilita la impresi
on de bit
acoras
print-time yes;
print-category yes;
print-severity yes;
severity debug 3;
};
category dnssec{dnssec log;};
};

trusted-keys {
. 257 3 5 AwEAAejnLLnjMVntHQbB23SMnN+2uoO8DpaKIZGKbzOxbYHniIx1Q1YF
wstprpcGTCkceah1MduEXUoXfd9ySPZt6h9fQiPcEQaRekTwQhZW+U88HJ20H4tp6v/Cj

101
4vguky/enADwSVeWpFepfl0hmbnhEMM5vgP/2YFHPYS+lfTUxCqP2GxDg+Y2Y6XMFYtKE
nGIRGAd4juGt9LKnn5jw5aelvRy0FfN8VR9SyU1fN775nWSzEYfsnvFRIN2Oj3Wcy9rDP
IF7nF1Jt6ckoP3kxROkTRFYpYCvWCgXcDgZe+fgm7ppSYG/3BFIP8126WZAlAicS+rwwK
jAKcnTJa1KDH8FU=; };

zone . {
type hint;
;El archivo root.hint contiene informaci
on sobre la ra
z
file root.hint;
};

F.2. Archivo root.hint

. 3600000 IN NS A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET. 3600000 A 200.34.22.57

102
Ap
endice G

Archivos de Configuraci
on para Servidor Raz

A continuacion se presentan los archivos utilizados para configurar el servidor raz uti-
lizado para las pruebas en el proceso recursivo El servidor raz se ubica en la computadora
con IP 200.34.22.57.

G.1. Archivo named.conf

options {
;IP donde el servidor ra
z escucha peticiones
listen-on { 200.34.22.57; };
;Directorio donde se ubica el archivo de zona
directory /named/zones;
;Se habilita DNSSEC
dnssec-enable yes;
;Se configura el servidor como autoritativo
recursion no;
additional-from-auth no;
additional-from-cache no;
};

zone . {
type master;
;Nombre del archivo de zona firmado
file root.zone.signed;
};

G.2. Archivo root.zone.signed

ns.test. 3600 IN A 200.34.22.59
. 3600 IN SOA a.root-servers.net. glozano.nic.mx. (
20070328 ;serial number
3600 ;refresh time

103
 900 ;retry time
3600000 ;expire time
3600 ) ;minimum time
3600 RRSIG SOA 5 0 3600 20071231235900 (
20070430151246 9975 .
QigafjQxFTzCMU4RXlu+Dg4dtXKcUZ0JpI2W
HXVAXvvwsyQEK0DvMJOgC5B5KayhPwiJJOpz
Kuv/bWNinFHy1DxKBUlZqMU8A4CqHWyGMWS/
z2Cu6BpKf0w9laSZHddWNVw9e+eqb8ErqVlP
fJ0exEV1qyuX69wzlgrovZgNTYA= )
3600 NS a.root-servers.net.
3600 RRSIG NS 5 0 3600 20071231235900 (
20070430151246 9975 .
OsAOrywM4VP2ChqTTo9rxxClmx/s1wirsAPz
HrkibqhhrBZautZB+XinMMgmKqgOEY6Utb1w
QqDVL2c+igGvvoF547xanJKsEbJFwHpQs3WS
l57b4QE7iqZSvD0wjCf1rPmRnVGKUNrWMvZ9
OuXWcfpbl8FyROQNABH6OJheoCU= )
3600 NSEC a.root-servers.net. NS SOA RRSIG NSEC DNSKEY
3600 RRSIG NSEC 5 0 3600 20071231235900 (
20070430151246 9975 .
Y7pAuDzIowoCYjL59JPP05do0crUQV3vIeQ3
cxP1tTFMDVkvgOANS75VYR+KB0sCiP4Ar2ie
blZp79kFlaSomne0BE0ajxWx/vWwmbwWJvog
2FbRn8/XoryTw26glGyE1bPj2Gx/yTWEGUMy
aB5Bspr/Zwi/BeJtp/EEny2/7Zg= )
3600 DNSKEY 256 3 5 (
AwEAAcSl6ysz9BgCOFutCagjt7ntAICWSour
Ml5gfDJ3ZdTY13AWqL7cm3UZqfabCRLYHqDL
bcWM/qWXIRjgLtwOLMnBcTVdf0Wr8bF45LHe
j24HINEDaYhSogl9JqBflbJK1ILUVC9M5u8o
aMZRwqTZlcFLR055/YzolImvd/jzlwDT
) ; key id = 9975
3600 DNSKEY 256 3 5 (
AwEAAejnLLnjMVntHQbB23SMnN+2uoO8DpaK
IZGKbzOxbYHniIx1Q1YFwstprpcGTCkceah1
MduEXUoXfd9ySPZt6h9fQiPcEQaRekTwQhZW
+U88HJ20H4tp6v/Cj4vguky/enADwSVeWpFe
pfl0hmbnhEMM5vgP/2YFHPYS+lfTUxCqP2Gx
Dg+Y2Y6XMFYtKEnGIRGAd4juGt9LKnn5jw5a
elvRy0FfN8VR9SyU1fN775nWSzEYfsnvFRIN
2Oj3Wcy9rDPIF7nF1Jt6ckoP3kxROkTRFYpY

104
 CvWCgXcDgZe+fgm7ppSYG/3BFIP8126WZAlA
icS+rwwKjAKcnTJa1KDH8FU=
) ; key id = 14983
3600 RRSIG DNSKEY 5 0 3600 20071231235900 (
20070430151246 9975 .
qHXd1EOFDyN+BTvE7nqOjNK9E0+8CHIxcIWX
pAjJnP+KBTd4uoeuTd2zaLo8ewPFUbagU7qd
fEbUxUlNxUEeKCCPs6KEjqm7sunQ9YD9qAUI
4smVprYG5xOxsMbtRWB+DDwYHJfQ/rozPehu
Ci0aBHxNtqjSQjeADiLxfJT7HeQ= )
3600 RRSIG DNSKEY 5 0 3600 20071231235900 (
20070430151246 14983 .
s6pKcjL1aGIhbfpKi9UybObmMDDIsLDn6Bst
nQh8je+1f4eS8t0fStqhFEJYCriANCs9ecC5
Ixg5vMad7Xqic3hgwB/lL0kwXA0uet04ctsK
ycW3989+taZ6EDBYp793yjx4SixOquDaHY8L
gmK8vViASIgUoTs5DcQfK0lbCkJWQzZ1yhxF
3OH70cVAt3Tz0CQ7Zc+4kh6pQuiqlfxxIHw8
fAWYhbzZf4cENWlglsNDS7aB/IydDndBrxY+
niZfOV69ViTw9PnHmJb+gQnhiOGg+ZPIjecy
jpxr5ES32iLpy9zeQA== )
a.root-servers.net. 3600 IN A 200.34.22.57
3600 RRSIG A 5 3 3600 20071231235900 (
20070430151246 9975 .
WzNCNGbdClGiBtASCO9VdzF3brcdPNvEyhbs
eUggYAt4aTL+DQQQGz2tiI4CzbYdFnhqc9Aq
YCXuAkzFhmbalApnynRGnEp8RcBwNC/aA7k3
6IxNDdO+jMF1dfUbVvukQe9gAB85P8yJS3E0
5/3JlX5QDBpJ7NNFeulhpN/L1Kg= )
3600 NSEC test. A RRSIG NSEC
3600 RRSIG NSEC 5 3 3600 20071231235900 (
20070430151246 9975 .
AfwXwgt+hCSqu31Cc8Ra5uyhWmBrOEuFCbAB
UAfvPBUokV42T6DE0WvyAE0HpWVE8/lEwjDD
Wko2L4be4uGeTOvGmyU6CVDN0p5FO+t/cwjn
loP7tyL8YjILrr5gopHTReeZYvsMGDxF/VED
GuGxXiZSEw1z76olBGbIjwST6uE= )
test. 3600 IN NS ns.test.
3600 DS 6544 5 1 (
2F0F8BA97621EDCFEB5EFC7377DD72C15DA7
2692 )
3600 RRSIG DS 5 1 3600 20071231235900 (

105
 20070430151246 9975 .
oDf571nxhpfjM4besf5YLe3/b+UgsLf81j49
Q3mmWKYHzgdKhQpedA1a/eeW5RTFFVyNW4kH
J1eUaKM6d3jTdcerR3Whv/qmQvddqjAPLmb5
daeJTIyHxSTJugjfHHTe0sRybIlI6AEyj2Ko
IZbixG9Zw8i4TPb8RiE1hPK6Flc= )
3600 NSEC . NS DS RRSIG NSEC
3600 RRSIG NSEC 5 1 3600 20071231235900 (
20070430151246 9975 .
M70ybZTNm0668EzDfmk1S1M9IJF1I4L7IBJ3
WgvDw5rOP6muBPfuyeW9g6e5Rjs7DiTQS/r+
b9G6syJpED6uB1rxKwxO9dVVosgLm8dsdfla
kEV8Kl/CqU6nxiESSwofK/C5oNchjQ/1jGd/
irbtXAgjp4yprlCxjnbti0prk2A= )

106