Pourquoi 1.1.1.1 ne résout-il pas archive.is?
Lorsque j'essaie d'accéder à http://archive.is/ avec DNS via 1.1.1.1, ça ne marche pas. Pourquoi?
% Dig +nocmd +nocomments @one.one.one.one archive.is
;archive.is. IN A
archive.is. 49050 IN A 127.0.0.3
;; Query time: 139 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Oct 3 17:12:50 2019
;; MSG SIZE rcvd: 44
%
Déclaration officielle
archive.today avait ceci à dire sur le problème:
https://Twitter.com/archiveis/status/1017902875949793285
2018-07-13T1545: oui, contrairement aux autres services DNS publics, 1.1.1.1 ne prend pas en charge le sous-réseau client EDNS
https://Twitter.com/archiveis/status/101869142118279168
2018-07-15T1958: "Avoir à faire" n'est pas si direct ici. L'absence d'EDNS et l'inadéquation massive (non seulement sur AS/Pays, mais même au niveau du continent) d'où proviennent les requêtes DNS et HTTP associées causent tellement de problèmes, donc je considère que les requêtes sans EDNS de Cloudflare sont invalides.
Vérification technique
D'un point de vue technique , la revendication pourrait facilement être vérifiée en exécutant les commandes suivantes; on peut remarquer que la grande majorité des résolveurs publics, autres que 1.1.1.1, fournissent en effet un "edns0-client-subnet XX.XX.XX.0/24" réponse, qui est nécessaire pour que les différentes fonctionnalités CDN fonctionnent au mieux.
% Dig +nocmd @dns.google. -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats
o-o.myaddr.l.google.com. 59 IN TXT "172.217.34.2"
o-o.myaddr.l.google.com. 59 IN TXT "edns0-client-subnet XX.XX.XX.0/24"
;; Query time: 28 msec
;; SERVER: 8.8.4.4#53(8.8.4.4)
;; WHEN: Thu Oct 3 17:41:29 2019
;; MSG SIZE rcvd: 113
% Dig +nocmd @resolver1.opendns.com. -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats
o-o.myaddr.l.google.com. 60 IN TXT "2620:0:cc7::68"
o-o.myaddr.l.google.com. 60 IN TXT "edns0-client-subnet XX.XX.XX.0/24"
;; Query time: 20 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Thu Oct 3 17:41:32 2019
;; MSG SIZE rcvd: 115
% Dig +nocmd @one.one.one.one. -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats
o-o.myaddr.l.google.com. 60 IN TXT "162.158.82.18"
;; Query time: 23 msec
;; SERVER: 1.0.0.1#53(1.0.0.1)
;; WHEN: Thu Oct 3 17:41:42 2019
;; MSG SIZE rcvd: 67
% Host 162.158.82.18
Host 18.82.158.162.in-addr.arpa not found: 2(SERVFAIL)
%
Même les résolveurs publics moins populaires qui ne fournissent pas ECS, sont toujours admissibles à l'exception d'archives.today où la géolocalisation du résolveur est triviale à déterminer de manière programmatique:
% Dig +nocmd @a.resolvers.level3.net -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats
o-o.myaddr.l.google.com. 60 IN TXT "8.0.18.0"
;; Query time: 14 msec
;; SERVER: 4.2.2.1#53(4.2.2.1)
;; WHEN: Thu Oct 3 19:24:44 2019
;; MSG SIZE rcvd: 62
% Host 8.0.18.0
0.18.0.8.in-addr.arpa domain name pointer cns1.Frankfurt1.Level3.net.
%
% Dig +nocmd @ordns.he.net -t txt o-o.myaddr.l.google.com +nocomments +noall +answer +stats
o-o.myaddr.l.google.com. 60 IN TXT "216.66.80.30"
;; Query time: 16 msec
;; SERVER: 74.82.42.42#53(74.82.42.42)
;; WHEN: Thu Oct 3 19:26:56 2019
;; MSG SIZE rcvd: 66
% Host 216.66.80.30
30.80.66.216.in-addr.arpa domain name pointer tserv1.fra1.he.net.
%
Conflit d'intérêt
Si vous êtes un opérateur Internet averti, il ne faut pas longtemps pour voir un conflit d'intérêts en jeu également.
La principale activité de Cloudflare est en tant que réseau de distribution de contenu, ainsi que des services associés tels que la protection contre les DDoS et les entraves aux robots.
Pour être plus efficaces, ils demandent à leurs clients (propriétaires de sites Web) d'abandonner complètement le contrôle de la configuration technique de leur site Web. Par exemple, cela inclut une exigence obligatoire de délégation de votre nom de domaine,
example.org, à un ensemble unique decloudflare.com.serveurs de noms - Cloudflare ne permet pas à ses clients de faire des hypothèses sur les adresses IP des services - pas de codage en dur des adresses IP. Cela s'applique non seulement aux serveurs HTTP/HTTPS, mais également au DNS faisant autorité.Fondamentalement, contrairement à Linode et HE.net, ils ne vous permettent même pas, chez Cloudflare, d'étiqueter gratuitement leurs serveurs NS) (c'est-à-dire d'utiliser les adresses IP de Cloudflare avec votre propre nom de domaine, comme
ns1.example.org.si vous êtes propriétaire deexample.org); cela est fait pour que Cloudflare ait le contrôle maximum et complet sur toutes les techniques de correction DoS disponibles, pour pouvoir changer n'importe quelle adresse IP de n'importe quel service vu par n'importe quel client à tout moment, ainsi que pour faciliter le suivi des demandes pour la collecte de données, l'apprentissage automatique et l'analyse des anomalies du trafic.En tant que tel, avec leur nouveau service 1.1.1.1, gratuit pour les utilisateurs finaux et subventionné par leur activité CDN massive, la décision de Cloudflare de refuser à leurs concurrents et non-clients d'avoir accès au même niveau d'information pour leur prise de décision qui Cloudflare lui-même a toujours eu accès à - archive.today gère son propre réseau CDN ici - ne semble pas exactement comme un terrain de jeu égal.
Cela oblige effectivement les opérateurs comme archive.today à succomber aux attaques DoS en ne disposant pas de tous les outils disponibles pour se protéger contre une telle attaque (en donnant aux clients ou sous-réseaux qui se comportent mal une résolution de nom distincte, ainsi qu'en effectuant une détection d'anomalies), ou pour devenir un client Cloudflare CDN - comment pratique pour Cloudflare!
Cloudflare vante sa décision d'omettre le sous-réseau client EDNS en tant qu'initiative de confidentialité (ce qui est une affirmation plutôt fallacieuse, car ECS n'est spécifique qu'à un
/24(/56avec IPv6), et ne fois la résolution DNS terminée, vous devrez quand même émettre votre demande HTTP/HTTPS à partir de votre propre adresse IP ), mais je pense qu'il est facile de lire entre les lignes que la seule monétisation connue de 1.1.1.1 serait le suivi, l'apprentissage automatique et la vente incitative de l'offre CDN de Cloudflare.Le fait de ne pas fournir le sous-réseau client EDNS rend beaucoup plus difficile pour quelqu'un comme archive.today de faire exactement les mêmes choses dans son propre CDN que Cloudflare lui-même aime faire dans son offre commerciale acclamée.
Archive.is a-t-il également un CoI? Peut-être. Les CDN empêchant les robots comme Cloudflare ont eu un effet net positif pour les propriétaires de sites Web au prix d'un effet net négatif significatif sur certains utilisateurs d'Internet moins courants, où certains malchanceux peuvent maintenant être tenus de - résoudre les captchas quotidiennement toute la journée . De toute évidence, il est facile de voir comment les captchas inconscients de Cloudflare peuvent également avoir des effets négatifs importants sur l'archivage de sites Web.
Rien n'est exactement noir et blanc, alors, je vous laisse le lecteur de faire votre propre conclusion.
Voici la déclaration du PDG et co-fondateur de CloudFlare sur Hacker News en mai 2019 à propos de ce problème:
Nous ne bloquons pas archive.is ou tout autre domaine via 1.1.1.1. Nous pensons que cela violerait l'intégrité du DNS et les promesses de confidentialité et de sécurité que nous avons faites à nos utilisateurs lorsque nous avons lancé le service. Les serveurs DNS faisant autorité d'Archive.is renvoient de mauvais résultats à 1.1.1.1 lorsque nous les interrogons. J'ai proposé de le corriger de notre côté, mais notre équipe, à juste titre, a déclaré que cela violerait également l'intégrité du DNS et les promesses de confidentialité et de sécurité que nous avons faites à nos utilisateurs lorsque nous avons lancé le service.
Le propriétaire d’archives.is a expliqué qu’il nous renvoyait de mauvais résultats car nous ne transmettons pas les informations du sous-réseau EDNS. Ces informations divulguent des informations sur l'IP d'un demandeur et, à leur tour, sacrifient la confidentialité des utilisateurs. Cela est particulièrement problématique car nous travaillons pour chiffrer plus de trafic DNS, car la demande du résolveur au DNS faisant autorité n'est généralement pas chiffrée. Nous connaissons des exemples concrets où des acteurs nationaux ont surveillé les informations du sous-réseau EDNS pour suivre les individus, ce qui faisait partie des motivations des politiques de confidentialité et de sécurité du 1.1.1.1.
Les sous-ensembles IP EDNS peuvent être utilisés pour mieux géolocaliser les réponses des services qui utilisent l'équilibrage de charge basé sur DNS. Cependant, la version 1.1.1.1 est fournie sur l'ensemble du réseau de Cloudflare qui couvre aujourd'hui 180 villes. Nous publions les informations de géolocalisation des adresses IP que nous interrogeons. Cela permet à tout réseau avec une densité inférieure à celle dont nous disposons de renvoyer correctement les résultats ciblés par DNS. Pour un opérateur relativement petit comme archive.is, il n'y aurait aucune perte de fidélité d'équilibrage de charge géographique en fonction de l'emplacement du PoP Cloudflare au lieu des sous-réseaux IP EDNS.
Nous travaillons avec le petit nombre de réseaux avec une densité de réseau/FAI plus élevée que Cloudflare (par exemple, Netflix, Facebook, Google/YouTube) pour proposer une alternative de sous-réseau IP EDNS qui leur fournit les informations dont ils ont besoin pour le ciblage de la géolocalisation sans risquer confidentialité et sécurité des utilisateurs. Ces conversations ont été productives et se poursuivent. Si archive.is a des suggestions dans ce sens, nous serions heureux de les considérer.
C'est une question très intéressante et j'y ai beaucoup réfléchi.
La réponse en une phrase est "parce que archive.is bloque les requêtes DNS des centres de données de Cloudflare ". Cela conduit bien sûr à la question centrale: "pourquoi?".
Ce comportement de archive.is est particulièrement intrigant pour moi car archive.is semble mettre l'accent sur l'anti-censure et la résilience, mais bloquer les utilisateurs 1.1.1.1 semble contraire à cela. La réponse de cnst est certainement intéressante et plausible, mais j'ai trouvé ma propre hypothèse qui est quelque peu similaire.
Conformité à la censure juridique robuste mais granulaire
Disons que vous exploitez un site Web et que vous devez censurer le contenu illégal. Vous pourriez trouver 3 règles:
Si le contenu est illégal dans le pays
X, ce contenu ne doit pas être diffusé aux utilisateurs du paysX.Si le contenu est illégal dans le pays
X, ce contenu ne doit jamais toucher les serveurs du paysX. Il ne doit donc pas être stocké sur ces serveurs, ni être mandaté via ces serveurs.Si le contenu est légal dans le pays
X, nous tenterons (dans des limites raisonnables) de mettre ce contenu à la disposition des utilisateurs du paysX.
Exemple simple
Prenons un exemple simple: vous avez un contenu A qui est illégal dans tous les pays du monde sauf le pays X. Comment pouvons-nous exploiter notre site Web conformément aux règles énoncées? C'est assez simple, mettez tous nos serveurs dans X, et si une demande de A vient du pays X, servez-la. Si une demande de A vient du pays Y, donnez un 404.
Exemple complexe
Maintenant, prenons un exemple plus compliqué: vous avez un contenu A qui est illégal dans tous les pays du monde sauf le pays X. Vous avez un contenu B qui est illégal dans tous les pays du monde sauf le pays Y. Maintenant, il n'y a plus de solution simple. Mais voici une solution compliquée:
Utilisez des serveurs dans X qui ont A mais pas B. Si les serveurs de X reçoivent une demande de A de X, servez-la. Si les serveurs de X reçoivent une demande de A de l'extérieur X, donnez un 404. Et de même pour Y et B. Si des serveurs reçoivent une demande de contenu, ils n'en ont pas, ils donnent un 404.
Utilisez un serveur DNS faisant autorité personnalisé pour votre site. S'il reçoit une demande DNS avec l'EDNS en tant qu'IP dans X, répondez avec l'adresse IP d'un serveur dans X. S'il reçoit une demande DNS avec l'EDNS en tant qu'IP dans Y, répondez avec l'adresse IP d'un serveur dans Y. S'il reçoit une demande DNS avec l'EDNS en tant qu'IP dans un pays nonX et nonY, choisissez arbitrairement une adresse IP de serveur avec laquelle répondre.
Cloudflare entre
Si vous essayez d'implémenter cette solution, vous aurez un problème: certains résolveurs DNS (comme 1.1.1.1) ne vous donnent pas l'EDNS, donc ce n'est pas possible. Donc archive.is aurait pu le faire, puis s'est rendu compte qu'il échouait pour certains résolveurs DNS, et plutôt que d'avoir un site semi-cassé, ils ont décidé de bloquer les utilisateurs qui utilisent ces résolveurs. Il reste cependant la question ouverte de savoir pourquoi bloquer uniquement certains résolveurs sans EDNS (tels que 1.1.1.1) et pas autre récupère sans EDNS .
Preuve
J'ai trouvé des preuves en faveur de cette explication du comportement de archive.is.
Archive.is exécute certains serveurs DNS spéciaux sur Linode et DigitalOcean . Lorsque Linode plaint que ces serveurs DNS ont été utilisés d'une manière ou d'une autre pour aider à distribuer du contenu controversé, archive.is s'est défendu en disant que ces serveurs n'étaient que des serveurs DNS, le contenu ne touche jamais ces serveurs. Cette défense utilise le même raisonnement que la règle 2 ci-dessus, à savoir que ce qui importe est de savoir si le contenu touche les serveurs spécifiques.
De plus, dans cette même conversation, Linode s'est plaint que archive.is faisait un blocage basé sur l'IP de l'utilisateur. Archive.is a répondu que oui, ils pratiquent la censure en fonction du pays dans lequel se trouve l'utilisateur. C'est un comportement très similaire à ce que j'ai proposé dans la solution complexe. Comme note latérale intéressante, archive.is considère ce type de censure comme améliorant la légalité en s'assurant que les utilisateurs ne voient pas le contenu interdit, tandis que Linode le voit exactement même comportement que nuisant à la légalité, en obscurcissant le comportement, en cachant des preuves et en rendant difficile les recherches de Linode.
Archive.is dit qu'ils utilisent outils de déploiement modernes et le marché du cloud très compétitif pour éviter les suppressions abusives, ce qui pourrait indiquer une configuration compliquée avec des serveurs dans de nombreux pays et une sorte de système d'orchestration pour les gérer.
Conclusion
Nous ne savons pas avec certitude le raisonnement de archive.is pour leur comportement car ils ne se sont pas pleinement expliqués. Si leur raisonnement est basé sur la loi, ils craignent peut-être que l'explication de leur configuration juridique expose les trous juridiques dans leur configuration.
Les lacunes dans les explications que archive.is a laissées offrent une opportunité de spéculation technique et philosophique intéressante.