Servidores Raíz DNS

Servidores Raíz DNS

Un servidor raíz (root server en inglés) es un servidor de nombres para la zona raíz del Sistema de nombres de dominio de Internet (DNS). Los servidores de nombres raíz son una parte fundamental de la Internet, ya que son el primer paso en la traducción de (resolver) los nombres de host legibles por humanos en direcciones IP que se utilizan en la comunicación entre los hosts de Internet.

Una combinación de los límites en el DNS y de ciertos protocolos, a saber, como el tamaño de los paquetes no fragmentados en el User Datagram Protocol (UDP), se tradujo en un número limitado de direcciones de los servidores raíz que se pueden acomodar en respuestas a consultas DNS de nombres. Este límite ha determinado el número de instalaciones de servidores de nombres en (actualmente) 13 grupos, para atender las necesidades de toda la Internet pública en el mundo.

Todos los servidores DNS de la red dependen de los servidores raíz y el resto del sistema para realizar su trabajo. Los trece servidores se denominan por las primeras trece letras del alfabeto, y están en manos de 9 organismos y corporaciones diferentes e independientes, principalmente universidades, empresas privadas y organismos relacionados con el ejercito de EEUU.

Aproximadamente la mitad depende de organizaciones públicas estadounidenses.

• Servidor A: Network Solutions, Herndon, Virginia, USA.
• Servidor B: Instituto de Ciencias de la Información de la Universidad del Sur de California, USA.
• Servidor C: PSINet, Virginia, USA.
• Servidor D: Universidad de Maryland, USA.
• Servidor E: NASA, en Mountain View, California, USA.
• Servidor F: Internet Software Consortium, Palo Alto, California, USA.
• Servidor G: Agencia de Sistemas de Información de Defensa, California, USA.
• Servidor H: Laboratorio de Investigación del Ejercito, Maryland, USA.
• Servidor I: NORDUnet, Estocolmo, Suecia.
• Servidor J: (TBD), Virginia, USA.
• Servidor K: RIPE-NCC, Londres, Inglaterra.
• Servidor L: (TBD), California, USA.
• Servidor M: Wide Project, Universidad de Tokyo, Japón.

1.- VeriSign es el root-server A (198.41.0.4). Está ubicado en Dulles (Virginia, EEUU). Es bastante conocida por el «escándalo» de Septiembre de 2003, que intentó establecer todas las peticiones erroneas de un dominio .com o .net a un servicio propio llamado SiteFinder. Se encuentra preparado ya para conexiones con IPv6.

2.- Instituto para la formación científica es el root-server B (192.228.79.201). Está situado en Marina del Rey (California). También está preparado para conexiones IPv6

3.- Cogent Communications es el root-server C (192.33.4.12). Es una multinacional fundada en 1999 situada en Washington.

4.- Universidad de Maryland es el root-server D (128.8.10.90) situado en la ciudad College Park.

5.- Centro de investigación Ames de la NASA es el root-server E (192.203.230.10). El centro de investigación está situado en Silicon Valley (California).

6.- Consorcio de Sistemas de Internet (ISC) es el root-server F (192.5.5.241), que en realidad no es un sólo servidor físico, sino un sistema distribuido de varios servidores DNS a lo largo de diferentes lugares como Ottawa, New York, Madrid, Roma, Paris, Barcelona, Buenos Aires,  hasta 43 ciudades. Fue el primero de los 7 servidores DNS distribuidos existentes.

7.- Departamento de Defensa de EEUU es el root-server G (192.112.36.4) y se encuentra ubicado en la capital de Ohio.

8.- Laboratorio de investigación de la Armada de EEUU es el root-server H (128.63.2.53). También está preparado para conexión vía IPv6

9.-Autonomica/NORDUnet es el root-server I (192.36.148.17). Es otro de los servidores distribuídos que abarca hasta 31 ciudades diferentes (Helsinki, Milán, Londrés, Chicago, Bruselas, entre otros.).

10.-VeriSign tiene un segundo servidor DNS, el root-server J (192.58.128.30). Este, a diferencia del primero, es un servidor distribuido a lo largo de 37 ciudades (Vienna, Miami, Atlanta, Seattle, Tokyo, Seúl, Praga, Madrid).

11.-Centro de coordinación de redes IP europeas es el root-server K (193.0.14.129). Como los anteriores servidores, dispone de una red de distribución (Londres, Amsterdam, Frankfurt, Budapest, Delhi).

12.- Corporación de Internet para la Asignación de Nombres y Números es el root-server L (199.7.83.42). Se basa en un servidor distribuído entre Los Angeles y Miami (Estados Unidos).

13.- WIDE Project es el root-server M (202.12.27.33). Sistema distribuido entre 6 lugares entre los que se encuentran varias ciudades de Tokyo, Seúl, Paris y San Francisco. Está también preparado para IPv6.

Servidores Raíz en México

En México no existen un servidor DNS raíz como tal, sólo existen copias del servidor raíz L (nombres de dominio) y del servidor raíz F. Éstas copias se encuentran ubicadas en la ciudad de Monterrey.

Se estima que aproximadamente un sexto de las consultas originadas en México destinadas a los servidores raíz se quedarán en México debido a las copias instaladas de los servidores mencionados anteriormente.
Referencias:

http://es.wikipedia.org/wiki/Servidor_ra%C3%ADz

Broadcast Storm Control y Spanning-Tree Protocol

Que es una tormenta de Broadcast?

Una tormenta de broadcast es una descripción del marco de comportamiento de las inundaciones que se produce bajo condiciones especiales en una red Ethernet. Durante una tormenta de broadcast las tramas Ethernet se encuentran atrapadas en un bucle sin fin y siguen siendo retransmitidos hasta que el conmutador de red se siente colapsado o el bucle se termina.

El broadcast es un riesgo permanente en nuestra red, ¿porqué?

• Porque inunda la red utilizando ancho de banda innecesariamente.
• Porque insume recursos de los dispositivos que deben procesar este broadcast.
• Porque insume recursos de las terminales y servidores que reciben el broadcast y deben analizarlo.

Adicionalmente, problemas de configuración o fallos de los dispositivos o de las terminales pueden provocar la presencia de montos muy importantes de broadcast en la red que quitan recursos para el procesamiento del tráfico de datos o la operación regular de la red, bajando de modo notable su performance.

Una tormenta de difusión puede consumir suficientes recursos de red con el fin de hacer que la red no puede transportar el tráfico normal.

Causas

Por lo general la causa es un circuito de conmutación en la topología de cableado Ethernet. Como broadcast y multicast se transmiten por medio de interruptores fuera cada puerto, el conmutador o conmutadores retransmitirán repetidamente mensajes de difusión e inundar la red.

En algunos casos, una tormenta de difusión puede ser instigado a los efectos de una denegación de servicio a través de uno de los ataques de amplificación de paquetes, como el ataque pitufo o ataque Fraggle, donde pitufo envía una gran cantidad de tráfico ICMP Echo Pide a una dirección de difusión , con cada paquete de eco ICMP contiene la dirección de origen de la parodia de la máquina víctima. Cuando el paquete falso llega a la red de destino, todas las máquinas de la red responden a la dirección falsa. La solicitud de eco inicial se multiplica por el número de máquinas de la red. Esto genera una tormenta de respuestas al host víctima inmovilización de ancho de banda de red, utilizando recursos de la CPU o, posiblemente, rompiendo la víctima.

En las redes inalámbricas un paquete disociación falsificado con la fuente a la del punto de acceso inalámbrico y enviado a la dirección de difusión puede generar una disociación ataque DOS difusión.

Broadcast Storm Control 

El control de tormentas se configura para el switch como un todo, pero opera por puerto.

El control de tormentas se encuentra inhabilitado por defecto.

La prevención de las tormentas de broadcast mediante el establecimiento de valores demasiado altos o bajos de umbral descarta el tráfico MAC excesivo de broadcast, multicast o unicast. Además, la configuración de valores para elevar umbrales en un switch puede desactivar el puerto.

Supresión de broadcast con Cisco IOS

Los switches Cisco IOS brindan un feature que permite con facilidad limitar la porción de ancho de banda que puede ser ocupada por tráfico de broadcast en cada puerto del switch. Esta función está deshabilitada por defecto. Esta función permite adicionalmente definir el modo en que cada puerto debe manejar el tráfico de broadcast que recibe: se puede descartar el tráfico de broadcast excedente por un tiempo limitado o hasta que el tráfico de broadcast que llega disminuya.

Un ejemplo de cómo configurar esta función en un switch Catalyst 2950:

Switch(config)#interface fastethernet 0/10
Switch(config-if)#storm-control broadcast level 50
Switch(config-if)#storm-control action trap

El primer comando es el único requerido. En esa línea se define el tráfico que se desea limitar (también se puede utilizar para limitar tráfico de multicast o de unicast) y hasta qué nivel se tolera el mismo.

La segunda línea indica la acción que se desea tomar. Si la opción buscada es que el puerto sea inhabilitado completamente, el comando será: storm-control action shutdown. Si no se especifica nada, por defecto, el comando descarta el tráfico de broadcast. También se puede solicitar que envíe un aviso de SNMP a una estación de management.

Spanning tree

En comunicaciones, STP (del inglés Spanning Tree Protocol) es un protocolo de red de nivel 2 del modelo OSI (capa de enlace de datos). Su función es la de gestionar la presencia de bucles en topologías de red debido a la existencia de enlaces redundantes (necesarios en muchos casos para garantizar la disponibilidad de las conexiones). El protocolo permite a los dispositivos de interconexión activar o desactivar automáticamente los enlaces de conexión, de forma que se garantice la eliminación de bucles. STP es transparente a las estaciones de usuario.

Motivación

Los bucles ocurren cuando hay rutas alternativas hacia un mismo destino (sea una máquina o segmento de red). Estas rutas alternativas son necesarias para proporcionar redundancia y así ofrecer una mayor fiabilidad a la red, dado que en caso de que un enlace falle, los otros puede seguir soportando el tráfico de ésta. Los problemas aparecen cuando utilizamos dispositivos de interconexión de nivel de enlace, como un puente de red o un conmutador de paquetes.

Cuando existen bucles en la topología de red, los dispositivos de interconexión de nivel de enlace de datos reenvían indefinidamente las tramas broadcast y multicast, creando así un bucle infinito que consume tanto el ancho de banda de la red como CPU de los dispositivos de enrutamiento. Esto provoca que se degrade el rendimiento de la red en muy poco tiempo, pudiendo incluso llegar a quedar inutilizable. Al no existir un campo TTL (tiempo de vida) en las tramas de capa 2, éstas se quedan atrapadas indefinidamente hasta que un administrador de sistemas rompa el bucle. Un router, por el contrario, sí podría evitar este tipo de reenvíos indefinidos. La solución consiste en permitir la existencia de enlaces físicos redundantes, pero creando una topología lógica libre de bucles. STP calcula una única ruta libre de bucles entre los dispositivos de la red pero manteniendo los enlaces redundantes desactivados como reserva, con el fin de activarlos en caso de fallo.

Si la configuración de STP cambia, o si un segmento en la red redundante llega a ser inalcanzable, el algoritmo reconfigura los enlaces y restablece la conectividad, activando uno de los enlaces de reserva. Si el protocolo falla, es posible que ambas conexiones estén activas simultáneamente, lo que podrían dar lugar a un bucle de tráfico infinito en la LAN.

El árbol de expansión (Spanning tree) permanece vigente hasta que ocurre un cambio en la topología, situación que el protocolo es capaz de detectar de forma automática. El máximo tiempo de duración del árbol de expansión es de cinco minutos. Cuando ocurre uno de estos cambios, el puente raíz actual redefine la topología del árbol de expansión o se elige un nuevo puente raíz.

CONFIGURACION STP

METODO 1, PARA CONFIGURACION DE UN SWITCH COMO RAIZ

Modo de configuracion global:

switch(config)# spanning-tree vlan 1 root primary - Con esta linea sera configurado un switch como distribuidor primario

Si se requiere un secundario:

switch(config)# spanning-tree vlan 1 root secondary

METODO 2, PARA CONFIGURACION DE UN SWITCH COMO RAIZ

switch(config)# spanning-tree vlan 1 priority 32768

PARA VERIFICAR LA CONFIGURACION: 

show spanning-tree: Mostrará un detalle de como esta configurado STP.
This bridge is the root - Esta linea nos indica que ese switch es la raiz.
Priority - Nos indica el numero de la prioridad, y si ha sido asignado a una VLAN.

CONTROL DE STP

Se refiere al conocimiento de como esta funcionando este protocolo para la deteccion de fallas y poder corregirlas a tiempo para no tener afectaciones en la red.

TIEMPOS DE CONVERGENCIA

Los tiempos de convergencia se pueden dar de varias maneras:

- Si se requiere el tiempo de convergencia para un usuario se puede habilitar PORT FAST, lo que hace que se deshabilite spanning tree en el puerto donde es configurado.

- Para evitar que sea deshabilitado STP existen dos modos de convergencia, los cuales se habilitan en puertos de modo truncal:

1) UpLinkFast: El cual opera a nivel de equipo, es decir, se configura en el switch.
2) BackBoneFast: El cual opera y es habilitado a nivel de interfaz, es decir, se habilita en un puerto.

ADMINISTRACION DE STP POR VLAN

PROPIETARIOS DE CISCO

1) PVST

• Utiliza el protocolo de enlace troncal ISL propiedad de CISCO. 
• Cada vlan cuenta con una instancia de spanning tree.
• Tiene la capacidad de balancear la carga de trafico de la capa 2. 
• Incluye las extensiones backbone, uplinkfast y portfast. 

2) PVST +

• Admite ISL y enlace troncal IEEE 802.1q
• Admite las extensiones de STP propiedad de cisco.
• Agrega mejoras en la proteccion de BPDU y en la proteccion de raiz.

3) PVST + rapido

• Basado en el estandar IEEE 802.1w
• Posee convergencia mas veloz que 802.1d.

ESTANDAR IEEE

1) RSTP

• Presentado en 1982, brinda una convergencia mas veloz que 802.1d
• Implementa versiones genericas de las extensiones de STP propiedad de CISCO.
• IEEE incorporo RSTP dentro de 802.1d identificando la especificacion como IEEE 802.1d-2004.

2) MSTP

• Pueden asignarse varias VLAN a una misma instancia de spanning-tree
• Inspirado en el protocolo de spanning tree de multiples instancias (MISTP) de cisco.
• IEEE 802.1q-2003 ahora incluye a MSTP.

Referencias

http://librosnetworking.blogspot.mx/2007/03/administracin-de-trfico-de-broadcast.html
http://docsetools.com/articulos-informativos/article_62977.html
http://programoweb.com/como-evitar-las-tormentas-de-broadcast/
http://es.wikipedia.org/wiki/Spanning_tree
http://ciscoccna3.blogspot.mx/2012/07/stp-spanning-tree-protocol.html