نام، نرمترین بخشِ این مجموعه است
سروری در ریکیاویک که با Monero پرداخت شده، بدونِ حساب و بدونِ بررسیِ هویت، واقعاً گرفتنش از شما دشوار است. شرکتی که آن را به شما اجاره میدهد در یک کشور است، سختافزار در کشوری دیگر، پرداخت هیچ نامی برجای نگذاشته، و هرکس که بخواهد ماشین را خاموش کند باید دادگاهی را در حوزهٔ قضاییای متقاعد کند که دقیقاً به این دلیل انتخاب شده که به چنین درخواستی کمکی نمیکند. این همان بخشی از مجموعه است که صنعتِ میزبانیِ آفشور بیست سال صرفِ درستکردنش کرده.
دامنه اصلاً اینطور نیست. شما مالکِ دامنه نیستید — هیچکس نیست. شما یک اجارهٔ قابلِتمدید در دست دارید، ثبتشده توسطِ یک ثبتکننده، تفویضشده توسطِ یک ریجیستری، تحتِ قراردادی که فقط کلیکش کردهاید، و هر طرفی که در آن زنجیره بالادستِ شماست میتواند بدونِ دخالتِ شما و معمولاً بدونِ هیچ قاضیای روی نام اقدام کند. نامتقارنی، کلِ ماجراست: رسیدن به میزبان یعنی یک حکمِ دادگاهِ خارجی و ماهها زمان؛ رسیدن به ثبتکننده یعنی یک فرمِ شکایت و، در یک روزِ بد، فقط یک بعدازظهر.
این موضوع برای پروژههای کاملاً معمولی هم اهمیت دارد. روزنامهنگاریِ مستقل، آینههایی از موادی که کسی ترجیح میداد آفلاین بماند، بایگانیها، کسبوکارهای بزرگسالانی که در همهجایی که فعالیت میکنند قانونیاند، پژوهشِ امنیتی، نقدهایی که یک شرکتِ دارایِ بخشِ حقوقی را عصبانی میکند — هیچکدام از اینها غیرقانونی نیست، و همهٔ آنها فشاری جذب میکنند که هدفش هرکدام از حلقههای زنجیره است که خمکردنش ارزانتر باشد. آن حلقه تقریباً هرگز میزبانِ آفشور نیست. ثبتکننده است، و از طریقِ ایمیل به آن میرسند.
پس این راهنما دربارهٔ پنهانشدن از نیروهای اجراییِ قانون نیست، که مسئلهای دیگر با پاسخی دیگر است و میزبانی نمیتواند حلش کند. این راهنما دربارهٔ دو چیزِ محدودتر و دستیافتنیتر است: ندادنِ این امکان به یک غریبهٔ ناراضی که از رویِ یک استعلامِ عمومی بفهمد شما که هستید، و در فاصلهٔ یک شکایتِ بیبررسی از دستدادنِ نامی نبودن که کلِ پروژهتان به آن پاسخگوست.
ترتیبِ عملیاتی که در ادامه میآید عامدانه است، چون بیشترِ توصیهها دربارهٔ این موضوع با «حریمِ خصوصیِ WHOIS را روشن کنید» شروع و تمام میشود — که از میانِ شش تصمیمِ مهم، بهوضوح کماهمیتترین است. اول حوزهٔ قضاییِ ریجیستری میآید، دوم خلقوخویِ ثبتکننده، سوم مدلِ ثبت، چهارم مسیرِ پرداخت، پنجم اپراتورِ DNS، و ششم بایگانیهایی که همهچیز را بهیاد میسپارند.
WHOIS بعد از توقفِ انتشار هنوز چه چیزی را ثبت میکند؟
در 2018، قانونِ حفاظت از دادههای اروپا با یک پایگاهدادهٔ عمومی که از دههٔ 1980 نام، نشانیِ پستی، ایمیل و شمارهٔ تلفنِ هر مالکِ دامنه را منتشر میکرد برخورد کرد، و بخشِ عمومیِ ماجرا بازنده شد. امروز یک دامنهٔ سطحبالای عمومی را استعلام بگیرید تا ثبتکننده، تاریخهای ایجاد و انقضا، سرورهای نام، کدهای وضعیت و یک مخاطبِ رلهایِ ناشناسسازیشده را ببینید. فیلدهای شخصی این را مینویسند: REDACTED FOR PRIVACY.
این را با دقت بخوانید، چون این تغییری در سیاستِ انتشار است، نه در سیاستِ داده. ثبتکننده هنوز نام، نشانی، ایمیل و تلفنِ شما را جمعآوری میکند. هنوز ابزارِ پرداختِ شما، آدرسِ IP ای که با آن ثبتنام کردهاید، و آدرسِ IP هر ورودی از آنموقع تا حالا را دارد. قراردادِ اعتبارنامهاش آن را ملزم میکند که آن داده را جمعآوری کند، نگهش دارد، و دستِکم آدرسِ ایمیل را تأیید کند. پنهانسازی، رکورد را پشتِ یک باجه برد؛ چیزی حذف نشد، و آن باجه کارمند دارد.
پروتکلِ استعلام هم تغییر کرد. سرویسِ متنیِ رویِ پورتِ 43 که همه آن را WHOIS مینامند، برای دامنههای عمومی جای خود را به RDAP داده، یک واسطِ JSONِ ساختیافته با چیزی که پروتکلِ قدیمی هرگز نداشت: یک لایهٔ احرازهویتشده. به درخواستدهندگانِ معتبر میتوان فیلدهایی را نشان داد که پرسوجوی عمومیِ ناشناس هرگز نمیبیند. میتوانید خودتان نمایِ عمومی را در ICANN Lookup امتحان کنید؛ فرض کنید آن نما کفِ چیزی است که افشا میشود، نه سقفش.
بخشی که مردم کاملاً فراموشش میکنند، تاریخچه است. بایگانیهای تجاری دو دهه است که بهطورِ پیوسته از سوابقِ ثبت اسنپشات میگیرند، از جمله سالهایی که همهچیز بهطورِ کامل منتشر میشد. اگر نامی از آنِ شما هرگز بهصورتِ علنی ثبت شده باشد — یک پروژهٔ سرگرمی در 2015، دامنهٔ یک شرکت، هر چیزی که آدرسِ ایمیلِ شما را به اشتراک گذاشته — آن رکورد برای همیشه، توسطِ هرکسی که حاضر باشد بابتِ یک استعلام پول بدهد، قابلِبازیابی است. پنهانسازی از چیزی که فردا ثبت میکنید محافظت میکند. دربارهٔ چیزی که پیش از اینکه برایتان مهم شود ثبت کردهاید، کاملاً هیچ کاری نمیکند.
پسوندهای کدِ کشوری کاملاً بیرون از همهٔ اینها میایستند. آنها مقیدِ سیاستِ دامنههای عمومی نیستند، و هر ریجیستری قوانینِ خودش را تعیین میکند: بعضی دارنده را کامل منتشر میکنند، بعضی هیچچیز منتشر نمیکنند، و چند تایی الزامِ اقامت یا حضورِ محلی تحمیل میکنند که چیزی نیست جز یک بررسیِ هویت با کلاهی دیگر بر سر. ریجیستریِ .eu دقیقاً نشان داد این موضوع میتواند چقدر تیز باشد، وقتی دهها هزار نامِ در دستِ دارندگانِ بریتانیایی، بعد از Brexit دیگر قاعدهٔ واجدشرایطبودن را برآورده نکردند و پس گرفته شدند. قواعدِ واجدشرایطبودن با بررسیِ اینکه شما که هستید اجرا میشوند.
پیامدِ عملیاش قاعدهای است که ارزش دارد پیش از خرجِ حتی یک سنت درونیاش کنید: پیش از هر کاری بررسی کنید دربارهٔ هر شناسهای که میخواهید دوباره استفاده کنید، از قبل چه چیزی عمومی است. آدرسِ ایمیلی که در یک ثبتِ عمومیِ قبلی استفاده کردهاید، نامِ جدید را در یک پرسوجوی واحد به نامِ قدیمی وصل میکند، و هیچمقدار پنهانسازی روی رکوردِ جدید این را خنثی نمیکند.
چه کسی میتواند نام را از شما بگیرد، و هرکدام پاسخگوی چه کسیاند؟
چهار طرف بالادستِ شما هستند، و هرکدام به فشارهای متفاوتی با سرعتهای متفاوتی واکنش نشان میدهند. دانستنِ اینکه کدامیک کدام است، فرقِ بینِ پاسخدادنِ درست به یک اطلاعیه و ازدستدادنِ نامی است که میتوانستید نگهش دارید.
ثبتکننده سریعترین طرف است و کمتر از همه در معرضِ بازبینی. میتواند تحتِ سیاستِ استفادهٔ قابلِقبولِ خودش نام را معلق یا حذف کند، و بدهکارِ هیچ جلسهٔ استماعی به شما نیست — در بعضی شرکتها یک شکایت، یک خطِ لولهٔ خودکارِ رسیدگی به سوءاستفاده، یا یک اختلافِ پرداخت کافی است. این همان لایهای است که ارزش دارد بابتِ اعتبار هزینه کنید، چون تنها دفاعِ معنادار این است که ثبتکنندهای انتخاب کرده باشید که پیش از اقدام روی شکایتها، آنها را میخواند.
ریجیستری بالادستِ ثبتکننده مینشیند و کدهای وضعیتی اعمال میکند که هیچ ثبتکنندهای نمیتواند بردارد. نامی که روی توقفِ ریجیستری قرار گرفته — وضعیتِ serverHold — از هر نظرِ رسمی همچنان مالِ شماست، اما بههیچوجه بهجایی resolve نمیشود، که دقیقاً همارزِ رفتن است. ریجیستریها بر اساسِ حکمهای دادگاه در حوزهٔ قضاییِ خودشان و بر اساسِ سیاستهای منتشرشدهٔ خودشان اقدام میکنند، و در بعضی کشورها بر اساسِ یک رویهٔ اداریِ صریح که در قانونِ ملی نوشته شده.
بعد رویههای حلِ اختلاف هستند، که برای تعارضهای علامتِ تجاری وجود دارند و هدفشان نام است، نه چیزی که رویش منتشر میکنید. سیاستِ یکپارچهٔ حلوفصلِ اختلافِ نامِ دامنه (UDRP) میتواند در عرضِ چند هفته یک نام را به شاکی منتقل کند، تصمیمی که یک هیئت میگیرد، رویِ کاغذ، با یک پنجرهٔ پاسخدهی که نباید از دستش بدهید. نسخهٔ سریعترِ آن بهجایِ انتقال، معلق میکند. هیچکدام دادگاه نیستند، هردو برایِ ثبتکنندهٔ شما الزامآورند، و هردو بهصورتِ تاکتیکی توسطِ طرفهایی استفاده میشوند که اعتراضِ واقعیشان به محتوای شماست.
در نهایت، توقیف. هر دادگاهی که بر ریجیستری صلاحیتِ قضایی داشته باشد میتواند دستور به انتقال یا نگهداشتنِ یک نام بدهد، فارغ از اینکه دارنده کجا زندگی میکند یا کدام ثبتکننده آن را فروخته. این همان واقعیتی است که بخشِ بعدی را تعیین میکند: چون اپراتورِ دو تا از بزرگترین پسوندهای جهان شرکتی در ویرجینیاست، هر .com و هر .net ای که وجود دارد در دسترسِ یک حکمِ دادگاهِ ایالاتِ متحده است. بایگانیِ EFF از توقیفِ دامنهها نسخهٔ مفصلِ همین جمله است.
روی هم که بگذاریم: ثبتکنندهٔ شما تعیین میکند نام با چه سهولتی به یک شکایت باخته میشود، و ریجیستریِ شما تعیین میکند کدام دادگاهها میتوانند آن را بگیرند. اینها دو تصمیمِ جداگانهاند، و شما هردویشان را در همان لحظهٔ خرید میگیرید، معمولاً بدونِ اینکه متوجه شوید هیچکدام را گرفتهاید.
انتخابِ پسوند، انتخابِ یک حوزهٔ قضایی است
این تأثیرگذارترین تصمیم در کلِ این فرایند است، هیچ هزینهای ندارد، و تقریباً هیچکس آگاهانه آن را نمیگیرد. روش، سی ثانیه کار است: پسوند را در پایگاهدادهٔ ناحیهٔ ریشهٔ IANA جستوجو کنید، سازمانِ حامی و نشانیاش را بخوانید، و بپذیرید که دادگاههای کشورِ آن سازمان از حالا بخشی از مدلِ تهدیدِ شما هستند.
نتیجهها مردم را غافلگیر میکند. پسوندهایی که حسِ فنی، بینالمللی یا کمابیش جایگزین دارند، اغلب توسطِ شرکتهای بزرگِ آمریکایی اداره میشوند — پسوندهای دوحرفیِ محبوبِ توسعهدهندهها، از میانِ یک رشته تصاحب، نهایتاً زیرِ مالکیتِ شرکتیِ ایالاتِ متحده قرار گرفتند، و شمارِ زیادی از پسوندهای عمومیِ جدیدتر هم زیرِ یک گروهِ ریجیستریِ آمریکایی واحد نشستهاند. حسِ جایگزینبودن برای .com، برندسازی است. همحوزهبودن با .com، یک واقعیتِ حقوقی است.
پسوندهای کدِ کشوری به همان اندازهٔ خودِ کشورها با هم فرق دارند، و محورِ کاربردی نه «کدام کشور بهترین شهرتِ حریمِ خصوصی را دارد» بلکه «چه رویهای وجود دارد، و چه کسی میتواند به آن استناد کند» است. ریجیستریِ ایسلند بهخوبی مورد احترام است، چون موضعِ منتشرشدهاش این است که بر اساسِ حکمهای دادگاهِ ایسلندی عمل میکند، نه مکاتباتِ خارجی — برای قوانینِ فعلی ISNIC را ببینید. سوئیس هم قانونِ حریمِخصوصیِ قوی دارد و هم یک مسیرِ مسدودسازیِ اداریِ مستند که در آییننامهٔ دامنهاش نوشته شده، که دقیقاً شکلِ واقعیِ حاکمیتِ قانون است و در عینِ حال رویهای است که وجود دارد. قانونِ خوب با نبودِ رویه یکی نیست، و شما میخواهید بدانید کدامیک را میخرید.
همزمان، ویژگیهای عملیاتیِ کسلکننده را هم بسنجید، چون بعداً نیش میزنند: اینکه آیا ریجیستری از قفلِ ریجیستری و DNSSEC پشتیبانی میکند، آیا پسوند الزامِ اقامت دارد، تمدید در سالِ سوم چقدر هزینه دارد، و رشته چقدر از نظرِ سیاسی بادوام است. پسوندی که از طرفِ یک قلمرو تفویض شده میتواند دستبهدست شود، سیاستش تغییر کند، یا درگیرِ دیپلماسیِ کسِ دیگری شود. این استدلالی علیهِ استفاده از چنین پسوندی نیست — استدلالی علیهِ ساختنِ هویتی است که نمیتوانید جابهجایش کنید.
| خانوادهٔ پسوند | اپراتورِ ریجیستری کجاست | پیامدِ عملی | چه زمانی هنوز انتخابِ درستی است |
|---|---|---|---|
| .com و .net | ایالاتِ متحده | حکمِ دادگاهِ آمریکا به نام میرسد، فارغ از ثبتکننده یا کشورِ خودتان | پروژههای تجاریای که شناختهشدگی واقعاً از حوزهٔ قضایی مهمتر است |
| .org، .info و بیشترِ پسوندهای عمومیِ جدید | ایالاتِ متحده | همان دسترسی؛ حسِ جایگزینبودنِ یک پسوندِ جدید بازاریابی است، نه قانون | وقتی نامی توصیفی میخواهید و آن دسترسی را پذیرفتهاید |
| پسوندهای دوحرفیِ محبوبِ فنی | اپراتورِ ایالاتِ متحده، رشتهای وابسته به یک قلمرو | دسترسیِ آمریکا بهعلاوهٔ ریسکِ سیاسیِ رشتهای وابسته به یک قلمرو | محصولاتِ روبهتوسعهدهنده که میتوانند تغییرِ نام را هم از سر بگذرانند |
| کدهای کشوریِ ایسلند و نوردیک | خودِ آن کشور | سیاستِ ریجیستری حولِ حکمهای دادگاهِ داخلی است؛ حفاظتِ قویِ آزادیِ بیان | پروژههای نشر، روزنامهنگاری و بایگانی که خانهای خوانا میخواهند |
| کدهای کشوریِ سوئیس و لیختناشتاین | سوئیس، لیختناشتاین | قانونِ حریمِخصوصیِ قوی در کنارِ یک مسیرِ مسدودسازیِ اداریِ مشخص | پروژههای بلندعمر که برای ثبات ارزش قائلاند و یک رویهٔ شناختهشده را میپذیرند |
| کدهای کشوریِ کشورهای عضوِ EU | کشورِ عضو یا یک نهادِ EU | قواعدِ اقامت یا حضورِ محلی یک بررسیِ هویتاند؛ ابزارهای سراسریِ EU هم اعمال میشوند | فقط وقتی واقعاً در آنجا مستقر باشید |
| .us | ایالاتِ متحده | الزامِ nexus بهعلاوهٔ سیاستی دیرینه علیهِ ثبتِ پروکسی | عملاً هرگز، برای هیچکدام از موضوعاتِ این راهنما |
یک ملاحظهٔ دیگر که بهراحتی نادیده گرفته میشود: پسوند خودش هم یک سیگنال است. یک پسوندِ عمومیِ کاملاً تازه با قیمتِ تمدیدِ پایین، سوءاستفاده جذب میکند، و در نتیجهٔ مستقیمِ همین، ایمیلِ ارسالی از آن توسطِ فیلترهای اسپم بدتر رفتار میشود. اگر قرار است این نام روزی ایمیل بفرستد، آن افتِ اعتبار واقعی است و خیلی زودتر از هر پرسشِ حوزهٔ قضایی حسش میکنید — راهنمای سرورِ ایمیل توضیح میدهد برای تحویلگرفتهشدن اصلاً چه چیزی لازم است.
سرویسِ حریمِ خصوصی، پروکسی و امین: سه چیزِ متفاوت که زیرِ یک عنوان فروخته میشوند
«ثبتِ خصوصی» بهعنوانِ یک محصولِ واحد فروخته میشود، اما در واقع سه ترتیبِ متفاوت با سه شیوهٔ شکستِ متفاوت است. شفافبودن دربارهٔ اینکه کدامیک را میخرید، بیشترِ کار است.
یک سرویسِ حریمِ خصوصی یا پروکسیِ WHOIS، مخاطبِ فورواردِ خودِ ثبتکننده را بهجای مخاطبِ شما در رکوردِ عمومی میگذارد. این کار شما را از یک استعلامِ گذرا پنهان میکند و از هیچکسِ دیگری: ثبتکننده دقیقاً میداند شما که هستید، یک احضاریه به ثبتکننده شما را بیرون میکشد، و یک پرسوجوی معتبر هم ممکن است شما را بیرون بکشد. روی یک پسوندِ عمومی، جایی که فیلدها بههرحال بهطورِ پیشفرض پنهاناند، پرداختِ اضافه برایِ این کار عمدتاً پرداخت بابتِ چیزی است که سیاست از پیش به شما داده.
ثبتِ پروکسی یا امینی جانورِ دیگری است. یک شخصِ ثالث دارندهٔ رسمیِ ثبت میشود و استفاده از نام را تحتِ قرارداد به شما لایسنس میدهد — همان مدلی که Njal.la آن را رایج کرد. رکوردهای ریجیستری و ثبتکننده نامِ آنها را میبرند، نه شما را، و چون چیزِ کمتری در پرونده هست، واقعاً چیزِ کمتری هم برای افشا وجود دارد. این قویترینِ آن سه است، و چیزی واقعی از شما میگیرد: شما دارندهٔ قانونی نیستید. نمیتوانید علیهِ امینِ خودتان یک رویهٔ حلِ اختلاف را به کار بیندازید، و به یک قرارداد و به تمایلِ آن اپراتور برای ایستادگی متکیاید.
ثبت به نامِ نهادی که خودتان کنترلش میکنید مسیرِ سوم است: شرکتی در حوزهٔ قضاییای که مالکیتِ ذینفعِ واقعی را منتشر نمیکند، دارنده میشود. این مسیر بادوام است، از علاقهٔ ازدسترفتهٔ اپراتورِ یک سرویسِ پروکسی جان سالم بهدر میبرد، و نظامِ افشای خودش، تعهداتِ گزارشدهیِ خودش و نمایندهٔ خودش را دارد که میتوان مجبورش کرد. شرکتی که صورتحسابهای عمومیاش را با نامِ مدیرانش ثبت میکند، مسئله را حل نکرده، فقط جابهجایش کرده.
هرکدام را که انتخاب کنید، سه پرسش تعیین میکند آیا ارزشِ پولی را که دادهاید دارد یا نه. این واسطه واقعاً چه دادهای دربارهٔ شما نگه میدارد، با اینکه فقط میتوان مجبورش کرد چیزی را بدهد که دارد؟ دربارهٔ انتقالهای خروجی، اگر واسطه تحتِ فشار قرار بگیرد، سیاستش را تغییر دهد، یا بهسادگی جوابدادن به ایمیل را متوقف کند، چه چیزی نوشته شده؟ و اگر لازم میشد، آیا امروز میتوانستید این نام را خودتان، بدونِ همکاریِ آنها، جابهجا کنید؟ این پاسخها را پیش از تکیهکردن به این ترتیب به دست بیاورید، نه در همان هفتهای که به آن نیاز دارید.
| مدل | رکورد چه کسی را نام میبرد | چه کسی هنوز میداند شمایید | کجا شکست میخورد |
|---|---|---|---|
| ثبتِ صرفاً عمومی | شما | هرکس با ابزارِ استعلام، برای همیشه | بلافاصله، و بهطورِ غیرقابلبازگشت — بایگانیها نگهش میدارند |
| پنهانسازیِ پیشفرض روی پسوندهای عمومی | فیلدهای پنهانشده، مخاطبِ رلهای | ثبتکننده، و درخواستدهندگانِ معتبر | هر درخواستِ قانونی به ثبتکننده؛ این یک پیشفرض است، نه یک سرویس |
| افزونهٔ حریمِ خصوصیِ پولی | مخاطبِ فورواردِ ثبتکننده | ثبتکننده، و درخواستدهندگانِ معتبر | همانجایی که پنهانسازی شکست میخورد، با پولِ اضافه |
| دارندهٔ پروکسی یا امینِ شخصِ ثالث | شرکتِ پروکسی | شرکتِ پروکسی و مسیرِ پرداختش | پروکسی تحتِ فشار قرار بگیرد، از پا دربیاید، یا با شما اختلافِ نظر پیدا کند |
| نهادی که کنترلش میکنید | آن نهاد | نمایندهٔ ثبتِ شرکتتان و نهادِ ناظرش | دفاترِ ثبتِ مالکیت، تعهداتِ گزارشدهی، نمایندهای که میتوان مجبورش کرد |
یک چیز که هرگز یک استراتژی نیست: سرهمکردنِ جزئیات. دادنِ اطلاعاتِ تماسِ عمداً نادرست به یک ثبتکننده، قراردادِ ثبت را نقض میکند، و سازوکارِ اجرا یک ایمیلِ تأییدیه است که وقتی بیپاسخ بماند، نام را معلق میکند. کلِ نکتهٔ مدلهای پروکسی و نهاد این است که اجازه میدهند رکورد هم دقیق باشد و هم دربارهٔ شما نباشد. دروغگفتن بدترینِ هر دو دنیا را نصیبتان میکند — از طریقِ ردِ پرداخت قابلِشناسایی، و با یک نکتهٔ فنی قابلِابطال.
پرداخت برای نام، بدون خنثیکردنِ همهٔ تلاشِ قبلی
یک پرداختِ کارتی کلِ زنجیره را فرومیریزد. پردازشگرِ پرداختِ ثبتکننده یک هویتِ کاملاً تأییدشده نگه میدارد، در یک نظامِ انطباق قرار دارد که هیچ سیاستِ ثبتی به آن دست نمیزند، و طبقِ قانون سالها رکورد نگه میدارد. اگر تنها مسیرِ پرداختِ یک ثبتکننده کارت باشد، پس هرچه دربارهٔ حریمِ خصوصی بگوید، بررسیِ هویت فقط یک پله بالاتر رفته — همان استدلالی که میزبانیِ فقط-با-ارزِ-دیجیتال را منطقی میکند، بدونِ هیچ تغییری اینجا هم صدق میکند.
پس هرجا ثبتکننده میپذیرد با ارزِ دیجیتال پرداخت کنید، و به همان دلیلی که در همهجای دیگر Monero را بر Bitcoin ترجیح میدهید، همینجا هم ترجیح دهید: یک دفترِکلِ شفاف، مبلغ، زمان و آدرسی را منتشر میکند که میتوان آن را به هر صرافیای که از آن خرید کردهاید وصل کرد، و یک دفترِکلِ خصوصی این کار را نمیکند. مصالحهها بهطورِ کامل در مقایسهٔ Bitcoin و Monero شرح داده شدهاند؛ خلاصه این است که برایِ یک پرداختِ تکرارشونده، کوچک و مرتبط با هویت، Monero ابزارِ بهتری است.
تمدید همان شیوهٔ شکستی است که هیچکس برایش برنامه نمیریزد و همه بالاخره تجربهاش میکنند. دامنهای که منقضی میشود، حذفی است که خودتان روی خودتان انجام دادهاید، و نامهای درحالِانقضا در عرضِ چند ثانیه پس از افتادن، توسطِ سرویسهای خودکاری خریداری میشوند که آنها را با سودِ اضافه دوباره میفروشند — اگر اصلاً به خودِ شما بفروشندشان. از پیش برایِ چند سال ثبت کنید، تاریخِ انقضا را در تقویمی نگه دارید که روی خودِ دامنه زندگی نمیکند، و مطمئن شوید ایمیلِ یادآوری به جایی میرسد که سه سالِ دیگر هم هنوز آن را میخوانید.
ناشناسماندن از کانالِ پشتیبانی هم جان سالم بهدر نمیبرد. یک گفتوگوی بازپرداخت، یک chargeback، تیکتی که از یک آدرسِ شخصی باز شده، فاکتوری که برایِ یک حسابدار فوروارد شده — هرکدام از اینها یک نام را به رکوردی میچسبانند که نامی نداشت. یکبار برای همیشه تصمیم بگیرید کدام هویت مالکِ این دامنه است، و هرگز از هیچ هویتِ دیگری به آن حساب دست نزنید، حتی روزی که چیزی خراب میشود و عجله دارید.
بودجه را صادقانه ببینید. یک ثبتِ امینی چندین برابرِ قیمتِ یک نامِ عمومیِ عمدهفروشی هزینه دارد، پیشپرداختِ چندساله یعنی پولی که زودتر خرج میشود، و یک نامِ یدکی در یک ثبتکنندهٔ دوم هم یک هزینهٔ سالانهٔ کوچکِ دیگر است. رویِهم بگویید چند ده واحدِ ارزی در سال. در برابرِ هزینهٔ ازدستدادنِ آدرسی که هر لینک، هر بوکمارک، هر رکوردِ ایمیل و هر نتیجهٔ جستوجو به آن اشاره میکند، این ارزانترین بیمهٔ کلِ این مجموعه است.
حسابِ ثبتکننده، بیشتر از سابقهٔ عمومی لو میدهد
همهچیز در پاراگرافهای بالا دربارهٔ چیزی است که غریبهها میتوانند استعلام بگیرند. هدفِ غنیتر، حسابِ شما نزدِ ثبتکننده است، که یک آدرسِ ایمیلِ فعلی، یک مسیرِ بازنشانیِ رمزِ عبور، آدرسِ IP هر ورود، و متنِ کاملِ هر تیکتِ پشتیبانیای که باز کردهاید را نگه میدارد. آن پرونده کاملتر، بهروزتر و مفیدتر از آن چیزی است که رکوردِ پنهاننشدهٔ WHOIS تابهحال بوده.
آدرسِ ایمیل کلیدِ اصلی است، چون هرکس آن را کنترل کند دامنه را کنترل میکند: بازنشانیِ رمزِ عبور، تأییدِ انتقالها و تأییدِ تغییرِ دارنده، همه به همانجا میرسند. آدرسی استفاده کنید که فقط برای همین دامنه وجود دارد و هیچ چیزِ دیگری، روی زیرساختی که خودتان اداره میکنید یا نزدِ ارائهدهندهای که شمارهٔ تلفن مطالبه نمیکند. اگر میخواهید آن صندوقِ ایمیل روی سختافزاری باشد که خودتان کنترل میکنید، راهنمای ایمیلِ خودمیزبان شرحِ صادقانهٔ چیزی است که این کار نیاز دارد. کاری که نباید بکنید این است که صندوق را روی همان دامنهای میزبانی کنید که از آن محافظت میکند — وقتی نام معلق شود، توانِ بازیابیتان هم معلق میشود.
احرازِ هویتِ دومرحلهای را با کدهای زمانبنیاد از یک اپلیکیشنِ احرازِ هویت روشن کنید، و مشخصاً نه با SMS. یک شمارهٔ تلفن همزمان یک سندِ هویتی است و قابلِاعتمادترین مسیرِ تصاحبِ حساب که وجود دارد، و دادنِ آن به یک ثبتکننده برای بهبودِ امنیت، معاملهٔ بدی است. کدهای بازیابی را آفلاین و جایی نگه دارید که به همان حسابی که بازیابی میکنند وابسته نباشد.
بعد همبستگی هست، که همان راهِ خاموشی است که بیشترِ این ماجرا از آن شکست میخورد. همان ایمیل روی حسابِ میزبانی و حسابِ ثبتکننده. همان رمزِ عبور. همان نشستِ مرورگر که در عرضِ یک دقیقه به هردو وارد میشود. همان نامِ کاربری روی همان انجمنی که پروژه را در آن اعلام کردید. هرکدام از اینها دو حسابِ ناشناسِ با دقت جداشده را به یک شخصِ شناساییشده تبدیل میکند، و هیچکدامشان در هیچ رکوردِ عمومیای دیده نمیشود — که دقیقاً به همین دلیل نادیده گرفته میشوند. راهنمای ردیابیپذیری همین مسئله را از سمتِ سرور بررسی میکند.
در آخر، وضعیتِ منعِ انتقال (clientTransferProhibited) را روی نام تنظیم کنید، و اگر ریجیستری قفلِ ریجیستری میفروشد، آن را هم بردارید. قفلِ ثبتکننده یک کلیک است و مسیرِ رایجِ سرقت را میبندد؛ قفلِ ریجیستری یک گامِ تأییدِ خارجازکانال پیش از اینکه هر تغییری اصلاً به ریجیستری برسد اضافه میکند. اکثریتِ قریببهاتفاقِ دامنههایی که دزدیده میشوند توسطِ دادگاهها توقیف نمیشوند — توسطِ هرکسی که وارد صندوقِ ایمیل شده انتقال داده میشوند، و هر دو قفل دقیقاً به همین دلیل وجود دارند.
میزبانیِ DNS، دومین سطحِ حذف است
ثبتِ یک نام و پاسخدادن به پرسوجوهای آن دو کارِ متفاوتاند، که معمولاً دو شرکتِ متفاوت انجامشان میدهند، و کسانی که اولی را با دقت انتخاب میکنند، اغلب میگذارند دومی روی هرچه رایگان بود پیشفرض بماند. این یک شکاف است: اپراتوری که پاسخگوی ناحیهٔ شماست میتواند پاسخدادن را متوقف کند، و نامی که بههیچجا resolve نمیشود، دقیقاً به همان اندازهٔ نامی که توقیف شده از اینترنت خارج است. ارائهدهندگانِ بزرگ میزهای رسیدگی به سوءاستفاده دارند، و میزهای رسیدگی به سوءاستفاده اقدام میکنند.
دو پاسخِ قابلِدفاع این است که یا DNS مرجع را خودتان روی سروری که از قبل بابتش پول میدهید اجرا کنید، یا از اپراتوری استفاده کنید که حوزهٔ قضاییاش را عامدانه و به همان دلایلی انتخاب کردهاید که حوزهٔ قضاییِ ریجیستری را انتخاب کردید. اجرای خودتان یک مسئولیتِ عملیاتی هزینهتان میکند — دو سرورِ نام در جاهای متفاوت، پایششده، وصلهخورده — و در عوض این قطعیت را میخرد که هیچ شخصِ ثالثی نمیتواند با اخطارِ کوتاه ناحیه را از زیرِ پایتان بیرون بکشد. برایِ پروژهای که نام داراییاش است، این معمولاً معاملهٔ درستی است.
ناحیهٔ شما چیزهایی هم دربارهٔ خودتان منتشر میکند. رکوردهای NS نامِ اپراتورتان را میبرند. رکوردِ SOA یک آدرسِ ایمیل حمل میکند، که باید یک آدرسِ نقشی باشد، نه یک شخص. و ناحیهای که انتقالهایش رو به اینترنتِ عمومی باز مانده، هر hostname ای که دارید را تحویل میدهد، از جمله آنهایی که فکر میکردید خصوصیاند — بررسی کنید که ناحیهٔ شما آنها را رد میکند، چون پیشفرض در بعضی پیکربندیها بازتر از چیزی است که مردم انتظار دارند.
DNSSEC ارزشِ فعالکردن دارد و اغلب بدفهمیده میشود: پاسخها را احرازِ هویت میکند، پنهانشان نمیکند. با رکوردهای اصلیِ انکارِ وجود، یک ناحیهٔ امضاشده را میتوان پیمایش کرد تا هر نامِ داخلش شمارش شود، که دقیقاً به همین دلیل NSEC3 مشخص شد. اگر قرار نیست زیردامنههای شما مثلِ فهرستی از سیستمهای داخلیتان خوانده شوند، از آن استفاده کنید.
و فرض کنید تاریخچهٔ resolve دائمی است. جمعآورهای DNS منفعل هر آدرسی که نامِ شما تابهحال به آن اشاره کرده را ثبت میکنند — از جمله آدرسی که ده دقیقه در حینِ آزمایش تنظیم کردید، از جمله آدرسی که پیش از آمادهشدنِ سرور به اتصالِ خانگیتان اشاره میکرد. برایِ آن داده نه انقضایی هست و نه راهی برای حذف. قاعدهای که از این نتیجه میشود مطلق است: هرگز یک نامِ واقعی را به چیزی اشاره ندهید که عامدانه منتشرش نمیکردید، حتی برایِ لحظهای کوتاه، حتی یک یکشنبه. راهنمای گامبهگامِ میزبانیِ ناشناس بقیهٔ آن مسئلهٔ لایهای را پوشش میدهد.
زمانِ زندهماندنِ رکوردهایی که اهمیت دارند را پایین نگه دارید — پنج دقیقه مقدارِ کاریِ معقولی است — تا جابهجاییِ ثبتکننده، جابهجاییِ ارائهدهنده یا جابهجاییِ سرور، تغییری در حدِ دقیقه باشد، نه روز. دقیقاً یکبار، زیرِ فشار، خوشحال خواهید شد که این کار را کردهاید، و همان تنها لحظهای است که اهمیت دارد. راهنمای مهاجرت کلِ توالیِ گذار را دارد.
بایگانیهای عمومی که یک نامِ پاک را دوباره به یک شخص وصل میکنند
فرض کنید ثبت پاک است، پرداخت هیچ ردی برجای نگذاشته و DNS مالِ خودتان است. با اینحال هنوز مجموعهای از بایگانیهای دائمی، عمومی و آزادانه قابلِجستوجو هست که همینالان هم بیسروصدا دارند زیرساختِ شما را ثبت میکنند، و اینها همان چیزیاند که در عمل اسنادسازی (attribution) را ممکن میکنند.
شفافیتِ گواهی بزرگترینِ آنهاست و کمقدردانیشدهترینشان. هر گواهیِ موردِ اعتمادِ عمومی که برایِ نامِ شما صادر شود، به لاگهای عمومیِ append-only ارسال میشود — این کلِ طراحیِ آن سامانه است، مرورگرها آن را الزامی میکنند، و اکوسیستم عامدانه باز است. هر گواهیای که برایِ یک hostname مشخص درخواست کنید، آن hostname را در عرضِ چند دقیقه، برایِ همیشه، به جهان منتشر میکند. بهجایش برایِ یک wildcard درخواست بدهید و فقط والد را منتشر میکنید. آن hostname داخلیای که یکبار، با عجله، در 2024 گواهی گرفتید، هنوز همانجاست.
شناسههای استفادهشدهٔ تکراری، سایتها را بهمراتب قابلِاعتمادتر از هر رکوردِ ثبتی بههم مرتبط میکنند. همان اکانتِ آنالیتیکس روی دو سایت، همان اکانتِ تبلیغاتی، همان نمونهٔ متریکِ خودمیزبان، همان گواهیِ بازاستفادهشده روی دو میزبان، همان کلیدِ میزبانِ SSH، همان چیدمانِ متمایزِ هدرهای پاسخِ HTTP، همان favicon. ایندکسهای تجاری و اسکنرهای سراسرِ اینترنت همهٔ اینها را نگه میدارند و به هرکسی اجازه میدهند در یک پرسوجوی واحد از یک دارایی به داراییای دیگر بپرد — این کارِ روتین است، نه یک توانایی عجیب.
محتوا کانالِ خودش را دارد و هیچچیز در لایهٔ دامنه دستنخوردهاش نمیگذارد. سبکِ نوشتار، ساعتِ روزی که کامیتهایتان ثبت میشود، پستِ اعلامیهای از حسابی که نامِ واقعیتان رویش است، عکسی که ابردادهٔ مکانش دستنخورده مانده، یک PDF که فیلدِ نویسنده را از همان واژهپردازی که تولیدش کرده حمل میکند. هیچ تصمیمِ ثبتکنندهای در برابرِ هیچکدام از اینها دفاعی ندارد.
| منبعِ عمومی | چه چیزی نگه میدارد | تا چه مدت | چه کاری دربارهٔ آن انجام دهید |
|---|---|---|---|
| بایگانیهای تاریخچهٔ ثبت | هر رکوردی که تابهحال منتشر شده، از جمله رکوردهای پیش از پنهانسازی | دائمی | پیش از فرضکردنِ یک شروعِ پاک بررسی کنید؛ شناسهای که سوخته، سوخته میماند |
| لاگهای شفافیتِ گواهی | هر hostname ای که تابهحال برایش گواهی گرفتهاید | دائمی، از نظرِ طراحی append-only | گواهیهای wildcard را ترجیح دهید؛ هرگز یک hostname داخلی را علناً گواهی نگیرید |
| DNS منفعل | هر آدرسی که نام تابهحال به آن resolve شده | سالها، بدونِ هیچ فرایندِ حذفی | هرگز یک نامِ واقعی را به یک آدرسِ شخصی اشاره ندهید، حتی برایِ یک تست |
| اسکنرهای سراسرِ اینترنت | بنرها، گواهیها، هشهای favicon، ترتیبِ هدرها | پیوسته، با تاریخچه | سطحِ عمومی را معمولی و بینشان نگه دارید؛ هرگز یک fingerprint را میانِ هویتهای مختلف بازاستفاده نکنید |
| شناسههای آنالیتیکس و تبلیغاتی | اینکه کدام سایتها یک اکانت را مشترکاند | تا زمانی که ایندکس نگهداری میشود | یک هویت، یک اکانت، هیچ بازاستفادهای هیچجا |
عادتِ مفید این است که این بررسی را روی خودتان پیش از راهاندازی انجام دهید، نه بعد از اینکه کسِ دیگری انجامش داد. نامتان را در یک بایگانیِ تاریخچهٔ ثبت جستوجو کنید، لاگهای گواهی را برایش بگردید، یک ابزارِ DNS منفعل را پرسوجو کنید، و آدرسِ خودتان را همانطور که یک اسکنر میکرد، اسکن کنید. بیست دقیقه نگاهکردن به پروژهٔ خودتان از دریچهٔ ابزارهای یک غریبه، زیردامنهٔ staging، گواهیِ سرگردان و رکوردِ آزمایشیِ فراموششده را پیدا میکند، درحالیکه هنوز تعمیرشان ارزان است.
راهِ فرار، و برنامه برای روزی که یک اطلاعیه میرسد
دقیقاً یک نوع نام هست که هیچکس نمیتواند بگیردش، و همان نامی است که هیچکس صادرش نمیکند. یک آدرسِ onion از کلیدی مشتق میشود که روی ماشینِ خودتان تولید میکنید: نه ریجیستریای هست، نه ثبتکنندهای، نه تمدیدی و نه فاکتورِ سالانهای، پس نه چیزی برای توقیف هست و نه کسی برای فشارآوردن. این کار قابلِکشفبودن، بهیادماندنیبودن و مخاطبِ معمولیِ وب را برایتان هزینه میکند، پس جایگزینِ یک نامِ clearnet نیست — گزینهٔ پشتیبانی است که همچنان صبحی که نامِ clearnet معلق میشود کار میکند. راهنمای سرویسِ onion کلِ ساخت را دارد.
هردو را اجرا کنید، و درحالیکه همهچیز آرام است، گزینهٔ پشتیبان را تبلیغ کنید. یک هدرِ پاسخِ واحد — Onion-Location — به یک سایتِ clearnet اجازه میدهد آدرسِ onion اش را بهطورِ خودکار به Tor Browser اعلام کند، که یعنی مخاطبی که روزی به آن جایگزین نیاز خواهد داشت از پیش آن را دارد، بهجایِ اینکه مجبور باشد در همان هفتهای که آدرسِ اصلیتان resolve شدن را متوقف کرد، پیدایش کند.
یک نامِ یدکی هم ثبت کنید، در یک ثبتکنندهٔ دیگر، تحتِ حوزهٔ قضاییِ یک ریجیستریِ دیگر، که به همان سرور اشاره میکند. این چند واحدِ ارزی در سال هزینه دارد. بهدستآوردنِ یکی زیرِ فشار — درحالیکه نامِ اصلی معلق است، ایمیلتان از میانش جریان دارد و کاربرانتان علناً سؤال میپرسند — یک بعدازظهرِ کاملاً متفاوت و بهمراتب بدتر است.
کیتِ بازیابی را جایی نگه دارید که حادثه نتواند به آن برسد: یک خروجیِ بهروز از ناحیه، اعتبارنامههای ثبتکننده و کدهای بازیابی که خارج از همان صندوقِ ایمیلی نگهداری میشوند که به دامنه وابسته است، کدِ مجوزِ انتقال، و پاسخی مکتوب به این پرسش: «اگر این نام ساعتِ سه بامداد ناپدید شود، چه میگوییم، و کجا میگوییمش؟» برنامهای که فقط در ذهنتان زندگی میکند، برنامه نیست.
قواعدِ انتقال را از پیش بشناسید، چون همان قیدیاند که برنامههای بداهه را خراب میکنند. طبقِ سیاستِ انتقال، یک نام به مدتِ 60 روز پس از ثبت، و دوباره پس از تغییرِ دارنده، قفلِ انتقال میشود، پس «اگر مشکلی پیش بیاید جابهجایش میکنیم» در دو ماهِ اول در اختیارِ شما نیست، و نه بلافاصله بعد از اینکه تازه جابهجایش کردهاید. جابهجایی را وقتی هیچ مشکلی نیست انجام دهید.
وقتی چیزی واقعاً میرسد، پیش از واکنشنشاندادن بخوانید که واقعاً چیست. یک شکایت به ثبتکنندهٔ شما حکمِ دادگاه نیست و اغلب سزاوارِ یک پاسخِ کوتاهِ مبتنیبر واقعیت است، نه سکوت. یک پروندهٔ اختلاف رویهای است با یک مهلت که اگر نادیدهاش بگیرید، بهطورِ پیشفرض علیهِ شما تصمیمگیری خواهد شد. توقفِ ریجیستری چیزی نیست که ثبتکنندهٔ شما بتواند با بحثکردن کنارش بزند. راهنمای DMCA نشان میدهد اطلاعیهها چطور در سراسرِ زیرساختِ آفشور جریان دارند و کدامیک کجا قدرتِ اجرایی دارد. و مدارک را نگه دارید: رکوردی که ممکن است لازم باشد نشان دهید، همان چیزی است که وسوسه میشوید حذفش کنید.
میزبان کجای این ماجرا قرار میگیرد؟ ما ماشین را میفروشیم، نه نام را — اینجا هیچ محصولِ دامنهای نیست، و اگر بود این راهنما بدتر میشد. چیزی که لایهٔ میزبانی به آن اضافه میکند این است که چیزی که نامِ با دقت انتخابشدهٔ شما به آن اشاره میکند، خودش هم در حوزهٔ قضاییای است که انتخابش کردهاید، بدونِ بررسیِ هویت پرداختش کردهاید، و در حدودِ چهل ثانیه از چهار موقعیت راهاندازی شده. لایهٔ نامگذاری را درست انجام دهید و آن دو نیمه بالاخره باهم جور درمیآیند؛ اشتباه انجامش دهید و قویترین سرور در ریکیاویک از طریقِ یک فرم روی وبسایتی در نیمکرهٔ دیگر در دسترس است.