ثبتِ ناشناسِ دامنه: حریمِ خصوصیِ WHOIS و آنچه هنوز نشت می‌کند

آنچه سانسور واقعاً حذف کرد

در سال 2018 رکوردِ ثبتِ اکثرِ دامنه‌ها خالی شد. GDPR از راه رسید، ICANN به ریجیسترارها گفت از انتشارِ نام، آدرس، شمارهٔ تلفن و ایمیلِ ثبت‌کننده در خروجیِ عمومیِ WHOIS دست بردارند، و جست‌وجویی که قبلاً یک شخص را برمی‌گرداند، از آن پس REDACTED FOR PRIVACY و یک فرمِ تماس برمی‌گرداند. ظاهرش حریمِ خصوصی است. واقعیتش یک تنظیمِ نمایش است.

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

دو چیزِ دیگر هم از سانسور جان به‌در بردند. اولی تاریخچه است: آرشیوهای تجاری برای دو دهه از WHOIS اسنپ‌شات گرفتند و آن اسنپ‌شات‌ها هرگز منقضی نمی‌شوند، پس نامی که پیش از 2018 با جزئیاتِ واقعی ثبت شده باشد، صرف‌نظر از آنچه رکورد امروز می‌گوید، برای همیشه افشا شده است. دومی بقیهٔ کانفیگِ خودِ شماست — نیم‌سرورهایی که انتخاب کردید، آدرسِ دفن‌شده در SOAِ شما، صندوقِ گزارش‌دهیِ DMARC، و هر گواهی‌ای که تا امروز درخواست داده‌اید. سانسور یک فیلد را خالی کرد و چهار موردِ دیگر را در حالِ انتشار رها کرد، و همین چهار مورد جایی است که این راهنما بیشترِ وقتش را آنجا می‌گذراند.

پسوند را پیش از ریجیسترار انتخاب کنید

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

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

هیچ‌کدامِ این‌ها آن‌قدر پایدار نیستند که بشود حفظشان کرد، و هر فهرستی از "TLDهای دوستدارِ حریمِ خصوصی" که آنلاین پیدا می‌کنید، تا زمانی که آن را می‌خوانید بخشی‌اش قدیمی و غلط شده است. به‌جایش خودتان چک کنید: مرحلهٔ دو همان جست‌وجوهایی را اجرا می‌کند که به هر سه پرسش، برای هر پسوندی که در نظر دارید، با استفاده از دامنه‌ای که مالکش نیستید، پاسخ می‌دهد. پیش از پرداخت این‌ها را اجرا کنید، چون یک پسوندِ بد را نمی‌شود با انتقالِ ریجیسترار درست کرد. تنها راهِ درستش این است که از نو، با نامی دیگر شروع کنید.

سه مدلِ ریجیسترار، و هرکدام در برابرِ چه چیزی دوام می‌آورد

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

در مدلِ owner-of-record — همان آرایشی که Njalla آن را معروف کرد — ارائه‌دهنده نام را به‌نامِ خودش ثبت می‌کند و یک حقِ قراردادی برای استفاده از آن به شما می‌دهد، پس هویتِ شما اصلاً هیچ‌وقت به‌عنوانِ ثبت‌کننده ثبت نمی‌شود. چیزی در ریجیستری نیست که افشا شود، چون اصلاً چیزی آنجا نیست. این معامله واقعی است و ارزشِ گفتنِ صریح دارد: شما به‌طورِ قانونی مالکِ دامنه نیستید. دارید به توانِ مالیِ یک شرکت، به میلِ آن به مقاومت در برابرِ یک درخواست، و به علاقهٔ تداوم‌یافته‌اش به این کسب‌وکار تکیه می‌کنید. اگر ورشکست شود، خریداری شود، یا تصمیم بگیرد که شما بیش از ارزش‌تان دردسر دارید، تنها راهِ چاره‌تان یک اختلافِ قراردادی بر سرِ دارایی‌ای است که به‌نامِ کسِ دیگری ثبت شده است.

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

فرمِ ثبت‌نام: چه چیزی را می‌توانید رد کنید، چه چیزی معلقتان می‌کند

فرم یک نام، یک آدرسِ پستی، یک شمارهٔ تلفن و یک ایمیل می‌خواهد. سه‌تای این‌ها داده‌های قراردادی‌اند که ریجیسترار موظف به نگه‌داشتنشان است و تقریباً هرگز راستی‌آزمایی‌شان نمی‌کند. یکی‌شان باربر است. ایمیل همان چیزی است که اهمیت دارد: طبقِ قراردادِ اعتبارسنجیِ ریجیسترار، آدرسِ ثبت‌کننده باید بعد از ثبت تأیید شود، و اگر کسی روی لینک کلیک نکند، دامنه معلق می‌شود — معمولاً ظرفِ پانزده روز. یک صندوقِ یک‌بارمصرف که از وجود بازمی‌ایستد، دامنه را هم با خودش می‌برد.

پس آدرس باید نام‌مستعاری باشد که واقعاً کنترلش را دارید و سه سالِ دیگر هم همچنان می‌خوانیدش، نزدِ ارائه‌دهنده‌ای که برای بازکردنِ حساب شمارهٔ تلفن نمی‌خواهد و به‌خاطرِ بی‌فعالیتی حسابش را نمی‌بندد. بقیهٔ چیزهای آن فرم مسئلهٔ سازگاری‌اند نه مسئلهٔ راستی: یک مجموعه جزئیاتِ باورپذیر انتخاب کنید، رمزنگاری‌شده ذخیره‌شان کنید، و دقیقاً همان‌ها را نزدِ ریجیسترار، در پروفایلِ حساب، و در هر تیکتِ پشتیبانی‌ای که تا به‌حال بازمی‌کنید به‌کار ببرید. ناسازگاری همان چیزی است که یک حساب را به سمتِ بازبینیِ دستی می‌فرستد، و بازبینیِ دستی جایی است که یک انسان شروع می‌کند مدرک خواستن.

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

DNS دومین ثبت است

همان لحظه‌ای که یک زون منتشر می‌کنید، خودتان را هم دوباره منتشر می‌کنید، آن هم در فیلدهایی که هیچ‌کس آن‌ها را هویت به‌حساب نمی‌آورد. رکوردِ SOA یک آدرسِ ایمیل را رمزگذاری‌شده حمل می‌کند، به‌طوری‌که اولین نقطه‌اش جای @ را می‌گیرد، و فایل‌های زونِ دستی‌نویس معمولاً یک آدرسِ واقعی حمل می‌کنند. نام‌های نیم‌سرور یک اثرِانگشت‌اند: دو دامنه را به همان نیم‌سرورهای سفارشی اشاره بدهید و برای همیشه به‌هم لینکشان کرده‌اید، در یک دیتاستی که موتورهای جست‌وجوی reverse-nameserver ایندکس و نگه‌داری می‌کنند. و وقتی آن نیم‌سرورها خودشان داخلِ همان دامنه زندگی می‌کنند، ریجیستری رکوردهای glue منتشر می‌کند — یعنی آدرس‌های IPِ آن‌ها، در زونِ ریشه، بیرون از دسترسِ هر CDNای که جلوی سایت گذاشته‌اید. آدم‌ها یک هفته وقت می‌گذارند تا یک origin را پنهان کنند و بعد آدرسش را در یک رکوردِ glue لو می‌دهند.

DNSSEC یک هشدارِ مشخص را سزاوار است، چون به‌عنوانِ یک قابلیتِ امنیتی فروخته می‌شود اما مثلِ یک قابلیتِ افشا رفتار می‌کند. امضاکردنِ یک زون با NSEC یک لیستِ زنجیره‌ایِ همهٔ نام‌های داخلش را منتشر می‌کند، که هرکسی ظرفِ چند ثانیه می‌تواند پیمایشش کند. NSEC3 به‌جایش نام‌ها را هش می‌کند، که بهتر به‌نظر می‌رسد و فقط قیمت را بالا می‌برد: هش‌ها آفلاین قابلِ کرک‌کردن‌اند و ابزارهایی هستند که کارشان فقط همین است. اگر پاسخ‌های احرازشده می‌خواهید زون را امضا کنید، و با این درک وارد شوید که دارید فهرستِ ساب‌دامنه‌هایتان را پنهان نمی‌کنید. هیچ‌وقت هم نمی‌کردید.

اینکه زون کجا سرو می‌شود، تصمیمی جداست از اینکه چه کسی نام را ثبت کرده، و پخش‌کردنشان روی دو شرکت در دو کشور، بیشتر از هرکدام از این انتخاب‌ها به‌تنهایی می‌ارزد. اجرای نیم‌سرورهای خودتان کنترل و یک اثرِانگشتِ کوچک و متمایز می‌خرد؛ استفاده از نیم‌سرورهای یک ارائه‌دهندهٔ بزرگ، گمنامی در میانِ جمعیت و یک شرکتی می‌خرد که هر کوئری را لاگ می‌کند و به یک درخواست دربارهٔ آن پاسخ می‌دهد. اینجا هیچ گزینهٔ مجانی‌ای نیست، فقط یک انتخاب دربارهٔ اینکه کدام رکورد را ترجیح می‌دهید وجود داشته باشد. اگر سایتِ پشتِ آن زون، پشتِ یک edge نشسته، راهنمای origin-IP بقیهٔ آن زنجیره را پوشش می‌دهد.

نشت‌هایی که بعد از ثبت‌نام سر می‌رسند

certificate transparency بزرگ‌ترینشان است. هر گواهیِ موردِ اعتمادِ عمومی در یک لاگِ عمومی، فقط‌الحاقی و برای‌همیشه قابلِ‌جست‌وجو نوشته می‌شود، پس هر نامی که تا امروز از یک CA خواسته‌اید امضا کند، قابلِ‌کشف است — از جمله هاست‌های staging.، vpn. و old-ای که فکر می‌کردید کسی از آن‌ها خبر ندارد، و از جمله همان نامِ داخلی‌ای که یک‌بار تصادفاً صادرش کردید و همان بعدازظهر حذفش کردید. یک ورودیِ لاگ را نمی‌شود پس گرفت. تنها کنترل، بالادستی است: یک wildcard را روی اعتبارسنجیِ DNS-01 درخواست کنید تا هاست‌نیم‌های تک‌تک هرگز اصلاً وارد هیچ لاگی نشوند، و نام‌های واقعاً خصوصی را روی یک CAِ داخلی نگه دارید که هیچ‌چیز را لاگ نمی‌کند.

میل دو موردِ دیگر را منتشر می‌کند. یک رکوردِ SPF نامِ relayای را که از طریقش می‌فرستید فاش می‌کند. یک رکوردِ DMARC معمولاً نامِ یک انسان را فاش می‌کند، چون rua= جایی است که گزارش‌ها به آن می‌روند و آدم‌ها صندوقِ واقعیِ خودشان را همان‌جا می‌گذارند. و یک MX که به همان ماشینی اشاره می‌کند که سایت را هم سرو می‌کند، آدرسِ origin را به هرکسی که یک کوئری اجرا کند تحویل می‌دهد — میل رایج‌ترین راهی است که یک origin از پشتِ یک edge فرار می‌کند.

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

تمدید، انتقال، و شکستِ سالِ سوم

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

قفل‌ها نیمهٔ دیگرِ ماجرا هستند، و رایگان‌اند. clientTransferProhibited، clientUpdateProhibited و clientDeleteProhibited هرکدام فقط یک کلیک می‌خواهند و کلِ آن دسته از حمله را که با واردشدنِ کسی به حسابِ ریجیسترارِ شما شروع می‌شود، خاموش می‌کنند. برخی ریجیستری‌ها هم registry lock ارائه می‌دهند، که پیش از هر تغییری به یک تأییدِ out-of-band نیاز دارد و روی نامی که از دست‌دادنش برایتان مقدور نیست، ارزشِ پول‌دادن دارد. کدِ مجوزِ انتقال را رمزنگاری‌شده و آفلاین نگه دارید، و بدانید که تغییرِ اطلاعاتِ ثبت‌کننده یک منعِ انتقالِ شصت‌روزه را فعال می‌کند — پس این خانه‌تکانی را وقتی عجله ندارید انجام دهید، هیچ‌وقت وسطِ یک حادثه.

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

یک مدلِ تهدیدِ واقع‌بینانه

دقیق باشید دربارهٔ اینکه این چه چیزی را شکست می‌دهد. در برابرِ اسکرِیپرها، دلال‌های داده، رقبا، پژوهشگرانِ متن‌بازِ open-source، و آن فرصت‌طلبی که از یکی از نام‌های شما به بقیه می‌رسد، یک هویتِ ثبت‌کنندهٔ تمیز همراه با یک زونِ بدونِ نشت جواب می‌دهد، و کاملاً جواب می‌دهد — چیزی در رکوردِ عمومی نیست که از آن به بقیه برسند. در برابرِ یک شاکیِ مدنی، هزینه را از یک جست‌وجوی رایگان به یک فرآیندِ حقوقی بالا می‌برد، که تفاوتی واقعی و اغلب تعیین‌کننده است. در برابرِ یک UDRP که یک دارندهٔ علامتِ تجاری ثبت کرده، مدلِ پروکسی خیلی کم به شما می‌دهد، و مدلِ owner-of-record یک شرکت به شما می‌دهد که باید تصمیم بگیرد چقدر می‌خواهد به‌نمایندگی از شما بجنگد.

در برابرِ دولتی که بر ریجیستریِ شما حوزهٔ قضایی دارد، برنده نمی‌شود، و هیچ آرایشی از ریجیسترارها هم نمی‌شود: نام را می‌شود در ریشه معلق کرد، فارغ از اینکه چه کسی نگهش می‌دارد. این استدلالی است برای انتخابِ آگاهانهٔ پسوند و برای مالکیتِ محتوایتان به‌اندازه‌ای که بتوانید جابه‌جایش کنید، نه برای یک ریجیسترارِ باهوش‌تر. و در برابرِ اشتباه‌های خودتان، هیچ چیزی ارائه نمی‌دهد. یک لاگین از یک پروفایلِ مرورگرِ شخصی، یک تیکتِ پشتیبانی که با لحنِ همیشگی‌تان از آدرسِ همیشگی‌تان نوشته شده، یک گواهیِ واحد که هر دو پرسونا را پوشش می‌دهد، و رکوردی که این راهنما را صرفِ تمیز نگه‌داشتنش کردید، ظرفِ یک بعدازظهر دوباره به‌هم دوخته می‌شود.

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

گام‌به‌گام

1. 01

   بررسی کنید نام همین حالا چه چیزی را منتشر می‌کند

   از دامنه‌ای که دارید شروع کنید، یا از دامنه‌ای که در آستانهٔ خریدنش از کسِ دیگری هستید. RDAP همان سرویسِ ثبتِ ماشین‌خوانی است که جایگزینِ WHOISِ پورت-43 برای gTLDها شده، به JSON روی HTTPS صحبت می‌کند، و rdap.org شما را به ریجیستریِ درست بوت‌استرپ می‌کند. بسیاری از ccTLDها هنوز فقط روی پورتِ 43 پاسخ می‌دهند، و چندتایی‌شان بیشتر از یک gTLD منتشر می‌کنند.

   # gTLDs: RDAP is the authoritative registration record
   curl -s https://rdap.org/domain/example.com | jq '{
     status,
     ns:     [.nameservers[]?.ldhName],
     events: [.events[] | {(.eventAction): .eventDate}],
     roles:  [.entities[]?.roles[]?]
   }'
   
   # the fields that are supposed to be blank -- read them, do not assume
   curl -s https://rdap.org/domain/example.com \
     | jq -r '.. | objects | select(has("vcardArray")) | .vcardArray[1][]
              | select(.[0]=="fn" or .[0]=="email" or .[0]=="adr")
              | "\(.[0]): \(.[3])"'
   
   # ccTLDs: many are port-43 only, and less redacted than you expect
   whois example.de | grep -viE '^%|^$'

   اگر یک نامِ واقعی، یک آدرسِ واقعی یا یک ایمیلِ شخصی برگشت، همین‌جا متوقف شوید: انتقالِ دامنه پاکش نمی‌کند، چون آرشیوها از قبل آن را دارند. آن نام از نظرِ حریمِ خصوصی سوخته است، و حرکتِ صادقانه این است که یک نامِ تازه ثبت کنید و ریدایرکت کنید.

2. 02

   پیش از متعهدشدن به پسوند، امتحانش کنید

   پسوندهای کاندید را تجربی مقایسه کنید، نه بر اساسِ یک پستِ وبلاگ. در هرکدام، دامنه‌ای را که مالکش نیستید جست‌وجو کنید و بخوانید ریجیستری واقعاً چه چیزی برمی‌گرداند، بعد چک کنید آن ریجیستری را چه کسی و کجا اداره می‌کند. شکلِ خروجی بینِ ریجیستری‌ها فرق می‌کند، و دقیقاً به همین دلیل است که ارزشِ اجراکردن دارد، نه فرض‌کردن.

   # what does each registry publish about a registrant?
   for d in example.com example.de example.is example.nl; do
     printf '\n== %s\n' "$d"
     curl -s "https://rdap.org/domain/$d" \
       | jq -r '.entities[]? | "\(.roles|join(",")): \(
           [.vcardArray[1][]? | select(.[0]=="fn")][0][3] // "redacted")"' \
       2>/dev/null || whois "$d" | grep -iE '^(registrant|owner|admin-c)'
   done
   
   # who runs the registry, and under whose law does that company sit?
   curl -s https://www.iana.org/domains/root/db/is.html \
     | sed -n 's/.*Organisation:*//p;/Registry Information/,+6p' | head -20

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

3. 03

   پیش از بازکردنِ حساب، هویت را بسازید

   هویت را در یک نشست بسازید و هیچ‌چیز را به‌صورتِ متنِ ساده ننویسید. هندل نباید هیچ سابقه‌ای حمل کند — نه یک نیک‌نیمی که جای دیگر استفاده کرده‌اید، نه کلمه‌ای که برای شما معنایی دارد. صندوق باید یک نام‌مستعار نزدِ ارائه‌دهنده‌ای باشد که شمارهٔ تلفن نمی‌خواهد، و باید سه سال بی‌توجهی را دوام بیاورد، چون ایمیلِ تأییدِ ریجیسترار و هر اعلانِ تمدیدی همان‌جا فرود می‌آید.

   # a handle with no history and no meaning
   head -c 10 /dev/urandom | base32 | tr -d '=' | tr 'A-Z' 'a-z'
   
   # a key for the secrets this account is about to hand you
   age-keygen -o registrar.key            # public key is printed on stderr
   
   # store profile details, recovery codes and (later) the auth code
   age -r age1... -o registrar.age registrar.txt && shred -u registrar.txt
   
   # read it back only when you need it
   age -d -i registrar.key registrar.age

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

4. 04

   ثبت کنید، بعد مثلِ یک غریبه به خودتان نگاه کنید

   نام را ثبت کنید، همان روز روی لینکِ تأیید کلیک کنید، و بعد پیش از چک‌کردنش صبر کنید تا رکورد به ریجیستری پراپاگیت شود — خروجیِ جالب چند ساعتِ بعد ظاهر می‌شود، نه فوری. دنبالِ هر فیلدی هستید که سانسور نشده، و کدهای وضعیتی که به شما می‌گویند تأیید واقعاً کامل شده.

   # the public record, 24h in
   curl -s https://rdap.org/domain/example.com | jq '{status, events}'
   # expect: "active" -- NOT "pendingVerification" or "clientHold"
   
   # anything at all that survived redaction
   curl -s https://rdap.org/domain/example.com \
     | jq -r '.. | objects | .vcardArray? // empty | .[1][]
              | select(.[0]=="fn" or .[0]=="email" or .[0]=="adr" or .[0]=="tel")
              | "\(.[0]): \(.[3])"'
   
   # and the archive view: does this name have a past you did not buy?
   curl -s 'https://crt.sh/?q=example.com&output=json' \
     | jq -r '.[] | "\(.not_before)  \(.name_value)"' | sort -u | head -20

   وضعیتِ clientHold یا pendingVerification یک هفته بعد، یعنی ایمیلِ تأیید هرگز نرسیده یا هرگز کلیک نشده، و دامنه روی شمارشِ معکوسِ تعلیق است. این را پیش از هر چیزِ دیگری درست کنید — این رایج‌ترین راهی است که یک دامنهٔ ناشناسِ درست‌ثبت‌شده، در اولین ماهش از دست می‌رود.

5. 05

   زونی منتشر کنید که نامتان را فاش نکند

   حالا آن بخشی که بیشترین نشت را دارد و کمترین بررسی می‌شود. زونِ خودتان را همان‌طور بخوانید که یک غریبه می‌خواندش: آدرسِ SOA، نام‌های نیم‌سرور، glueای که ریجیستری از طرفِ شما منتشر می‌کند، و اینکه آیا کسی می‌تواند کلِ آن را به‌سادگی دانلود کند.

   # SOA -- the second field is an email, first dot standing in for @
   dig +short SOA example.com
   # ns1.example.com. hostmaster.example.com. 2026090601 7200 3600 1209600 3600
   #                  ^-- must not be a personal address
   
   # glue: if your nameservers live inside the domain, the ROOT holds their IPs
   dig +norec +short NS example.com @a.gtld-servers.net
   dig +norec +short ns1.example.com A @a.gtld-servers.net
   
   # can anyone download the entire zone?
   dig AXFR example.com @ns1.example.com | head
   # want: "Transfer failed" -- anything else is your full host inventory
   
   # pin issuance to one CA, and give abuse somewhere impersonal to land
   dig +short CAA example.com
   # 0 issue "letsencrypt.org"
   # 0 iodef "mailto:abuse@example.com"

   به این ترتیب درستش کنید: آدرسِ SOA را با یک صندوقِ نقشی در خودِ دامنه جایگزین کنید، نیم‌سرورها را بیرون از دامنه ببرید (یا کلاً از ماشینِ خودتان بیرون) تا هیچ glueای لازم نباشد، AXFR را از هر چیزی جز سکاندری‌های خودتان رد کنید، و یک رکوردِ CAA اضافه کنید. اگر با DNSSEC امضا می‌کنید، از NSEC3 استفاده کنید و بپذیرید که فهرستِ ساب‌دامنه‌هایتان همچنان برای هرکسی که حاضر باشد یک ساعت وقت بگذارد، شمارش‌پذیر است.

6. 06

   نشتِ گواهی و میل را ببندید

   دو دیتاستِ عمومی، بیشتر از DNSِ شما دربارهٔ زیرساختتان می‌دانند. certificate transparency هر هاست‌نیمی را که تا امروز امضا گرفته‌اید می‌شناسد؛ رکوردهای میلِ خودتان نامِ relay، صندوقِ گزارش‌دهی، و اغلب originِ شما را فاش می‌کنند. هر دو را روی خودتان شمارش کنید.

   # every name you have ever asked a CA to sign, including deleted ones
   curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
     | jq -r '.[].name_value' | tr ' ' '\n' | sort -u
   
   # the mail records, read for identity rather than deliverability
   dig +short TXT example.com          # SPF include: names your relay
   dig +short TXT _dmarc.example.com   # rua=mailto: usually names a human
   dig +short MX  example.com          # an MX on the origin IS the origin
   
   # does the site answer on its own address, ignoring the edge?
   curl -sI --resolve example.com:443:203.0.113.10 https://example.com/ | head -1

   صدورِ آینده را به یک wildcardِ اعتبارسنجی‌شده روی DNS-01 منتقل کنید تا هاست‌نیم‌ها دیگر وارد لاگ‌ها نشوند، rua= را به آدرسی روی خودِ دامنه اشاره بدهید نه یک صندوقِ شخصی، و میل را از روی origin بردارید — یک relay یا یک ماشینِ جدا، هرگز همان باکسی که سایت رویش اجرا می‌شود. نام‌هایی که از قبل در لاگ‌ها هستند را نمی‌شود پس گرفت؛ بازنشسته‌شان کنید یا بپذیرید که برای همیشه عمومی‌اند.

7. 07

   قفلش کنید، مانیتورش کنید، و برای غیبتِ خودتان برنامه بریزید

   آخرین کار: ثبت را سخت برای جابه‌جایی و سخت برای فراموش‌کردن کنید. آن سه قفلِ client رایگان‌اند و کلِ آن دسته از حمله را که از داخلِ حسابِ ریجیسترارِ شما شروع می‌شود، متوقف می‌کنند. تاریخِ انقضا باید در سامانهٔ هشدارِ شما باشد، نه در صندوقی که ممکن است دیگر نخوانیدش.

   # what the registry says about locks and dates
   curl -s https://rdap.org/domain/example.com \
     | jq -r '.status[], (.events[] | "\(.eventAction) \(.eventDate)")'
   # want: clientTransferProhibited, clientUpdateProhibited, clientDeleteProhibited
   
   # days until expiry, straight from the registry -- no email involved
   exp=$(curl -s https://rdap.org/domain/example.com \
         | jq -r '.events[] | select(.eventAction=="expiration") | .eventDate')
   echo $(( ( $(date -d "$exp" +%s) - $(date +%s) ) / 86400 )) days left
   
   # keep the escape hatch encrypted and off the machine it protects
   age -r age1... -o auth-code.age auth-code.txt && shred -u auth-code.txt

   آن چکِ انقضا را از cron اجرا کنید و در نود روزِ مانده هشدار بدهید. بستهٔ رمزنگاری‌شده — جزئیاتِ حساب، کدهای بازیابی، کدِ مجوزِ انتقال — را جایی نگه دارید که فردی موردِاعتمادتان بتواند به آن دسترسی داشته باشد، چون یک دامنهٔ ناشناس نه ترکه‌ای دارد و نه نردبانِ پشتیبانی‌ای. بعد مرحله‌های چهار تا شش را سالی یک‌بار دوباره اجرا کنید: زون‌ها دِریفت می‌کنند، گواهی‌ها به‌دستِ آدم‌هایی صادر می‌شوند که فراموش می‌کنند، و نشتی که در ژانویه بسته بودید معمولاً تا پاییز برگشته است.