it-swarm.asia

لماذا 1.1.1.1 لا يحل archive.is؟

عندما أحاول الوصول http://archive.is/ مع DNS من خلال 1.1.1.1 ، لا يعمل. لماذا ا؟

% 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

%
78
cnst

الخطاب الرسمي

archive.today = يقول هذا عن المشكلة:

https://Twitter.com/archiveis/status/1017902875949793285

2018-07-13T1545: نعم ، على عكس خدمات DNS العامة الأخرى ، 1.1.1.1 لا يدعم الشبكة الفرعية لعميل EDNS

https://Twitter.com/archiveis/status/101869142118279168

2018-07-15T1958: "الاضطرار إلى" ليس مباشرًا هنا. عدم وجود EDNS وعدم تطابق هائل (ليس فقط في AS/Country ، ولكن حتى على مستوى القارة) حيث تأتي طلبات DNS و HTTP ذات الصلة من العديد من المشاكل لذا فأنا أعتبر الطلبات الأقل من EDNS من Cloudflare غير صالحة.


التحقق الفني

من منظور تقني ، يمكن التحقق من المطالبة بسهولة عن طريق تشغيل الأوامر التالية ؛ يمكن للمرء أن يلاحظ أن الغالبية العظمى من المحللين العامين ، بخلاف 1.1.1.1 ، يقدمون بالفعل "edns0-client-subnet XX.XX.XX.0/24" الجواب ، وهو أمر ضروري لكي تعمل وظائف CDN المختلفة بأفضل ما لديها.

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

حتى المحللون العامون الأقل شهرة الذين لا يقدمون ECS ، لا يزالون مؤهلين بموجب أرشيف اليوم ، حيث يكون تحديد الموقع الجغرافي للمحلل أمرًا تافهًا لتحديد بطريقة آلية:

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

تضارب المصالح

إذا كنت من مستخدمي الإنترنت المحنكين ، فلن يستغرق الأمر وقتًا طويلاً لرؤية تضارب في المصالح أثناء اللعب أيضًا.

  • إن خط أعمال Cloudflare الرئيسي هو شبكة توصيل المحتوى ، بالإضافة إلى الخدمات المرتبطة مثل حماية DDoS وإعاقة البوت.

    ليكونوا أكثر فعالية ، يطلبون من عملائهم (مالكي مواقع الويب) التخلي تمامًا عن التحكم في الإعداد الفني لموقعهم على الويب. على سبيل المثال ، يتضمن هذا متطلبًا إلزاميًا لتفويض اسم نطاقك ، example.org ، لمجموعة فريدة من cloudflare.com. خوادم الأسماء - لا تسمح Cloudflare لعملائها بإجراء أي افتراضات حول أي عناوين IP لأي خدمات على الإطلاق - لا يوجد ترميز ثابت لعنوان IP. وهذا لا ينطبق فقط على خوادم HTTP/HTTPS ، ولكن أيضًا على DNS الموثوق به أيضًا.

    بشكل أساسي ، على عكس Linode و HE.net ، فإنهم في Cloudflare لا يسمحون لك حتى بتسمية خوادمهم NS مجانًا (على سبيل المثال ، استخدم عناوين IP الخاصة بـ Cloudflare مع اسم نطاقك الخاص ، مثل ns1.example.org. إذا كنت مالك example.org) ؛ يتم ذلك من أجل أن يكون لدى Cloudflare أقصى قدر من التحكم الكامل في جميع تقنيات معالجة DoS المتاحة ، حتى تتمكن من تغيير أي عنوان IP لأي خدمة كما يراها أي عميل في أي وقت ، بالإضافة إلى تسهيل تتبع الطلبات لجمع البيانات ، والتعلم الآلي ، وتحليل شذوذ حركة المرور.

    على هذا النحو ، مع خدمتهم الجديدة 1.1.1.1 ، المجانية للمستخدمين النهائيين ، والمدعومة من أعمال CDN الضخمة ، قرر Cloudflare منع منافسيهم وغير العملاء من الوصول إلى نفس المستوى من المعلومات لاتخاذ قراراتهم التي Cloudflare نفسها كان لديها دائمًا إمكانية الوصول إلى - archive.today تدير شبكة CDN الخاصة بها هنا - لا يبدو تمامًا مثل مجال لعب متكافئ.

    وهذا يجبر المشغلين بشكل فعال مثل archive.today إما على الخضوع لهجمات DoS من خلال عدم وجود جميع الأدوات المتاحة تحت تصرفهم لحماية أنفسهم من مثل هذا الهجوم (من خلال إعطاء عملاء أو شبكات فرعية يسيئون التصرف دقة اسم مميزة ، وكذلك الكشف عن الشذوذ) ، أو لتصبح عميل Cloudflare CDN - ما مدى ملاءمة Cloudflare!

    تروج Cloudflare لقرارها حذف EDNS Client Subnet كمبادرة خصوصية (وهو ادعاء مخادع إلى حد ما ، لأن ECS تقتصر على /24 (/56 مع IPv6) و بعد اكتمال حل نظام أسماء النطاقات ، سيظل عليك إصدار طلب HTTP/HTTPS من عنوان IP الخاص بك على أي حال ) ، ولكن أعتقد أنه من السهل القراءة بين الخطوط التي سيكون تحقيق الربح الوحيد المعروف من 1.1.1.1 هو تتبع التعلم الآلي وزيادة مبيعات عرض CDN الخاص بـ Cloudflare.

    الفشل في توفير الشبكة الفرعية لعميل EDNS يجعل الأمر أكثر صعوبة بشكل كبير بالنسبة لشخص مثل - archive.today للقيام بنفس الأشياء بالضبط في CDN الخاصة به التي يتمتع بها Cloudflare نفسه في عرضه التجاري المشهود.

  • هل يحتوي الأرشيف. على CoI أيضًا؟ ربما. كانت شبكات CDN التي تعوق الروبوت مثل Cloudflare لها تأثير إيجابي صافٍ على مالكي مواقع الويب بسعر تأثير صافي سلبي كبير على بعض مستخدمي الإنترنت الأقل شيوعًا ، حيث قد يُطلب من بعض غير المحظوظين الآن - حل اختبار CAPTCHA بشكل يومي طوال اليوم . من الواضح أنه من السهل أن نرى كيف يمكن أن يكون لكلمة CAPTCHA الغامضة آثار سلبية كبيرة على أرشفة مواقع الويب أيضًا.

لا يوجد شيء أبيض وأسود تمامًا ، لذا سأترك لك القارئ لتشكيل استنتاجك الخاص.

74
cnst

هذا هو بيان الرئيس التنفيذي والشريك المؤسس لـ CloudFlare على Hacker News في مايو 2019 حول هذه المشكلة:

نحن لا نحظر archive.is أو أي مجال آخر عبر 1.1.1.1. نعتقد أن القيام بذلك من شأنه أن ينتهك سلامة DNS وخصوصية الخصوصية والأمان التي قطعناها على أنفسنا لمستخدمينا عندما أطلقنا الخدمة. تُرجع خوادم DNS الموثوقة Archive.is النتائج السيئة إلى 1.1.1.1 عندما نستعلم عنها. لقد اقترحت أن نصلحها فقط من ناحيتنا ، لكن فريقنا ، عن حق ، قال إن ذلك أيضًا من شأنه أن ينتهك سلامة DNS ووعود الخصوصية والأمن التي قطعناها على أنفسنا لمستخدمينا عندما أطلقنا الخدمة.

شرح مالك archis.is أنه يعيد نتائج سيئة إلينا لأننا لا نمرر معلومات الشبكة الفرعية EDNS. تسرِّب هذه المعلومات معلومات حول عنوان IP لمقدم الطلب ، وتضحي بدورها بخصوصية المستخدمين. يعد هذا أمرًا صعبًا بشكل خاص لأننا نعمل على تشفير المزيد من حركة مرور DNS حيث أن الطلب من Resolver إلى DNS الرسمي غير مشفر عادةً. نحن على دراية بأمثلة من العالم الحقيقي حيث قام ممثلو الدولة بمراقبة معلومات الشبكة الفرعية EDNS لتتبع الأفراد ، والتي كانت جزءًا من الدافع لسياسات الخصوصية والأمان 1.1.1.1.

يمكن استخدام مجموعات EDNS IP الفرعية لتحسين تحديد موقع الاستجابات الجغرافية للخدمات التي تستخدم موازنة التحميل المستندة إلى DNS. ومع ذلك ، يتم تسليم 1.1.1.1 عبر شبكة Cloudflare بأكملها والتي تمتد اليوم إلى 180 مدينة. ننشر معلومات تحديد الموقع الجغرافي لعناوين IP التي نستعلم منها. يسمح ذلك لأي شبكة ذات كثافة أقل مما يجب علينا بإرجاع النتائج التي تستهدف DNS بشكل صحيح. بالنسبة لمشغل صغير نسبيًا مثل arch.is ، لن يكون هناك خسارة في دقة موازنة التحميل الجغرافي اعتمادًا على موقع Cloudflare PoP بدلاً من الشبكات الفرعية EDNS IP.

نحن نعمل مع عدد قليل من الشبكات ذات كثافة شبكة/ISP أعلى من Cloudflare (على سبيل المثال ، Netflix و Facebook و Google/YouTube) للتوصل إلى بديل EDNS IP Subnet الذي يوفر لهم المعلومات التي يحتاجونها لاستهداف الموقع الجغرافي دون المخاطرة خصوصية وأمان المستخدم. كانت تلك المحادثات مثمرة ومستمرة. إذا كان لـ archive.is اقتراحات على هذا المنوال ، يسعدنا التفكير فيها.

تحرير: a سلسلة أخبار Hacker جديدة في أكتوبر 2019

57
pba

هذا سؤال مثير للاهتمام ، وقد فكرت فيه كثيرًا.

الجواب من جملة واحدة هو "لأن archive.is يمنع طلبات DNS من مراكز بيانات Cloudflare ". وهذا بالطبع يقود إلى السؤال الجوهري: "لماذا؟".

هذا السلوك من الأرشيف هو مثير للاهتمام بالنسبة لي بشكل خاص لأن الأرشيف. يبدو أنه يركز على كونه مناهضًا للرقابة وأن يكون مرنًا ، ولكن حظر 1.1.1.1 يبدو أن المستخدمين يتعارضون مع ذلك. إجابة cnst مثيرة للاهتمام ومقبولة بالتأكيد ، لكني توصلت إلى فرضية الحيوانات الأليفة الخاصة بي التي تشبه إلى حد ما.

الامتثال القوي للرقابة القانونية الدقيقة

لنفترض أنك تدير موقعًا إلكترونيًا ، ويجب عليك مراقبة المحتوى غير القانوني. قد تتوصل إلى 3 قواعد:

  1. إذا كان المحتوى غير قانوني في البلد X ، فيجب عدم عرض هذا المحتوى للمستخدمين في البلد X.

  2. إذا كان المحتوى غير قانوني في البلد X ، يجب ألا يلمس هذا المحتوى الخوادم في البلد X. لذلك يجب ألا يتم تخزينها على تلك الخوادم ، ولا يجب أن يتم تحويلها عبر الخوادم.

  3. إذا كان المحتوى قانونيًا في البلد X ، فسنحاول (ضمن السبب) إتاحة هذا المحتوى للمستخدمين في البلد X.

مثال بسيط

لنأخذ مثالاً بسيطًا: لديك جزء من المحتوى A غير قانوني في كل بلد في العالم باستثناء البلد X. كيف يمكننا تشغيل موقعنا الإلكتروني ضمن القواعد المنصوص عليها؟ هذا بسيط إلى حد ما ، ضع جميع خوادمنا في X ، وإذا كان طلب A يأتي من البلد X ، فقم بتقديمه. إذا كان طلب A يأتي من البلد Y ، أعط 404.

مثال معقد

الآن دعونا نحصل على مثال أكثر تعقيدًا: لديك جزء من المحتوى A غير قانوني في كل بلد في العالم باستثناء البلد X. لديك جزء من المحتوى B غير قانوني في كل بلد في العالم باستثناء البلد Y. الآن لم يعد هناك حل بسيط. ولكن إليك حل معقد:

تشغيل الخوادم في X التي تحتوي على A ولكن ليس B. إذا كانت الخوادم في X تتلقى طلبًا لـ A من X ، فقدمها. إذا كانت الخوادم في X تتلقى طلبًا لـ A من خارج X ، فقم بإعطاء 404. وبالمثل لـ Y و B. إذا تلقت أي خوادم طلبًا للحصول على محتوى ، فليس لديها 404.

قم بتشغيل خادم DNS موثوق به مخصص لموقعك. إذا تلقى طلب DNS مع EDNS باعتباره IP في X ، فاستجب بعنوان IP الخاص بالخادم في X. إذا تلقى طلب DNS مع EDNS باعتباره IP في Y ، فاستجب بعنوان IP الخاص بالخادم في Y. إذا تلقى طلب DNS مع EDNS كعنوان IP في بعض البلدان غير X وغير _Y ، فاختر بشكل تعسفي عنوان IP للخادم للرد عليه.

يدخل Cloudflare

إذا حاولت تنفيذ هذا الحل فعليًا ، فستواجه مشكلة: بعض محللو DNS (مثل 1.1.1.1) لا يمنحك EDNS ، لذا لا يمكن ذلك. لذلك ربما كان archive.is قد فعل ذلك ، ثم أدرك أنه فشل لبعض محللي DNS ، وبدلاً من أن يكون لديه موقع شبه مكسور ، قرروا حظر المستخدمين الذين يستخدمون تلك المحللون. لا يزال هناك سؤال مفتوح على الرغم من سبب حظر فقط بعض المحللون EDNS (مثل 1.1.1.1) و ليس أخرى EDNS-less يسترد .

دليل

لقد وجدت بعض الأدلة المؤيدة لهذا التفسير لسلوك الأرشيف.

يقوم Archive.is بتشغيل بعض خوادم DNS الخاصة على Linode و DigitalOcean . عندما Linode يشكو من أن خوادم DNS هذه تم استخدامها بطريقة ما للمساعدة في توزيع المحتوى المثير للجدل ، دافع archive.is عن نفسه بقوله أن هذه الخوادم ليست سوى خوادم DNS ، ولا يلمس المحتوى تلك الخوادم أبدًا. يستخدم هذا الدفاع نفس المنطق الذي تستخدمه القاعدة 2 من الأعلى ، أي أن ما يهم هو ما إذا كان المحتوى يلامس خوادم معينة.

بالإضافة إلى ذلك ، في تلك المحادثة نفسها ، اشتكى لينود من أن الأرشيف كان يقوم بالحظر بناءً على عنوان IP للمستخدم. رد Archive.is بنعم ، إنهم يمارسون الرقابة بناءً على البلد الذي يوجد فيه المستخدم. هذا سلوك مشابه جدًا لما اقترحته في الحل المعقد. كملاحظة جانبية مثيرة للاهتمام ، رأى archive.is هذا النوع من الرقابة على أنه تحسين الشرعية من خلال ضمان عدم رؤية المستخدمين للمحتوى المحظور ، في حين أن Linode شاهد هذا بالضبط نفس السلوك إيذاء الشرعية ، من خلال تشويش السلوك ، وإخفاء الأدلة ، وتجعل من الصعب على Linode التحقيق.

Archive.is يقول أنهم يستخدمون أدوات النشر الحديثة والسوق السحابي عالي التنافسية لمنع عمليات الإزالة الخاطئة ، والتي قد تشير إلى إعداد معقد مع خوادم عبر العديد من البلدان ونوع من نظام التنسيق لإدارتها.

استنتاج

لا نعلم بالنسبة لأرشيف معين. إنه سبب سلوكهم لأنهم لم يشرحوا أنفسهم بشكل كامل. إذا كان تفكيرهم قائمًا على القانون ، فربما يخشون من أن شرح إعدادهم القانوني سيكشف عن ثغرات قانونية في إعدادهم.

توفر الثغرات في التفسير التي تركها archive.is فرصة لبعض التكهنات التقنية والفلسفية المثيرة للاهتمام.

20
Buge