DocsTec-7197

Vista previa del material en texto

INSTITUTO TECNOLÓGICO Y DE ESTUDIOS
SUPERIORES DE MONTERREY
CAMPUS MONTERREY
PROGRAMA DE GRADUADOS EN COMPUTACIÓN, INFORMACIÓN Y
COMUNICACIONES
TESIS PARA LA MAESTRÍA EN CIENCIAS EN
INGENIERÍA ELECTRÓNICA CON ESPECIALIDAD
EN TELECOMUNICACIONES
Desempeño de una Arquitectura de Doble Anillo P2P de Alta Disponibilidad para
DNS
por
Carolina Del Valle Soto
Monterrey, N. L., Mayo de 2009
Instituto Tecnológico y de Estudios Superiores de
Monterrey
Campus Monterrey
Programa de Graduados en Electrónica, Computación,
Información y Comunicaciones
Los miembros del comité de tesis recomendamos que la presente propuesta de Carolina Del
Valle Soto sea aceptada para desarrollar el proyecto de tesis que es requisito parcial para obtener
el grado de Maestría en Ciencias en Ingeniería Electrónica con especialidad en Teleco-
municaciones.
Comité de Tesis
Dr. Joaquín Acevedo Mascarúa
Director de Investigación y Posgrado de la Escuela de Ingeniería
Mayo de 2009
Agradezco a Dios y la Virgen que siempre son mis guias en el camino de la vida.
A mis padres, Gustavo y Lucina, y a mi hermano David porque sin ellos no
hubiera sido posible mi estancia en México y les ofrezco todo este esfuerzo
y dedicación que tuve durante estos dos años. Y a mi país, COLOMBIA,
porque es la base de mi formación y mis valores.
AGRADECIMIENTOS
Agradecimientos al Doctor Jorge Carlos Mex Perera por su gran conocimiento y sus valiosos
aportes a lo largo de este proyecto de Tesis. Al MsC Iván Salvador Razo Zapata por su incondicional
apoyo y grandes aportes.
Agredecimientos a CONACYT, a la Cátedra de Biométricas y Protocolos Seguros para Internet,
a NIC México y a Google.
Carolina Del Valle Soto
ÍNDICE GENERAL
1.. Introducción 4
1.1. Definición del Problema 8
1.2. Objetivos 10
1.2.1. Objetivos Específicos 10
1.3. Hipótesis 10
1.4. Motivación 11
2.. Antecedentes 12
2.1. Modelo de la Popularidad de Consultas DNS 12
2.2. DNS 14
2.2.1. Delegación 17
2.2.2. Ataques al DNS 18
2.3. El caché 22
2.4. Protocolos de coherencia del caché 24
2.5. Sistemas de Información Autoconfigurables 24
2.5.1. Topologías de Red 25
2.5.2. Protocolos 27
2.5.3. Proceso P2P 30
3.. Propuesta 35
3.1. Esquemas Relacionados 35
3.2. Esquema Propuesto 39
3.2.1. Arquitectura 41
3.2.2. Arquitectura del Anillo de Clientes 41
3.2.3. Arquitectura del Anillo de Servidores 43
4.. Simulaciones y Resultados 46
4.1. Metodología 47
4.2. Consideraciones Preliminares 48
4.3. Construcción de la Arquitectura e DNS 48
4.4. Confiabilidad 60
5.. Conclusiones 61
5.1. Trabajo Futuro 62
ÍNDICE DE FIGURAS
1.1. Estructura del árbol DNS 5
1.2. Peticiones en DNS 6
1.3. Esquema general de una red P2P 7
2.1. Comportamiento de los datos según la Ley de Potencia 14
2.2. Comportamiento de los datos según la Ley de Potencia con escala logarítmica . . . . 15
2.3. Línea de tendencia a la línea de datos 16
2.4. Estructuras de topologías de red 28
2.5. Ejemplo del comportamiento del protocolo Pastry 30
2.6. Esquemas P2P híbrido y mixto 34
3.1. Esquema Beehive [12] 37
3.2. Esquema de replicación CoDoNS [13] 38
3.3. Esquema de petición-respuesta CoDoNS [13] 39
3.4. Esquema Codificación de Red (Echelon) [23] 40
3.5. Esquema general de la estructura de doble anillo 43
4.1. Porcentaje de nodos coalicionados contra porcentaje de peticiones perdidas 52
4.2. Porcentaje de nodos coalicionados contra número promedio de saltos 53
4.3. Saltos según niveles de replicación 57
4.4. Saltos promedio con distribución con Ley de Potencias 58
4.5. Saltos promedio con recursos con igual popularidad 59
ÍNDICE DE TABLAS
2.1. Tipos de ataques 19
2.2. Ventajas y desventajas de las redes P2P 26
2.3. Arquitecturas P2P 32
3.1. Cuatro primeras filas de la Tabla de enrutamiento de un nodo con ID: 1234 42
3.2. Esquemas 44
3.3. Ventajas y desventajas en los esquemas 45
4.1. Tablas de caché compartido y caché no compartido 55
4.2. Saltos por frecuencia y nivel de replicación 56
4.3. Número de saltos promedio según el nivel de replicación 56
4.4. Relación costo/beneficio del empleo del caché 60
RESUMEN
La presente tesis muestra una arquitectura de doble anillo, que pretende ser más útil que
un esquema de anillo simple, puesto que el hecho de tener una red más sirve como emergencia
y da mayor estabilidad al sistema. Además se analiza el desempeño de la red con base en un
caché compartido entre los nodos del sistema con lo que se logra mayor rapidez en la satisfacción
de peticiones.
La arquitectura consiste en dos anillos, uno de clientes y otro de servidores, la cual combina
las características y ventajas de un sistema P2P, en el cual no hay clientes y servidores fijos,
sino una serie de nodos que se comportan a la vez como clientes y como servidores de los demás
nodos de la red. Además de las características del DNS, en el cual se presenta un sistema cliente-
servidor, donde la aplicación servidora está distribuida. Esta arquitectura propuesta tiene como
fundamento poseer un segundo anillo más estable y organizado, que es el de servidores, que sirva
como respaldo al sistema y que evite ciclos innecesarios en la red. Se busca principalmente dar un
enfoque de disponibilidad de rutas en el sistema teniendo en cuenta parámetros de simulaciones
tales como: número de saltos promedio y cantidad de peticiones perdidas, los cuales van a ser
medidores del desempeño total del sistema propuesto. Se presentan además simulaciones basadas
en el caché compartido y no compartido por los nodos en el sistema, con lo cual se logra medir
de otra forma el desesmpeño y la robustez de la arquitectura gracias a niveles de replicaciones
prestablecidos en los cuales los nodos van a tener un caché repartido de forma aleatoria bajo ciertos
parámetros de replicación.
1. INTRODUCCIÓN
El desarrollo de este trabajo se enfoca en el estudio del DNS (Domain Name System) sobre
redes P2P (Peer-To-Peer). Se propone una estructura de doble anillo de redes P2P que provee las
ventajas de DNS. Esta arquitectura es llamada eDNS (emergency DNS). eDNS puede ser usada
como un mecanismo de emergencia en caso de pérdida de disponibilidad del DNS original. Además,
provee seguridad y robustez en la búsqueda de información en caso de ataques. El desempeño de la
arquitectura propuesta fue medido por medio del procentaje de peticiones perdidas y por el número
promedio de saltos en cada petición, considerando escenarios con un número determinado de nodos
comprometidos. Además, se trata también el tema del caché compartido entre los nodos de una
red, donde se dan escenarios de replicación organizada por niveles y peticiones DNS en las cuales
hay un porcentaje real de peticiones inexistentes que hacen más verídicas las simulaciones.
El sistema de nombres de dominio (DNS por sus siglas en inglés) proporciona un servicio es-
encial a los usuarios del Internet. El propósito principal del DNS es traducir nombres de dominio
a direcciones IP. Cuando un usuario quiere descargar un sitio web, es decir, una página de In-
ternet determinada, éste digita en su navegador el nombre de dominio que desea (por ejemplo
www.google.com), así el DNS obtendrá la respectiva dirección IP de dicho dominio. La estructura
DNS está basada en un modelo jerárquico de árbol invertido (ver figura 1.1), en el cual el origen
es llamado raíz. En el siguiente nivel se encuentran unos dominio llamados TLDs (Top Level Do-
mains). De esta forma los dominios se clasifican en gTLDs (generic TLDs tales como .com, .net,
.org, .edu, .gov, .mil) y ccTLDs (country-code TLDs tales como .uk, .co, .es, .mx). Estos dominios
que forman ramas en el árbol DNS se llaman también zonas, así, si una aplicación requiere la
dirección IP dónde enviar una petición DNS entonces le pregunta al servidor de su zona "padre".
Este proceso se conoce como iteración recursiva. Con el fin de tener autenticación de los datos y
de negación de existencia de los nombres de dominio para DNS, se emplea Domain Name System
SecurityExtensions (DNSSEC). DNSSEC se usa para proteger de ataques como por ejemplo en-
venenamiento en el caché [21]. Además, DNSSEC es un esquema distribuido (por su jerarquía) y
puede ser atacado por diversos daños provocados a los TLDs disminuyendo el desempeño del DNS,
donde este cambio a DNSSEC se hace como reacción a la creciente amenaza de ataques de des-
bordamientos de caché a los servidores de nombres y el reciente fallo de seguridad. Esto se explica
porque, con la extensión DNSSEC, todas las respuestas a un servidor de nombres son firmadas lo
que permite al destinatario comprobar a través de infraestructura de clave pública si las respuestas
de los servidores de nombres son auténticas. Lo anterior es una de las razones por las cuales es
recomendable contar con otras esquemas distribuidos, tales como redes P2P (Peer-To-Peer), que
soporten y protejan al DNS.
En la figura 1.1 se muestra la estructura básica de un árbol DNS donde se observa la dependencia
en los dominios que van formando las ramas del árbol DNS. Cada dominio (o nodo en el árbol) tiene
un nombre y puede contener subdominios. El nombre de dominio identifica la posición del dominio
en el árbol respecto a su dominio principal, utilizándose puntos para separar los nombres de los
nodos. Cualquier nombre de dominio DNS que se utiliza en el árbol es un dominio. En otras palabras,
un sistema de nombres de dominio (DNS) consta de una base de datos de nombres distribuida. Los
nombres de la base de datos DNS establecen una estructura lógica de árbol, conocida como espacio
de nombres del dominio. Cada nodo o dominio del espacio de nombres del dominio tiene un nombre
y puede contener subdominios. Los dominios y subdominios se agrupan en zonas para permitir
la administración distribuida del espacio de nombres. Por ejemplo, el nombre de dominio DNS
itesm.mx. se conoce como un dominio de segundo nivel. Esto se debe a que el nombre tiene dos
partes (llamadas etiquetas) que indican que se encuentra dos niveles por debajo de la raíz o la parte
superior del árbol. La mayor parte de los nombres de dominio DNS tienen dos etiquetas o más,
cada una de las cuales indica un nuevo nivel en el árbol. En los nombres se utilizan puntos para
separar las etiquetas.
Fig. 1.1: Estructura del árbol DNS
Y en la figura 1.2 se muestra el proceso de preguntas y respuestas hacia un servidor por parte
5
Fig. 1.2: Peticiones en DNS
de un cliente, donde los servidores de nombres guardan la información referente a su dominio en
registros (resource records).
Cabe anotar que el DNS se diseñó originalmente como un protocolo abierto y, por tanto, es
vulnerable a intrusos, donde uno de los ataques más frecuentes se da hacia el caché de las máquinas,
donde el caché se puede definir como una memoria rápida y pequeña, especialmente diseñada para
contener información que se utiliza con frecuencia en un proceso con el fin de evitar accesos a otras
memorias, reduciendo considerablemente el tiempo de acceso al ser más rápida que el resto de la
memoria principal. Es por esto que los recursos por los que pregunta más frecuentemente un usuario
de Internet se van almacenando en su caché para tener un acceso más rápido a dicha información y
no estar acudiendo siempre a su servidor respectivo. Es así como los sistemas tradicionales basados
en un modelo de cliente-servidor sufren de varias limitaciones, tales como tener un único punto de
falla, mucho tiempo en recuperación de documentos, espacio limitado en el caché, etc [10]. Y es
por estos problemas que las redes comienzan a tener diversas arquitecturas con que se conectan
los protocolos y otros programas de software y se mitigan ciertos problemas como los mencionados
anteriormente.
Con una red DNS los usuarios pueden preguntar por recursos que se encuentren en ciertos
dominios organizados como árboles, sin embargo, si a esta búsqueda se le agrega un enfoque P2P,
es decir, una arquitectura combinada en la que las usuarios se desenvuelvan en un entorno dis-
6
Fig. 1.3: Esquema general de una red P2P
tribuido y además haya un esquema de búsqueda organizada de la información, esto podría reducir
ampliamente la latencia y el caché de las máquinas se tornaría más organizado y útil.
Una arquitectura P2P es un concepto que ha estado creciendo en el mundo de las tencologías de
red y la Internet. En un sistema P2P los nodos son computadores distribuidos con iguales capaci-
dades y tareas en la red, intercambian información y servicios directamente con los otros nodos.
El objetivo de un sistema de compartir información es soportar un protocolo de búsqueda y hacer
eficiente la búsqueda de información entre los caches de los usuarios. El hecho de buscar información
conforma un problema fundamental en los ambientes P2P porque se debe tratar de asegurar que
no se cree un único punto de falla y además, que haya escalabilidad y dinamismo en el sistema [7].
Actualmente, las aplicaciones P2P más difundidas son las que comparten contenidos relativamente
simples (música, video), pero existen sistemas más sofisticados que crean infraestructuras de alma-
cenamiento, organización, búsqueda y recuperación de datos. Sin embargo, ¿qué tan seguras son
estas redes?. Esta pregunta suscita especulaciones como la necesidad de garantizar la integridad
de los datos distribuidos (para que ningún usuario los modifique sin autorización) o cuando se
requiere una comunicación confidencial entre nodos o se presenta la necesidad de un esquema de
autorización que delimite los contenidos a los que pueda acceder un usuario determinado.
Un esquema sencillo de una red P2P de forma general se muestra en la figura 1.3 donde se
observa que varios nodos comparten archivos en una red de forma no definida.
7
1.1. Definición del Problema
Las redes P2P son altamente inseguras y es aquí donde este trabajo tiene su enfoque. En In-
ternet, para el canal de subida, las redes P2P juegan un papel de ocupación muy importante,
ocupando nada menos que el 61 por ciento del caudal disponible. Viendo esta cifra se puede enten-
der por qué el problema con el ancho de banda de subida que presentan estas redes. Además, de los
problemas más importantes en las redes P2P para compartir archivos es que éstas adicionan sobre-
carga, retardos y baja seguridad; además, son susceptibles a diversos ataques. Un nodo atacante
puede insertarse en la red por medio de varios otros nodos o por un único nodo y así enviar una
gran cantidad de peticiones o desechar otras. También, una red P2P segura es un reto por tener
una topología de red dinámica y debido a que los nodos se están conectando y desconectando de
la misma constantemente. De esta forma se presentan problemas de firmado de contraseñas para
verificar y legitimar los paquetes y desechar los paquetes que no pasen dicha verificación. Por esta
razón se propone una estructura de doble anillo para una mejor distribución de la información
combinada con sub-árboles DNS, esto conforma un sistema híbrido que toma las ventajas de ambas
estrategias, esquemas centralizados y descentralizados [24]. El DNS es un esquema de árboles que
se ha venido desarrollando en los últimos años con el que se pretende dar mayor seguridad a las
redes y la combinación de redes P2P con la robustez que proporciona el DNS forma el conjunto de
propuestas que se pretenden desarrollar en este trabajo.
De esta forma en la redes P2P aparece otro problema en cuanto a la repartición de réplicas a
lo largo de la red y cómo repartirlas adecuadamente sin que esto pueda afectar en mayor medida
el desempeño de la misma. Así se deben reducir problemas como la latencia en la búsqueda y
reducir la carga en la red sin afectar notablemente la tolerancia del sistema y la disponibilidad de
la información.
El sistema jerárquico DNS es altamente sensitivo a la latencia y por esto tiene un significativo
reto en cuanto a servir eficientemente. Además, la misma organización jerárquica del DNS hace
que haya una carga desproporcionadaen los diferentes niveles de la jerarquía. Los nodos más altos
en dicha jerarquía son altamente susceptibles a ataques por negación de servicio, lo que causa
una seguridad vulnerable a todo el sistema. Otro de los problemas del DNS es que los servidores
de nombres son requeridos para salidas internas, incurriendo en costos administrativos muy altos
porque requieren ser asegurados y adminitrados manualmente [12]. Es así como se puede establecer
una propuesta híbrida en la que se combinen conceptos de una red P2P eficiente para mejorar las
8
carencias que presenta el DNS y así obtener una búsqueda más rápida y segura por medio de
una red poco vulnerable. El principal problema que presenta el DNS es que, al estar basado en
UDP (protocolo de transporte que no garantiza la recepción de la información enviada), tanto las
consultas como las respuestas pueden perderse (por ejemplo, a causa de congestionamiento en algún
enlace de la red). Es común apreciar cómo, en el caso de servidores y redes no muy bien configuradas,
la resolución de nombres se resiente sensiblemente ante cualquier anomalía (saturación de tráfico o
del servidor de nombres local).
Como principales amenazas que puede sufrir el sistema DNS, se presentan a continuación las
siguientes:
Hay un proceso de robo de información de zona es el que mediante el cual un intruso
obtiene los datos de zona DNS para obtener los nombres de dominio DNS, nombres de equipo y
direcciones IP de recursos de red. Un intruso suele empezar un ataque utilizando estos datos DNS
para obtener un diagrama de una red. Los nombres de equipo y dominio DNS suelen indicar la
función o ubicación de un dominio o equipo para ayudar a los usuarios a recordar e identificar los
dominios con mayor facilidad. Un intruso se aprovecha del mismo principio DNS para aprender la
función o ubicación de dominios y equipos en la red.
Un ataque por negación de servicio se produce cuando un intruso intenta eliminar o afectar
la disponibilidad de los servicios de red desbordando uno o varios servidores DNS de la red con
consultas recursivas, es decir, haciendo peticiones en repetidas ocasiones. Cuando un servidor DNS
se desborda con consultas, el uso de la CPU alcanzará su nivel máximo y el servicio del Servidor DNS
dejará de estar disponible. Sin un servidor DNS completamente operativo en la red, los servicios
de red que utilicen DNS dejarán de estar disponibles para los usuarios de la red.
La modificación de datos es un intento del intruso (que ha ocupado una red mediante DNS)
de utilizar direcciones IP válidas en paquetes IP que ha creado él mismo, de manera que propor-
ciona a estos paquetes la apariencia de proceder de una dirección IP válida de la red. Esto se
denomina comúnmente IP ficticia. Con una dirección IP válida (una dirección IP dentro del rango
de direcciones IP de una subred), el intruso puede tener acceso a la red y destruir datos o realizar
otro tipo de ataque.
La redirección se produce cuando un intruso puede redirigir consultas de nombres DNS a
servidores que él controle. Un método de redirección incluye el intento de contaminar el caché DNS
de un servidor DNS con datos DNS erróneos que pueden dirigir consultas futuras a servidores que
controle el intruso. La redirección puede realizarse siempre que el intruso disponga de acceso de
escritura a datos DNS, como ocurre, por ejemplo, con las actualizaciones dinámicas no seguras.
9
1.2. Objetivos
Se persigue simular el modelo de disponibilidad aplicado a DNS, pero ahora implementado para
una arquitectura Peer To Peer, donde se pretende mejorar la robustez de la red y su desempeño y
reducir en la medida de lo posible, la latencia, con base en técnicas de replicación del caché y la
eficiencia que proporciona una estructura de doble anillo.
1.2.1. Objetivos Específicos
• Considerar la estructura del DNS en Peer To Peer para reemplazar la convención jerárquica
DNS debido a mejor tolerancia a fallas y balance de carga.
• Analizar la conectividad entre los nodos del sistema, teniendo en cuenta nodos coalicionados
que funcionan como barreras de información y evitan que las peticiones sean satisfechas.
• Medir el desempeño del sistema con una replicación adecuada del caché y tener una estruc-
tura de doble anillo como solución a emergencias, lo que la hace más disponible que una
arquitectura de anillo simple.
• Crear una red de doble anillo que sirva como respaldo y que proporcione eficiencia en las
respuestas a las consultas, evitando loops lo que ocasiona retardos innecesarios en la red.
• Analizar el caché de la red, tomando en cuenta el caché personal de los clientes, el caché de
la red que satisface necesidades comunes en un entorno de red, y el caché de los clientes y de
la red combinado. Observar y comparar el comportamiento de la red según la influencia de
estos tipos de caché.
1.3. Hipótesis
Se plantea una arquitectura de doble anillo capaz de tener un mejor desempeño que algunos
otros esquemas ya establecidos en la literatura, midiendo parámetros tales como: número de saltos
y cantidad de peticiones perdidas. Se pretende tener un sistema capaz de reducir latencia en la red
con ayuda de la replicación de los recursos a lo largo de los caches de los nodos que forman la red.
Además, se espera que el segundo anillo, que es un anillo conformado por servidores, pueda servir
de respaldo para el otro anillo haciendo así una red equilibrada y con pocos puntos de falla.
10
1.4. Motivación
Muchos de los protocolos de redes de comunicaciones están basados en modelos tradicionales de
cliente-servidor. Así, un servidor está atento a las peticiones de los clientes que se conectan a él para
recibir los beneficios de sus servicios [10]. De todas formas estos modelos tienden a intensificar la
carga de los servidores en una red. Esto explica entonces la importancia de la necesidad de un modelo
alternativo, como lo es un Modelo de Red Peer-To-Peer, con el que se consigue intercambio de datos
no dependiente de una máquina individual, delegando capacidad de poder y almacenamiento en
una red de carga auto-organizada. Entonces, las funciones de cada nodo son de clientes y servidores
a la vez.
Con la expansión de los usuarios y de los recursos que proporciona el Internet, ha tomado gran
fuerza la implementación de sistemas para compartir archivos web. Los nodos almacenan copias
de los recursos web los cuales pueden ser accedidos frecuentemente por otros usuarios reduciendo
así la carga de un recurso muy popular por parte del nodos original que tiene el recurso.
El reto entonces es encontrar una forma eficiente que haga uso de los caches individuales de
los nodos conectados a una red y a su vez mantener la consistencia de los datos en el sistema de
tal forma que se forme una red de trabajo en equipo, y el objetivo de presentar una red P2P es
porque éstas no necesitan despliegue físico, los recursos son compartidos (almacenamiento, CPU,
BW), haciendo la arquitectura escalable, no hacen un solo punto de falla (robustez), optimizan los
retardos y se minimizan los cuellos de botella.
De esta forma se pretende hacer una arquitectura de emergencia, denominada eDNS, con dos
enfoques alternativos: por un lado el sistema de doble anillo que se va a proponer sirve como
respaldo, es decir, si una consulta no es satisfecha en uno de los anillos no se van a empezar a
crear loops innecesarios que congestionen la red, sino que ésta pasa a un segundo anillo para ver
si allí puede llegar a ser satisfecha. Otro enfoque es que esta arquitectura pretende ser un sistema
respaldo momentáneo en caso de que el árbol jerárquico DNS llegase a fallar, es así como uno de los
anillos de la arquitectura presentada actuaría como segundo eslabón en los niveles de la jerarquía
DNS. Entonces la motivación principal de esta tesis es ofrecer una opción diferente a las redes P2P
manteniendo las características básicas del DNS.
11
2. ANTECEDENTES
Este capítulo provee información deconceptos generales y trabajos relacionados donde se sientan
las bases para la comprensión de esquemas y estructuras especiales en redes P2P con ayuda de la
seguridad que proporciona el DNS. En un comienzo se pretende explicar el comportamiento de
los datos tomados de un servidor, luego, cómo estos datos DNS puede encontrarse a expensas de
ciertos ataques y finalmente, cómo se establecen las relaciones entre los servidores y clientes en
una red, y específicamente cómo funciona un red Peer-To-Peer. Se espera tener claridad en todos
estos conceptos puesto que la comprensión de los mismos hace que se entienda el entorno de una
arquitectura de red, con sus interacciones, ventajas y desventajas.
2.1. Modelo de la Popularidad de Consultas DNS
Cuando la probabilidad de medida de un valor particular de alguna cantidad, varía inversamente
como una potencia de ese valor se dice que la cantidad sigue una ley de potencia (como se muestra
en la ecuación 2.1), también conocida como Ley de Zipf o distribución de Pareto. Una distribución
de Zipf se caracteriza por tener pocas observaciones muy frecuentes y muchas poco frecuente. Al
granearse en escala log-log se presenta un recta. Más específicamente, a lo que se denomina una ley
de potencias es: si la variable independiente y la dependiente se representan en escala logarítmica, la
línea que mejor se adapta a los puntos es una línea recta. En el caso de que la variable dependiente
sea el orden en el que aparecen las cantidades que se representan, se le suele denominar ley de
Zipf.
(2.2)
(2.1)
La constante a es el exponente de la Ley de Potencia; la constante C no es importante una
vez que se fija a, porque C se va a determinar siguiendo la condición de que P(x) sume 1, [11].
Es así como en la Ley de Potencia las frecuencias decrecen muy lentamente cuando el tamaño del
evento aumenta. La variable xi es cada una de las frecuencias que hay en la distribución que se
tiene y xmin es la mínima frecuencia que se tiene en la distribución, donde este último valor es
generalmente 1 para distribuciones de sitios web.
Con lo que se forma la siguiente ecuación, que va a generar una línea de distribución para los
datos obtenidos:
Distribuciones de Ley de Potencias ocurren en diversos fenómenos, tales como poblaciones de
ciudades, tamaño de los terremotos, cráteres de la luna, manchas solares, archivos de computadores,
frecuencia de uso de palabras en un lenguaje, frecuencia de ocurrencia de los nombres en una
cultura, número de peticiones a una página web, venta de libros, etc [11]. La Ley de Potencias
ha sido extrapolada a la distribución de enlaces entrantes, la red que forman correos electrónicos
enviados y recibidos, la conectividad de los routers en Internet, o ya más recientemente, a los correos
enviados a grupos de noticias. Es así como comienza a perfilarse el proceso de este trabajo, donde
se intenta comprobar la distribución que siguen las peticiones hechas a un servidor durante un
determinado tiempo. Poder identificar el comportamiento que siga una ley de potencias puede ser
complicado. La estrategia idónea hace uso de este resultado: un histograma de una cantidad con
una ley de distribución del potencias aparece como una línea recta cuando se gráfica en escalas
logarítmicas. Lo anterior se puede ver reflejado en los datos tomados en la presente tesis para poder
partir de una hipótesis verdadera. Los datos se observan en la figura 2.1 y con escalas logarítmicas
se observan en la figura 2.2.
Y empleando las ecuaciones 2.1, 2.2 y 2.3 se puede generar una línea de tendencia que siga la
distribución de Ley de Potencia que siguen los datos en la figura 2.3.
13
(2.3)
(2.4)
Fig. 2.1: Comportamiento de los datos según la Ley de Potencia
2.2. DNS
Cuando se tiene un conjunto de datos obtenidos gracias a la recopilación de los mismos por
medio de un servidor es necesario tener en cuenta que esos datos son información DNS (Domain
Name System, por sus siglas en inglés). El proceso para tener una lista de recursos DNS es cuando
la resolución de nombres se hace de forma transparente por las aplicaciones del cliente (por ejemplo,
navegadores, clientes de correo y otras aplicaciones que usan Internet). Al realizar una petición que
requiere una búsqueda de DNS, la petición se envía al servidor DNS local del sistema operativo. El
sistema operativo, antes de establecer alguna comunicación, comprueba si la respuesta se encuentra
en la memoria caché. En el caso de que no se encuentre, la petición se enviará a uno o más servidores
DNS.
El Sistema de nombres de dominio (DNS) se definió originalmente en los RFC 1034 y 1035. Estos
documentos especifican elementos comunes a todas las implementaciones de software relacionadas
con DNS, entre los que se incluyen: un espacio de nombres de dominio DNS, que especifica una
14
Fig. 2.2: Comportamiento de los datos según la Ley de Potencia con escala logarítmica
jerarquía estructurada de dominios utilizados para organizar nombres. Los registros de recursos,
que asignan nombres de dominio DNS a un tipo específico de información de recurso para su uso
cuando se registra o se resuelve el nombre en el espacio de nombres. Los servidores DNS, que
almacenan y responden a las consultas de nombres para los registros de recursos. Los clientes DNS,
también llamados solucionadores, que consultan a los servidores para buscar y resolver nombres de
un tipo de registro de recursos especificado en la consulta.
El DNS se utiliza para distintos propósitos. Los más comunes son:
• Resolución de nombres: Dado el nombre completo de un host, obtener su dirección IP.
• Resolución inversa de direcciones: Es el mecanismo inverso al anterior. Consiste en, dada
una dirección IP, obtener el nombre asociado a la misma.
• Resolución de servidores de correo: Dado un nombre de dominio obtener el servidor a
través del cual debe realizarse la entrega del correo electrónico.
El Centro de Información de la Red Internet administra la raíz de la base de datos DNS en
15
Fig, 2.3: Línea de tendencia a la línea de datos
Internet. Los dominios superiores se han asignado a organizaciones y países. Estos nombres de
dominio siguen un estándar internacional. La zona DNS raíz está servida por trece servidores de
nombres de dominio, donde éstos y las bases de datos que mantienen el DNS están distribuidos
geográficamente y están a lo largo del mundo para evitar que una falla de uno de ellos colapse la red
entera. Trece es el número máximo de servidores raíz posibles en la arquitectura actual del DNS
puesto que es el que más puede encajar dentro de un paquete UDP de respuesta de 512 bytes. Diez
servidores raíz se encuentran en los EE.UU., dos se encuentran en Europa, y uno se encuentra en
Asia [22].
Un servidor de nombres principal es un servidor de nombres que obtiene los datos de sus zonas
de archivos locales. Los cambios en una zona, como la adición de dominios, se realizan en el servidor
de nombres principal.
Un servidor de nombres secundario obtiene los datos de sus zonas de otro servidor de nombres
de la Red que tiene autoridad para esa zona (normalmente de un servidor de nombres principal).
El proceso de obtención de información de estas zonas (es decir, el archivo de base de datos) por
16
red se conoce como una transferencia de zona.
En el proceso de resolución de nombres, los servidores de nombres almacenan en caché las
respuestas obtenidas fuera de su zona para evitar tiempo en la resolución de respuestas a peticiones
similares. En este proceso, se realiza la búsqueda a través de la jerarquía de nodos de nombres del
DNS hasta encontrar la resolución de la petición. Existe un tiempo de vida (TTL Time To Live)
que se especifica a través de los datos que se intercambian los servidores de nombres, y que controla
el tiempo que se almacenarán estos datos. Evidentemente, a menor tiempo de vida, mayor carga
para el servidor de nombres, pero más fiabilidad de los datos del dominio.
2.2.1.Delegación
El objetivo principal del diseño del Sistema de Nombres de Dominio es su administración de-
scentralizada. Esto se consigue a través de la delegación. La delegación de dominios funciona de
forma parecida a la delegación de tareas en una organización. Así, una organización que administra
un dominio puede dividirla en subdominios. Cada subdominio puede ser delegado a diferentes orga-
nizaciones, lo cual implica que esa organización será responsable de mantener los datos (registros de
recursos) de ese subdominio. Esa organización puede libremente cambiar los datos e incluso volver
a dividir el dominio delegado en subdominios y delegarlos. El dominio padre solamente contiene
enlaces a los responsables del subdominio delegado, de forma que pueda hacer referencia a ellos
cuando se le planteen consultas sobre nombres en dicho subdominio delegado.
Realmente, la subdivisión de un dominio en subdominios y la delegación de dichos subdominios
son cosas distintas. En primer lugar, un dominio que tenga capacidad de autogestión (autoridad),
siempre puede decidir subdividirse en diferentes subdominios, manteniendo él, en principio, la
autoridad sobre todos ellos. Posteriormente, la organización que gestiona el dominio puede decidir
además delegar la autoridad de algunos (o todos) sus subdominios en otras organizaciones. La
delegación es una acción que siempre decide el dominio padre, y éste puede revocarla cuando desee,
volviendo a retomar la autoridad sobre el subdominio que había delegado.
Para que una zona especifique que uno de sus subdominios está delegado en una zona diferente, es
necesario agregar un registro de delegación y, generalmente, el denominado registro de pegado" (glue
record). El registro de delegación es un registro NS en la zona principal (padre) que define el servidor
de nombres autorizado para la zona delegada. El registro de pegado es un registro tipo A para el
servidor de nombres autorizado para la zona delegada, y es necesario cuando el servidor de nombres
autorizado para la zona delegada también es un miembro de ese dominio (delegado). Donde un
17
registro de recursos NS (Name Server) indica los servidores de nombres autorizados para la zona.
Cada zona debe contener registros indicando tanto los servidores principales como los secundarios.
Por tanto, cada zona debe contener, como mínimo, un registro NS. Y un registro de recurso tipo
A (Address) asigna un nombre de dominio completamente cualificado a una dirección IP, para que
los clientes puedan solicitar la dirección IP de un nombre de host dado.
2.2.2. Ataques al DNS
Aunque DNS es un sistema distribuido podría verse afectado por algunos tipos de ataques
tratando daños críticos a los TLDs y llevando a atenuantes en el rendimiento. En los últimos foros,
se concluyó que es necesario advertir que la red es vulnerable a un ataque terrorista o malicioso, y
es aquí donde se presenta el término ataque. Así, un ataque se puede definir como todas aquellas
acciones que supongan una violación de la seguridad de un sistema (confidencialidad, integridad
o disponibilidad). Un recurso del sistema es destruido o se vuelve no disponible y es así como se
forma un ataque contra la disponibilidad. Una entidad no autorizada consigue acceso a un recurso
y esto es un ataque contra la confidencialidad. Una entidad no autorizada no sólo consigue acceder
a un recurso, sino que es capaz de manipularlo (virus y troyanos poseen esa capacidad) y pues éste
es un ataque contra la integridad.
Los servidores raíz son objetivos potenciales, porque llevan todo el tráfico dirigido a la Web
y contienen toda la información, como listas de direcciones. Ataques de denegación de servicio a
estos trece servidores raíz podría ser una de las armas para hacer caer el gran árbol de DNS. Por
ejemplo, durante determinados períodos de tiempo, muchos de los servidores fueron totalmente
inoperantes, con un incremento del 10 por ciento en la pérdida total de paquetes transmitidos en la
red. Esto es lo que se conoce actualmente como un ataque al DNS. El más común de los ataques de
piratas informáticos borra o desfigura sitios Web, o disminuye su velocidad de respuesta a ataques
de denegación de servicio. La combinación con los virus, gusanos y troyanos ha logrado destruir más
documentos de los que cualquier tipo de violencia física podría generar. Como ejemplo concreto se
tiene el famoso ataque de Akamai [19]. El ataque fue expresamente hacia los servidores de DNS
de Akamai, produciendo lentitud en la resolución de nombres y en el momento la imposibilidad de
llevarla a cabo. Los sitios Web de Google, Yahoo, Microsoft y otros, estuvieron fuera de línea debido
a un ataque distribuido de negación de servicio (DDoS por sus siglas en inglés), que duró dos horas
hasta que estas compañías redireccionaron sus registros de DNS hacia sus propias computadoras. El
error en el servidor DNS de Akamai, fue por un ataque DDoS dirigido por piratas informáticos rusos
18
Tab. 2.1: Tipos de ataques
con el propósito de mostrar su capacidad para inactivar el sitio de Microsoft www.microsoft.com. De
igual forma existen varias clases distintas de amenazas al DNS. Muchas de las cuales, son instancias
relacionadas al DNS en problemas más generales, pero algunas son específicas a peculiaridades del
protocolo DNS. El resumen de los principales ataques al DNS se muestra en la tabla 2.1. Un ataque
al DNS puede traer consecuencias severas, impidiendo el funcionamiento correcto del Internet y
afectando a un gran número de usuarios. Así, se hace sorprendente que aproximadamente el 80 por
ciento de los nombres de dominio son servidos por sólo 2 servidores, y el 0.8 por ciento, por sólo
uno [13].
19
1
2
3
4
5
6
Tipos de Ataques
Interceptación de paquetes
Predicción de preguntas DNS e ID
Cambiar el nombre
Traición por un servidor confiable
Negación de servicio
Negación autenticada de Nombres de Dominio
Man-in-the-middle(MITM) y
escuchar detrás de la puerta
(eavesdropping)
Ataque de búsqueda de fuerza
bruta
Conocido como envene-
namiento del caché
El servidor puede ser configu-
rado para dar respuestas que
no son las esperadas por el
usuario
Ataque a un sistema que
causa que un servicio o recur-
so sea inaccesible a los usuar-
ios legítimos
Existencia de tipos de RR
donde su ausencia causa una
acción más que la falla in-
mediata
En cuanto a la Interceptación de paquetes, este tipo de amenazas en peticiones, combinada
con respuestas corruptas alteran la respuesta real que el DNS regresa al resolver (servidor que se
encarga de la traducción de un nombre Internet en su dirección IP equivalente u otra información
para DNS). Mientras que la interceptación de paquetes está lejos de ser un problema único del DNS,
el comportamiento usual del DNS es enviar preguntas o respuestas completas en paquetes UDP
individuales que no están cifrados. Esto hace que este tipo de ataques sean particularmente fáciles
para cualquier agente malicioso con la habilidad de interceptar paquetes en una red compartida.
En la predicción de preguntas DNS e ID es importante tener en cuenta que desde que el DNS
es usado, en su mayor parte, sobre los protocolos UPD/IP, es relativamente fácil para un atacante
generar paquetes los cuales concuerden con los parámetros de los protocolos de transporte. El campo
ID en el encabezado del DNS es un campo de únicamente 16 bits y el puerto UDP del servidor
asociado con DNS es un valor bien conocido, por lo tanto existen solo 232 posibles combinaciones
de ID y el puerto UDP por cada cliente-servidor asociados. Esto no es un rango muy grande y
no es suficiente para proteger en contra de un ataque de búsqueda de fuerza bruta; además, en la
práctica, tanto el puerto UDP del cliente como el ID pueden ser predichos gracias al tráfico previo,
y no es fuera de lo común para el puerto del cliente ser un valor fijo conocido (esto es debido a
los firewalls u otras restricciones), así, frecuentemente sereduce el espacio de búsqueda a un rango
menor que 216.
Quizás la clase más interesante de amenazas específicas al DNS son los ataques name changing
(cambiando el nombre). Éstos son un subconjunto de una clase mas amplia de ataques basados
en nombres, algunas veces estos ataques son conocidos como envenenamiento del caché (cache
poissoning). La mayoría de los ataques basados en nombres pueden ser parcialmente mitigados
revisando registros de recursos (RRs) en mensajes de respuesta para verificar relevancia con la
pregunta original, pero este tipo de defensa no puede detectar ataques name changing. Así, cualquier
RR es, al menos en principio, un gancho que le permite al atacante alimentar datos corruptos
dentro del caché de la víctima, potencialmente subvertiendo de esta manera decisiones subsecuentes
basadas en nombres DNS.
Otra variación en la interceptación de paquetes es un servidor confiable que se torna no tan
confiable, Traición por un servidor confiable, ya sea por accidente o por intento. Muchas máquinas
clientes están configuradas únicamente con resolvers incompletos y usan servidores confiables para
realizar todas sus preguntas DNS. En muchos casos el servidor confiable es suministrado por el ISP
(Internet Service Provider, por sus siglas en inglés) del usuario y le satisface al cliente sus necesi-
dades. Además de la traición accidental de esta relación confiable (vía fallas del servidor, roturas
20
exitosas dentro del servidor, etc.), el servidor mismo puede ser configurado para dar respuestas que
no son las esperadas por el usuario, ya sea en un intento legítimo para ayudar al usuario o para
promover algún otro objetivo tal como suministrar un socio de negocios entre el ISP y alguna otra
tercera parte.
Como cualquier otro servicio de red, DNS es vulnerable a ataques de negación de servicio (DoS,
Denial of Service, por sus siglas en inglés). En estos ataques el atacante utiliza una máquina para
quitar de operación un servicio o computadora conectada a Internet. Algunos ejemplos de este tipo
de ataque son: generar una gran sobrecarga en el procesamiento de datos de una máquina, de modo
que el usuario no pueda utilizarlo; generar un gran tráfico de datos en una red, ocupando todo
el ancho de banda disponible, de modo que cualquier computador en esta red quede inutilizable;
eliminar servicios importantes de un proveedor de internet, imposibilitando el acceso de los usuarios
a sus cuentas de correo en el servidor de e-mail o en el servidor Web. Servidores DNS están también
en riesgo de ser usados como amplificadores de negación de servicio, ya que los paquetes de respues-
tas DNS tienden a ser significativamente más largos que los paquetes DNS de preguntas. Algunas
de las variantes de un ataque de negación de servicio son: consumo de ancho de banda, que consiste
en consumir todo el ancho de banda, y puede darse de forma individual o bien uniendo multitud de
pequeñas máquinas para saturar la conexión de red de la víctima. Un segundo tipo de ataque es por
inanición de recursos; está enfocado al consumo de los recursos del sistema, a la saturación de la
CPU y/o memoria hasta que la máquina se cae. Este tipo de ataque, generalmente provoca un fallo
general del sistema. Un tercer tipo de ataque DoS es por los errores de programación por medio de
envío de datos anormales, que no cumplen las RFC (normas de definición del protocolo) al sistema
objetivo: si la pila TCP/IP no es capaz de manejar estas excepciones y los programadores no han
supuesto estos casos, terminará con la caída del sistema. A veces no son defectos de programación:
son defectos del hardware, defectos de algún chip, o defectos de la propia CPU. Un cuarto tipo de
ataque son los ataques DNS y de enrutamiento. La mayoría de los protocolos de enrutamiento como
RIP (Routing Information Protocol, por sus siglas en inglés) o BGP (Border Gateway Protocol, por
sus siglas en inglés) carecen de autenticación, o tienen una muy sencilla. Se trata por tanto de
un escenario perfecto para que cualquier atacante pueda alterar las rutas correctas y, falsificando
su IP origen, crear una condición DoS. Las víctimas de estos ataques verán cómo su tráfico se
dirige por ejemplo hacia a una red que no existe. Los ataques DoS sobre servidores de nombres de
dominios (DNS) son tan problemáticos como los anteriores. Estos ataques intentan convencer al
servidor DNS, por ejemplo, para almacenar direcciones falsas: cuando un servidor DNS realiza una
búsqueda, el atacante puede redireccionar a su propio servidor o bien a un Agujero Negro.
21
Han tomado lugar mucha discusiones sobre la cuestión de negación autenticada de nombres de
dominio. La pregunta particular es si hay un requerimiento para autenticar la no-existencia de un
nombre. El problema es si el resolver debería poder detectar cuando un atacante remueve RRs
desde una respuesta. Algo inquietante es la existencia de tipos de RRs de quienes su ausencia causa
una acción más que la falla inmediata, esto constituye la verdadera amenaza. Se podría decir, en
algunos casos, que incluso la falta de un RR podría ser considerado un problema.
2.3. El caché
El caché es una colección de datos duplicados donde los datos originales fueron almacenados
en algún otro computador anteriormente. El funcionamiento del caché es como sigue: cuando el
caché de un cliente (una CPU, un navegador web, un sistema operativo) espera acceder a un
recurso de datos, el cliente primero revisa su caché. Si la información por la que quiere preguntar
es encontrada, el cliente toma la respuesta del caché y la graba [10]. La situación alternativa,
cuando se consulta el caché y el recurso deseado no se encuentra, el dato se busca entonces en la
fuente original y posteriormente es pasado al cliente que preguntaba por el mismo. El resultado se
almacena en el caché del cliente, listo para un acceso futuro [10]. Actualmente, el caché evita la
transmisión de los objetos idénticos repetidos, pero sólo funciona si los objetos son completamente
intercambiables, pero falla cuando éstos se han modificado ligeramente [5].
Cada vez que un servidor de nombres envía una respuesta, lo hace adjuntando el tiempo de
validez de la misma (TTL, Time-To-Live, por sus siglas en inglés, "tiempo de vida"). Esto posi-
bilita que el receptor, ante la necesidad de volver a resolver la misma consulta, pueda utilizar la
información previamente obtenida en vez de realizar un nuevo requerimiento. Esta es la razón por
la cual los cambios realizados en el DNS no se propagan instantáneamente a través del sistema.
Dependiendo de la naturaleza de los mismos (y de la configuración de cada servidor), la propagación
puede tardar desde algunos minutos hasta varios días.
Sin embargo la utilidad del caché se ve ampliamente reducida si las copias del mismo no son
actualizadas cuando el servidor original cambia sus datos. Así mismo, los mecanismos de consis-
tencia del caché aseguran que las copias deben ser constantemente actualizadas al reflejar cambios
la información original. Algunos de estos mecanismos son: campos TTL (Time-To-Live, por sus
siglas en inglés), preguntas frecuentes de un cliente, e invalidación de protocolos [10]. Los campos
TTL estiman el tiempo de vida de un recurso el cual es usado para determinar cuánto tiempo
22
los datos pueden permanecer como válidos en el caché. La pregunta frecuente de un cliente es la
técnica en la cual los clientes periódicamente están revisando su información con el servidor con el
fin de determinar si sus recursos en el caché aún siguen válidos. La invalidación de protocolos es
requerida cuando se necesita una fuerte consistencia y depende de la forma de rastreo del servidor
por los datos, así, en cada intervalo de tiempo un ítem cambia y el servidor notifica a sus caches
que ya las copias que tienen no son válidas. Un problema de la invalidación de protocolos es que
requieren un alto costo y varias modificaciones al servidor [10].
Un ataquefrecuente al caché es llamado Envenenamiento del Caché. Este tipo de ataques
requiere la existencia de una falla de seguridad en el servidor, con el objetivo que esa falla haga
que el servidor acepte información falsa que parece legítima como si fuera verdadera. Las fallas
referidas son aquellas que provocan que el servidor no pueda validar la veracidad del punto origen
de la información, dando por buena cualquier información recibida, que evidentemente, es servida
a los usuarios que circulen por el servidor DNS. Esto puede ser aprovechado para que el atacante
tome control de las acciones del servidor DNS, siendo la más frecuente la redirección a un servidor
que opere bajo su control. Estos ataques han sido recientes, es decir, a medida que el Internet se ha
vuelto una red cada vez más amplia y complicada, los equipos han adquirido mayor almacenamiento
de información y es aquí donde el caché juega un papel importante y, a la vez, puede hacerse
también vulnerable. Es por esto que el mantenimiento de la coherencia de un caché fuerte en
DNS como un mecanismo de manejo se ha vuelto más y más exigente en cuanto a tres objetivos
importantes: responder rápidamente y manejar peticiones excepcionales, como las repentinas fallas
de Internet causadas por desastres naturales y humanos. Adaptar cada vez frecuentes cambios de
direcciones IP, debido a la introducción de técnicas DNS dinámicas para dispositivos de Internet.
Y para proporcionar servicios de control de contenido y equilibrio de distribuciones. De esta forma,
el caché del DNS con una fuerte coherencia mejora la disponibilidad y fiabilidad de los servicios
de Internet [3]. Es por esto que con un despliegue que ha tenido el uso del caché como medio
indispensable en las redes de la actualidad, la consistencia en el caché empieza a tomar más seriedad.
Una fuerte consistencia en el caché se define como el modelo en el cual una copia antigua de un
recurso original nunca es entregada a los clientes. Actualmente, DNS sólo soporta una consistencia
débil de caché con el uso del mecanismo de TTL, así el campo TTL de cada registro indica cuánto
tiempo puede ser almacenado en caché este recurso [3]. La mayoría de los TTLs de los registros
de recursos están en el rango de 1 hora a 1 día [6]. Si un cambio puede ser anticipado el TTL
debe ser reducido para minimizar la inconsistencia para dicho cambio y luego se incrementa a su
23
valor anterior para esperar el siguiente cambio (según el RFC 1034, Request for Comments). Sin
embargo, el RFC no especifica en cuánto se debe reducir el TTL [3]. Sin embargo un tamaño de
TTL demasiado reducido puede disminuir las posibilidades de incosistencia en el caché, pero va a
significar en un incremento en el tráfico DNS lo cual puede degradar seriamente la escalabilidad de
este servicio. Con todo esto, si no hay una consistencia en el caché entre los servidores DNS va a
ser muy difícil saber cuándo un registro ya caducó, es decir, ya no tiene información actualizada
[3] y es por esto que la incosistencia forma una gran amenaza para los servicios de Internet.
2.4. Protocolos de coherencia del caché
Con la replicación se lograr coherencia en el caché, la cual es utilizada para el mantenimiento
automático de copias de datos en múltiples computadores, por ejemplo el almacenamiento de datos
provenientes de servidores Web en la memoria caché. Los protocolos aseguran que el caché (general-
mente controlado por los clientes en lugar de los servidores) es consistente con las réplicas iniciadas
por el servidor. En sistemas multiprocesador con memoria compartida muchas soluciones se basan
en el hardware. En sistemas distribuidos generalmente, las soluciones son basadas en software y
son más interesantes.
2.5. Sistemas de Información Autoconfigurables
En los últimos 10 años los sistemas han visto la necesidad de volverse rápidamente reconfig-
urables para satisfacer las demandas de forma eficiente, lograr alta disponibilidad en escenarios de
fallas e incorporación fácil a nuevos equipos y maquinaria. Los sistemas autoconfigurables tienen
ventajas potenciales, tales como: descomposición jerárquica del problema de control, lenguaje for-
mal para descripción de problemas de equipos y verificación de incorrecciones de los sistemas de
control [2]. Aquí también juegan un papel muy importante los sistemas distribuidos, los cuales son
funcionales, hacen distribución del trabajo en toda la red, son económicos y se distribuyen fácil-
mente de forma geográfica. La técnica mas simple de interconectar varios computadores se llama
punto a punto, la cual enlaza a los computadores mediante cable o inalámbricamente. Aquí se per-
mite a los usuarios compartir impresoras e intercambiar archivos, pero no existe un almacenamiento
centralizado de datos ni elementos de seguridad.
Una clase específica de las redes autoconfigurables son las redes Peer-To-Peer que aprovechan,
administran y optimizan el uso del ancho de banda que acumulan de los demás usuarios en una
24
red por medio de la conectividad entre los mismos usuarios participantes de la red, obteniendo
como resultado mucho más rendimiento en las conexiones y transferencias que con algunos métodos
centralizados convencionales donde una cantidad relativamente pequeña de servidores provee el total
de ancho de banda y recursos compartidos para un servicio o aplicación. El elemento fundamental
de toda red P2P es un par o un igual ( en inglés: peer), y es la unidad de procesamiento básico de
cualquier red P2P. Un par es una entidad capaz de desarrollar algún trabajo útil y de comunicar los
resultados de ese trabajo a otra entidad de la red, ya sea directa o indirectamente. El mapeo de la
topología de una red, junto con las reglas de comportamiento de cómo se vinculan los nodos, provee
una explicación potencial del comportamiento subyacente de la misma. Las topologías de redes P2P
emergen espontáneamente de una multitud de acciones individuales, los usuarios se conectan a la
red P2P cuando lo desean y la abandonan a su gusto. Consecuentemente, la estructura de las redes
P2P evoluciona segundo a segundo, dependiendo de qué usuarios están conectados [8].
En una red P2P ni los clientes ni los servidores son fijos. Además en estas redes se hace un
manejo y optimización del ancho de banda para todos los usuarios repartiendo adecuadamente la
carga de forma balanceada. Como resultado se obtiene más eficiencia en las conexiones y en las
transferencias, lo que no es tan eficiente con un método centralizado convencional donde un número
de servidores provee el ancho de banda total y maneja la compartición de archivos para un servicio o
aplicación. Entre las aplicaciones más comunes de las redes P2P están compartir y buscar archivos,
sistemas de archivos distribuidos, sistemas de telefonía por Internet, alternativas a la distribución
convencional de filmaciones y televisión y cálculos científicos con bases de datos, entre otras.
Las ventajas que puede tener un sistema distribuido como las redes P2P son bastante in-
teresantes. En la tabla 2.2 se muestran de forma comparativa las ventajas y desventajas de una
arquitectura P2P.
2.5.1. Topologías de Red
La topología de red es la disposición física en la que se conecta una red de equipos. Si una red
tiene diversas topologías se la llama mixta. Algunas de las topologías más comunes para las redes
son:
• Bus: Es una topología de red en la que todas las estaciones están conectadas a un único canal
de comunicaciones. Los nodos utilizan este canal para comunicarse con el resto. Es la más
sencilla de las topologías. Físicamente cada nodo está conectado a un cable común, por lo que
25
Tab. 2.2: Ventajas y desventajas de las redes P2P
Redes P2P
VENTAJAS
Minimización la conegestión y cuel-
los de botella debido a que las
conexiones se realizan punto a punto
Descentralizadas
Anónimas
Al añadir un nodo a la red no es
necesario reestructurarla
Mayor escalabilidad por tener
menor latenciay mejor auto-
organización
Bajos costos de funcionamiento
Alta tolerancia a errores
Las transferencias son más rápidas
y facilita encontrar varias fuentes de
descarga
DESVENTAJAS
Incrementa la complejidad del en-
torno debido a la heterogenidad de
los nodos
Difícil de administrar
No existe ningún tipo de nitro, lo
que la hace poco confiable
Baja seguridad y ésta depende de
cada nodo
El software y el hardware de un no-
do son generalmente muy determi-
nantes en cuanto al caché
26
se pueden comunicar directamente, aunque la ruptura del cable hace que los nodos queden
desconectados.
• Estrella: Es una red en la cual las estaciones están conectadas directamente a un pun-
to central y todas las comunicaciones se han de hacer necesariamente a través de éste. Es
comúnmente utilizada sobre todo para redes locales.
• Árbol: Los nodos están colocados en forma de árbol. Físicamente es parecida a una serie de
redes en estrella interconectadas salvo en que no tiene un nodo central. En cambio, tiene un
nodo de enlace troncal desde el que se ramifican los demás nodos. Es una variación de la red
en bus, la falla de un nodo no implica interrupción en las comunicaciones. Se comparte el
mismo canal de comunicaciones.
• Anillo: Las estaciones se conectan formando un anillo. Cada estación está conectada a la
siguiente y la última está conectada a la primera. Cada estación tiene un receptor y un
transmisor pasando así la señal a la siguiente estación.
• Malla: Es una topología de red en la que cada nodo está conectado a uno o más de los
otros nodos. De esta manera es posible llevar los mensajes de un nodo a otro por diferentes
caminos. Si la red de malla está completamente conectada, no puede existir absolutamente
ninguna interrupción en las comunicaciones.
Las principales topologías de red está ilustradas en la figura 2.4 donde se expresa gráficamente
la ubicación de los nodos en cada una de ellas. En el presente trabajo, las redes P2P están basadas
en una topología de anillo donde los nodos están conectados como circuito cerrado sin ningún
sistema central en la red.
2.5.2. Protocolos
Adicionalmente, las redes P2P pueden trabajar sobre protocolos como algunos de los siguientes,
los cuales definen cómo está distribuida la información y cómo será el desempeño de la búsqueda
de dicha información:
• Tapestry: Es una estructura de soporte de código abierto para la creación de aplicaciones
web de forma dinámica, robusta y altamente escalable en Java. Además es una infraestructura
de ruteo que provee enrutamiento de ubicación independiente de mensajes hacia la copia
más cercana de un objeto o servicio usando enlaces punto a punto y sin emplear recursos
27
Fig. 2.4: Estructuras de topologías de red
centralizados. Tapestry es seguro en la administración, tolerante a fallas y resistente a sobre
carga en la red [25].
• Pastry: Es un esquema genérico, escalable y enciente para aplicaciones P2P. Los nodos Pastry
forman una red descentralizada, auto-organizada y tolerante a fallos. Así, cada nodo tiene un
único identificador, guarda información de sus vecinos, notifica aplicaciones si hay algún nodo
que arriba, que falla o que se descubre. Pastry es completamente descentralizado y escalable,
se adapta automáticamente a nuevas conexiones, desconexiones y fallas de nodos [15].
• CAN: Es un protocolo de comunicaciones basado en una topología bus para la transmisión
de mensajes en ambientes distribuidos, además ofrece una solución a la gestión de la comu-
nicación. Es decir, es una infraestructura distribuida que proporciona tablas "hash". Tiene
características como: escalabilidad, tolerancia a fallas y completa organización. Posiblemente
el mejor ejemplo de sistemas de Internet actuales que son potencialmente implementados por
CAN son los sistemas para compartir archivos P2P recientemente introducidos, tales como
Napster y Gnutella [14].
28
• Chord: Es un protocolo sencillo y escalable de búsqueda distribuida en redes P2P que rela-
ciona contraseñas con nodos. Está diseñado para funcionar en redes descentralizadas y su
funcionamiento permite concluir con un resultado exhaustivo de la búsqueda. Provee soporte
para las contraseñas y las mapea dentro de un nodo. Además, se adapta eficientemente si en
el sistema los nodos están entrando y saliendo y puede responder peticiones aunque el sistema
esté cambiando continuamente [18].
Es así como, en la propuesta que se presenta en este trabajo se ha usado el protocolo Pastry
y Tablas de Hash Distribuido (Distributed Hash Tables, DHT, por sus siglas en inglés). Las tablas
DHT son una clase de sistemas distribuidos descentralizados que proveen servicios de búsqueda y
recuperación y reparten la propiedad de un conjunto de claves entre los nodos que participan en
una red, y son capaces de encaminar eficientemente mensajes al dueño de una clave determinada.
Estas tablas son diseñadas para tratar un número grande nodos y procesar altas y bajas de los
mismos. Las tablas DHT pueden servir para sistemas de almacenamiento y recuperación de archivos
en redes P2P y almacenamiento cooperativo en la Web.
El sistema Pastry es una red auto-organizada de nodos, donde cada nodo rutea las peticiones
de los clientes e interactúa con los demás en una o más aplicaciones. Cualquier computador que se
conecta a Internet y corre bajo el protocolo Pastry, dicho nodo puede actuar como un nodo Pastry y
bajo las políticas de seguridad de las aplicaciones específicas. A cada nodo en una red P2P Pastry se
le asigna un identificador de nodo (ID) de 128 bits. El ID es usado para indicar la posición del nodo
en un espacio circular, cuyo rango es de 0 a 2128 — 1. El ID es asignado de forma aleatoria cuando
un nodo se une al sistema. Se asume que los IDs generados forman un conjunto uniformemente
distribuido. Por ejemplo los IDs pueden ser generados por la computación criptográfica hash de las
claves públicas o de las direcciones IP. Como resultado de esta asignación aleatoria de IDs, con alta
probabilidad, los nodos con IDs adyacentes son diversos en la red. Asumiendo una red que consta
de N nodos, Pastry puede rutear al nodo numéricamente más cercano en menos que [log(2b).N]
pasos, bajo una operación normal (6 es un parámetro de configuración de valor típico 4). A pesar
de las fallas de nodos en la red, la entrega de información se garantiza a menos que [ L / 2 j nodos
con IDs adyacentes fallen simultáneamente (\L\ es un parámetro de configuración de valor típico 16
ó 32) [15]. La figura 2.5 muestra la búsqueda para satisfacer una petición donde la red se comporta
bajo el protocolo Pastry, y cuando se hace la petición, los nodos van acercando a la misma a su
nodo destino de una forma lógica y eficiente, buscando tener el menor número de saltos para avitar
congestionar la red.
29
Fig. 2.5: Ejemplo del comportamiento del protocolo Pastry
congestionar la red.
En estudios recientes se ha visto que las redes P2P han sido altamente empleadas para compartir
información o para dar pasos para encontrar dicha información. Los datos en los caches de la red
son frecuentemente utilizados para reducir el tiempo de respuesta en las redes P2P y es aquí donde
se presenta uno de los problemas más comunes actualmente, que es el envenenamiento del caché.
Esto ocurre puesto que la funcionalidad principales de una red P2P es permitir la entrada y salida
de nodos al sistema, donde para buscar archivos, un nodo envía un mensaje a los nodos con
los cuales está conectado. Estos nodos buscan si los archivos están disponibles de forma local y
reenvían el mensaje de búsqueda a los nodos a los que ellos están conectados. Si un nodo posee el
archivo, inmediatamente contesta al nodo original que lo solicitó. Este es un método de difusión
del mensajes llamado inundación de red. La descarga de archivos se hace directamente desde los
nodos que contestaron. Si son múltiples nodos, suele partirse el archivo en diferentes trozos y cada
nodo envíauno de estos, aumentando la velocidad total de descarga.
2.5.3. Proceso P2P
En el proceso de preguntas y respuestas a un servidor, juegan un papel muy importante los
conceptos que allí se manejan, tanto de preguntas y respuestas, como los entes que están involucra-
dos en satisfacer dichas peticiones, entre los cuales se explican a continuación los más relevantes.
Un cliente es un computador o equipo configurado para conectarse a un servidor y realiza peti-
ciones de servicio a los proveedores del mismo. Así, el cliente envía mensajes a un servidor que las
30
quedará satisfecha. Un servidor es un equipo, generalmente, más sofisticado y robusto que el del
cliente, encargado de proporcionar información, recursos y servicios a los clientes de la red. Los pro-
cesos del servidor pueden residir en una máquina que también actúa como cliente de otro servidor.
Además, un servidor puede dar acceso a otras redes, actuando como un servidor de comunicaciones
que conecta a otros servidores que actúan como nodos de la red. Un nodo de una red es un espacio
real o abstracto en el que confluyen parte de las conexiones de otros espacios reales o abstractos
que comparten sus mismas características y que a su vez también son nodos. Todos estos nodos
se interrelacionan entre sí de una manera no jerárquica (para una red P2P) y conforman una red.
Una petición consiste en una lista de palabras que se envían. Cuando un servidor recibe una peti-
ción busca si tiene información que coincida con dicha petición en su índice. El servidor, entonces,
reúne el máximo número de resultados para retornarlos, y así se dice que la petición ha quedado
satisfecha [24]. De esta forma la respuesta es el número de resultados que el servidor proporciona
cuando encontró una coincidencia en él mismo con respecto a la petición que le fue hecha.
Cuando un usuario se registra, sólo los archivos que fueron adicionados o removidos desde la
última salida del usuario serán reportados, esto para incrementar la eficiencia; sin embargo, esta
política en algunas arquitecturas se torna ineficiente puesto que quiere decir que el usuario se debe
reconectar al mismo servidor siempre. A continuación en la tabla 2.3 se presentan las principales
arquitecturas en cuanto al registro y la interacción usuario-servidor [24].
En una arquitectura Encadenada, cuando un usuario se registra por primera vez, sólo el servidor
local lo agrega a su índice y si el usuario hace una petición, su servidor trata de satisfacerla solo, si
no puede, se comunica con un servidor remoto de la cadena para que éste satisfaga la petición. El
servidor local sigue enviando la petición hasta que hayan encontrado el mayor número de resultados
o hasta que todos los servidores hayan recibido y atendido la petición. En la Replicación Completa,
cada nuevo servidor debe procesar la petición, los resultados deben ser enviados al servidor original,
y dichos resultados deben unirse. En la arquitectura de Hash, Las diferentes palabras de los datos
son puestas en un algoritmo de hash en los servidores, entonces un servidor dado mantiene la lista
invertida completa de un subconjunto de todas las palabras. Las palabras puestas bajo el algoritmo
de hash son distribuidas tal que cada servidor tiene un trabajo aproximadamente igual. Cuando un
cliente se registra, los datos de sus archivos son enviados a los servidores que contienen las listas
de esas palabras. Y en una arquitectura Desencadenada, un usuario que se registra en un servidor
local sólo puede ver los archivos de los usuarios de ese mismo servidor local [24].
31
Tab. 2.3: Arquitecturas P2P
32
ARQUITECTURA
Encadenada
Replicación comple-
ta
Hash
Desencadenada
MODELO
Los servidores
utilizan una
cadena lineal
para responder
peticiones
Depende de la
razón de fre-
cuencia de los
registros a las
peticiones y del
tamaño del índice
Por medio de
identificadores
generados de
forma aleatoria
Conjunto de
servidores inde-
pendientes que no
se comunican con
los otros
VENTAJAS
El registro y la descarga son
rápidos y escalables porque
afectan sólo el servidor local
del usuario
Cada servidor mantiene
un índice completo de los
archivos de todos los usuarios,
entonces todas las peticiones
podrán ser satisfechas por
un solo servidor. Así, con el
incremento de registros los
usuarios pueden conectarse
a cualquier servidor. Si los
servidores están conectados
en una red de broadcast,
la propagación de regis-tros
será más enciente
Un número limitado de servi-
dores se encargan de una peti-
ción y los resultados no nece-
sitan ser enviados entre servi-
dores
Es escalable linealmente con
el número de servidores en el
sistema
DESVENTAJAS
Las peticiones se logran
de una forma más cos-
tosa si son requeridos
muchos servidores de la
cadena para satisfacer
la petición [24]
Todos los registros
deben ser enviados a
cada servidor, entonces
cada uno debe tener
su copia del índice
y la información de
conexión [24]
El ancho de banda nece-
sario para enviar las lis-
tas entre servidores [24]
No permite que los
usuarios puedan ver
a otros usuarios del
sistema. Provee una
búsqueda parcial [24]
Así, todos estos conceptos juegan un papel fundamental en una red P2P, donde los sistemas
P2P pueden ser clasificados en 3 categorías. Sistemas centralizados, los cuales tienen un servidor
de directorio central al cual los usuarios (clientes) hacen las peticiones o búsquedas. Cada vez que
un cliente se conecta o desconecta de la red, la base de datos se actualiza. Todos los mensajes
de búsqueda y control son enviados al servidor centralizado. El servidor centralizado compara la
solicitud de sus clientes con el contenido de su base de datos y envía las correspondencias al cliente
en cuestión. Como ventajas, permite mantener las tareas de control de acceso, administración y
sincronización. Proporciona un rendimiento muy elevado a la hora de localizar recursos siempre
y cuando el servidor esté bien dimensionado. Aunque este modelo centralizado puede funcionar en
ciertas organizaciones, éste no suele ser el caso de grandes organizaciones distribuidas geográfica-
mente con un gran número de usuarios, en las cuales puede resultar inmanejable e impracticable
gestionar todos los recursos desde un único servidor centralizado. Así es como se presentan algunos
inconvenientes como que estos sistemas tienen un único punto de falla lo que los hace altamente
vulnerables [9], y otros problemas como no escalabilidad, necesidad de presencia física y alto costo;
como ejemplo de estos sistemas se encuentra Napster.
Los sistemas descentralizados o P2P puros no tienen un servidor central, sino que al contrario, los
nodos forman una red entre ellos mismos y así se envían peticiones formando un modelo distribuido.
Cada nodo actúa como servidor y como clientes en la red. Cada par dentro de esta arquitectura
trata de mantener un cierto número de conexiones con otros pares durante todo el tiempo. A pesar
de que el número de saltos de la red es potencialmente infinito, permanece limitado por un tiempo
de vida máximo o TTL, relacionado con el máximo número de saltos que puede dar un mensaje.
Por cada nodo o par por el que circula el mensaje de petición se decrementa en una unidad el TTL
descartándose la petición si esta llega a cero. El modelo P2P puro es más robusto al no depender
de un servidor central, además más económico. La principal desventaja es el elevado tiempo y
sobrecarga de ancho de banda que suponen las búsquedas de información en la red. Además puede
ser que el recurso buscado y existente ni siquiera pueda ser encontrado [16]. Un esquema de un
sistema P2P puro se muestra en la figura 2.6.
Entre estas redes de diseño descentralizado, algunas son estructuradas en las que hay un cercano
acoplamiento entre la topología de red P2P y la ubicación de los datos; entre estos sistemas se
encuentran Pastry [15], Tapestry [25], Skipnet, CAN [14] y Chord [18]. Otros sistemasP2P
descentralizados son los no estructurados donde no hay acoplamiento entre la topología de red y la
ubicación de la información [4], es decir, no se tiene un control preciso entre la topología de la red
y el lugar donde se encuentran los datos en la misma. Entre estos sistemas se encuentran Gnutella
33
y Freenet.
En los sistemas P2P mixtos o semicentralizados cada nodo cliente mantiene sólo un pequeño
número de conexiones abiertas y cada una de esas conexiones es a un superpar. Así mismo los
superpares están conectados entre sí. Este diseño tiene el efecto de hacer la red escalable, mediante
la reducción del número de nodos involucrados en el enrutamiento y manejo de los mensajes,
así como la disminución del volumen de tranco entre ellos. Además la velocidad de respuesta a las
solicitudes dentro de un entorno mixto es comparable al de un entorno P2P centralizado [16]. Un
esquema de un sistema P2P mixto se muestra en la figura 2.6.
Sistema P2P híbrido
Sistema P2P puro
Fig. 2.6: Esquemas P2P híbrido y mixto
34
3. PROPUESTA
En este capítulo se presentan algunas propuestas que hacen que una red no segura, como P2P,
tenga características de seguridad de la información gracias a las ventajas de DNS en algunos casos,
y en otros, gracias a las ventajas de la codificación de la red. El objetivo principal de esta propuesta
es describir un diseño de servicio de búsqueda P2P de baja latencia para un desarrollo a escala.
Actualmente, el servicio de búsqueda distribuido a escala global y usado en el Internet es el DNS.
Algunos grupos de investigación han comenzado en enfocarse en sistemas P2P para sustituir o
ampliar el sistema DNS.
En una arquitectura de cliente-servidor, según se van añadiendo más clientes, la tasa de trans-
ferencia disminuye a niveles bajos. Esto ocurre porque los recursos en el servidor se ven consumidos
debido al intenso tráfico. En las redes P2P, cada nodo es el que provee los recursos, como es el an-
cho de banda, el espacio de almacenamiento, etc. lo cual se traduce en velocidades de transferencia
mayores. Una red P2P es más robusta en el sentido de que si un nodo falla, los otros nodos no se ven
afectados. Si el nodo que lleva la transferencia de datos se detiene de repente, el mismo contenido
se puede entregar por otros nodos sin tener que esperar hasta que el problema se resuelva. Esto
contrasta con otras arquitecturas de red, donde el fallo en un nodo significa el colapso de toda la
red. El uso de un servidor central como índice de los nodos, pero sin que éste almacene todos los
datos, es una gran ventaja. Las transferencias son más rápidas y más fáciles, dando factibilidad de
encontrar varias fuentes de choque. Sin embargo, estas redes son muy inciertas y es aquí donde este
trabajo tiene su enfoque. Igualmente, cabe hacer una reseña en la que se exponen algunas técnicas
o esquemas relacionados con la propuesta que se va a presentar.
3.1. Esquemas Relacionados
La propuesta [12] Beehive aspira a tener una red "Peer-To-Peer" distribuida con tablas hash
donde se propone una búsqueda bajo el protocolo de Pastry y la búsqueda de información se
realiza por medio de niveles de replicación, así, cada nodo consta de un identificador asignado
aleatoriamente que lo hace único en la red y los niveles de replicación se crean según el acople que
tienen los prefijos de los identificadores. Esto se explica con con figura 3.1, donde el recurso 0121
se replica en su -nodo hogar- E en el nivel 3 y comparte 3 prefijos con éste. Si el modelo analítico
indica que este recurso debe ser replicado a nivel 2, el nodo E pone el recurso en los nodos B e I
con los que comparte 2 prefijos. Ahora, con base en la popularidad del recurso, los nodos del nivel
2 pueden decidir replicar el recurso a nivel 1; así, si el nodo B decide hacer esto, pone copias del
recurso en los nodos A y C con los cuales comparte 1 prefijo y se convierte en nodo de nivel 1.
De igual forma, el nodo E puede replicar el recurso a nivel 1 poniendo copias en los nodos D y F,
y el nodo I, poniendo copias en los nodos G y H [12]. Este esquema propone un desempeño de
búsqueda rápida para peticiones con distribución que sigue la Ley de Potencias con una plataforma
de alto desempeño y aplicaciones de baja latencia, tales como el servicio de nombres de dominios en
redes P2P. Beehive [12] propone, de forma óptima, soluciones indicando los niveles de replicación
apropiados para cada recurso. Además, se trata de evitar el problema de la redundancia en el
protocolo de redes a través de la replicación pro-activa haciendo copias de la información deseada
en torno a la red. Presenta características como: alto desempeño, alta escalabilidad minimizando el
tráfico en la red y reduciendo la carga agregada por nodo con ayuda del menor consumo de ancho
de banda por nodo, y alta adaptabilidad que se ajusta al desempeño del sistema con base en la
distribución de popularidad de los recursos. En este esquema se analiza como medida de desempeño
el número de saltos que requiere un recurso para ser satisfecho, con lo que se obtiene que gracias a
los niveles de replicación, estos saltos disminuyen. Esta propuesta consta de niveles de replicación
en los que se establecen las prioridades para los recursos por medio de sus frecuencias, es decir, los
más comunes se reproducen a un nivel superior y a un mayor número de nodos. Y, por tanto, los
recursos menos frecuentes se replican en un pequeño porcentaje de nodos en el anillo.
En la figura 3.1 se muestra un esquema de la arquitectura mencionada anteriormente.
En la propuesta [13] establece un sistema llamado Sistema de Nombres de Dominio de Co-
operativas (CoDoNS, Cooperative Domain Name System) con la que consigue una búsqueda de
alto rendimiento y resistencia a ataques de denegación de servicio a través de balanceo de cargas
automático, así como con una rápida propagación de las actualizaciones. Esta técnica se aplica a
un anillo P2P distribuido por medio de áreas que tiene ventajas tales como: escalabilidad, descen-
tralización, auto-organización, resistencia y crea un fondo competitivo para el servicio de nombres.
Busca lograr alto desempeño empleando replicación Beehive [12] y pretende ser un respaldo para
el esquema DNS. Esta propuesta pretenede brindar alto desempeño, resistencia a ataques y rápida
36
Fig. 3.1: Esquema Beehive [12]
propagación de las actualizaciones. Además presenta un esquema combinado de redes P2P estruc-
turadas, que mantienen una cooperativa de nodos, con un análisis proactivo del caché.
Trata de una gran cooperativa, donde los nodos comparten el caché, ya que es aquí donde existen
grandes ataques, como causa de denegación de servicio producido por la latencia que provoca
la resolución de consultas y actualización de recursos. El número de popularidades incrementa
exponencialmente en cada nivel. Los nodos del mismo nivel comparten actualizaciones con mensajes
instantáneos. La jerarquización en niveles se hace para hacer eficaz el ancho de banda de la red.
Así, los nodos de cada zona son proporcionales a la popularidad de la misma. Cada nivel tiene
diferente número de clientes, de tamaño y de tasa de actualización. Aquí también se habla de un
nodo hogar en el que se guarda la copia original del recurso, y si este nodo falla, el nodo siguiente
más cercano en el espacio de red automáticamente se convierte en el nuevo nodo hogar. CoDoNS
replica todos los recursos en muchos nodos adyacentes al nodo hogar para evitar la pérdida de datos
debida a fallas en los nodos. Sin embargo, esta propuesta tiene inconvenientes como la dificultad de
administración. Y como ventaja patente, este método hace que los clientes reciban información de
los recursos pedidos en poco tiempo sin causar un tráfico innecesario en la red. Además de contar
con una rápida replicación de recursos en cada uno de los niveles de los que habla la propuesta de
Beehive [12], logrando así una rápida formación del caché de la red con lo