Introducción
Red.es tiene encomendada la Autoridad de Asignación de los dominios de nivel superior geográfico “.es” (en adelante, ccTLD, del inglés, “country code Top Level Domain”), así como, las extensiones de segundo nivel “.com.es”, “.nom.es”, “.edu.es”, “.gob.es” y “.org.es”.
¿Cómo es la arquitectura y el funcionamiento del protocolo DNS?
El acrónimo DNS viene de “Domain Name System”, uno de los protocolos más usados en internet y en cualquier red IP en general. Una de sus funciones principales consiste en proporcionar direcciones IP correspondientes a nombres DNS.
Por ejemplo, cuando un usuario teclea en su navegador web https://www.dominios.es, en primer lugar y de forma transparente, se produce una consulta DNS para hallar la dirección IP correspondiente. Este proceso de resolución DNS es necesario porqué la comunicación siempre se va a realizar con direcciones IP.
El DNS público es jerárquico y distribuido. Los servidores DNS de cada dominio tienen información detallada de su propio dominio e información de los servidores de nombres NS (Name Servers) autoritativos de los dominios “hijo”. A esta lista de NS asociados a los dominios “hijo” también se le denomina delegaciones. A continuación, una representación simplificada del árbol DNS de internet:
Ejemplos concretos:
- Los servidores root (primer nivel) son gestionados a nivel mundial por la organización IANA y tienen información de los NS asociados de todos sus dominios “hijo”, también denominado de segundo nivel, ya que “cuelgan” directamente del primer nivel. Se trata de los ccTLD’s (“.es”, “.fr”, “.pt”, etc.), los gTLD’s (del inglés, “generic Top Level Domain”, como por ejemplo, “.com”, “.net”, etc.), etc.
- Los servidores DNS del dominio “.es” tienen información de los NS de todos los dominios hijo del “.es”. Por ejemplo: “dominios.es”, “nic.es”, “rediris.es”, etc.
- Los servidores DNS del dominio “dominios.es” tienen toda la información detallada de su propio dominio. Por ejemplo, tendrán información sobre las direcciones IPv4 e IPv6 correspondientes al nombre www.dominios.es, de sus registros tipo NS, etc.
Los usuarios, en general, tienen configurados dos servidores DNS, uno primario y otro secundario. Este último solamente se va a utilizar en caso de que el primario no funcione o no sea alcanzable. A este tipo de servidores DNS se les denomina “resolvers”. Dan respuestas “no autoritativas” y guardan información en caché, durante el tiempo de vida marcado por el TTL (Time To Live) o acorde a políticas definidas. Si la respuesta para una consulta recibida del cliente no está en caché, realizan un proceso de iteración, consultando en primer lugar a los servidores root, después a los servidores de segundo nivel que han obtenido en la primera consulta, y así sucesivamente bajando por el árbol DNS hasta conseguir la respuesta buscada, proporcionada por un servidor DNS autoritativo del dominio consultado. Una vez obtenida la respuesta, la guardan en caché un tiempo determinado y le contestan al cliente.
Existen varias implementaciones de software para servidores DNS. Las más comunes en entornos de TLD son:
- BIND. https://www.isc.org/bind/
- KNOT. https://www.knot-dns.cz/
- NSD. https://nlnetlabs.nl/projects/nsd/about/
- Otros.
Tradicionalmente, el tráfico DNS no viaja cifrado. Con el objetivo de proporcionar autenticación del origen de datos, integridad de los datos y “prueba de no existencia de datos”, existe un conjunto de protocolos denominado DNSSEC que básicamente consiste en añadir una firma en las respuestas DNS. Dicha firma puede ser validada por los “resolvers” a través de una cadena de confianza. El requisito fundamental para esta validación es que todos los dominios “padre” estén firmados. El uso de DNSSEC ayuda además a mitigar ciertos tipos de ataques.
¿Por qué es tan importante el DNS como servicio esencial?
Dado que la mayoría (por no decir todos) los accesos a aplicaciones informáticas se realizan a través de nombre DNS, es evidente que el servicio DNS es crítico. Por ejemplo, a pesar de que un sitio web se encuentre plenamente operativo, en el caso de que la resolución DNS no funcione, el sitio web será inalcanzable por los usuarios. Algunas posibles causas de esto podrían ser: resolución incorrecta o no existente, ninguno de los servidores DNS autoritativos del dominio están operativos, problema en las delegaciones definidas en el dominio “padre”, claves DNSSEC incorrectas o caducadas, etc.
El dominio “.” (root) es el más crítico de todos. Si fallaran todos los servidores autoritativos de dicho dominio, una vez que se agotara el tiempo de caché, ningún “resolver” podría obtener las delegaciones a NS de dominios de segundo nivel. Un fallo en todos los servidores DNS de un dominio de segundo nivel (por ejemplo, el “.es”) podría afectar a todos los dominios “hijo” del “.es”, y así sucesivamente. Cuanto más arriba se esté en la jerarquía, el posible impacto es mayor.
La normativa europea NIS2 (Network and Information Security), cataloga el servicio DNS ofrecido por los TLD’s como un servicio esencial de internet, y establece una serie de requerimientos de obligado cumplimiento y otros de cumplimiento recomendado.
Directive - 2022/2555 - EN - EUR-Lex (europa.eu)
La normativa cubre muchos aspectos, tales como:
- Cumplimiento de normativas ISO 27001
- Auditorías internas periódicas
- Gestión de ciberseguridad
- Calidad del dato
- Autenticación multifactorial
- Protecciones para evitar cambios no autorizados en los datos de los dominios
¿Qué conceptos técnicos están asociados al protocolo DNS?
A parte de lo comentado en el apartado “¿Cómo es la arquitectura y el funcionamiento del protocolo?”, a continuación, se explican brevemente algunos acrónimos y conceptos alrededor del término DNS:
- FQDN (Fully Qualified Domain Names): Un nombre FQDN está compuesto por un “hostname”, un punto, y el “domain_name”. Ejemplo: el hostname “www” junto con el nombre de dominio “dominios.es” forman el FQDN “www.dominios.es.”, que es el nombre que se debe utilizar para realizar una consulta DNS.
- NS (Name Server): Servidor autoritativo para un determinado dominio DNS. Tal como se ha comentado anteriormente, los servidores autoritativos (primarios o secundarios) contienen información local en sus ficheros de zona de los dominios que albergan y delegaciones hacia dominios “hijo” (o subdominios). Para resolver las consultas DNS, los servidores autoritativos no necesitan preguntar a ningún otro servidor DNS. Además, en el caso de existir subdominios firmados con DNSSEC, contendrán también unos registros llamados DS (ver siguiente punto)
- RR (Resource Records): Es el nombre genérico que reciben los diferentes tipos de registros en un dominio DNS, que podemos encontrar en su fichero de zona correspondiente. El fichero de zona es un fichero de texto donde se define el contenido. Hay muchos tipos de registros, los más comunes son:
o NS. Name Server. Mandatorio. Comentado anteriormente.
o A. Define la(s) dirección(es) IPv4 asociadas a un host.
o AAAA. Equivalente al tipo A pero con IPv6.
o SOA. Start of Authority. Mandatorio. Define parámetros globales de la zona DNS tales como el Serial (número de versión), Refresh y Retry (son valores que usan otros servidores secundarios para determinar la frecuencia de refresco), Expire, y el tiempo de caché negativa (asociados a registros no existentes).
o CNAME. Canonical Name. Define un alias. Útil para asociar la resolución de un registro con otro.
o RRSIG. Resource Record Signature. Son las firmas DNSSEC asociadas a los distintos grupos de RR.
o DNSKEY. Claves DNSSEC ZSK (Zone Signing Key) y KSK (Key Signing Key).
o DS. Delegation Signer. Es un “hash” de la KSK de un dominio “hijo” firmado con DNSSEC.
o MX. Define servidores de correo.
o PTR. Pointer. En zonas DNS inversas se usan este tipo de registros para asociar un nombre DNS a una dirección IP (Al revés de lo que se define en los registros A).
- Servidor Primario: Es el único servidor donde se pueden realizar cambios. Lo más común es que este servidor esté en modo oculto, es decir, no accesible directamente desde internet.
- Servidor Secundario: Obtiene una copia del fichero de zona del servidor primario, o desde otro servidor secundario, y la va actualizando al recibir notificaciones o bien, al superarse el tiempo de “Refresh” del SOA. Un servidor secundario puede dar servicio a pesar de que no reciba actualizaciones de zona durante el tiempo de “Expire” definido en el registro SOA.
- Notify: Notificaciones que un servidor primario o secundario envía a otros servidores DNS cuando ha obtenido una nueva versión del fichero de zona.
- XFR (AXFR y IXFR): transferencias de zona DNS. Pueden ser incrementales (IXFR) o bien absolutas (AXFR)
- Recursividad: Permite resolver consultas DNS para nombres de dominios para los cuales el servidor no es autoritativo. En este caso, el servidor realizará iteración (usando sus “root hints”) o “forwarding” hacia otros servidores. En el caso de los servidores autoritativos de un TLD en general, la recursividad siempre está deshabilitada, por lo tanto, este tipo de servidores solamente pueden responder a consultas DNS para los dominios que tengan definidos y posean un fichero de zona válido.
- Iteración y Recursividad: cuando los clientes realizan peticiones DNS recursivas contra su DNS primario, esperan recibir la respuesta final desde dicho servidor. El DNS recursivo (también llamado resolver), en caso de ser necesario, realizará consultas DNS iterativas hasta conseguir la resolución IP buscada. Obtendrá además el TTL (Time to Live) durante el cual la respuesta se puede considerar válida. Una vez obtenida, responderá al cliente (con la IP y el TTL asociado) y puede guardar la resolución en caché durante el tiempo marcado en el TTL recibido. El cliente final también puede guardar la resolución IP en caché local.
- BGP (Border Gateway Protocol): es un protocolo de enrutamiento utilizado para intercambiar información de enrutamiento entre sistemas autónomos (AS) en Internet. Un sistema autónomo es un conjunto de direcciones IP y redes que están bajo el control de una única entidad, como un proveedor de servicios de Internet (ISP) o una organización.
- SOC (Centro de Operaciones de Seguridad): es una unidad dentro de una organización que se encarga de monitorear, detectar, responder y gestionar incidentes de seguridad cibernética. El SOC está compuesto por un equipo de profesionales de la seguridad que utilizan diversas herramientas y tecnologías para proteger la infraestructura de TI de la organización.
Robustez, Seguridad y Confiabilidad
¿Cómo es la arquitectura Anycast de Red.es?
Con el fin de dar robustez, seguridad y confiabilidad al entorno DNS del ccTLD “.es”, se despliegan 4 NS (Name Servers) que se corresponden a su vez con las delegaciones definidas en el dominio root según https://www.iana.org/domains/root/db/es y que son los servidores autoritativos del dominio “.es”.
A su vez, cada uno de estos NS está compuesto por varios nodos que, de forma transparente a los clientes, dan servicio. En otras palabras, desde internet solo se observa una IPv4 y otra IPv6 para cada uno de los NS, pero realmente por detrás puede haber varios servidores atendiendo consultas DNS.
En el caso de “a.nic.es” existe un balanceador de tráfico que reparte las peticiones sobre dos servidores.
Los otros tres NS son direcciones IP anycast publicadas a internet por 3 proveedores de servicio DNS anycast distintos. Cada una de esas direcciones IP se publica desde diferentes zonas del mundo, teniendo varios nodos en cada una de las regiones. El total de nodos, sumando los tres proveedores, supera los 120, cubriendo todos los continentes.
Este tipo de arquitectura conlleva principalmente tres ventajas:
- Alto grado de resiliencia ante fallos de algunos nodos.
- Mejores tiempos de respuesta. El tráfico llega a los nodos más cercanos en términos de routing BGP, por lo que esto se traduce en mejores tiempos de respuesta.
- Protección ante ataques de denegación de servicio (DoS). El hecho tener el servicio tan distribuido hace que sea muy difícil atacarlo en su totalidad.
Referente a las medidas de protección ante ataques DoS, cada uno de los proveedores externos posee sus mecanismos de protección, tales como divergencia de tráfico hacia Scrubbing Centers donde se pueda limpiar el tráfico, y configuraciones de “ratelimit” en los propios servidores DNS. En el caso de los nodos ubicados en Red.es, se tienen contratados mecanismos AntiDoS con los operadores de internet, se implementan “ratelimits” en los propios servidores DNS, y el SOC puede detectar anomalías de tráfico con la información recopilada en las sondas de red.
A continuación, un par de diagramas de dos de los proveedores anycast que nos pueden dar una idea de la cobertura global del servicio DNS:
https://www.pch.net/services/anycast
DENIC Anycast Nodes
El software usado en los servidores propios de Red.es es BIND. Los proveedores anycast disponen de nodos por lo menos en BIND y KNOT. Por lo tanto, se tiene diversificación de software para dar el servicio DNS.
¿Hablamos del DNSSEC?
Tal como se comentado anteriormente, DNSSEC aporta:
- autenticación del origen de datos.
- integridad de los datos.
- “prueba de no existencia de datos”.
Los dos primeros puntos se consiguen con los registros tipo RRSIG, que son firmas generadas con la clave ZSK (Zone Signing Key). El tercer punto se consigue con los registros tipo NSEC o NSEC3.
A su vez, existe otra clave denominada KSK (Key Signing Key) que firma a la clave ZSK. Para establecer la cadena de confianza, se genera un “hash” de la KSK, llamado DS (Delegation Signer) que se publica en el dominio “padre”. En este caso, es la zona root gestionada por IANA.
Rotación de claves, también llamado rollover.
- Clave ZSK. Se rota de forma más frecuente, debido a que los algoritmos de cifrado suelen ser menos fuertes, permitiendo mayor rendimiento en el firmado. El registro es autónomo en esta operación.
- Clave KSK. Se utilizan algoritmos de encriptación más fuertes y por lo tanto, el periodo de rotación puede ser más alto (2 años). Requiere la publicación del nuevo registro DS en IANA y posteriormente el borrado del antiguo.
La orquestación de todo el firmado DNSSEC se realiza con el software OpenDNSSEC, quien a su vez está enlazado con un hardware criptográfico de alto rendimiento (HSM) donde se almacenan las claves y se generan las firmas RRSIG. OpenDNSSEC se encarga de controlar el tiempo de vida de las firmas generadas para los distintos grupos de RR, y generar las nuevas firmas (RRSIG) antes de que expiren las antiguas. Un registro RRSIG tiene un tiempo de validez determinado. Por ejemplo, usando la herramienta “dig” podemos realizar una consulta de tipo NS para el dominio “.es” al DNS recursivo de Google (8.8.8.8). En la consulta le añadimos la opción “+dnssec” para que nos devuelva también el registro RRSIG. En este registro, además de la firma, se incluyen las fechas de validez y el identificador de clave con la cual se ha generado la firma:
¿Cómo se valida el DNSSEC?
En el caso de que un dominio esté firmado, los DNS Resolvers pueden validar las firmas, gracias a la cadena de confianza. Los dominios “padre” poseen un registro DS del dominio “hijo” firmado con la clave DNSSEC del dominio “padre”. Así hasta llegar a los root, en quien todos confían (trust anchor). En la anterior ilustración se puede observar el flag “ad” (Authentic Data). Esto significa que el resolver ha validado correctamente la cadena de confianza.
Existen otras herramientas gráficas como “dnsviz” que pueden ayudar a comprobar el estado de salud y coherencia de diversos parámetros de un determinado dominio de una forma sencilla. Ver, por ejemplo: https://dnsviz.net/d/es/dnssec/ para validar el dominio “.es”
Mejora continua del servicio
¿Cuándo se producen las actualizaciones de software y cómo es el soporte oficial?
Regularmente se realizan actualizaciones de los diferentes sistemas operativos y del software cuando aparecen nuevas versiones estables, o bien se identifica alguna vulnerabilidad que requiere la aplicación de algún parche.
¿Cuáles son las mejoras en la arquitectura del servicio?
Se utiliza un modelo de desarrollo continuo, con metodología CI/CD, para cubrir nuevos requerimientos o corregir fallos detectados y se dispone de tres entornos: PRE, DEMO y PRO. Cualquier nuevo desarrollo debe pasar por PRE y DEMO antes de aplicarse en PRO.
Por otro lado, diversos proyectos están en curso:
- Nuevo servicio RDAP (Registration Data Access Protocol). Servicio basado en protocolo seguro y con interfaz API. Este servicio va a ser el sucesor de WHOIS43.
- Optimización del proceso de generación de zona y aumento de la frecuencia de su ejecución.
- Mejoras en el servicio de DNS Secundario para dominios “.es”.
- Servicio de DNS secundario para otros TLD’s y convenios de colaboración recíproca.
- Anycast propio y futura ampliación de nodos.
- Evaluación de opciones para la diversificación de software.
¿Cuáles son las mejoras en la monitorización?
En la actualidad se tienen diversas fuentes de información y diversas herramientas de monitorización. El objetivo principal es mejorar la visibilidad y gestión proactiva del servicio. Para ello, se está en proceso de implementación de:
- Recolección y centralización de diferentes fuentes de información.
- Correlación de datos.
- Generación de nuevas métricas del servicio DNS.
- Uso de nuevas herramientas avanzadas como ENTRADA