ProHoster > Blog > Administración > Coñecemos o servizo de Cloudflare nos enderezos 1.1.1.1 e 1.0.0.1, ou "chegou o estante DNS público!"

Coñecemos o servizo de Cloudflare nos enderezos 1.1.1.1 e 1.0.0.1, ou "chegou o estante DNS público!"

Coñecemos o servizo de Cloudflare nos enderezos 1.1.1.1 e 1.0.0.1, ou "chegou o estante DNS público!"

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

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

Dise que a política é "Privacidade primeiro" para que os usuarios poidan ter tranquilidade sobre o contido das súas solicitudes.

O servizo é interesante porque, ademais do habitual DNS, ofrece a posibilidade de utilizar tecnoloxías DNS sobre TLS и DNS sobre HTTPS, o que impedirá en gran medida que os provedores escoiten as túas solicitudes ao longo do camiño das solicitudes e recompilen estatísticas, supervisan e xestionan a publicidade. Cloudflare afirma que a data do anuncio (1 de abril de 2018 ou 04/01 en notación americana) non foi elixida por casualidade: que outro día do ano se presentarán as "catro unidades"?

Dado que a audiencia de Habr é técnicamente experta, a sección tradicional "por que necesitas DNS?" Poñereino ao final do post, pero aquí indicarei cousas máis útiles na práctica:

Como usar o novo servizo?

O máis sinxelo é especificar os enderezos do servidor DNS anteriores no seu cliente DNS (ou como ascendente na configuración do servidor DNS local que utiliza). Ten sentido substituír os valores habituais DNS de Google (8.8.8.8, etc.), ou algo menos común Servidores DNS públicos de Yandex (77.88.8.8 e outros parecidos) aos servidores de Cloudflare: eles decidirán por ti, pero falan por un principiante axenda velocidade de resposta, segundo a cal Cloudflare é máis rápido que todos os competidores (aclararei: as medicións foron tomadas por un servizo de terceiros e a velocidade a un cliente específico, por suposto, pode diferir).

Coñecemos o servizo de Cloudflare nos enderezos 1.1.1.1 e 1.0.0.1, ou "chegou o estante DNS público!"

É moito máis interesante traballar con novos modos nos que a solicitude voa ao servidor a través dunha conexión cifrada (de feito, a resposta devólvese a través dela), os mencionados DNS-over-TLS e DNS-over-HTTPS. Desafortunadamente, non son compatibles "fóra da caixa" (os autores cren que isto é "aínda"), pero non é difícil organizar o seu traballo no teu software (ou incluso no teu hardware):

DNS sobre HTTPs (DoH)

Como o nome indica, a comunicación realízase a través dunha canle HTTPS, o que significa

  1. a presenza dun punto de aterraxe (punto final): está situado no enderezo https://cloudflare-dns.com/dns-queryE
  2. un cliente que pode enviar solicitudes e recibir respostas.

As solicitudes poden estar no formato DNS Wireformat definido en RFC1035 (enviado mediante os métodos POST e GET HTTP) ou en formato JSON (utilizando o método GET HTTP). Para min persoalmente, a idea de facer solicitudes de DNS a través de solicitudes HTTP pareceume inesperada, pero hai un gran racional: esa solicitude pasará moitos sistemas de filtrado de tráfico, analizar as respostas é bastante sinxelo e xerar solicitudes é aínda máis doado. As bibliotecas e protocolos habituais son os responsables da seguridade.

Solicite exemplos, directamente da documentación:

Solicitude GET 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

Solicitude 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

O mesmo 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 (se polo menos un) pode funcionar con DNS deste xeito, pero isto non significa que mañá non apareza o soporte e, curiosamente, aquí podemos implementar o traballo con DNS na nosa aplicación (como xa vai facer Mozilla, só nos servidores Cloudflare).

DNS sobre TLS

Por defecto, as consultas DNS transmítense sen cifrado. DNS sobre TLS é unha forma de envialos a través dunha conexión segura. Cloudflare admite DNS sobre TLS no porto estándar 853 tal e como se indica RFC7858. Isto utiliza un certificado emitido para o servidor cloudflare-dns.com, admite TLS 1.2 e TLS 1.3.

Establecer unha conexión e traballar segundo o protocolo é algo así:

  • Antes de establecer unha conexión DNS, o cliente almacena un hash SHA64 codificado en base256 do certificado TLS de cloudflare-dns.com (chamado SPKI)
  • O cliente DNS establece unha conexión TCP con cloudflare-dns.com:853
  • O cliente DNS inicia o enlace TLS
  • Durante o proceso de conexión de TLS, o servidor cloudflare-dns.com presenta o seu certificado TLS.
  • Unha vez que se establece unha conexión TLS, o cliente DNS pode enviar solicitudes de DNS a través dunha canle segura, o que evita que as solicitudes e as respostas sexan escoitadas e falsificadas.
  • Todas as consultas DNS enviadas a través dunha conexión TLS deben cumprir enviando DNS a través de TCP.

Un exemplo dunha solicitude a través de 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 mellor para servidores DNS locais que atenden ás necesidades dunha rede local ou dun único usuario. Verdade, co apoio do estándar non é moi bo, pero - esperemos!

Dúas palabras de explicación do que trata a conversa

A abreviatura DNS significa Servizo de nomes de dominio (polo que dicir "servizo DNS" é algo redundante, a abreviatura xa contén a palabra "servizo") e úsase para resolver unha tarefa sinxela: comprender que enderezo IP ten un nome de host en particular. Cada vez que unha persoa fai clic nunha ligazón ou introduce un enderezo na barra de enderezos do navegador (por exemplo, algo así como "https://habrahabr.ru/post/346430/"), o ordenador humano está tentando descubrir a que servidor enviar unha solicitude para obter o contido da páxina. No caso de habrahabr.ru, a resposta do DNS conterá unha indicación do enderezo IP do servidor web: 178.248.237.68 e, a continuación, o navegador xa tentará contactar co servidor co enderezo IP especificado.

Pola súa banda, o servidor DNS, recibindo a solicitude "cal é o enderezo IP do host chamado habrahabr.ru?", determina se sabe algo sobre o host especificado. Se non, fai unha solicitude a outros servidores DNS do mundo e, paso a paso, tenta descubrir a resposta á pregunta formulada. Como resultado, ao atopar a resposta final, os datos atopados son enviados ao cliente aínda esperando por eles, ademais de almacenarse na caché do propio servidor DNS, o que lle permitirá responder a unha pregunta semellante moito máis rápido a próxima vez.

Un problema común é que, en primeiro lugar, os datos das consultas DNS transmítense en claro (o que dá a calquera persoa con acceso ao fluxo de tráfico a posibilidade de illar as consultas DNS e as respostas que recibe e despois analizalas para os seus propios fins; isto dá a capacidade de orientar anuncios con precisión para un cliente DNS, que é bastante!). En segundo lugar, algúns ISP (non apuntaremos co dedo, pero non os máis pequenos) tenden a mostrar anuncios en lugar dunha ou outra páxina solicitada (que se implementa de forma sinxela: en lugar do enderezo IP especificado para unha consulta por parte de habranabr.ru). nome de host, unha persoa aleatoria Así, devólvese o enderezo do servidor web do provedor, onde se serve a páxina que contén o anuncio). En terceiro lugar, hai provedores de acceso a Internet que implementan un mecanismo para cumprir os requisitos para bloquear sitios individuais substituíndo as respostas DNS correctas sobre os enderezos IP dos recursos web bloqueados polo enderezo IP do seu servidor que contén páxinas de código (como resultado, o acceso a tales sitios son sensiblemente máis complicados) ou ao enderezo do seu servidor proxy que realiza o filtrado.

Esta probablemente debería ser unha imaxe do sitio. http://1.1.1.1/, usado para describir a conexión co servizo. Os autores parecen estar bastante seguros da calidade do seu DNS (sen embargo, é difícil esperar outra cousa de Cloudflare):

Coñecemos o servizo de Cloudflare nos enderezos 1.1.1.1 e 1.0.0.1, ou "chegou o estante DNS público!"

Pódese entender plenamente a Cloudflare, o creador do servizo: gáñanse o pan mantendo e desenvolvendo unha das redes CDN máis populares do mundo (que as súas funcións inclúen non só a distribución de contido, senón tamén a hospedaxe de zonas DNS) e, debido a o desexo daqueles, quen non está ben versado, ensinalos a quen non coñecen, a iso onde ir na rede global, moitas veces sofre de bloquear os enderezos dos seus servidores non digamos quen - polo que ter un DNS que non se vexa afectado por "gritos, asubíos e garabatos" para a empresa significa menos dano para o seu negocio. E as vantaxes técnicas (un pouco, pero agradables: en particular, para os clientes do DNS Cloudflare gratuíto, a actualización dos rexistros DNS dos recursos aloxados nos servidores DNS da empresa será instantánea) fan que o uso do servizo descrito na publicación sexa aínda máis interesante.

Só os usuarios rexistrados poden participar na enquisa. Rexístrate, por favor.

Vai utilizar o novo servizo?

  • Si, simplemente especificándoo no SO e/ou no router

  • Si, e usarei novos protocolos (DNS sobre HTTPs e DNS sobre TLS)

  • Non, teño bastantes servidores actuais (este é un provedor público: Google, Yandex, etc.)

  • Non, nin sequera sei o que estou a usar agora mesmo

  • Eu uso o meu DNS recursivo cun túnel SSL para eles

Votaron 693 usuarios. 191 usuario abstívose.

Fonte: www.habr.com

Engadir un comentario