Nous rencontrons le service de Cloudflare aux adresses 1.1.1.1 et 1.0.0.1, ou « l'étagère DNS publique est arrivée ! »

Nous rencontrons le service de Cloudflare aux adresses 1.1.1.1 et 1.0.0.1, ou « l'étagère DNS publique est arrivée ! »

Société Cloudflare présenté DNS public aux adresses :

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

La politique est dite « Privacy first » afin que les utilisateurs puissent avoir l'esprit tranquille quant au contenu de leurs demandes.

Le service est intéressant dans la mesure où, en plus du DNS habituel, il offre la possibilité d'utiliser des technologies DNS sur TLS и DNS sur HTTPS, ce qui empêchera grandement les fournisseurs d'écouter vos demandes tout au long du parcours des demandes - et de collecter des statistiques, de surveiller et de gérer la publicité. Cloudflare affirme que la date de l'annonce (le 1er avril 2018, ou 04/01 en notation américaine) n'a pas été choisie par hasard : quel autre jour de l'année les « quatre unités » seront-elles présentées ?

Étant donné que le public de Habr est techniquement averti, la section traditionnelle « pourquoi avez-vous besoin de DNS ? » Je le mettrai à la fin de l'article, mais ici j'énoncerai des choses plus pratiques :

Comment utiliser le nouveau service ?

Le plus simple est de préciser les adresses des serveurs DNS ci-dessus dans votre client DNS (ou en amont dans les paramètres du serveur DNS local que vous utilisez). Est-il judicieux de remplacer les valeurs habituelles Google DNS (8.8.8.8, etc.), ou légèrement moins courant Serveurs DNS publics Yandex (77.88.8.8 et autres comme eux) aux serveurs de Cloudflare - ils décideront pour vous, mais parlent pour un débutant calendrier vitesse de réponse, selon laquelle Cloudflare est plus rapide que tous les concurrents (je précise : les mesures ont été prises par un service tiers, et la vitesse vers un client spécifique, bien sûr, peut différer).

Nous rencontrons le service de Cloudflare aux adresses 1.1.1.1 et 1.0.0.1, ou « l'étagère DNS publique est arrivée ! »

Il est beaucoup plus intéressant de travailler avec de nouveaux modes dans lesquels la requête est acheminée vers le serveur via une connexion cryptée (en fait, la réponse est renvoyée via celle-ci), les DNS-over-TLS et DNS-over-HTTPS mentionnés. Malheureusement, ils ne sont pas pris en charge « prêts à l'emploi » (les auteurs estiment que c'est « encore »), mais il n'est pas difficile d'organiser leur travail dans votre logiciel (ou même sur votre matériel) :

DNS sur HTTP (DoH)

Comme son nom l'indique, la communication s'effectue via un canal HTTPS, ce qui signifie

  1. la présence d'un point d'atterrissage (endpoint) - il est situé à l'adresse https://cloudflare-dns.com/dns-queryEt
  2. un client qui peut envoyer des demandes et recevoir des réponses.

Les requêtes peuvent être au format DNS Wireformat défini dans RFC1035 (envoyé à l'aide des méthodes HTTP POST et GET), ou au format JSON (à l'aide de la méthode GET HTTP). Pour moi personnellement, l'idée de faire des requêtes DNS via des requêtes HTTP semblait inattendue, mais elle contient un grain rationnel : une telle requête passera par de nombreux systèmes de filtrage du trafic, l'analyse des réponses est assez simple et la génération de requêtes est encore plus facile. Les bibliothèques et protocoles habituels sont responsables de la sécurité.

Demandez des exemples, directement à partir de la documentation :

Requête GET au format 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

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

Idem 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"
    }
  ]
}

Évidemment, un routeur domestique rare (voire au moins un) peut fonctionner avec DNS de cette manière, mais cela ne signifie pas que le support n'apparaîtra pas demain - et, fait intéressant, ici nous pouvons tout à fait implémenter le travail avec DNS dans notre application (comme déjà je vais faire Mozilla, uniquement sur les serveurs Cloudflare).

DNS sur TLS

Par défaut, les requêtes DNS sont transmises sans cryptage. DNS sur TLS est un moyen de les envoyer via une connexion sécurisée. Cloudflare prend en charge DNS sur TLS sur le port standard 853 comme prescrit RFC7858. Cela utilise un certificat émis pour l'hôte cloudflare-dns.com, TLS 1.2 et TLS 1.3 sont pris en charge.

Établir une connexion et travailler selon le protocole ressemble à ceci :

  • Avant d'établir une connexion DNS, le client stocke un hachage SHA64 codé en base256 du certificat TLS de cloudflare-dns.com (appelé SPKI)
  • Le client DNS établit une connexion TCP à cloudflare-dns.com : 853
  • Le client DNS lance la négociation TLS
  • Pendant le processus de prise de contact TLS, l'hôte cloudflare-dns.com présente son certificat TLS.
  • Une fois la connexion TLS établie, le client DNS peut envoyer des requêtes DNS via un canal sécurisé, ce qui empêche les requêtes et les réponses d'être écoutées et usurpées.
  • Toutes les requêtes DNS envoyées via une connexion TLS doivent être conformes aux envoi de DNS sur TCP.

Un exemple de requête via DNS sur 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

Cette option semble fonctionner mieux pour les serveurs DNS locaux répondant aux besoins d'un réseau local ou d'un seul utilisateur. Certes, avec le support de la norme, ce n'est pas très bon, mais - espérons-le !

Deux mots d'explication du sujet de la conversation

L'abréviation DNS signifie Domain Name Service (donc dire « service DNS » est quelque peu redondant, l'abréviation contient déjà le mot « service ») et est utilisée pour résoudre une tâche simple : comprendre quelle adresse IP possède un nom d'hôte particulier. Chaque fois qu'une personne clique sur un lien ou saisit une adresse dans la barre d'adresse du navigateur (par exemple, quelque chose comme "https://habrahabr.ru/post/346430/"), l'ordinateur humain essaie de déterminer à quel serveur envoyer une requête pour obtenir le contenu de la page. Dans le cas de habrahabr.ru, la réponse du DNS contiendra une indication de l'adresse IP du serveur Web : 178.248.237.68, puis le navigateur tentera déjà de contacter le serveur avec l'adresse IP spécifiée.

À son tour, le serveur DNS, après avoir reçu la demande « quelle est l'adresse IP de l'hôte nommé habrahabr.ru ? », détermine s'il sait quelque chose sur l'hôte spécifié. Dans le cas contraire, il fait une requête à d'autres serveurs DNS dans le monde et, étape par étape, essaie de trouver la réponse à la question posée. En conséquence, une fois la réponse finale trouvée, les données trouvées sont envoyées au client qui les attend toujours et sont stockées dans le cache du serveur DNS lui-même, ce qui vous permettra de répondre beaucoup plus rapidement à une question similaire la prochaine fois.

Un problème courant est que, d'abord, les données des requêtes DNS sont transmises en clair (ce qui donne à toute personne ayant accès au flux de trafic la possibilité d'isoler les requêtes DNS et les réponses qu'elles reçoivent, puis de les analyser à leurs propres fins ; cela donne la possibilité de cibler les publicités avec précision pour un client DNS, ce qui est beaucoup !). Deuxièmement, certains FAI (nous ne pointerons pas du doigt, mais pas les plus petits) ont tendance à diffuser des publicités à la place de l'une ou l'autre page demandée (ce qui est mis en œuvre assez simplement : au lieu de l'adresse IP spécifiée pour une requête par habranabr.ru nom d'hôte, une personne aléatoire Ainsi, l'adresse du serveur Web du fournisseur est renvoyée, où la page contenant la publicité est servie). Troisièmement, il existe des fournisseurs d'accès Internet qui mettent en œuvre un mécanisme permettant de remplir les exigences de blocage de sites individuels en remplaçant les réponses DNS correctes concernant les adresses IP des ressources Web bloquées par l'adresse IP de leur serveur contenant des pages de stub (en conséquence, l'accès à ces sites sont sensiblement plus compliqués), ou à l'adresse de votre serveur proxy qui effectue le filtrage.

Cela devrait probablement être une photo du site. http://1.1.1.1/, utilisé pour décrire la connexion au service. Les auteurs semblent plutôt confiants dans la qualité de leur DNS (il est cependant difficile d’attendre autre chose de Cloudflare) :

Nous rencontrons le service de Cloudflare aux adresses 1.1.1.1 et 1.0.0.1, ou « l'étagère DNS publique est arrivée ! »

On comprend parfaitement Cloudflare, le créateur du service : ils gagnent leur pain en maintenant et en développant l'un des réseaux CDN les plus populaires au monde (dont les fonctions incluent non seulement la distribution de contenu, mais aussi l'hébergement de zones DNS) et, grâce à le désir de ceux-là, qui ne connaît pas bien, enseigne à ceux qui ils ne connaissent pas, pour que où aller dans le réseau mondial, souffrent assez souvent du blocage des adresses de leurs serveurs de ne disons pas qui - donc avoir un DNS qui n'est pas affecté par les "cris, sifflets et gribouillages" pour l'entreprise signifie moins de préjudice à son activité. Et les avantages techniques (un peu, mais sympa : en particulier, pour les clients du DNS gratuit 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 l'article encore plus intéressante.

Seuls les utilisateurs enregistrés peuvent participer à l'enquête. se connecters'il te plait.

Utiliserez-vous le nouveau service ?

  • Oui, en le précisant simplement dans l'OS et/ou sur le routeur

  • Oui, et j'utiliserai de nouveaux protocoles (DNS sur HTTP et DNS sur TLS)

  • Non, j'ai suffisamment de serveurs actuels (il s'agit d'un fournisseur public : Google, Yandex, etc.)

  • Non, je ne sais même pas ce que j'utilise en ce moment

  • J'utilise mon DNS récursif avec un tunnel SSL vers eux

693 utilisateurs ont voté. 191 utilisateur s'est abstenu.

Source: habr.com

Ajouter un commentaire