BitVPS
ثبت دامنه به‌صورت ناشناس: WHOIS، ثبت‌کننده‌ها و لایه‌ای که هویتتان را لو می‌دهد
راهنمای دامنه

ثبت دامنه به‌صورت ناشناس: WHOIS، ثبت‌کننده‌ها و لایه‌ای که هویتتان را لو می‌دهد

مردم هفته‌ها وقت صرفِ انتخابِ حوزهٔ قضاییِ سرور می‌کنند و بعد فقط نود ثانیه صرفِ خریدِ دامنه با کارتِ اعتباری از اولین ثبت‌کننده‌ای می‌کنند که سرِ راهشان قرار می‌گیرد. این کار وارونه است، و رایج‌ترین راهی است که یک راه‌اندازیِ در بقیهٔ جهات دقیق، از هم باز می‌شود. سرور دارایی‌ای است که اجاره می‌کنید؛ دامنه یک اجاره است، اعطاشده توسط یک ثبت‌کننده، تحتِ قوانینی که یک ریجیستری تعیین کرده، در کشوری که احتمالاً هرگز به آن فکر نکرده‌اید، و قابلِ‌لغو توسط هر دادگاهی که بر هر حلقه‌ای از آن زنجیره صلاحیتِ قضایی داشته باشد. لایهٔ میزبانی همان بخشی است که واقعاً می‌توانید دسترسی به آن را دشوار کنید. لایهٔ نام‌گذاری همان بخشی است که به آن دسترسی پیدا می‌کنند — با یک فرم، یک ایمیل، و بدونِ هیچ جلسهٔ استماعی. این راهنما زنجیره را به همان ترتیبی بالا می‌رود که واقعاً اهمیت دارد: کدام ریجیستری به کدام دادگاه‌ها پاسخ‌گوست، ثبت‌کننده‌تان بعد از توقفِ انتشارِ WHOIS هنوز چه چیزی را نگه می‌دارد، آن سه چیزی که با عنوانِ «ثبتِ خصوصی» فروخته می‌شوند در آنچه از آن دفاع می‌کنند چه تفاوتی دارند، چطور بدونِ خنثی‌کردنِ همهٔ آن پرداخت کنید، و بایگانی‌های عمومی — شفافیتِ گواهی، DNS منفعل، تاریخچهٔ WHOIS — که بی‌سروصدا یک کپی از هر چیزی که تابه‌حال زیرِ یک نام منتشر کرده‌اید نگه می‌دارند.

بدون KYC، هرگز DMCA نادیده گرفته می‌شود بدون لاگ ترافیک در 60 ثانیه فعال

نام، نرم‌ترین بخشِ این مجموعه است

سروری در ریکیاویک که با 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 نشان می‌دهد اطلاعیه‌ها چطور در سراسرِ زیرساختِ آف‌شور جریان دارند و کدام‌یک کجا قدرتِ اجرایی دارد. و مدارک را نگه دارید: رکوردی که ممکن است لازم باشد نشان دهید، همان چیزی است که وسوسه می‌شوید حذفش کنید.

میزبان کجای این ماجرا قرار می‌گیرد؟ ما ماشین را می‌فروشیم، نه نام را — این‌جا هیچ محصولِ دامنه‌ای نیست، و اگر بود این راهنما بدتر می‌شد. چیزی که لایهٔ میزبانی به آن اضافه می‌کند این است که چیزی که نامِ با دقت انتخاب‌شدهٔ شما به آن اشاره می‌کند، خودش هم در حوزهٔ قضایی‌ای است که انتخابش کرده‌اید، بدونِ بررسیِ هویت پرداختش کرده‌اید، و در حدودِ چهل ثانیه از چهار موقعیت راه‌اندازی شده. لایهٔ نام‌گذاری را درست انجام دهید و آن دو نیمه بالاخره باهم جور درمی‌آیند؛ اشتباه انجامش دهید و قوی‌ترین سرور در ریکیاویک از طریقِ یک فرم روی وب‌سایتی در نیم‌کرهٔ دیگر در دسترس است.

پاسخ‌های سریع

سؤالات متداول

آیا ثبتِ ناشناسِ دامنه قانونی است؟
بله. هیچ قاعده‌ای در هیچ‌جا شما را ملزم نمی‌کند برایِ اجرایِ یک وب‌سایت، آدرسِ خانه‌تان را منتشر کنید، و از 2018 پسوندهای عمومی به‌طورِ پیش‌فرض آن فیلدها را پنهان می‌کنند. آنچه سیاستِ ثبت واقعاً الزام می‌کند این است که داده‌ای که ثبت‌کننده‌تان نگه می‌دارد دقیق و قابلِ‌دسترس باشد — پس مسیرهای مشروع به‌سمتِ ناشناس‌ماندن، مسیرهایی‌اند که در آن‌ها رکورد واقعاً دقیق است و واقعاً دربارهٔ شما نیست: یک پروکسی یا امین که دارنده می‌شود، یا نهادی که کنترلش می‌کنید. سرهم‌کردنِ جزئیات تنها رویکردی است که هم برخلافِ قراردادی است که امضا کرده‌اید و هم به‌راحتی می‌توان علیه‌اش اقدام کرد، چون یک ایمیلِ تأییدیهٔ بی‌پاسخ، نام را معلق می‌کند.
آیا افزونهٔ حریمِ خصوصیِ پولیِ WHOIS هنوز ارزشِ خریدن دارد؟
روی یک پسوندِ عمومی، معمولاً نه. فیلدهای تماس به‌طورِ پیش‌فرض پنهان‌اند، پس این افزونه عمدتاً همان وضعِ موجود را به شما می‌فروشد — و دقیقاً در برابرِ همان دشمنی دفاع می‌کند که پیش‌فرض از قبل با آن مقابله می‌کند: یعنی کسی که یک استعلامِ گذرا می‌گیرد. این افزونه در برابرِ یک درخواست به ثبت‌کننده، یک پرس‌وجوی معتبر، یا ردِ پرداخت هیچ کاری نمی‌کند. روی پسوندهای کدِ کشوری این محاسبه فرق می‌کند، چون چند تا از آن ریجیستری‌ها هنوز جزئیاتِ دارنده را کامل منتشر می‌کنند و یک گزینهٔ حریمِ خصوصی شاید تنها چیزی باشد که میانِ نامِ شما و رکوردِ عمومی ایستاده. پیش از تصمیم‌گیری بررسی کنید ریجیستریِ مشخصِ شما چه چیزی منتشر می‌کند.
آیا یک ثبت‌کنندهٔ پروکسی مثلِ Njal.la واقعاً از یک سرویسِ حریمِ خصوصی قوی‌تر است؟
از نظرِ ساختاری، بله، چون این‌که دارنده کیست را تغییر می‌دهد، نه این‌که چه چیزی نمایش داده می‌شود. پروکسی همان دارندهٔ رسمی است، پس ثبت‌کننده و ریجیستری جزئیاتِ او را دارند، نه جزئیاتِ شما را، و از نظرِ محتوایی چیزِ کمتری دربارهٔ شما هست که کسی بتواند مطالبه کند. هزینه‌اش واقعی است و ارزش دارد گفته شود: شما دارندهٔ قانونی نیستید، نمی‌توانید از یک رویهٔ حلِ اختلاف برای پس‌گرفتنِ نام از پروکسیِ خودتان استفاده کنید، و به یک قرارداد و به تمایلِ آن اپراتور برایِ دردسرسازشدن برایِ شاکی متکی‌اید. پیش از این‌که چیزی رویش بسازید، بخوانید آن‌ها دربارهٔ افشا و دربارهٔ خارج‌کردنِ یک نام چه چیزی منتشر می‌کنند.
برایِ سایتی که می‌خواهم ناشناس نگهش دارم، از کدام پسوند استفاده کنم؟
پاسخِ واحدی وجود ندارد، فقط یک روش هست: پیدا کنید چه کسی پسوند را اداره می‌کند، یادداشت کنید آن اپراتور در کدام کشور است، و آن دادگاه‌ها را بخشی از مدلِ تهدیدِ خودتان بپذیرید. در عمل این استدلال علیهِ .com و .net و علیهِ بیشترِ پسوندهای عمومیِ جدید است، که همه‌شان از ایالاتِ متحده اداره می‌شوند، و به‌نفعِ یک پسوندِ کدِ کشوری‌ای است که ریجیستری‌اش سیاستِ منتشرشده‌ای دارد مبنی‌بر این‌که فقط بر اساسِ حکم‌های دادگاهِ داخلی عمل می‌کند. از هر چیزی که الزامِ اقامت یا nexus دارد دوری کنید مگر واقعاً واجدِ شرایطش باشید، و از پسوندهایی که ریجیستری‌شان ثبتِ پروکسی را ممنوع کرده دوری کنید.
آیا ممکن است دامنه‌ام حتی اگر میزبانم اطلاعیه‌های DMCA را نادیده بگیرد، معلق شود؟
بله، و این به‌تنهایی مهم‌ترین نکتهٔ این صفحه است. میزبان و ثبت‌کننده دو شرکتِ جدا هستند که تحتِ قوانینِ جدایی‌اند، و اطلاعیه‌ای که در جایی که سرورتان زندگی می‌کند قدرتِ اجرایی ندارد، همچنان می‌تواند رویِ میزِ ثبت‌کننده یا ریجیستری‌ای فرود بیاید که رویش اقدام خواهد کرد. دقیقاً به همین دلیل است که فشار اول به آن‌جا می‌رود: تعقیبِ یک ثبت‌کننده از تعقیبِ یک میزبانِ آف‌شور ارزان‌تر، سریع‌تر و کم‌قابلِ‌بازبینی‌تر است. سروری آف‌شور که پشتِ نامی است که با کارت نزدِ یک ثبت‌کنندهٔ متعارف ثبت شده، یک راه‌اندازیِ آف‌شور نیست — یک راه‌اندازیِ داخلی با یک مسیرِ شبکه‌ایِ طولانی‌تر است.
آیا باید سرورهای DNS خودم را اجرا کنم؟
اگر نام برایِ پروژه محوری است، بله — اپراتوری که پاسخ‌گوی ناحیهٔ شماست یک سطحِ حذف است، و اجرای خودتان یک شرکت را از فهرستِ طرف‌هایی که می‌توان تحتِ فشارشان گذاشت حذف می‌کند. این کار رایگان نیست: به دو سرورِ نام در موقعیت‌های متفاوت، مانیتورینگ، وصله‌گذاری، و انضباطِ ردکردنِ انتقال‌های ناحیه و نگه‌داشتنِ مخاطبِ SOA به‌صورتِ غیرشخصی نیاز دارید. اگر ترجیح می‌دهید این بار را به دوش نکشید، جایگزینِ قابلِ‌قبول این است که یک اپراتورِ DNS را عامدانه بر اساسِ حوزهٔ قضایی انتخاب کنید، همان‌طور که ریجیستری را انتخاب کردید — نه بر اساسِ هرکدام که با چیزِ دیگری همراه شده بود.
آیا یک گواهیِ TLS می‌تواند ارتباطِ میانِ من و دامنه‌ام را افشا کند؟
می‌تواند hostname ها را افشا کند، که اغلب کافی است. هر گواهیِ موردِ اعتمادِ عمومی، برای همیشه و در عرضِ چند دقیقه، در لاگ‌های شفافیتِ append-only منتشر می‌شود، پس هر گواهی‌ای که برایِ یک hostname مشخص صادر شود، آن hostname را به هرکسی که تماشا می‌کند اعلام می‌کند — و مردم واقعاً با ابزارهای خودکار تماشا می‌کنند. یک گواهیِ wildcard فقط نامِ والد را منتشر می‌کند. خودِ گواهی نامِ شما را نمی‌برد مگر این‌که یکی با تأییدِ سازمانی (OV) درخواست داده باشید، که برایِ این کاربرد نباید بدهید.
اگر یک آدرسِ onion دارم، اصلاً به یک دامنه نیاز دارم؟
فقط اگر به مخاطبی نیاز دارید که مرورگر نصب نمی‌کند. یک آدرسِ onion نه ریجیستری‌ای دارد، نه تمدیدی و نه مسیرِ ابطالی، که آن را بادوام‌ترین نامِ موجود می‌کند و هم‌زمان کم‌کشف‌ترینش. بیشترِ پروژه‌ها نهایتاً هر دو را اجرا می‌کنند: نامِ معمولی برایِ دسترسی، و آدرسِ onion به‌عنوانِ گزینهٔ پشتیبانی که وقتی معمولی معلق می‌شود همچنان کار می‌کند، و هرکدام از طریقِ دیگری تبلیغ می‌شود. اگر مخاطبِ شما فنی و خودگزین است، مسیرِ فقط-onion واقعاً عملی است و کلِ لایهٔ نام‌گذاری را از مدلِ تهدیدِ شما حذف می‌کند.
اعمال کنید

بارهای کاری که این راهنما برای آن‌ها اعمال می‌شود

هر کارت یک صفحه مخصوص بار کاری با توصیه‌های اندازه‌گیری و FAQ sysadmin باز می‌کند.

ادامه مطالعه

راهنماهای دیگر

مطالعه‌های همراه که از جایی که این یکی متوقف می‌شود ادامه می‌دهند.

راهنمای عملیاتی چگونه در ۲۰۲۶ یک وب‌سایت را به‌صورت ناشناس میزبانی کنیم

چگونه در ۲۰۲۶ یک وب‌سایت را به‌صورت ناشناس میزبانی کنیم

A practical six-step playbook for standing up a website without leaving identifying metadata — host, domain, payment, network, content, and deploy hygiene.

12 دقیقه مطالعه راهنما را بخوانید
اعتماد و قابلیت ردیابی آیا یک VPS ناشناس است؟ میزبانی کریپتویی واقعاً چقدر قابل ردیابی است

آیا یک VPS ناشناس است؟ میزبانی کریپتویی واقعاً چقدر قابل ردیابی است

نقشه‌ای صادقانه از آنچه یک میزبان بدون KYC می‌تواند و نمی‌تواند درباره‌ی شما ببیند — ردِ پرداخت، IP اتصال، محتوایی که سرو می‌کنید — و سه نوع جداگانه از «ناشناس‌بودن» که مردم آن‌ها را با هم قاطی می‌کنند.

9 دقیقه مطالعه راهنما را بخوانید
راهنمای ناشناسی راه‌اندازی سایت .onion: سرویس Tor، آدرس نسخه 3 و نشتی‌هایی که هویت را لو می‌دهند

راه‌اندازی سایت .onion: سرویس Tor، آدرس نسخه 3 و نشتی‌هایی که هویت را لو می‌دهند

سرویس onion تنها راه انتشار یک سایت بدون افشای IP است. راهنمای کامل torrc، آدرس نسخه 3، احراز هویت کلاینت، و نشتی‌هایی که بیش از خودِ Tor هویت سرویس‌ها را لو داده‌اند.

15 دقیقه مطالعه راهنما را بخوانید
توضیح حقوقی هاستینگ DMCA-ignored توضیح داده شده: معنای واقعی آن، از نظر حقوقی و عملیاتی

هاستینگ DMCA-ignored توضیح داده شده: معنای واقعی آن، از نظر حقوقی و عملیاتی

تحلیل دقیق معنای «DMCA-ignored» تحت قوانین ایالات متحده، اتحادیه اروپا و کارائیب — چه چیزی را یک هاست می‌تواند نادیده بگیرد، چه چیزی را نمی‌تواند، و گردش کار takedown واقعاً چطور روی زیرساخت offshore اجرا می‌شود.

10 دقیقه مطالعه راهنما را بخوانید
مرجع حوزه‌های قضایی که اطلاعیه‌های DMCA را نادیده می‌گیرند — مرجعی برای ۲۰۲۶

حوزه‌های قضایی که اطلاعیه‌های DMCA را نادیده می‌گیرند — مرجعی برای ۲۰۲۶

A working reference of which hosting jurisdictions fall outside DMCA reach in 2026 — what each will and will not honour, and what process replaces a takedown notice locally.

10 دقیقه مطالعه راهنما را بخوانید
مرجع معنی واقعی «هاستینگ بدون KYC» در ۲۰۲۶

معنی واقعی «هاستینگ بدون KYC» در ۲۰۲۶

A precise explainer on the term every privacy-focused hosting site uses — what KYC is, where it came from, what no-KYC providers do not collect, and the honest limits of the model.

8 دقیقه مطالعه راهنما را بخوانید

کافی خواندید؟ در ۶۰ ثانیه استقرار دهید

بدون تأیید ایمیل، بدون شناسه، بدون حساب. یک پلن انتخاب کنید، با هر ارز دیجیتالی پرداخت کنید، root بگیرید.