Damos la bienvenida al servicio de Cloudflare en las direcciones 1.1.1.1 y 1.0.0.1, ¡o 'la estantería de DNS públicos ha llegado!'

Damos la bienvenida al servicio de Cloudflare en las direcciones 1.1.1.1 y 1.0.0.1, ¡o 'la estantería de DNS públicos ha llegado!'

 

Empresa Cloudflare ha presentado DNS públicos en las direcciones:

 

  • 1.1.1.1
  • 1.0.0.1
  • 2606:4700:4700::1111
  • 2606:4700:4700::1001

 

Se afirma que se utiliza una política de «Privacy first», por lo que los usuarios pueden estar tranquilos sobre el contenido de sus solicitudes.

 

El servicio es interesante porque, además de un DNS convencional, ofrece la posibilidad de utilizar tecnologías DNS-over-TLS y DNS-over-HTTPS, lo que dificultará que los proveedores escuchen sus solicitudes y recojan estadísticas, gestionen publicidad. Cloudflare afirma que la fecha de anuncio (1 de abril de 2018, o 04/01 en la notación estadounidense) fue elegida por una razón: ¿en qué otro día del año se puede presentar «cuatro unidades»?

Dado que la audiencia de Habr está tecnológicamente capacitada, colocaré la sección tradicional de «¿para qué sirve el DNS?» al final del post, y aquí presentaré cosas más prácticas:

 

¿Cómo utilizar el nuevo servicio?

 

Lo más sencillo es indicar las direcciones DNS mencionadas anteriormente en su cliente DNS (o como upstream en la configuración de su servidor DNS local utilizado)servidores. ¿Tiene sentido reemplazar los valores habituales de los DNS de Google (8.8.8.8, etc.), o los menos comunes de los servidores DNS públicos de Yandex (77.88.8.8 y similares) por los servidores de Cloudflare? Esa decisión queda en sus manos, pero a favor del novato está el gráfico de velocidades de respuesta, según el cual Cloudflare trabaja más rápido que todos los competidores (para aclarar: las mediciones fueron realizadas por un servicio externo, y la velocidad puede diferir para un cliente específico).

 

Damos la bienvenida al servicio de Cloudflare en las direcciones 1.1.1.1 y 1.0.0.1, ¡o 'la estantería de DNS públicos ha llegado!'

 

Mucho más interesante es el trabajo con los nuevos modos, en los cuales la solicitud se envía a través de servidor una conexión cifrada (la respuesta se devuelve a través de la misma), mencionadas DNS-over-TLS y DNS-over-HTTPS. Desafortunadamente, «de fábrica» no son compatibles (los autores creen que es «por ahora»), pero no es difícil organizarlas en su software (o incluso en su hardware):

 

DNS over HTTPs (DoH)

 

Como se deduce del nombre, la comunicación se lleva a cabo sobre un canal HTTPS, lo que implica

 

  1. la existencia de un punto de aterrizaje (endpoint) — que se encuentra en la dirección https://cloudflare-dns.com/dns-query, y
  2. un cliente que sepa enviar solicitudes y recibir respuestas.

 

Las solicitudes pueden ser en formato DNS Wireformat, definido en RFC1035 (enviarse mediante métodos HTTP POST y GET), o en formato JSON (se utiliza el método HTTP GET). Personalmente, la idea de hacer consultas DNS a través de peticiones HTTP me pareció inesperada, pero hay un fondo racional en ello: tal consulta pasará muchos sistemas de filtrado de tráfico, analizar las respuestas es bastante simple, y formar las solicitudes es aún más fácil. La seguridad es responsabilidad de las bibliotecas y protocolos habituales.

 

Ejemplos de solicitudes, directamente de la documentación:

 

Solicitud GET en formato DNS Wireformat

 

$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Usando HTTP2, el servidor soporta uso múltiple
* El estado de conexión cambió (HTTP/2 confirmado)
* Copiando datos de HTTP/2 en el buffer de conexión después de la actualización: len=0
* Usando ID de Stream: 1 (manejador fácil 0x7f968700a400)
GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
Accept: */*

* El estado de conexión cambió (¡MAX_CONCURRENT_STREAMS actualizado!)
HTTP/2 200
date: Fri, 23 Mar 2018 05:14:02 GMT
content-type: application/dns-udpwireformat
content-length: 49
cache-control: max-age=0
set-cookie: __cfduid=dd1fb65f0185fadf50bbb6cd14ecbc5b01521782042; expires=Sat, 23-Mar-19 05:14:02 GMT; path=/; domain=.cloudflare.com; HttpOnly
server: cloudflare-nginx
cf-ray: 3ffe69838a418c4c-SFO-DOG

{ [49 bytes de datos]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* La conexión #0 al host cloudflare-dns.com se mantuvo intacta
0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77
0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8
0000030 22
0000031

 

Solicitud POST en formato DNS Wireformat

 

$ echo -n 'q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB' | base64 -D | curl -H 'Content-Type: application/dns-udpwireformat' --data-binary @- https://cloudflare-dns.com/dns-query -o - | hexdump

{ [49 bytes de datos]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* La conexión #0 al host cloudflare-dns.com se mantuvo intacta
0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77
0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8
0000030 22
0000031

 

Lo mismo, pero utilizando JSON

 

$ curl 'https://cloudflare-dns.com/dns-query?ct=application/dns-json&name=example.com&type=AAAA'

{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [
    {
      "name": "example.com.",
      "type": 1
    }
  ],
  "Answer": [
    {
      "name": "example.com.",
      "type": 1,
      "TTL": 1069,
      "data": "93.184.216.34"
    }
  ]
}

 

Es evidente que rara vez (si es que alguno) de los enrutadores domésticos puede trabajar así con DNS, pero eso no significa que el soporte no pueda aparecer mañana — además, lo interesante es que aquí podríamos implementar el trabajo con DNS en nuestra aplicación (como ya se propone hacer Mozilla, justo en los servidores de Cloudflare).

 

DNS sobre TLS

 

Por defecto, las solicitudes DNS se transmiten sin cifrado. DNS sobre TLS es una manera de enviarlas a través de una conexión segura. Cloudflare soporta DNS sobre TLS en el puerto estándar 853, como se prescribe. RFC7858. Se utiliza un certificado emitido para el host cloudflare-dns.com, con soporte para TLS 1.2 y TLS 1.3.

 

La conexión y el funcionamiento del protocolo se realizan aproximadamente de la siguiente manera:

 

  • Antes de establecer la conexión, el cliente DNS guarda el hash SHA256 del certificado TLS de cloudflare-dns.com codificado en base64 (conocido como SPKI).
  • El cliente DNS establece una conexión TCP con cloudflare-dns.com:853.
  • El cliente DNS inicia el procedimiento de negociación TLS.
  • Durante el proceso de negociación TLS, el host cloudflare-dns.com presenta su certificado TLS.
  • Una vez que se establece la conexión TLS, el cliente DNS puede enviar solicitudes DNS a través del canal seguro, lo que previene el espionaje y la suplantación de solicitudes y respuestas.
  • Todas las solicitudes DNS enviadas a través de una conexión TLS deben cumplir con la especificación de enviar DNS sobre TCP..

 

Ejemplo de una solicitud a través de DNS sobre TLS:

 

$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com
;; DEBUG: Consultando por owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, importados 170 certificados del sistema
;; DEBUG: TLS, recibida jerarquía de certificados:
;; DEBUG:  #1, C=US,ST=CA,L=San Francisco,O=Cloudflare, Inc.,CN=*.cloudflare-dns.com
;; DEBUG:      PIN SHA-256: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA
;; DEBUG:      PIN SHA-256: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw=
;; DEBUG: TLS, saltando verificación de PIN de certificado
;; DEBUG: TLS, El certificado es de confianza.
;; Sesión TLS (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 58548
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; SECCIÓN PSEUDO EDNS:
;; Versión: 0; flags: ; tamaño UDP: 1536 B; ext-rcode: NOERROR
;; PADDING: 408 B

;; SECCIÓN DE PREGUNTAS:
;; example.com.             IN  A

;; SECCIÓN DE RESPUESTAS:
example.com.            2347    IN  A   93.184.216.34

;; Recibido 468 B
;; Tiempo 2018-03-31 15:20:57 PDT
;; Desde 1.1.1.1@853(TCP) en 12.6 ms

 

Esta opción parece más adecuada para servidores DNS locales que atienden las necesidades de una red local o de un solo usuario. Sin embargo, el soporte para el estándar no es muy bueno, pero - ¡esperemos!

 

Dos palabras de aclaración sobre de qué se trata

 

La abreviatura DNS se descompone como Dominio Name Service (así que decir «servicio DNS» es un poco redundante, la abreviatura ya incluye la palabra «servicio»), y se utiliza para resolver una tarea simple: entender qué dirección IP corresponde a un nombre de host específico. Cada vez que una persona hace clic en un enlace o introduce en la barra de direcciones del navegador una dirección (digamos, algo como «https://habrahabr.ru/post/346430/«), la computadora del usuario intenta entender a qué servidor debe enviar la solicitud para obtener el contenido de la página. En el caso de habrahabr.ru, la respuesta del DNS contendrá la dirección IP del servidor web: 178.248.237.68, y luego el navegador intentará conectarse al servidor con la dirección IP indicada.

 

A su vez, el servidor DNS, al recibir la consulta «¿cuál es la dirección IP del host con el nombre habrahabr.ru?», determina si tiene información sobre el host especificado. Si no, envía consultas a otros servidores DNS en el mundo y, paso a paso, intenta averiguar la respuesta a la pregunta planteada. Como resultado, al encontrar la respuesta final, los datos encontrados se envían al cliente que aún los está esperando, además de ser guardados en la caché del mismo servidor DNS, lo que permitirá responder a una pregunta similar mucho más rápido la próxima vez.

 

Un problema común es que, por un lado, los datos de las consultas DNS se transmiten en texto claro (lo que permite a todos los que tienen acceso al flujo de tráfico extraer las consultas DNS y las respuestas recibidas, y luego analizarlas para sus propios fines; esto permite una segmentación publicitaria con precisión para el cliente DNS, lo cual no es poco). Por otro lado, algunos proveedores de Internet (sin señalar con el dedo, pero no los más pequeños) tienden a mostrar anuncios en lugar de la página solicitada (esto se implementa de manera bastante simple: en lugar de la dirección IP indicada para la consulta del nombre de host habranabr.ru, se devuelve aleatoriamente la dirección del servidor web del proveedor, donde se muestra una página con anuncios). En tercer lugar, existen proveedores de acceso a Internet que implementan mecanismos para cumplir con las solicitudes de bloqueo de ciertos sitios, mediante la sustitución de las respuestas DNS correctas para las direcciones IP de los recursos web bloqueados por la dirección IP de su servidor, que contiene páginas de aviso (como resultado, el acceso a tales sitios se complica notablemente), o por la dirección de su servidor proxy, que lleva a cabo filtrados.

 

Aquí, probablemente, deberíamos colocar una imagen del sitio http://1.1.1.1/, que sirve para describir la conexión al servicio. Los autores, como se puede ver, están completamente seguros de la calidad de funcionamiento de su DNS (sin embargo, es difícil esperar algo diferente de Cloudflare):

 

Damos la bienvenida al servicio de Cloudflare en las direcciones 1.1.1.1 y 1.0.0.1, ¡o 'la estantería de DNS públicos ha llegado!'

 

Se puede entender perfectamente a Cloudflare, el creador del servicio: ganan su pan manteniendo y desarrollando una de las redes CDN más populares del mundo (entre cuyas funciones se incluyen no solo la entrega de contenido, sino también el alojamiento de zonas DNS), y, debido al deseo de aquellos que no tienen mucho conocimiento, enseñar a aquellos a quienes no conocen, sobre a dónde ir en la red global, a menudo sufren bloqueos de las direcciones de sus servidores por parte de no diré quién — así que tener un DNS que no esté sujeto a 'gritos, silbidos y notas' significa para la empresa un menor daño a su negocio. Y los beneficios técnicos (es un detalle, pero agradable: en particular, para los clientes que usan el DNS gratuito de Cloudflare, la actualización de los registros DNS de los recursos alojados en los servidores DNS de la empresa será instantánea) hacen que el uso del servicio descrito en la publicación sea aún más interesante.

Solo los usuarios registrados pueden participar en la encuesta. Inicie sesión, por favor.

¿Usarás el nuevo servicio?

  • Sí, simplemente indicándolo en el SO y/o en el router
  • Sí, y usaré nuevos protocolos (DNS sobre HTTPs y DNS sobre TLS)
  • No, tengo suficientes servidores actuales (este es un proveedor público: Google, Yandex, etc.)
  • No, ni siquiera sé qué estoy usando ahora
  • Uso mis DNS recursivos con túnel SSL hacia ellos

693 usuarios votaron. 191 usuarios se abstuvieron.

Fuente: habr.com

Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS 🔥 Compra un hosting fiable para sitios web con protección contra DDoS, servidores VPS VDS | ProHoster