Suscríbete para recibir notificaciones de nuevas publicaciones:

Presentamos el Resolutor de DNS, 1.1.1.1 (no es una broma)

01/04/2018

9 min de lectura

La misión de Cloudflare es ayudar a construir un mejor Internet, y hoy lanzamos nuestro resolutor de DNS, 1.1.1.1: un servicio de DNS recursivo. Con esta oferta, estamos arreglando los cimientos de Internet mediante el desarrollo de un resolutor de DNS público, centrado en la privacidad, más rápido y más seguro. El resolutor de DNS, 1.1.1.1, está disponible públicamente para que todos puedan utilizarlo: es el primer servicio orientado al consumidor que ha lanzado Cloudflare.

Estamos utilizando las siguientes direcciones IPv4 para nuestro resolutor: 1.1.1.1 y 1.0.0.1. Fácil de recordar. APNIC ha proporcionado estas direcciones a Cloudflare para realizar una investigación conjunta y para este servicio. Puede leer más acerca de su trabajo en el blog de APNIC.

El resolutor de DNS, 1.1.1.1, se sirve de la red global Anycast de Cloudflare.

Antecedentes: Un rápido repaso sobre el papel del resolutor en DNS

Nuestros amigos de DNSimple han realizado este increíble tutorial de DNS para que cualquiera pueda sacarse las dudas sobre el funcionamiento de DNS. Explican todo sobre los resolutores, los servidores de nombre raíz y mucho más de un modo muy informativo.

Al resolver un nombre de dominio, una consulta viaja de su sistema final (es decir, un navegador web) a un servicio de DNS recursivo. Si el registro de DNS no está en el caché local del servicio, el recursor consultará la jerarquía DNS autorizada para encontrar la información de la dirección IP que está buscando. El recursor es la parte que desempeña el resolutor de DNS, 1.1.1.1. ¡Tiene que ser rápido y muy seguro estos días!

Objetivos para el resolutor de DNS, 1.1.1.1

Nuestros objetivos con el resolutor público son simples: CloudFlare quiere operar el resolutor público más rápido del planeta a la vez que eleva el estándar de las protecciones de privacidad para los usuarios. Para acelerar el Internet, ya estamos construyendo centros de datos en todo el mundo para reducir la distancia (es decir, la latencia) de los usuarios al contenido. Finalmente, queremos que todos se encuentren a 10 milisegundos de por lo menos una de nuestras ubicaciones.

Solamente en marzo, habilitamos 31 nuevos centros de datos a nivel mundial (Estambul, Reikiavik, Riad, Macao, Bagdad, Houston, Indianápolis, Montgomery, Pittsburgh, Sacramento, México, Tel Aviv, Durban, Port Louis, Cebú, Edimburgo, Riga, Tallin, Vilna, Calgary, Saskatoon, Winnipeg, Tallahassee Jacksonville, Memphis,, Bogotá, Ciudad de Luxemburgo, Chisinau) y, al igual que en todas las otras ciudades en nuestra red, nuevos sitios ejecutan el Resolutor de DNS, 1.1.1.1 desde el primer día.

Nuestra red rápida y altamente distribuida se ha desarrollado para servir a cualquier protocolo y, actualmente, somos el mayor proveedor autorizado de DNS en Internet, una capacidad que han aprovechado más de 7 millones de propiedades de Internet. Además, ya proporcionamos un servicio de anycast a dos de trece de los servidores de nombres raíz. El siguiente paso lógico era proporcionar un servicio DNS recursivo más rápido para los usuarios. Nuestro recursor puede aprovechar los servidores autorizados que están coubicados con nosotros, y así obtener búsquedas más rápidas para todos los nombres de dominio.

A pesar de que DNSSEC asegura la integridad de los datos entre un resolutor y un servidor autoritativo, no protege la privacidad de la «última milla" hacia su parte. El resolutor de DNS, 1.1.1.1, admite ambos estándares emergentes de privacidad DNS: DNS-mediante-TLS, y DNS-mediante-HTTPS. Ambos proporcionan un cifrado de última milla para mantener sus consultas de DNS privadas y sin manipulaciones.

Concientizar a nuestro resolutor sobre de la privacidad

Históricamente, el recursor envía el nombre del dominio completo a cualquier intermediario que encuentre en su camino al DNS raíz o autoritativo. Esto quiere decir que si va a www.cloudflare.com, el servidor raíz y el servidor .com serían consultados con el nombre de dominio completo (es decir, las partes de www, cloudflare y com), a pesar de que los servidores raíz solo tienen que redireccionar el recursivo al punto com (independiente de cualquier otra cosa en el nombre de dominio totalmente cualificado). Esta facilidad de acceso a toda esta información de navegación personal mediante DNS supone una grave brecha de privacidad para muchos. Esto se ha abordado con varios paquetes de software de resolutores, aunque no todas las soluciones se han adaptado o desplegado ampliamente.

El resolutor de DNS, 1.1.1.1, ofrece, desde el primer momento, todos los mecanismos de protección de privacidad propuestos y definidos para su uso entre el resolutor stub y el resolutor recursivo. Para aquellos que no estén familiarizados, un resolutor stub es un componente de su sistema operativo que habla con el resolutor recursivo. Solo con el uso de DNS Query Name Minimisation definido en RFC7816, el resolutor de DNS, 1.1.1.1, reduce la información que se filtra a los servidores DNS intermediarios, como la raíz y los TLD. Eso quiere decir que el resolutor de DNS, 1.1.1.1, envía solo lo suficiente del nombre para que la autoridad indique al resolutor dónde hacer la siguiente pregunta.

El resolutor de DNS, 1.1.1.1, también admite consultas TLS con privacidad habilitada en el puerto 853 (DNS mediante TLS), para que podamos mantener las consultas ocultas de redes intrusas. Además, al ofrecer el protocolo DoH experimental (DNS mediante HTTPS), mejoramos tanto la privacidad como un número de futuras aceleraciones para los usuarios finales, puesto que los navegadores y otras aplicaciones ahora pueden mezclar tráfico DNS y HTTPS en una sola conexión.

Con la caché negativa agresiva de DNS, como se describe en RFC8198, podemos disminuir todavía más la carga en el sistema global de DNS. Esta técnica primero intenta usar la memoria caché negativa del resolutor existente que mantiene la información negativa (o inexistente) a mano por un período de tiempo. Para zonas firmadas con DNSSEC y de los registros de NSEC en caché, el resolutor puede averiguar si el nombre solicitado NO existe sin necesidad de hacer otra consulta. Así que si escribe wwwwwww punto algo y luego wwww punto algo, la segunda consulta bien podría ser respondida con un «no» instantáneo (NXDOMAIN en el mundo DNS). La memoria caché negativa agresiva solo funciona con zonas firmadas de DNSSEC, que incluyen tanto la raíz como 1400 de los 1544 TLD firmados hoy.

Utilizamos la validación de DNSSEC cuando es posible, ya que nos permite asegurarnos de que las respuestas sean exactas y no estén manipuladas. El coste de las verificaciones de firma es bajo, y el ahorro potencial que obtenemos de la caché negativa agresiva lo compensa sobradamente. Queremos que nuestros usuarios confíen en las respuestas que proporcionamos y, por tanto, realizamos todas las comprobaciones posibles para evitar dar malas respuestas a los clientes.

Sin embargo, DNSSEC es implacable. Los errores en la configuración de DNSSEC de parte de operadores de DNS autoritativos pueden hacer irresolubles tales dominios mal configurados. Para tratar con este problema, Cloudflare configurará «Anclajes de confianza negativa» en los dominios con errores DNSSEC investigados y detectados, y los eliminará una vez que la configuración sea rectificada por operadores autoritativos. Esto limita el impacto de los dominios DNSSEC rotos al deshabilitar temporalmente la validación de DNSSEC para un determinado dominio mal configurado, lo que restaura el acceso a los consumidores finales.

¿Cómo lo desarrollamos?

Inicialmente, pensamos en desarrollar nuestro propio resolutor, pero este enfoque se rechazó debido a la complejidad y a las consideraciones de go-to-market. Entonces examinamos todos los resolutores de código abierto del mercado; de esta larga lista nos quedamos con dos o tres que serían adecuados para cubrir la mayor parte de los objetivos del proyecto. Al final, decidimos construir el sistema alrededor de Knot Resolver de CZ NIC. Es un resolutor moderno que se lanzó originalmente hace aproximadamente dos años y medio. Al seleccionar Knot Resolver, también aumentamos la diversidad de software. El punto crítico fue que tenía más características principales de las que queríamos, con una arquitectura modular similar a OpenResty. Knot Resolver se encuentra en pleno uso y desarrollo.

Cosas interesantes que hacemos y nadie más hace

Las recientes características avanzadas que queríamos eran:

  • Minimización de consulta RFC7816,
  • DNS-mediante-TLS (Seguridad de la capa de transporte) RFC7858,
  • Protocolo DNS-mediante-HTTPS DoH,
  • Respuestas negativas agresivas RFC8198,

Pequeño aviso: el principal desarrollador original de Knot Resolver, Marek Vavruša, ha estado trabajando en el equipo de DNS de Cloudflare durante más de dos años.

Cómo hacer que nuestro resolutor sea más rápido

Hay muchos factores que afectan la velocidad de un resolutor. La primera y principal es: ¿puede responder desde la caché? Si puede, entonces el tiempo de respuesta es solo el tiempo de ida y vuelta para un paquete del cliente al resolutor.

Cuando un resolutor necesita una respuesta de una autoridad, las cosas se vuelven un poco más complicadas. Un resolutor tiene que seguir la jerarquía DNS para resolver un nombre, lo que significa que tiene que hablar con múltiples servidores autoritativos a partir de la raíz. Por ejemplo, nuestro resolutor en Buenos Aires, Argentina, necesitará más tiempo para seguir una jerarquía DNS que nuestro resolutor en Frankfurt, Alemania, debido a su proximidad a los servidores autorizados. Para tratar con este problema, rellenamos automáticamente nuestra caché, fuera de banda, para nombres populares, que significa que cuando entra una consulta, las respuestas se pueden traer desde la caché, lo cual es mucho más rápido. En las próximas semanas, publicaremos blogs en relación con algunas de las otras cosas que estamos haciendo para mejorar y acelerar el resolutor, incluida nuestra caché rápida.

Un problema con nuestra amplia red es que la proporción de acierto de la caché es inversamente proporcional al número de nodos configurados en cada centro de datos. Si solo hubiera un nodo en un centro de datos que esté cerca suyo, podría estar seguro de que si pide dos veces la misma consulta, obtendría una respuesta de caché la segunda vez. Sin embargo, como hay cientos de nodos en cada uno de nuestros centros de datos, puede obtener una respuesta sin caché pagando el precio de latencia por cada solicitud. Una solución común es poner un equilibrador de carga de caché delante de todos sus resolutores, lo que desgraciadamente presenta un punto único de fallo. Nosotros no hacemos puntos únicos de fallo.

En lugar de depender de una caché centralizada, el resolutor de DNS, 1.1.1.1, utiliza una innovadora caché distribuida, de la que hablaremos más tarde en el blog.

Política de datos

Este es el trato: nunca jamás almacenamos las direcciones IP del cliente, y solo utilizamos nombres de consulta para cosas que mejoran el rendimiento del resolutor de DNS (como rellenar automáticamente todas las cachés en base a los dominios populares en una región o después de la ofuscación y la investigación de APNIC).

CloudFlare nunca almacenará información en sus registros que identifique a un usuario final, y todos los registros que recopile nuestro resolutor público se eliminarán en 24 horas. Seguiremos cumpliendo con nuestra política de privacidad y nos aseguraremos de que los datos de los usuarios no se vendan a anunciantes ni se utilicen para captar consumidores.

La configuración

¡Vea https://1.1.1.1/ porque es muy simple!

Acerca de esas direcciones

Agradecemos a APNIC, nuestro socio, por las direcciones IPv4 1.0.0.1 y 1.1.1.1 (de las que todo el mundo reconoce que son increíblemente fáciles de recordar). Sin sus años de investigación y pruebas, sería imposible poner estas direcciones en producción. Con todo, todavía tenemos un largo camino por recorrer. Siga atento para enterarse de nuestras aventuras con esas IP en futuros blogs.

Para IPv6, hemos elegido 2606:4700:4700::1111 y 2606:4700:4700::1001 para nuestro servicio. No es tan fácil conseguir buenas direcciones de IPv6; sin embargo, hemos elegido una dirección que solo utiliza dígitos.

Pero, ¿por qué utilizar direcciones fáciles de recordar? ¿Qué tienen de especial los resolutores públicos? A pesar de que utilizamos nombres para casi todo lo que hacemos, se necesita dar ese primer paso en el proceso, y ahí es donde entran en juego estos números. Necesitamos un número ingresado en cualquier ordenador o dispositivo conectado que esté utilizando para encontrar un servicio de resolutor.

Cualquiera en internet puede utilizar el resolutor público. Para ver cómo hacerlo, visite https://1.1.1.1/ y haga clic en EMPEZAR.

¿Por qué anunciarlo el primero de abril?

Para la mayor parte del mundo, el domingo es 01/04/2018 (en EE. UU., el día y el mes se invierten: 04/01/2018). ¿Ve el 4 y el 1? Nosotros sí lo vimos y por eso anunciamos hoy 1.1.1.1. ¡Cuatro unos! Si le ayuda a recordar 1.1.1.1, ¡entonces es algo bueno!

Claro, también es el día de los inocentes de abril, y para una buena parte de la gente es un día de chistes, tonterías o bromas inofensivas. Esto no es ningún chiste, ni broma, ni tontería. ¡Esto es el resolutor de DNS, 1.1.1.1 ! Sígalo en #1dot1dot1dot1

Etiquetado con DNS, 1.1.1.1, Privacidad, Resolutor, Noticias de productos

Protegemos redes corporativas completas, ayudamos a los clientes a desarrollar aplicaciones web de forma eficiente, aceleramos cualquier sitio o aplicación web, prevenimos contra los ataques DDoS, mantenemos a raya a los hackers, y podemos ayudarte en tu recorrido hacia la seguridad Zero Trust.

Visita 1.1.1.1 desde cualquier dispositivo para empezar a usar nuestra aplicación gratuita y beneficiarte de una navegación más rápida y segura.

Para saber más sobre nuestra misión para ayudar a mejorar Internet, empieza aquí. Si estás buscando un nuevo rumbo profesional, consulta nuestras ofertas de empleo.
Product News (ES)Privacy (ES)EspañolDNS (ES)1.1.1.1 (ES)

Síguenos en X

Cloudflare|@cloudflare

Publicaciones relacionadas