ProHoster > Blog > administración > Nos encontramos con el servicio de Cloudflare en las direcciones 1.1.1.1 y 1.0.0.1, o "¡ha llegado el estante de DNS público!"

Nos encontramos con el servicio de Cloudflare en las direcciones 1.1.1.1 y 1.0.0.1, o "¡ha llegado el estante de DNS público!"

Nos encontramos con el servicio de Cloudflare en las direcciones 1.1.1.1 y 1.0.0.1, o "¡ha llegado el estante de DNS público!"

Compañía Cloudflare presentado DNS público en direcciones:

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

Se dice que la política es "Privacidad primero" para que los usuarios puedan estar tranquilos sobre el contenido de sus solicitudes.

El servicio es interesante porque, además del DNS habitual, ofrece la posibilidad de utilizar tecnologías. DNS sobre TLS и DNS sobre HTTPS, lo que evitará en gran medida que los proveedores escuchen sus solicitudes a lo largo del camino de las solicitudes y recopilen estadísticas, monitoreen y administren publicidad. Cloudflare afirma que la fecha del anuncio (1 de abril de 2018 o 04/01 en notación americana) no fue elegida por casualidad: ¿qué otro día del año se presentarán las “cuatro unidades”?

Dado que la audiencia de Habr tiene conocimientos técnicos, la sección tradicional "¿por qué necesitas DNS?" Lo pondré al final del post, pero aquí expondré cosas más útiles en la práctica:

¿Cómo utilizar el nuevo servicio?

Lo más simple es especificar las direcciones de servidor DNS anteriores en su cliente DNS (o como ascendentes en la configuración del servidor DNS local que utiliza). ¿Tiene sentido reemplazar los valores habituales? DNS de Google (8.8.8.8, etc.), o un poco menos común Servidores DNS públicos de Yandex (77.88.8.8 y otros similares) a los servidores de Cloudflare: ellos decidirán por usted, pero hablan por un principiante calendario velocidad de respuesta, según la cual Cloudflare es más rápido que todos los competidores (aclararé: las mediciones fueron tomadas por un servicio de terceros y la velocidad para un cliente específico, por supuesto, puede diferir).

Nos encontramos con el servicio de Cloudflare en las direcciones 1.1.1.1 y 1.0.0.1, o "¡ha llegado el estante de DNS público!"

Es mucho más interesante trabajar con nuevos modos en los que la solicitud vuela al servidor a través de una conexión cifrada (de hecho, la respuesta se devuelve a través de ella), los mencionados DNS sobre TLS y DNS sobre HTTPS. Desafortunadamente, no son compatibles "de fábrica" ​​(los autores creen que "todavía"), pero no es difícil organizar su trabajo en su software (o incluso en su hardware):

DNS sobre HTTP (DoH)

Como sugiere el nombre, la comunicación se realiza a través de un canal HTTPS, lo que significa

  1. la presencia de un punto de aterrizaje (punto final): está ubicado en la dirección https://cloudflare-dns.com/dns-queryY
  2. un cliente que puede enviar solicitudes y recibir respuestas.

Las solicitudes pueden estar en el formato DNS Wireformat definido en RFC1035 (enviado mediante los métodos POST y GET HTTP), o en formato JSON (utilizando el método GET HTTP). Personalmente, para mí, la idea de realizar solicitudes de DNS a través de solicitudes HTTP parecía inesperada, pero tiene una esencia racional: dicha solicitud pasará por muchos sistemas de filtrado de tráfico, analizar las respuestas es bastante simple y generar solicitudes es aún más fácil. Las bibliotecas y protocolos habituales son responsables de la seguridad.

Solicite ejemplos, directamente de la documentación:

OBTENER solicitud en formato DNS Wireformat

$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f968700a400)
GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
Accept: */*

* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
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 data]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* Connection #0 to host cloudflare-dns.com left intact
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 data]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* Connection #0 to host cloudflare-dns.com left intact
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 usando 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"
    }
  ]
}

Obviamente, un enrutador doméstico raro (si al menos uno) puede funcionar con DNS de esta manera, pero esto no significa que el soporte no aparecerá mañana y, curiosamente, aquí podemos implementar bastante el trabajo con DNS en nuestra aplicación (como ya voy a hacer Mozilla, solo en servidores de Cloudflare).

DNS sobre TLS

De forma predeterminada, las consultas DNS se transmiten sin cifrado. DNS sobre TLS es una forma de enviarlos a través de una conexión segura. Cloudflare admite DNS sobre TLS en el puerto estándar 853 según lo prescrito RFC7858. Esto utiliza un certificado emitido para el host cloudflare-dns.com, se admiten TLS 1.2 y TLS 1.3.

Establecer una conexión y trabajar según el protocolo es algo como esto:

  • Antes de establecer una conexión DNS, el cliente almacena un hash SHA64 codificado en base256 del certificado TLS de cloudflare-dns.com (llamado SPKI).
  • El cliente DNS establece una conexión TCP con cloudflare-dns.com:853
  • El cliente DNS inicia el protocolo de enlace TLS
  • Durante el proceso de protocolo de enlace TLS, el host de cloudflare-dns.com presenta su certificado TLS.
  • Una vez que se establece una conexión TLS, el cliente DNS puede enviar solicitudes DNS a través de un canal seguro, lo que evita que las solicitudes y respuestas sean escuchadas y falsificadas.
  • Todas las consultas DNS enviadas a través de una conexión TLS deben cumplir con los enviando DNS sobre TCP.

Un ejemplo de una solicitud vía DNS sobre TLS:

$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com  example.com
;; DEBUG: Querying for owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 170 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=CA,L=San Francisco,O=Cloudflare, Inc.,CN=*.cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA
;; DEBUG:      SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted.
;; TLS session (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

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1536 B; ext-rcode: NOERROR
;; PADDING: 408 B

;; QUESTION SECTION:
;; example.com.             IN  A

;; ANSWER SECTION:
example.com.            2347    IN  A   93.184.216.34

;; Received 468 B
;; Time 2018-03-31 15:20:57 PDT
;; From 1.1.1.1@853(TCP) in 12.6 ms

Esta opción parece funcionar mejor para servidores DNS locales que satisfacen las necesidades de una red local o de un solo usuario. Es cierto que el soporte del estándar no es muy bueno, pero ¡esperemos!

Dos palabras de explicación de qué trata la conversación.

La abreviatura DNS significa Servicio de nombres de dominio (por lo que decir "servicio DNS" es algo redundante, la abreviatura ya contiene la palabra "servicio") y se utiliza para resolver una tarea simple: comprender qué dirección IP tiene un nombre de host en particular. Cada vez que una persona hace clic en un enlace o ingresa una dirección en la barra de direcciones del navegador (por ejemplo, algo como "https://habrahabr.ru/post/346430/"), la computadora humana está tratando de averiguar a qué servidor enviar una solicitud para obtener el contenido de la página. En el caso de habrahabr.ru, la respuesta de DNS contendrá una indicación de la dirección IP del servidor web: 178.248.237.68, y luego el navegador intentará comunicarse con el servidor con la dirección IP especificada.

A su vez, el servidor DNS, después de recibir la pregunta "¿cuál es la dirección IP del host llamado habrahabr.ru?", determina si sabe algo sobre el host especificado. En caso contrario, realiza una solicitud a otros servidores DNS del mundo y, paso a paso, intenta encontrar la respuesta a la pregunta formulada. Como resultado, al encontrar la respuesta final, los datos encontrados se envían al cliente que aún los está esperando, además se almacenan en el caché del servidor DNS, lo que le permitirá responder una pregunta similar mucho más rápido la próxima vez.

Un problema común es que, primero, los datos de la consulta DNS se transmiten sin cifrar (lo que le da a cualquier persona con acceso al flujo de tráfico la capacidad de aislar las consultas DNS y las respuestas que reciben y luego analizarlas para sus propios fines; esto da la capacidad de orientar anuncios con precisión para un cliente DNS, ¡que es bastante!). En segundo lugar, algunos ISP (no señalaremos con el dedo, pero no los más pequeños) tienden a mostrar anuncios en lugar de una u otra página solicitada (lo cual se implementa de manera bastante simple: en lugar de la dirección IP especificada para una consulta de habranabr.ru). nombre de host, una persona aleatoria (por lo tanto, se devuelve la dirección del servidor web del proveedor, donde se muestra la página que contiene el anuncio). En tercer lugar, hay proveedores de acceso a Internet que implementan un mecanismo para cumplir con los requisitos de bloqueo de sitios individuales reemplazando las respuestas DNS correctas sobre las direcciones IP de los recursos web bloqueados con la dirección IP de su servidor que contiene páginas auxiliares (como resultado, el acceso a dichos sitios son notablemente más complicados), o a la dirección de su servidor proxy que realiza el filtrado.

Probablemente debería ser una imagen del sitio. http://1.1.1.1/, utilizado para describir la conexión al servicio. Los autores parecen tener bastante confianza en la calidad de su DNS (sin embargo, es difícil esperar algo más de Cloudflare):

Nos encontramos con el servicio de Cloudflare en las direcciones 1.1.1.1 y 1.0.0.1, o "¡ha llegado el estante de DNS público!"

Se puede entender perfectamente a Cloudflare, el creador del servicio: se gana la vida manteniendo y desarrollando una de las redes CDN más populares del mundo (cuyas funciones incluyen no sólo la distribución de contenidos, sino también el alojamiento de zonas DNS) y, debido a el deseo de aquellos, quien no esta bien versado, enseñarles a esos a quien no conocen, a ese dónde ir en la red global, a menudo sufre el bloqueo de las direcciones de sus servidores no digamos quien - Por lo tanto, tener un DNS que no se vea afectado por "gritos, silbidos y garabatos" para la empresa significa menos daño para su negocio. Y las ventajas técnicas (un poco, pero agradables: en particular, para los clientes del DNS gratuito 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 el post sea aún más interesante.

Solo los usuarios registrados pueden participar en la encuesta. Registrarsepor favor

¿Usarás el nuevo servicio?

  • Sí, simplemente especificándolo en el SO y/o en el router

  • Sí, y usaré nuevos protocolos (DNS sobre HTTP 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

  • Utilizo mi DNS recursivo con un túnel SSL hacia ellos.

693 usuarios votaron. 191 usuario se abstuvo.

Fuente: habr.com

Añadir un comentario