Encontramos o serviço da Cloudflare nos endereços 1.1.1.1 e 1.0.0.1, ou “a prateleira DNS pública chegou!”

Encontramos o serviço da Cloudflare nos endereços 1.1.1.1 e 1.0.0.1, ou “a prateleira DNS pública chegou!”

Empresa Cloudflare apresentado DNS público nos endereços:

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

Alega-se que é utilizada uma política de “Privacidade em primeiro lugar”, para que os utilizadores possam ter a certeza do conteúdo dos seus pedidos.

O serviço é interessante porque, além do DNS usual, oferece a oportunidade de utilizar tecnologias DNS sobre TLS и DNS sobre HTTPS, o que impedirá fortemente que os provedores espionem suas solicitações ao longo do caminho da solicitação - e coletem estatísticas, monitorem e gerenciem publicidade. A Cloudflare afirma que a data do anúncio (1º de abril de 2018, ou 04/01 na notação americana) não foi escolhida por acaso: em que outro dia do ano seriam apresentadas “quatro unidades”?

Como o público de Habr é tecnicamente experiente, a seção tradicional “por que precisamos de DNS?” Colocarei no final do post e aqui descreverei coisas mais úteis na prática:

Como usar o novo serviço?

A coisa mais simples é especificar os endereços de servidor DNS acima em seu cliente DNS (ou como upstream nas configurações do servidor DNS local que você usa). Faz sentido substituir os valores habituais? DNS do Google (8.8.8.8, etc.), ou um pouco menos comum Servidores DNS públicos Yandex (77.88.8.8 e outros semelhantes) para servidores da Cloudflare - eles decidirão por você, mas fala por um iniciante programar velocidade de respostas, segundo a qual o Cloudflare funciona mais rápido que todos os concorrentes (deixe-me esclarecer: as medições foram feitas por um serviço terceirizado, e a velocidade para um cliente específico, claro, pode ser diferente).

Encontramos o serviço da Cloudflare nos endereços 1.1.1.1 e 1.0.0.1, ou “a prateleira DNS pública chegou!”

É muito mais interessante trabalhar com novos modos em que a solicitação chega ao servidor por meio de uma conexão criptografada (na verdade, a resposta é retornada por meio dela), os mencionados DNS-over-TLS e DNS-over-HTTPS. Infelizmente, eles não são suportados imediatamente (os autores acreditam que isso “ainda”), mas organizar seu trabalho em seu software (ou mesmo em seu hardware) não é difícil:

DNS sobre HTTPs (DoH)

Como o nome sugere, a comunicação ocorre através de um canal HTTPS, o que implica

  1. presença de um ponto de pouso (ponto final) - está localizado em https://cloudflare-dns.com/dns-queryE
  2. um cliente que pode enviar solicitações e receber respostas.

As solicitações podem estar no DNS Wireformat definido em RFC1035 (enviado usando os métodos POST e GET HTTP) ou em formato JSON (usando o método GET HTTP). Para mim, pessoalmente, a ideia de fazer consultas DNS por meio de solicitações HTTP parecia inesperada, mas há uma essência racional nela: tal solicitação passará por muitos sistemas de filtragem de tráfego, a análise de respostas é bastante simples e a geração de solicitações é ainda mais simples. Bibliotecas e protocolos familiares são responsáveis ​​pela segurança.

Consultas de exemplo, direto da documentação:

Solicitação GET no 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

Solicitação POST em 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, mas 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, poucos (se houver) roteadores domésticos podem trabalhar com DNS dessa forma, mas isso não significa que o suporte não aparecerá amanhã - e, curiosamente, aqui podemos facilmente implementar o trabalho com DNS em nosso aplicativo (como já vai fazer o Mozilla, apenas em servidores Cloudflare).

DNS sobre TLS

Por padrão, as consultas DNS são enviadas sem criptografia. DNS sobre TLS é uma forma de enviá-los por uma conexão segura. Cloudflare suporta DNS sobre TLS na porta padrão 853 conforme prescrito RFC7858. Isso usa um certificado emitido para o host cloudflare-dns.com, TLS 1.2 e TLS 1.3 são suportados.

Estabelecer uma conexão e trabalhar com o protocolo é mais ou menos assim:

  • Antes de estabelecer uma conexão com o DNS, o cliente armazena um hash SHA64 codificado em base256 do certificado TLS do cloudflare-dns.com (chamado SPKI)
  • O cliente DNS estabelece uma conexão TCP com cloudflare-dns.com:853
  • Cliente DNS inicia procedimento de handshake TLS
  • Durante o handshake TLS, o host cloudflare-dns.com apresenta seu certificado TLS.
  • Depois que a conexão TLS for estabelecida, o cliente DNS poderá enviar consultas DNS por meio de um canal seguro, o que evita espionagem e falsificação de solicitações e respostas.
  • Todas as solicitações DNS enviadas por uma conexão TLS devem estar em conformidade com a especificação de acordo com enviando DNS sobre TCP.

Exemplo de solicitação via 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 opção parece ser mais adequada para servidores DNS locais que atendem às necessidades de uma rede local ou de um único usuário. É verdade que o suporte ao padrão não é muito bom, mas esperemos!

Duas palavras de explicação do que estamos falando

A abreviatura DNS significa Domain Name Service (dizer “serviço DNS” é um tanto redundante; a sigla já contém a palavra “serviço”) e é usada para resolver uma tarefa simples - entender qual endereço IP um nome de host específico possui. Cada vez que uma pessoa clica em um link ou insere um endereço (digamos, algo como “https://habrahabr.ru/post/346430/"), o computador de uma pessoa está tentando descobrir para qual servidor enviar uma solicitação para receber o conteúdo de uma página. No caso de habrahabr.ru, a resposta do DNS conterá uma indicação do endereço IP do servidor web: 178.248.237.68, e então o navegador tentará entrar em contato com o servidor com o endereço IP especificado.

Por sua vez, o servidor DNS, tendo recebido a solicitação “qual é o endereço IP do host chamado habrahabr.ru?”, determina se sabe alguma coisa sobre o host especificado. Caso contrário, ele faz uma consulta a outros servidores DNS do mundo e, passo a passo, tenta descobrir a resposta à pergunta feita. Com isso, ao encontrar a resposta final, os dados encontrados são enviados ao cliente que ainda está em espera, além de serem armazenados no cache do próprio servidor DNS, o que permitirá responder a uma pergunta semelhante com muito mais rapidez na próxima vez.

Um problema comum é que, em primeiro lugar, os dados da consulta DNS são enviados de forma clara (o que permite que qualquer pessoa com acesso ao fluxo de tráfego isole as consultas DNS e as respostas resultantes e depois as analise para seus próprios fins; isso permite a capacidade direcionar a publicidade com precisão para o cliente DNS, e isso é bastante!). Em segundo lugar, alguns provedores de Internet (não vamos apontar o dedo, mas não os menores) tendem a mostrar publicidade em vez de uma ou outra página solicitada (que é implementada de forma muito simples: em vez do endereço IP especificado para uma solicitação de nome de host habranabr.ru para uma pessoa aleatória. Desta forma, é retornado o endereço do servidor web do provedor, onde é veiculada a página que contém o anúncio). Em terceiro lugar, existem fornecedores de acesso à Internet que implementam um mecanismo para cumprir os requisitos de bloqueio de sites individuais, substituindo as respostas DNS corretas sobre os endereços IP de recursos da web bloqueados pelo endereço IP do seu servidor contendo páginas stub (como resultado, o acesso a tais sites se tornam visivelmente mais complicados) ou para o endereço do seu servidor proxy que realiza a filtragem.

Você provavelmente deveria colocar uma foto do site aqui http://1.1.1.1/, que serve para descrever a conexão com o serviço. Os autores, aparentemente, estão completamente confiantes na qualidade de seu DNS (no entanto, é difícil esperar algo diferente do Cloudflare):

Encontramos o serviço da Cloudflare nos endereços 1.1.1.1 e 1.0.0.1, ou “a prateleira DNS pública chegou!”

Pode-se entender perfeitamente a Cloudflare, a criadora do serviço: eles ganham seu pão apoiando e desenvolvendo uma das redes CDN mais populares do mundo (cujas funções incluem não apenas distribuição de conteúdo, mas também hospedagem de zonas DNS) e, devido ao desejo daqueles, quem não sabe muito, ensine aqueles quem eles não conhecem, para isso onde ir na rede global, muitas vezes sofre com o bloqueio dos endereços de seus servidores por não vamos dizer quem - portanto, ter um DNS que não seja influenciado por “gritos, assobios e rabiscos” significa menos danos aos negócios de uma empresa. E as vantagens técnicas (uma coisa pequena, mas bacana: em especial, para clientes do DNS gratuito Cloudflare, a atualização dos registros DNS dos recursos hospedados nos servidores DNS da empresa será instantânea) tornam a utilização do serviço descrito no post ainda mais interessante .

Apenas usuários registrados podem participar da pesquisa. Entrarpor favor

Você usará o novo serviço?

  • Sim, bastando especificá-lo no SO e/ou no roteador

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

  • Não, tenho servidores atuais suficientes (este é um provedor público: Google, Yandex, etc.)

  • Não, eu nem sei o que estou usando agora

  • Eu uso meu próprio DNS recursivo com um túnel SSL antes deles

693 usuários votaram. 191 usuário se absteve.

Fonte: habr.com

Adicionar um comentário