Accueillons le service de Cloudflare aux adresses 1.1.1.1 et 1.0.0.1, ou « la section des DNS publics est arrivée ! »

La société Cloudflare présentée DNS publics aux adresses :

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

Il est affirmé que la politique « Privacy first » est utilisée, de sorte que les utilisateurs peuvent être tranquilles quant au contenu de leurs requêtes.

Le service est intéressant car, en plus du DNS habituel, il offre la possibilité d'utiliser des technologies DNS-over-TLS et DNS-over-HTTPS, ce qui empêche fortement les fournisseurs de surveiller vos requêtes en cours de route — et de collecter des statistiques, de suivre et de gérer la publicité. Cloudflare affirme que la date de lancement (1er avril 2018, ou 04/01 dans la notation américaine) n'a pas été choisie par hasard : quel autre jour de l'année pourrait-on présenter « quatre unité » ?

Étant donné que l'audience de Habr est techniquement avertie, je placerai la section traditionnelle « pourquoi le DNS est-il nécessaire ? » à la fin du post, et ici j'exposerai des choses plus pratiques :

Comment utiliser le nouveau service ?

Le plus simple est d'indiquer dans votre client DNS (ou comme upstream dans les paramètres de votre serveur DNS local) les adresses DNS mentionnées ci-dessus -serveurs. Faut-il remplacer les valeurs habituelles des DNS de Google (8.8.8.8, etc.), ou des serveurs publics moins répandus de Yandex (77.88.8.8 et autres) par les serveurs de Cloudflare — vous déciderez, mais les débutants seront convaincus par un graphique des temps de réponse, selon lequel Cloudflare fonctionne plus vite que tous ses concurrents (je précise que les mesures ont été réalisées par un service externe, et la vitesse pour un client spécifique peut bien sûr varier).

Il est beaucoup plus intéressant de travailler avec les nouveaux modes, dans lesquels la requête est envoyée sur serveur une connexion chiffrée (en fait, la réponse est renvoyée par celle-ci), mentionnée dans DNS-over-TLS et DNS-over-HTTPS. Malheureusement, « par défaut », ils ne sont pas pris en charge (les auteurs espèrent que c'est « pour l'instant »), mais il est facile de les faire fonctionner dans votre logiciel (ou même sur votre matériel) :

DNS over HTTPs (DoH)

Comme son nom l'indique, la communication se fait sur un canal HTTPS, ce qui implique

1. la nécessité d'un point d'atterrissage (endpoint) — il se trouve à l'adresse https://cloudflare-dns.com/dns-query, et
2. d'un client capable d'envoyer des requêtes et de recevoir des réponses.

Les requêtes peuvent être en format DNS Wireformat, défini dans RFC1035 (envoyer avec les méthodes HTTP POST et GET), ou au format JSON (utilisant la méthode HTTP GET). Personnellement, l'idée d'effectuer des requêtes DNS via des requêtes HTTP m'a semblé inattendue, cependant, elle a un fondement rationnel : une telle requête passera de nombreux systèmes de filtrage du trafic, analyser les réponses est assez simple, et formuler des requêtes l'est encore plus. Les bibliothèques et protocoles habituels garantissent la sécurité.

Exemples de requêtes, directement depuis la documentation :

Requête GET au format DNS Wireformat

$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Utilisation de HTTP2, le serveur supporte les connexions multiples
* État de la connexion changé (HTTP/2 confirmé)
* Copie des données HTTP/2 dans le tampon de connexion après la mise à niveau : len=0
* Utilisation de l'ID de flux : 1 (manipulation facile 0x7f968700a400)
GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
Accept: */*

* État de la connexion changé (MAX_CONCURRENT_STREAMS mis à jour)!
HTTP/2 200
date: ven., 23 mars 2018 05:14:02 GMT
content-type: application/dns-udpwireformat
content-length: 49
cache-control: max-age=0
set-cookie: __cfduid=dd1fb65f0185fadf50bbb6cd14ecbc5b01521782042; expires=sam., 23 mars 2019 05:14:02 GMT; path=/; domain=.cloudflare.com; HttpOnly
server: cloudflare-nginx
cf-ray: 3ffe69838a418c4c-SFO-DOG

{ [49 octets de données]
100     49  100   49    0     0    493      0 --:--:-- --:--:-- --:--:--  494
* Connexion #0 au serveur cloudflare-dns.com laissée intacte
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

Requête POST au format 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 octets de données]
100     49  100   49    0     0    493      0 --:--:-- --:--:-- --:--:--  494
* Connexion #0 au serveur cloudflare-dns.com laissée intacte
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

La même chose, mais en utilisant 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"
    }
  ]
}

Il est évident qu'un routeur domestique rare (s'il y en a un) sait travailler ainsi avec DNS, mais cela ne signifie pas que le support n'apparaîtra pas demain — et ce qui est intéressant, c'est qu'ici, nous pouvons tout à fait mettre en œuvre le travail avec DNS dans notre application (comme cela) prévoit de le faire Mozilla, précisément sur les serveurs Cloudflare).

DNS sur TLS

Par défaut, les requêtes DNS sont envoyées sans cryptage. DNS over TLS est une méthode pour les transmettre via une connexion sécurisée. Cloudflare prend en charge DNS over TLS sur le port standard 853, comme le stipule RFC7858. Un certificat délivré pour l'hôte cloudflare-dns.com est utilisé, prenant en charge TLS 1.2 et TLS 1.3.

L'établissement de la connexion et le fonctionnement selon le protocole se déroulent à peu près comme suit :

• Avant d'établir une connexion avec DNS, le client DNS conserve le hachage SHA256 du certificat TLS de cloudflare-dns.com (appelé SPKI) encodé en base64.
• Le client DNS établit une connexion TCP avec cloudflare-dns.com:853
• Le client DNS initie la procédure de handshake TLS
• Au cours du handshake TLS, l'hôte cloudflare-dns.com présente son certificat TLS.
• Une fois que la connexion TLS est établie, le client DNS peut envoyer des requêtes DNS sur le canal sécurisé, empêchant ainsi l'écoute clandestine et la falsification des requêtes et réponses.
• Toutes les requêtes DNS envoyées via une connexion TLS doivent être conformes à la spécification sur l'envoi de DNS sur TCP.

Exemple de requête via DNS over TLS :

$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com  example.com
;; DEBUG: Interrogation pour le propriétaire(example.com.), classe(1), type(1), serveur(1.1.1.1), port(853), protocole(TCP)
;; DEBUG: TLS, importé 170 certificats systèmes
;; DEBUG: TLS, hiérarchie de certificats reçue :
;; 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, vérification du PIN du certificat ignorée
;; DEBUG: TLS, Le certificat est de confiance.
;; session TLS (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; statut: NOERROR; id: 58548
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; SECTION PSEUDOEDNS :
;; Version: 0; flags: ; taille UDP: 1536 B; code-err-ext: NOERROR
;; PADDING: 408 B

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

;; SECTION RÉPONSE :
example.com.            2347    IN  A   93.184.216.34

;; Reçu 468 B
;; Temps 2018-03-31 15:20:57 PDT
;; Depuis 1.1.1.1@853(TCP) en 12.6 ms

Cette option semble mieux adaptée pour les serveurs DNS locaux, répondant aux besoins d'un réseau local ou d'un seul utilisateur. Bien que le support de la norme ne soit pas très bon, espérons !

Deux mots d'explications sur le sujet

L'acronyme DNS signifie Domaine Name Service (donc dire « service DNS » est un peu redondant, l'acronyme contient déjà le mot « service »), et est utilisé pour résoudre une tâche simple : comprendre quelle adresse IP correspond à un nom d'hôte spécifique. Chaque fois qu'une personne clique sur un lien ou saisit une adresse dans la barre d'adresse du navigateur (disons quelque chose comme «https://habrahabr.ru/post/346430/L'ordinateur de l'utilisateur essaie de comprendre à quel serveur il doit diriger la requête pour obtenir le contenu de la page. Dans le cas de habrahabr.ru, la réponse du DNS indiquera l'adresse IP du serveur web : 178.248.237.68, et ensuite, le navigateur essaiera de se connecter au serveur à l'adresse IP indiquée.

À son tour, le serveur DNS, ayant reçu la requête « quelle est l'adresse IP de l'hôte avec le nom habrahabr.ru ? », détermine s'il sait quelque chose sur l'hôte en question. S'il ne sait pas, il fait appel à d'autres serveurs DNS dans le monde, et, étape par étape, essaie de trouver une réponse à la question posée. En fin de compte, une fois la réponse trouvée, les données trouvées sont envoyées au client qui les attend toujours, et de plus, elles sont enregistrées dans le cache du serveur DNS lui-même, ce qui permettra de répondre beaucoup plus rapidement à une question similaire la prochaine fois.

Un problème courant est que, tout d'abord, les données des requêtes DNS sont transmises en clair (ce qui permet à quiconque ayant accès au flux de trafic d'extraire les requêtes DNS et les réponses reçues, puis de les analyser à ses propres fins ; cela permet un ciblage publicitaire précis pour le client DNS, ce qui n'est pas négligeable !). Deuxièmement, certains fournisseurs d'accès à Internet (sans donner de noms, mais ce ne sont pas les plus petits) ont tendance à afficher des publicités au lieu de telle ou telle page demandée (ce qui est réalisé de manière très simple : au lieu de l'adresse IP spécifiée pour la requête du nom d'hôte habranabr.ru, on renvoie au client aléatoirement l'adresse du serveur web du fournisseur, où une page contenant de la publicité est affichée). Troisièmement, il existe des fournisseurs d'accès à Internet qui mettent en œuvre un mécanisme de blocage de certains sites, en remplaçant les réponses DNS correctes des adresses IP des ressources bloquées par l'adresse de leur propre serveur contenant des pages de remplacement (ce qui complique considérablement l'accès à ces sites), ou par l'adresse de leur serveur proxy qui effectue le filtrage.

Il semble qu'ici, il faille insérer une image du site http://1.1.1.1/, visant à décrire la connexion au service. Les auteurs sont manifestement très confiants dans la qualité du travail de leur DNS (d'ailleurs, il est difficile d'attendre autre chose de Cloudflare) :

On peut comprendre Cloudflare, le créateur du service : ils gagnent leur vie en soutenant et en développant l'une des CDN les plus populaires au monde (dont les fonctionnalités incluent non seulement la distribution de contenu, mais aussi l'hébergement de zones DNS), et en raison du désir de ceux, qui ne s'y connaissent pas très bien, d'éduquer ceux, qu'ils ne connaissent pas, sur où aller dans le réseau mondial, souffre souvent de blocages d'adresses de leurs serveurs de la part de nous ne dirons pas qui — donc avoir un DNS, pas soumis aux "cries, sifflets et messages écrits", signifie pour l'entreprise un moindre préjudice pour leur activité. Et les avantages techniques (c'est un petit quelque chose, mais c'est agréable : en particulier, pour les clients du DNS gratuit de Cloudflare, la mise à jour des enregistrements DNS des ressources hébergées sur les serveurs DNS de l'entreprise sera instantanée) rendent l'utilisation du service décrit dans le post encore plus attrayante.

Seuls les utilisateurs enregistrés peuvent participer au sondage. Connectez-vous, s'il vous plaît.

Utiliserez-vous le nouveau service ?

• Oui, en le spécifiant simplement dans le système d'exploitation et/ou sur le routeur
• Oui, et j'utiliserai les nouveaux protocoles (DNS sur HTTPs et DNS sur TLS)
• Non, mes serveurs actuels me suffisent (c'est un fournisseur public : Google, Yandex, etc.)
• Non, je ne sais même pas ce que j'utilise actuellement
• J'utilise mes DNS récursifs avec un tunnel SSL vers eux

693 utilisateurs ont voté. 191 utilisateurs se sont abstenus.

Source : habr.com