A empresa Cloudflare apresentou DNS públicos nos endereços:
- 1.1.1.1
- 1.0.0.1
- 2606:4700:4700::1111
- 2606:4700:4700::1001
A política 'Privacidade em primeiro lugar' é afirmada, garantindo que os usuários possam ficar tranquilos quanto ao conteúdo de suas solicitações.
O serviço é interessante pois, além de oferecer DNS comum, permite o uso de tecnologias DNS-over-TLS e DNS-over-HTTPS, o que dificulta que provedores interceptem suas solicitações durante o caminho — 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) foi escolhida a dedo: em que outro dia do ano apresentar 'quatro unidades'?
Como o público do Habr é tecnicamente dotado, colocarei a seção tradicional 'para que serve o DNS?' no final do post, e aqui apresentarei coisas mais pragmáticas:
Como usar o novo serviço?
A maneira mais simples é, no seu cliente DNS (ou como upstream nas configurações do servidor DNS local que você está usando), indicar os endereços DNS mencionados acimaservidores. Faz sentido substituir os valores habituais DNS do Google (8.8.8.8 e assim por diante), ou menos comuns servidores públicos DNS da Yandex (77.88.8.8 e similares) pelos servidores da Cloudflare — a decisão é sua, mas a velocidade gráfico das respostas, segundo a qual a Cloudflare é a mais rápida de todos os concorrentes (especifico: as medições foram feitas por um serviço externo, e a velocidade até um cliente específico pode variar).
Muito mais interessante é o trabalho com os novos modos, onde a solicitação é enviada por servidor uma conexão criptografada (na verdade, a resposta também retorna por ela), mencionados DNS-over-TLS e DNS-over-HTTPS. Infelizmente, 'pronto para uso' eles não são suportados (os autores acreditam que isso é 'por enquanto'), mas configurar sua aplicação (ou até mesmo em seu hardware) para fazê-los funcionar não é difícil:
DNS sobre HTTPS (DoH)
Como o nome indica, a comunicação ocorre sobre um canal HTTPS, implicando
- a existência de um ponto de aterrissagem (endpoint) — que está no endereço https://cloudflare-dns.com/dns-query, e
- um cliente que pode enviar solicitações e receber respostas.
As solicitações podem ser feitas em formato DNS Wireformat, conforme definido em RFC1035 (enviar por métodos HTTP POST e GET), ou em formato JSON (usado o método HTTP GET). Para mim, a ideia de fazer consultas DNS através de requisições HTTP pareceu inesperada, mas há um fundo racional nisso: tal solicitação passará por muitos sistemas de filtragem de tráfego, analisar as respostas é bastante simples, e formular as solicitações é ainda mais fácil. A segurança é garantida por bibliotecas e protocolos conhecidos.
Exemplos de requisições, diretamente 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
* Usando HTTP2, o servidor suporta múltiplo uso
* Estado da conexão alterado (HTTP/2 confirmado)
* Copiando dados HTTP/2 no buffer de fluxo para o buffer de conexão após a atualização: len=0
* Usando o ID do fluxo: 1 (manipulação 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: */*
* Estado da conexão alterado (MAX_CONCURRENT_STREAMS atualizado)!
HTTP/2 200
data: Sex, 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=Sab, 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
* Conexão #0 com o host cloudflare-dns.com mantida
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 no 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
* Conexão #0 com o host cloudflare-dns.com mantida
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 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"
}
]
}
É evidente que um roteador doméstico raro (se é que algum) consegue operar assim com o DNS, mas isso não significa que o suporte não apareça amanhã — e o que é interessante é que aqui podemos implementar a operação com DNS em nosso aplicativo (como já pretende fazer a Mozilla, exatamente nos servidores da Cloudflare).
DNS sobre TLS
Por padrão, as consultas DNS são transmitidas sem criptografia. O DNS sobre TLS é uma forma de enviá-las por uma conexão segura. O Cloudflare suporta o DNS sobre TLS na porta padrão 853, conforme prescrito. RFC7858. Neste caso, é utilizado um certificado emitido para o host cloudflare-dns.com, suportando TLS 1.2 e TLS 1.3.
O estabelecimento de conexão e operação do protocolo ocorre mais ou menos da seguinte forma:
- Antes de estabelecer a conexão com o DNS, o cliente armazena o hash SHA256 do certificado TLS do cloudflare-dns.com codificado em base64 (chamado SPKI).
- O cliente DNS estabelece uma conexão TCP com cloudflare-dns.com:853
- O cliente DNS inicia o procedimento de handshake TLS.
- Durante o handshake TLS, o host cloudflare-dns.com apresenta seu certificado TLS.
- Assim que a conexão TLS é estabelecida, o cliente DNS pode enviar consultas DNS através de um canal seguro, o que impede a espionagem e falsificação de consultas e respostas.
- Todas as consultas DNS enviadas através da conexão TLS devem estar em conformidade com a especificação de envio de DNS sobre TCP..
Exemplo de consulta via DNS sobre TLS:
$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com example.com
;; DEBUG: Consultando para owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, importados 170 certificados de sistema
;; DEBUG: TLS, hierarquia de certificado recebida:
;; 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, ignorando verificação de PIN de certificado
;; DEBUG: TLS, O certificado é confiável.
;; Sessão 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
;; SEÇÃO PSEUDO EDNS:
;; Versão: 0; flags: ; tamanho UDP: 1536 B; ext-rcode: NOERROR
;; PADDING: 408 B
;; SEÇÃO DE QUESTÃO:
;; example.com. IN A
;; SEÇÃO DE RESPOSTA:
example.com. 2347 IN A 93.184.216.34
;; Recebido 468 B
;; Tempo 2018-03-31 15:20:57 PDT
;; De 1.1.1.1@853(TCP) em 12.6 ms
Esta opção parece ser mais adequada para servidores DNS locais, atendendo às necessidades de uma rede local ou de um único usuário. Embora o suporte ao padrão não seja muito bom, vamos torcer!
Duas palavras de explicação sobre o que estamos falando:
A sigla DNS significa Domínio Name Service (portanto, dizer "serviço DNS" é um pouco redundante, pois a sigla já contém a palavra "serviço"), e é utilizada para resolver uma tarefa simples — entender qual é o endereço IP de um determinado nome de host. Cada vez que uma pessoa clica em um link ou digita na barra de endereços do navegador um endereço (digamos, algo como "https://habrahabr.ru/post/346430/Neste caso, o computador tenta entender a qual servidor deve direcionar o pedido para obter o conteúdo da página. No caso do habrahabr.ru, a resposta do DNS incluirá o endereço IP do servidor web: 178.248.237.68, e em seguida, o navegador tentará se conectar ao servidor com o endereço IP informado.
Por sua vez, o servidor DNS, ao receber o pedido "qual é o endereço IP do host com o nome habrahabr.ru?", determina se ele possui informações sobre o host especificado. Se não tiver, ele faz um pedido a outros servidores DNS ao redor do mundo e, passo a passo, tenta descobrir a resposta para a pergunta feita. No final, uma vez encontrada a resposta, os dados são enviados ao cliente que ainda a aguarda, além de serem armazenados em cache no próprio servidor DNS, o que permitirá responder a uma pergunta semelhante muito mais rapidamente na próxima vez.
Um problema comum é que, em primeiro lugar, os dados das consultas DNS são transmitidos de forma aberta (o que permite que todos que têm acesso ao fluxo de tráfego possam extrair as consultas DNS e as respostas obtidas, e depois analisá-las para seus próprios fins; isso possibilita a segmentação de anúncios com precisão para o cliente DNS, o que não é pouco!). Em segundo lugar, alguns provedores de internet (não vamos apontar dedos, mas não são os menores) têm a tendência de mostrar anúncios em vez da página solicitada (o que é realizado de forma bastante simples: em vez do endereço IP especificado para a consulta do nome do host habrahabr.ru, o cliente recebe aleatoriamente o endereço do servidor web do provedor, onde uma página contendo anúncios é exibida). Em terceiro lugar, existem provedores de acesso à internet que implementam mecanismos para atender a solicitações de bloqueio de determinados sites, substituindo as respostas DNS corretas por endereços IP de seus próprios servidores, que contêm páginas de aviso (o que dificulta bastante o acesso a esses sites), ou pelo endereço de seu servidor proxy, que realiza a filtragem.
Aqui, provavelmente, precisa-se adicionar uma imagem do site http://1.1.1.1/, que serve para descrever a conexão ao serviço. Os autores, como se vê, estão completamente certos da qualidade do funcionamento de seu DNS (afinal, esperar algo diferente da Cloudflare é difícil):
É perfeitamente compreensível para a Cloudflare, criadora do serviço: eles ganham a vida mantendo e expandindo uma das redes de CDN mais populares do mundo (entre cujas funções estão não apenas a distribuição de conteúdo, mas também o hosting de zonas DNS), e, devido ao desejo de aqueles que não têm muito conhecimento, ensinar aquelesque eles não conhecem , sobre comonavegar na rede global, frequentemente sofre com bloqueios de endereços de seus servidores por parte de não vamos mencionar quem — portanto, ter um DNS que não está sujeito a "gritos, assobios e bilhetes" significa menos danos para seus negócios. Além disso, as vantagens técnicas (um pequeno detalhe, mas agradável: em particular, para os clientes do DNS gratuito da Cloudflare, a atualização de registros DNS de recursos hospedados nos servidores DNS da empresa será instantânea) tornam o uso do serviço descrito neste post ainda mais interessante. Você vai usar o novo serviço?
Apenas usuários registrados podem participar da pesquisa. Entre, por favor.
Sim, apenas configurando-o no SO e/ou no roteador
- Sim, e usarei novos protocolos (DNS sobre HTTPs e DNS sobre TLS)
- Não, estou satisfeito com os servidores atuais (este é um provedor público: Google, Yandex, etc.)
- Não, eu nem sei o que estou usando atualmente
- Estou usando meus DNS recursivos com túnel SSL para eles
- 693 usuários participaram da votação. 191 usuários se abstiveram.
🥇Apresentamos o serviço da Cloudflare nos endereços 1.1.1.1 e 1.0.0.1, ou "a prateleira de DNS públicos aumentou!" | ProHoster
Fonte: habr.com
