VPSCrypto
میتوانید بابت یک سرور با Monero پرداخت کنید، چیزی جز یک آدرس یکبارمصرف به آن ندهید، و هرگز مدرکی آپلود نکنید. بعد یازده دلار برای یک نام دامنه خرج میکنید، نام واقعیتان را در فرمی تایپ میکنید چون فرم آن را خواسته بود، و به شرکتی در کشوری دیگر سابقهای دائمی میدهید که آن نام را به سایت پیوند میزند. سرور همان لایهای بود که به آن فکر کرده بودید. دامنه همان لایهای است که مردم را گیر میاندازد.
دامنه چیزی نیست که مالکش باشید. این یک اجاره از یک ریجیستری است که ثبتکنندهای آن را به شما میفروشد، زیر قواعدی که خودتان ننوشتهاید و میتوانند بدون اطلاع شما تغییر کنند. سه طرف متفاوت میتوانند آن را پس بگیرند، و سریعترینشان اصلاً به حکم دادگاه نیاز ندارد. این استدلالی بر ضد ثبتکردن یک دامنه نیست — استدلالی است برای انتخاب آگاهانه، با دانستن دقیق اینکه کدام طرف را همین الان تبدیل به تنها نقطهٔ شکست خود کردهاید.
این راهنما کل زنجیره را پوشش میدهد: اینکه حریم خصوصیِ ثبتنام واقعاً چه چیزی را پنهان میکند و از چه کسی، چگونه یک TLD را مثل یک حوزهٔ قضایی بخوانید نه یک قیمت، چگونه بدون کارت پرداخت کنید، چگونه نام را قفل کنید تا نتوان آن را از زیر پایتان درآورد، و چگونه آن را همراه با رکوردهایی که از پوشهٔ اسپم دیگران دورش نگه میدارد به سرورتان تفویض کنید. ما اساساً VPS ارائه میدهیم و دامنه نمیفروشیم، پس چیزی اینجا نیست که بخواهیم شما را بهسمتش سوق دهیم.
آنچه حریم خصوصیِ ثبتنام واقعاً پنهان میکند، و از چه کسی
وقتی نامی را ثبت میکنید، اطلاعاتتان دستکم به دو جا میرود: ثبتکنندهای که آن را از او خریدهاید، و ریجیستریای که TLD را اداره میکند. یک سرویس حریم خصوصی چیزی را که استعلامِ عمومی برمیگرداند تغییر میدهد. هیچچیزی در آن دو نسخه تغییر نمیکند.
دو محصول از نظر ساختاری متفاوت زیر یک کلمهٔ یکسان فروخته میشوند، و تفاوتشان بیش از قیمت اهمیت دارد:
- یک سرویس حریم خصوصی یا پراکسی. شما همچنان دارندهٔ قانونیِ ثبت باقی میمانید؛ ثبتکننده بهجای اطلاعات شما یک مخاطب واسط منتشر میکند و نامهها را به شما میرساند. سریع، ارزان، معمولاً فقط یک تیکزدن. ثبتکننده میتواند آن را پس بگیرد — با یک شکایت، با یک احضاریه، یا چون شرایطش اجازه میدهد.
- یک دارندهٔ نیابتی. یک شخص ثالث بهعنوان دارندهٔ نام ثبت میشود و شما قراردادی دارید که کنترل آن را به شما میدهد. هیچچیز از شما اصلاً به ریجیستری نمیرسد. این معامله واقعی است: شما دارنده نیستید، پس اگر آن شرکت ورشکسته شود، سیاستش را تغییر دهد یا تصمیم بگیرد شما یک ریسک هستید، ادعای شما یک اختلاف قراردادی است، نه یک ثبتنام که خودتان کنترلش کنید.
دانستنِ چیزی که همین حالا رایگان در اختیار دارید هم ارزش دارد. از سال 2018، قواعد حفاظت از داده صنعت را واداشت که بهطور پیشفرض اطلاعات تماسِ دارندگان را برای TLDهای عمومی سانسور کند، پس یک استعلام عمومی روی یک .com که در اختیار یک فرد است معمولاً «REDACTED FOR PRIVACY» را برمیگرداند، چه پولی برای چیزی داده باشید چه نه. پروتکل هم تغییر کرد: از ژانویهٔ 2025 ثبتکنندهها و ریجیستریهای TLDهای عمومی دیگر مجبور نیستند روی پروتکل قدیمیِ WHOIS مبتنی بر پورت-43 پاسخ دهند، و RDAP همان استعلامی است که واقعاً تضمینشده کار میکند. TLDهای کدکشوری قواعد خودشان را دارند و برخی از آنها همهچیز را منتشر میکنند.
پس دربارهٔ چیزی که میخرید دقیق باشید. حریم خصوصیِ ثبتنام بهطور قابلاتکا اسکرِیپرها، دلالهای عمدهٔ داده، اسپم، و اولین جستوجویی که هر فرد کنجکاوی انجام میدهد را شکست میدهد. ثبتکننده، ریجیستری، یک احضاریه، یا نسخهای که کسی پیش از روشنکردنِ آن سرویس از رکورد گرفته را شکست نمیدهد.
سه طرف میتوانند آن را بگیرند، و فقط یکی از آنها کند است
دربارهٔ یک دامنه همانطور فکر کنید که دربارهٔ هر وابستگیِ دیگری فکر میکنید: نه «آیا خوب است» بلکه «چه کسی میتواند خاموشش کند، و برای این کار به چه چیزی نیاز دارد». سه پاسخ وجود دارد.
- ثبتکننده. با فاصلهٔ زیاد سریعترین. میتواند
clientHoldرا اعمال کند، که نام را از زون حذف میکند — دامنه همچنان وجود دارد، همچنان ثبتشده نشان داده میشود، و بهسادگی در هیچکجای دنیا دیگر ریزالو نمیشود. هیچ دادگاهی درگیر نیست. یک بندِ استفادهٔ مجاز و یک شکایت کافی است، و برخی ثبتکنندهها فقط با همان شکایت اقدام میکنند. - ریجیستری. کندتر، نادرتر، سنگینتر. یک ریجیستری میتواند
serverHoldرا اعمال کند یا انتقالها را مسدود کند، و هیچ ثبتکنندهای نیست که به آن نقل مکان کنید و از این فرار کنید، چون ریجیستری خودِ TLD است. هر ریجیستری زیر یک حوزهٔ قضاییِ ملی قرار دارد: اپراتور.comو.netبه ایالات متحده پاسخگوست، و هر TLD کدکشوری به دولت یا نمایندهٔ خودش پاسخگوست. - دادگاه، از هر دو طرف. احکام معمولی، بهعلاوهٔ مسیر مخصوصِ دامنه: یک دعوای علامت تجاری که تحت UDRP مطرح شود، به تصمیمی میرسد که ثبتکننده قراردادی موظف به اجرای آن است، بدون هیچ قاضی و بدون امکانِ تجدیدنظر در دادگاهی ملی، مگر آنکه خودتان یکی را آغاز کنید.
این پرسشی را که باید از یک ثبتکننده بپرسید بازتعریف میکند. نه «آیا حریم خصوصی ارائه میدهید» — تقریباً همهشان میدهند. در عوض: وقتی شکایتی دریافت میکنید چه میکنید، و باید از قانونِ کدام کشور پیروی کنید؟ ثبتکنندهای که اول تعلیق میکند و بعد میپرسد، بیسروصدا به ضعیفترین حلقهٔ یک برپاییِ در باقیِ موارد دقیق تبدیل شده است.
ما نسخهٔ خودمان از این ماجرا را داریم. این سایت از زمانِ راهاندازی روی vpscrypto.io اجرا میشد تا 29 ژوئیهٔ 2026، که به vpscrypto.com تبدیل شد — همان شرکت، همان سرورها، همان حسابها، همان مسیرها، که در صفحهٔ دربارهٔ ما و در فهرست حقایق مستند شده است. درسی که از این کار گرفتیم همان چیزی است که ارزشِ انتقال دارد: لایهٔ ثبتکننده همان بخشی از پشته است که کمترین کنترل را رویش دارید، و ازپیشبرنامهریزیشدهبودنِ جابهجایی، بیش از هر اطمینانی که کسی از پیش به شما بدهد ارزش دارد.
TLD را مثل یک حوزهٔ قضایی بخوانید، نه مثل یک قیمت
ریجیستری قواعد را مینویسد. ثبتکننده آنها را اجرا میکند. یک ثبتکنندهٔ آسانگیر که زیر یک ریجیستریِ سختگیر نشسته باشد، هیچ سودی برایتان ندارد، و به همین دلیل انتخاب پسوند بیش از آنچه معمولاً موردتوجه قرار میگیرد فکر میخواهد، و بسیار بیشتر از آنچه قیمتِ سال اول توجیه میکند.
پیش از آنکه عاشق یک نام شوید، به چهار پرسش دربارهٔ پسوندی که با آن تمام میشود پاسخ دهید:
- چه کسی ریجیستری را اداره میکند، و آن شرکت کجا ثبت شده است؟ این یک واقعیت عمومی است و بررسیاش تنها یک دستور میخواهد.
- آیا ریجیستری اطلاعات دارنده را منتشر میکند، یا اجازهٔ سرویسهای حریم خصوصی را میدهد؟ برخی این کار را نمیکنند. برای نمونه، پسوند
.usنیازمند انتشار اطلاعات دارنده است و ثبتِ نیابتی را مجاز نمیداند — هیچ ثبتکنندهای نمیتواند دور آن بزند. - آیا نیازمندیِ حضور یا پیوند وجود دارد؟
.euبه یک پیوند با اتحادیهٔ اروپا یا EEA نیاز دارد،.caبه حضوری کانادایی نیاز دارد، و چند کدکشوریِ اروپایی اگر دارنده جای دیگری زندگی کند به یک مخاطب محلیِ ثبتشده نیاز دارند. اینها دقیقاً نقطهٔ مقابل خصوصیبودناند: شما را وادار میکنند هویتی واقعی و قابلتأیید را به نام متصل کنید. - آیا پسوند ریسک سیاسی دارد؟ TLDهای کدکشوری به قلمروها گره خوردهاند، و قلمروها تغییر میکنند. در سال 2024 بریتانیا موافقت کرد حاکمیتِ قلمروی پشتِ
.ioرا به موریس منتقل کند، که یک علامت سؤال روی پسوندی گذاشت که دهها هزار شرکت فناوری رویش بنا شدهاند. بازنشستهشدنِ یک TLD کدکشوری فرایندی است که با سال سنجیده میشود نه هفته، پس این یک وضعیت اضطراری نیست — یک نمونهٔ روشن از دستهای ریسک است که TLDهای عمومی اصلاً ندارند.
بعد قیمت را درست بخوانید. عددی که اهمیت دارد تمدید است، نه سال اول؛ نامی با قیمت 0.99 دلار که با 45 دلار تمدید میشود، یک دامنهٔ 45 دلاری با یک تخفیفِ چسبیده به آن است. بررسی کنید آیا حریم خصوصی شاملِ قیمت است یا جدا حساب میشود، آیا ثبتکننده برای آزادکردنِ نامی که میخواهید جابهجا کنید هزینه میگیرد، و آیا دامنه بهعنوان پرمیوم علامت خورده، چون نامهای پرمیوم اغلب برای همیشه با نرخ پرمیوم تمدید میشوند.
برای بیشتر مردم پاسخ صادقانه بیروح است: یک TLD عمومیِ قدیمی از یک ثبتکننده که با دقت انتخابش کردهاید، بیشتر از یک کدکشوریِ باهوشانه که بهخاطر جناسش انتخاب شده دوام میآورد.
پرداخت فقط یکی از چهار وجه هویتی است
مردم رکورد ثبت را درست میکنند و سهتای دیگر را کاملاً باز میگذارند. یک دامنه شما را از چهار کانال مستقل افشا میکند، و ضعیفترینشان سطح همه را تعیین میکند:
- رکورد ثبت — که با یک سرویس حریم خصوصی یا یک دارندهٔ نیابتی حل میشود، همانطور که بالاتر گفته شد.
- پرداخت — کارتی با نام حقیقیِ شما، رکوردی نزد ثبتکننده، نزد پردازشگر، و نزد بانکتان میسازد، که هیچکدامشان را نمیتوانید بعداً سانسور کنید.
- صندوق ایمیل — آدرسِ روی حساب، اعلانهای تمدید، تأییدیههای انتقال، و بازنشانیهای رمز عبور را دریافت میکند. هم یک شناسه است و هم کلید کل ماجرا.
- الگوی دسترسی — آدرسی که از آن وارد میشوید، و اینکه آیا آن آدرس هرگز به چیز دیگری از آنِ شما هم وارد شده یا نه.
میدانِ ثبتکنندههایی که رمزارز میپذیرند بسیار کوچکتر از میدانِ میزبانهایی است که آن را میپذیرند، و برای Monero حتی نازکتر. اگر یکی پیدا کردید، همان انضباطی را بهکار ببرید که برای یک سرور بهکار میبرید: از کیفپولی بفرستید که آدرس برداشتِ صرافیِ شما نیست، و ارزی را ترجیح دهید که یک نمودار عمومیِ دائمی از منشأ وجوه منتشر نمیکند. راهنمای پرداخت با Monero ما جزئیات را پوشش میدهد، و خرید بدون کارت رسیدن به آنجا از صفر را پوشش میدهد.
اگر هیچ ثبتکنندهٔ رمزارزپذیری با نیازهای شما جور درنمیآید، این یک تصمیم واقعی است نه یک شکست: کارتی با نام خودتان نزد ثبتکنندهای با سابقهٔ سیاستیِ خوب، میتواند واقعاً معاملهٔ بهتری باشد در مقایسه با ثبتکنندهای رمزارزدوست که نامها را با اولین ایمیلی که دریافت میکند تعلیق میکند. آگاهانه تصمیمش بگیرید، نه اینکه پیشفرض به آن بیفتید.
گام به گام
- پیش از انتخاب نام، پسوند را انتخاب کنید
تصمیمگیری دربارهٔ TLD در قدم اول، از این جلوگیری میکند که یک حوزهٔ قضاییِ بد را فقط چون نام عالی بود توجیه کنید. با فهمیدنِ اینکه واقعاً چه کسی آن را اداره میکند شروع کنید — رکورد تفویض در IANA معتبر و عمومی است:
whois -h whois.iana.org io whois -h whois.iana.org comبلوکِ
organisationدر پاسخ، همان اپراتور ریجیستری و کشوری است که در آن ثبت شده. آن شرکت، زیر قانونِ آن کشور، همان سیاستی را تعیین میکند که ثبتکنندهتان روی شما اعمال خواهد کرد. صفحهٔ سیاست ثبتش را یک بار بخوانید؛ معمولاً کوتاه است و به شما میگوید آیا اطلاعات دارنده منتشر میشود، آیا سرویسهای حریم خصوصی مجازند، و آیا نیازمندیِ اقامت یا پیوندی وجود دارد.هرچیزی را که از شما اثباتِ حضور محلی میخواهد کنار بگذارید، مگر آنکه واقعاً چنین حضوری دارید و راضیاید مستندش کنید. پسوندی را ترجیح دهید که ریجیستریاش سابقهٔ تعلیقِ نامها بنا به درخواست را نداشته باشد. و اگر در حالِ سنجیدنِ یک TLD کدکشوری هستید، این را هم در قیمت لحاظ کنید که به یک قلمرو و یک دولت گره خورده، به شکلی که
.comاینطور نیست. - دسترسپذیری را با یک استعلامِ بیطرف بررسی کنید
بررسیِ دسترسپذیری در جعبهٔ جستوجوی یک ثبتکننده در عمل مشکلی ندارد — ICANN سالها پیش موضوعِ جلوخریدن را بررسی کرد و شواهد کمی از آن یافت — اما یک استعلامِ بیطرف هیچ هزینهای ندارد و چیزهای بیشتری به شما میگوید:
curl -s https://rdap.org/domain/example.com | jq -r '.ldhName, .status[]' whois example.com | grep -iE 'registrar:|creation|expiry|status'یک «not found» تمیز یعنی ثبتنشده. اگر ثبتشده برگردد، فیلدهای جالب، تاریخ ایجاد و کدهای وضعیتاند: نامی که در وضعیت
redemptionPeriodیاpendingDeleteاست دارد به سمتِ رهاشدن میرود و چیزی نیست که بهسادگی بتوانید بخرید، درحالیکه نامی که درclientHoldنشسته، متعلق به کسی است که ثبتکنندهاش آن را خاموش کرده. هر دو سیگنالهای مفیدی دربارهٔ تاریخچهای هستند که آن را به ارث میبرید.اگر لازمش دارید، اول
jqرا نصب کنید — باapt install jqروی Debian یا Ubuntu. - ثبتکننده را بر اساس پنج چیزی که واقعاً اهمیت دارد انتخاب کنید
بازاریابی را کاملاً نادیده بگیرید و نامزدها را بر اساس این موارد، به همین ترتیب، نمرهگذاری کنید:
پرداخت. آیا چیزی را میپذیرد که مایلید با آن پرداخت کنید، و آیا آن را مستقیم میپذیرد نه از طریق پردازشگری که مدارک شناساییِ خودش را جمع میکند؟
مدلِ حریم خصوصی. سرویس حریم خصوصی یا دارندهٔ نیابتی — این دو یک محصول نیستند. بفهمید کدامیک را میخرید، هنگام تمدید چقدر هزینه دارد، و ثبتکننده تحت چه شرایطی آن را برمیدارد.
حوزهٔ قضایی و سیاست. شرکت کجا ثبت شده، و سیاستِ استفادهٔ مجازش چه کاری را بدون حکم دادگاه به آن اجازه میدهد؟ دنبال صفحهای منتشرشده دربارهٔ شفافیت یا برخورد با سوءاستفاده بگردید. سکوت در آنجا خودش یک پاسخ است.
کنترل. قفلِ ثبتکننده، احراز هویت دومرحلهایای که SMS نباشد، و دسترسیِ خودخدمت به کد مجوز انتقال. ثبتکنندهای که شما را وادار میکند برای رفتن یک تیکت باز کنید، به شما گفته رفتن چطور پیش خواهد رفت.
DNS. یا سرورهای نامِ قابلاستفادهای که انواع رکوردِ موردنیازتان را پشتیبانی کنند —
CAA،TXT، مستعارسازیِ ریشهٔ دامنه — یا، دستکم، امکانِ تفویض به سرورهای نامِ خودتان.پرچمهای قرمزی که ارزشِ کنار کشیدن دارند: نبودِ احراز هویت دومرحلهای، حریم خصوصیای که فقط در یک ردهٔ گران فروخته میشود، نبودِ ثبتنام چندساله، و هر بندی که حق تغییرِ یکطرفهٔ اطلاعات ثبتتان را برای خودش محفوظ میدارد.
- هویتی را که دامنه زیرِ آن زندگی خواهد کرد بسازید
این کار را پیش از ثبتِ هرچیزی انجام دهید، چون انجامش بعداً یعنی تغییرِ دارنده و یک قفلِ انتقال.
یک صندوق ایمیل نزد ارائهدهندهای که به حریم خصوصی احترام میگذارد بسازید که فقط برای همین پروژه وجود دارد. نه آدرس شخصیتان، و نه همان آدرسِ حساب هاستینگتان — کل هدفِ جداکردنِ ثبتکننده از میزبان، اگر یک صندوق ایمیل هردو را باز کند، از بین میرود. آدرسِ بازیابیِ آن صندوق را هم روی چیزی بگذارید که باز هم آدرس شخصیتان نیست، چون زنجیرههای بازیابی همان راهیاند که حسابها واقعاً از دست میروند.
بعد: یک رمز عبورِ یکتا از یک مدیر رمز عبور، احراز هویتِ دومرحلهایِ TOTP بهجای SMS، و کدهای بازیابی که نوشته و آفلاین نگهداری شدهاند. SMS بهطور کلی عامل دومِ بدی است و اینجا بهطور خاص بدتر، چون یک شمارهتلفن، هویتی از دنیای واقعی است که همین الان به حساب پیچاندهاید.
در پایان، آدرسِ اطلاعرسانیای را که استفاده کردید یادداشت کنید. شش ماه از حالا، وقتی هشدارِ تمدیدی به صندوق ایمیلی میرود که فراموشش کردهاید، همان یادداشت است که دامنه را نجات میدهد.
- ثبتش کنید، و بیشتر از آنچه لازم به نظر میرسد سال پرداخت کنید
هنگام تسویهحساب، سه چیز ارزشِ آهستهکردن را دارند.
سال بخرید، نه ماه. هر تمدید یک پرداختِ دیگر است که باید درحالیکه حواستان هست موفق شود. ثبتنام برای پنج سال، پنج فرصت برای از دستدادنِ نام را به یکی تبدیل میکند.
اطلاعاتی بگذارید که بتوانید با آنها کنار بیایید — اما نسازیدشان. اینجا همان جایی است که مردم خودشان را به یک اشتباه راضی میکنند. دادهٔ ثبتِ عمداً نادرست، نقضِ قرارداد ثبتنام و زمینهای برای ثبتکننده است تا نام را کاملاً لغو کند: شما با دستِ خودتان دقیقاً همان زیانی را ساختهاید که سعی داشتید جلویش را بگیرید. سازوکارِ مشروع برای بیرون نگهداشتنِ نامتان از رکوردِ عمومی، سرویس حریم خصوصی یا دارندهٔ نیابتی است. از آن سازوکار استفاده کنید؛ به فرم دروغ نگویید.
انتظار داشته باشید 60 روز قفل بمانید. یک TLD عمومیِ تازهثبتشده تا 60 روز نمیتواند به ثبتکنندهٔ دیگری منتقل شود، و همان ساعت پس از هر انتقالی از نو شروع میشود. این یک تله نیست، اما به این معناست که ثبتکنندهای که دربارهٔ آن مطمئن نیستید، یک تعهدِ دوماهه است، پس دقتِ لازم را در قدمِ قبلی انجام دهید نه اینکه برنامهریزی کنید بعداً جابهجا شوید.
- قفلش کنید، بعد قفل را از بیرون تأیید کنید
قفلِ ثبتکننده و احراز هویت دومرحلهای را در پنل کنترل روشن کنید، بعد از بیرون تأیید کنید، چون پنلها و واقعیت گاهی با هم اختلاف دارند:
curl -s https://rdap.org/domain/example.com | jq -r '.status[]' whois example.com | grep -i 'status'چیزی که میخواهید ببینید
clientTransferProhibitedاست، ترجیحاً همراه باclientUpdateProhibitedوclientDeleteProhibited. اینها همان قفلهاییاند که خواسته بودید، و تا زمانی که برقرارند هیچ درخواستِ انتقالی نمیتواند کامل شود. این دو دستور همان وضعیتها را متفاوت هجی میکنند — WHOIS مبتنی بر پورت-43 نامهای EPP را با حروف بزرگِ ابتدای کلمه چاپ میکند، درحالیکه RDAP معادلهای حروفکوچکِ خودش را با فاصله چاپ میکند، پسclientTransferProhibitedبه شکلclient transfer prohibitedظاهر میشود وokبه شکلactive. از تغییرِ عبارت اینطور نتیجه نگیرید که قفلی وجود ندارد.آنهایی را هم بشناسید که نمیخواهید ببینید.
clientHoldوserverHoldیعنی نام توسطِ ثبتکننده یا ریجیستریتان از زون بیرون کشیده شده — دامنه همچنان وجود دارد و بهسادگی هیچجا ریزالو نمیشود.redemptionPeriodوpendingDeleteیعنی منقضی شده و روی ساعت است.okبهتنهایی یعنی اصلاً هیچ قفلی برقرار نیست، که پیشفرضِ بسیاری از ثبتکنندههاست و چیزی نیست که بخواهید.حالا که اینجایید، تأیید کنید ثبتنام به صندوق ایمیلی که در نظر داشتید اشاره میکند، و کدِ مجوز انتقال را جایی آفلاین نگه دارید. لحظهای که به آن کد نیاز پیدا میکنید معمولاً همان لحظهای است که دسترسی به پنلی را که در آن زندگی میکند از دست دادهاید.
- تصمیم بگیرید DNS کجا زندگی خواهد کرد
ثبتِ نام و پاسخدادن به پرسوجوهایش دو کارِ متفاوتاند، و میتوانید آنها را از افراد متفاوتی بخرید. سه ترتیبِ کاربردی وجود دارد:
سرورهای نامِ ثبتکننده. سادهترین، رایگان، و برای اکثریتِ قریببهاتفاقِ سایتها کافی. هزینهاش این است که یک حساب اکنون هم ثبتنام و هم زون را کنترل میکند، پس یک نفوذ یا یک تعلیق همهچیز را میبرد.
یک ارائهدهندهٔ DNSِ مدیریتشدهٔ جدا. این دو را از هم جدا میکند و معمولاً شبکهای بهتر و یک API به شما میدهد. حسابی دیگر برای ایمننگهداشتن، و شرکتی دیگر که کل زون و حجمِ پرسوجوهای شما را میبیند.
DNSِ معتبر روی سرورهای خودتان. هیچچیز بیرون از کنترل شما نیست، و یک تعهدِ عملیاتیِ واقعی: به دو سرور نامِ معتبر روی شبکههای متفاوت نیاز دارید، وگرنه یک قطعیِ VPS کلِ دامنه را آفلاین میکند نه فقط وبسایت را.
برای بیشترِ خوانندگان، DNS ثبتکننده یا یک ارائهدهندهٔ مدیریتشدهٔ جدا پاسخِ درستی است؛ فقط اگر واقعاً یک سرورِ ثانویه اجرا خواهید کرد، خودمیزبانی کنید. هرکدام را که انتخاب کنید، فایلِ زون را استخراج کنید و یک نسخه نگه دارید کنار بقیهٔ پشتیبانهای رمزگذاریشدهتان. بازسازیِ یک زون از حافظه در طول یک قطعی عذابآور است، و از آن چیزهایی است که تا قطعی پیش نیاید کسی کشفش نمیکند.
در این نقطه DNSSEC ارزشِ فکرکردن دارد. از بازدیدکنندگانتان در برابر پاسخهای جعلی محافظت میکند، و یک چرخشِ کلیدِ خرابشده، دامنهتان را بهشکلی آفلاین میکند که اشتباهاتِ معمولیِ DNS اینطور نیستند. اگر ثبتکننده و میزبانِ DNSتان کلیدها را بینِ خودشان مدیریت میکنند، فعالش کنید؛ اگر یعنی چرخشِ کلید را دستی انجام دهید و نگهش نمیدارید، خاموشنگهداشتنش یک انتخابِ قابلدفاع و صادقانه است.
- نام را به سمتِ VPS خود هدایت کنید
زون برای یک سرورِ تکی کوتاه است. آدرسهای خودتان را جایگزین کنید:
@ 300 IN A 203.0.113.10 @ 300 IN AAAA 2001:db8:2c:1::10 www 300 IN CNAME example.com.دو جزئیات که مردم را گیر میاندازد. اول، مشخصاتِ DNS اجازهٔ یک
CNAMEدر ریشهٔ یک زون را نمیدهد، و به همین دلیل@در بالا یک رکوردِAاست نه یک مستعار؛ ارائهدهندههایی که بهنظر میرسد چنین چیزی پیشنهاد میدهند، در سمتِ خودشانALIAS،ANAMEیا مسطحسازیِ CNAME را پیادهسازی میکنند. دوم، تا وقتی هنوز درحالِ تغییردادنِ چیزها هستید از یک TTLِ پایین مثل 300 استفاده کنید، و بهمحضِ باثباتشدنِ برپایی، آن را به یک ساعت برسانید — استدلالش، و اینکه TTL واقعاً چه چیزی را کنترل میکند، در راهنمای مهاجرت آمده است.در برابر یک ریزالورِ غیرِ خودتان تأییدش کنید، و بررسی کنید که نقطهٔ پایانی واقعاً روی هدفِ
CNAMEباشد:dig +short example.com A @1.1.1.1 dig +short example.com AAAA @1.1.1.1 dig +short www.example.com CNAME @8.8.8.8همچنین میتوانید سرور را زیرِ نامِ میزبانِ واقعیاش، پیش از آنکه DNS چیزی دربارهٔ آن بداند تست کنید، که ارزشِ انجامدادن دارد درحالیکه یک اشتباه هنوز رایگان است:
curl -sI https://example.com --resolve example.com:443:203.0.113.10یک
200یا یک تغییرمسیر یعنی میزبانِ مجازی و گواهی درستاند. یک404یا یک صفحهٔ فرودِ پیشفرض یعنی سرور روی IP پاسخ میدهد اما هنوز چیزی دربارهٔ نام به آن گفته نشده. - رکوردهایی را اضافه کنید که از سوءاستفاده از نامتان جلوگیری میکنند
یک دامنهٔ تازه بدون هیچ سیاستِ ایمیلی، یک دعوتِ باز است: هرکسی میتواند ایمیلی بفرستد و ادعا کند از طرفِ آن است، و وقتی آن ایمیل اسپم باشد، این نامِ شماست که روی فهرستهای اعتبار مینشیند، نه نامِ آنها. رفعِ این مشکل سه رکورد و پنج دقیقه میگیرد.
اگر دامنه قرار نیست ایمیل بفرستد — که وضعیتِ بیشترِ وبسایتهاست — این را صراحتاً اعلام کنید:
@ IN MX 0 . @ IN TXT "v=spf1 -all" _dmarc IN TXT "v=DMARC1; p=reject;"MXپوچ، اعلام میکند دامنه هیچ ایمیلی نمیپذیرد، رکوردِ SPF میگوید هیچ میزبانی مجاز نیست بهنامِ آن ارسال کند، و سیاستِ DMARC به گیرندهها میگوید هرچیزی را که خلافِ این ادعا کند رد کنند. اگر دامنه قرار است ایمیل بفرستد، هیچکدام از موارد بالا کاربرد ندارد و در عوض برپاییِ کامل را در راهنمای سرور ایمیل ما میخواهید.بعد محدود کنید چه کسی میتواند برای این نام گواهی صادر کند:
@ IN CAA 0 issue "letsencrypt.org" @ IN CAA 0 issuewild ";"این کار یک مرجعِ صدورِ گواهی را مجاز میکند و وایلدکارتها را کاملاً ممنوع میکند. هر CA سازگاری باید پیش از صدور این را بررسی کند، پس این یک محدودیتِ ارزان و مؤثر روی صدورِ نادرست است.
یک رکورد که اینجا تنظیم نشده: DNS معکوس.
PTRبرای IP شما توسطِ هرکس که بلوکِ آدرس را در اختیار دارد کنترل میشود — میزبانتان، نه ثبتکنندهتان — و مستقیم و معکوس باید با هم همخوانی داشته باشند تا ایمیل قابلاعتماد باشد. درحینِ بررسیِ آدرس، این هم لحظهٔ درستی است برای تأییدِ اینکه IP از قبل در یک بلاکلیست نیست. - بنویسید چطور میتوانید آن را پس بگیرید
همهٔ آنچه بالاتر آمد، یک دامنهٔ کارکننده را محافظت میکند. این قدم دربارهٔ روزی است که از کار میافتد، و همین حالا ده دقیقه میگیرد بهجای یک بعدازظهرِ بد بعداً.
یادداشت کنید، جایی آفلاین و بیرون از سرور: کدام ثبتکننده نام را نگه داشته، حساب از کدام صندوق ایمیل استفاده میکند، کدِ مجوزِ انتقال کجاست، تاریخِ دقیقِ انقضا، و خروجیِ زون کجا زندگی میکند. یادآوریهای تقویم را تنظیم کنید. بررسیِ انقضا از بخشِ تمدید را از ماشینی که این یکی نیست به سمتِ آن هدایت کنید.
بعد از پیش پاسخِ یک پرسش را تعیین کنید: اگر این نام فردا از ریزالوشدن بایستد، مردم چطور شما را پیدا میکنند؟ هیچ پاسخِ بداههٔ خوبی وجود ندارد. پاسخهای خوب همه باید از پیش وجود داشته باشند — یک دامنهٔ دوم نزدِ ثبتکنندهای دیگر زیرِ یک TLD دیگر، یک آدرسِ onion، یا بهسادگی IP سرور که جایی منتشر شده که مخاطبانتان از قبل به آن اعتماد دارند. یکی را انتخاب کنید و مطمئن شوید جایی غیر از همان سایتی که تازه خاموش شده نوشته شده.
در پایان، اگر سرورِ پشتِ این نام تازه است، پیش از آنکه چیزی که برایتان اهمیت دارد رویش بگذارید، آن دهدقیقهعبور را در راهنمای سختسازیِ Debian ما رویش انجام دهید. یک ثبتنامِ قفلشده جلوی یک سرورِ قفلنشده، جای عجیبی است که به آن برسید.
دامنه پس از همهٔ اینها هنوز چه چیزی را لو میدهد
حریم خصوصیِ ثبتنام یک کانال را میبندد. اینها همانهاییاند که باز میمانند، تقریباً به ترتیبِ اینکه چقدر واقعاً یک نام را به یک شخص وصل میکنند:
- شفافیت گواهی. هر گواهی TLS که عموماً مورد اعتماد است، در لاگهای عمومیِ فقط-افزایشی نوشته میشود که هرکسی میتواند جستوجویش کند. برای
staging.example.comگواهی صادر کنید و وجودِ آن میزبان را برای همیشه به دنیا اعلام کردهاید. یک گواهیِ وایلدکارد از برشمردنِ زیردامنهها جلوگیری میکند، اما ریشهٔ دامنه در هر صورت منتشر میشود. اگر وجودِ دامنه همان رازتان است، TLS آن را حفظ نخواهد کرد. - دادهٔ تاریخیِ ثبتنام. پایگاههای دادهٔ تجاری دهههاست استعلامها را آرشیو میکنند. اگر نام روزی با اطلاعات واقعی ثبت شده باشد — حتی برای یک ساعت، حتی پیش از آنکه آن را از کس دیگری بخرید — آن عکسِ لحظه وجود دارد و روشنکردنِ حریم خصوصی پس از آن، پسش نمیگیرد.
- زیرساخت مشترک. سرورهای نامِ یکسان، IP سرورِ یکسان، شناسهٔ آنالیتیکسِ یکسان، فاویکنِ متمایزِ یکسان در دو پروژه، آنها را بسیار مطمئنتر از هر رکورد ثبتی به هم پیوند میزند. اسکنرهای کلاینترنت این را پیوسته نمایه میکنند و جستوجویش بسیار ساده است.
- مکاتباتِ خودِ ثبتکننده. اعلانهای تمدید، فاکتورها، و تیکتهای پشتیبانی، همه در یک صندوق ایمیل فرود میآیند، همه نام دامنه را میبرند، و همه روی سرور ایمیلِ یک شخص دیگر مینشینند.
قاعدهای که از این نتیجه میشود ساده و تقریباً غیرقابلجبران است: یک پروژه، یک صندوق ایمیل، یک حساب ثبتکننده، یک سرور. جداسازی، روزی که شروع میکنید تقریباً رایگان است و بعدش دیگر نمیتوان آن را پسخرید.
ثبتکننده و میزبان را عمداً از هم جدا نگه دارید
بستهبندیِ دامنه همراه با هاستینگ راحت است و دو حوزهٔ شکست را به یکی تبدیل میکند. شکایتی که به میزبانتان میرسد نام را لمس نمیکند؛ شکایتی که به ثبتکنندهتان میرسد سرور را لمس نمیکند — مگر آنکه هر دو یک شرکت باشند، که در آن صورت یک ایمیل به همهچیز میرسد و یک رمز عبورِ لورفته همهچیز را از دست میدهد.
جداسازی همچنین جایی برای ایستادن در طول یک مشکل به شما میدهد. اگر میزبان از بین برود، نام همچنان ریزالو میشود و آن را ظرف چند دقیقه به سروری تازه هدایت میکنید، که دقیقاً همان تمرینِ راهنمای مهاجرت ماست. اگر ثبتکننده از بین برود، سرور همچنان روی IP خودش کار و سرویسدهی میکند تا شما تکلیف نام را روشن کنید. در حالت بستهبندیشده، هیچکدام از این بازیابیها در دسترس نیست.
این هم یکی از دلایلی است که ما دامنه نمیفروشیم. ما اساساً VPS ارائه میدهیم: حسابهای ما بدون KYC هستند، چیزی جز یک آدرس برای تحویلِ اطلاعات ورود نمیخواهند، و روی زنجیره پرداخت میشوند — و شکل درست این است که ثبتکنندهٔ شما شرکتی دیگر باشد، در کشوری دیگر، با صفِ شکایتی دیگر. راهنمای میزبانیِ خصوصی نشان میدهد این لایهها چطور کنار هم قرار میگیرند.
هزینهاش صادقانه است: دو حساب، دو تاریخ تمدید، دو دسته اطلاعات ورود، دو جا برای نگهداریِ کدهای بازیابی. این همان قیمت است، و قیمتِ خوبی است.
تمدید همان چیزی است که بیشتر دامنهها واقعاً بهخاطرش از دست میروند
نه توقیف. نه یک شکایت. یک تاریخ که گذشته. برای TLDهای عمومی، چرخهٔ حیات پس از انقضا ثابت و بیرحم است:
- از انقضا تا حدود روز 45 — یک دورهٔ ارفاقِ تمدید خودکار، که طولش بهصلاحدید ثبتکننده است. نام معمولاً زودتر از این بازه از کار میافتد، هرچند هنوز میتوانید با قیمت عادی تمدیدش کنید.
- سپس 30 روز دورهٔ بازخرید — قابلبازیابی، اما فقط با پرداختِ هزینهٔ بازخریدی که معمولاً چندین برابرِ قیمت دامنه است.
- سپس 5 روز در انتظار حذف — دیگر هیچ کاری نمیتوان کرد.
- سپس رها میشود — و اگر نام هرگونه ترافیک یا لینک ورودی داشته باشد، یک سرویس شکارِ دامنهٔ رهاشده بهاحتمال زیاد همان ثانیهای که در دسترس قرار میگیرد آن را ثبت میکند.
هرکسی که با رمزارز پرداخت میکند اینجا بهطرزی غیرعادی آسیبپذیر است، چون سازوکاری که بیسروصدا بقیه را نجات میدهد، یک کارتِ ثبتشده است. شما عمداً آن را کنار گذاشتید، پس عمداً جایگزینش کنید: برای چند سال یکجا ثبتنام کنید، اگر ثبتکننده از آن پشتیبانی میکند موجودیای نزدش نگه دارید، و تاریخ انقضا را در تقویمی با یادآوری در 90، 30 و 7 روز بگذارید. بعد آن را از بیرون تأیید کنید، نه با اعتماد به پنل:
#!/bin/sh
# warn when a domain is within 45 days of expiry
D=example.com
EXP=$(curl -s https://rdap.org/domain/$D | jq -r '.events[] | select(.eventAction=="expiration") | .eventDate')
LEFT=$(( ( $(date -d "$EXP" +%s) - $(date +%s) ) / 86400 ))
[ "$LEFT" -lt 45 ] && echo "$D expires in $LEFT days ($EXP)"آن را از cron روی ماشینی اجرا کنید که همان ماشینی نیست که دامنه به آن اشاره میکند. یک بررسیِ هفتگی هیچ هزینهای ندارد و رایجترین راهی را که مردم نامی را که برایشان اهمیت داشت از دست میدهند، از میان برمیدارد.
محدودیتهای صادقانه
خصوصی، ناشناس نیست، و این تفاوت، موشکافیِ بیمورد نیست. حریم خصوصیِ ثبتنام هزینهٔ شناساییِ گذرا را بهشدت بالا میبرد و هزینهٔ شناساییِ مصمم و بافاینانس را تقریباً اصلاً بالا نمیبرد. اگر آنچه منتشر میکنید خصمی با قدرتِ احضاریه و صبر را جذب کند، رکورد ثبت آن چیزی نیست که تعیین میکند ماجرا چطور تمام میشود — ردِ پرداخت، صندوق ایمیل، الگوی دسترسی، و خودِ محتوا، همه بیشتر اهمیت دارند.
روشنکردنِ این نکته هم ارزش دارد که یک دامنه یک اجاره درونِ فضاینامِ شخصی دیگر است، و هیچ انتخابِ ثبتکنندهای این را تغییر نمیدهد. تنها فضاهاینامی که هیچ ثبتکنندهای ندارند، همانهاییاند که هیچ ریجیستریای ندارند: یک آدرس onion در Tor از یک جفتکلید که خودتان تولیدش میکنید مشتق میشود، پس کسی نیست که حکمی به او ابلاغ شود و چیزی نیست که تعلیق شود. معامله این است که هیچکس نمیتواند آن را از حفظ تایپ کند و یک مرورگرِ معمولی آن را باز نخواهد کرد. اجرای هر دو، پاسخی رایج و معقول است — دامنه برای دسترسپذیری، آدرس onion برای تداوم — و راهنمای Tor و کاربردِ Tor ما آن سمتِ ماجرا را پوشش میدهند.
در سمتِ خودمان، تا بتوانید بسنجید: ما سرورهای بدون KYC اجرا میکنیم، ایمیلهای حذفِ محتوای بهسبک آمریکایی را نه بهخاطر مصونیت حقوقی بلکه بهعنوان یک سیاست عملیاتی اجرا نمیکنیم، به احکام دادگاه در حوزههای قضاییای که در آنها فعالیت میکنیم پاسخ میدهیم، و یک کفِ سختگیرانهٔ برخورد با سوءاستفاده را حفظ میکنیم. ما دامنه ثبت نمیکنیم و نمیتوانیم از دامنهای محافظت کنیم. هرکس به شما بگوید یک ثبتنام دستنیافتنی است، دارد چیزی میفروشد.
پرسشهای متداول
آیا حریم خصوصی WHOIS همان ثبت ناشناسِ دامنه است؟
نه، و فاصله زیاد است. یک سرویس حریم خصوصی چیزی را که استعلامِ عمومی برمیگرداند تغییر میدهد؛ ثبتکنندهتان همچنان اطلاعاتِ واقعیتان را نگه میدارد، ریجیستری هم اغلب یک نسخه دارد، و هر دو تحتِ فرایندِ قانونیِ معتبر آنها را ارائه خواهند داد. آنچه واقعاً شکست میدهد، اسکرِیپینگِ انبوه، اسپم، دلالهای داده، و اولین جستوجوی هر فردِ کنجکاوی است — که ارزشِ پولدادن دارد، تا وقتی روشن باشد که این یک پرده است نه یک دیوار. ترتیبِ یک دارندهٔ نیابتی، که در آن یک شخص ثالث دارندهٔ ثبتشده است و شما قراردادی برای کنترل دارید، فراتر میرود، به قیمتِ اینکه خودتان دارنده نباشید.
اگر اطلاعاتم از پیش بهطور پیشفرض سانسور شده، باز هم به حریم خصوصی نیاز دارم؟
برای TLDهای عمومی، اغلب کمتر از آنچه فکر میکنید. از سال 2018 صنعت بهطور پیشفرض اطلاعاتِ تماسِ دارندگانِ فردی را سانسور میکند، پس یک استعلامِ عمومی روی .comتان احتمالاً همین حالا هم تقریباً هیچچیز برنمیگرداند. سه چیز همچنان برای سرویسِ پولی استدلال میآورند: بسیاری از ریجیستریهای کدکشوری بهطور کامل منتشر میکنند و زیرِ پوششِ این رویه نیستند، ثبتنامهایی که شبیهِ سازمانها بهنظر میرسند اغلب سانسور نمیشوند، و یک سرویس حریم خصوصی همچنین چه کسی نامه را دریافت میکند را هم تغییر میدهد. اول رکوردِ عمومیِ واقعیِ نامتان را بررسی کنید — فقط یک دستور میگیرد و ممکن است بفهمید دارید چیزی را میخرید که از قبل دارید.
میتوانم فقط اطلاعاتِ نادرست در فرمِ ثبتنام بگذارم؟
نگذارید. دادهٔ ثبتِ عمداً نادرست، قرارداد ثبتنام را نقض میکند و زمینهای صریح برای ثبتکننده است تا دامنه را تعلیق یا لغو کند، معمولاً بدون فرایندِ چندانی. شما دقیقاً همان نتیجهای را ساختهاید که سعی داشتید از آن دوری کنید، و هیچ راهِ جبرانی نخواهید داشت. راهِ پشتیبانیشده برای بیرون نگهداشتنِ نامتان از رکوردِ عمومی، یک سرویس حریم خصوصی یا یک دارندهٔ نیابتی است — هر دو مشروعاند، هر دو بهطور گسترده ارائه میشوند، و هر دو به شکلی که یک آدرسِ ساختگی نمیتواند، در برابرِ بررسیِ دقیق دوام میآورند.
کدام TLD خصوصیترین است؟
هیچ برندهٔ واحدی وجود ندارد، چون پرسش سه بخش دارد. بپرسید چه کسی ریجیستری را اداره میکند و به کدام کشور پاسخگوست؛ آیا آن ریجیستری اطلاعاتِ دارنده را منتشر میکند یا سرویسهای حریم خصوصی را ممنوع میکند، همانطور که .us این کار را میکند؛ و آیا حضورِ محلی میخواهد، همانطور که .eu و .ca میخواهند. هرچیزی که نیازمندیِ پیوند داشته باشد کنار گذاشته میشود، چون هویتی واقعی و قابلتأیید را به نام تحمیل میکند. پس از آن، یک TLD عمومیِ رایج با ثبتکنندهای که با دقت انتخاب شده، معمولاً از یک کدکشوریِ عجیبوغریب بهتر است، که علاوهبراین ریسکِ سیاسیِ گرهخوردن به یک قلمرو را هم با خود دارد.
میتوانم بابتِ یک دامنه با Monero پرداخت کنم؟
برخی ثبتکنندهها رمزارز میپذیرند و تعدادِ کمتری بهطور مشخص Monero میپذیرند — میدانی بسیار نازکتر از سمتِ هاستینگ، پس انتظار داشته باشید روی چیزی مصالحه کنید. پرداخت را متناسب نگه دارید: این یکی از چهار وجهِ هویتی است، در کنارِ رکوردِ ثبت، صندوق ایمیل، و آدرسهایی که از آنها وارد میشوید. یک پرداختِ Monero به ثبتکنندهای که اعلانهای تمدید را به صندوق ورودیِ شخصیتان ایمیل میکند، چیزِ زیادی به دست نیاورده. اگر دارید سمتِ پرداخت را از صفر برپا میکنید، راهنمای بدونکارتِ ما و راهنمای گامبهگامِ Monero بدون تغییر بهکار میآیند.
آیا DNS باید نزدِ ثبتکنندهام زندگی کند یا روی VPS خودم؟
برای تقریباً همه، نزدِ ثبتکننده یا نزدِ یک ارائهدهندهٔ مدیریتشدهٔ جدا. خودمیزبانیِ DNSِ معتبر واقعاً رضایتبخش است و آرامآرام طلبکار: برای انجامِ درستش به دو سرور نام روی شبکههای متفاوت نیاز دارید، وگرنه یک قطعیِ تکیِ VPS نهفقط وبسایت، بلکه هر رکوردِ دامنه از جمله ایمیل را هم از کار میاندازد. تنها ترتیبی که در هر صورت ارزشِ اجتناب دارد این است که ثبتکننده، DNS، و هاستینگ همه در یک حساب باشند — که یعنی فقط یک اطلاعاتِ ورود و یک صفِ شکایت بینِ شما و هرچیزی که اجرا میکنید ایستاده.
اگر ثبتکننده دامنه را تعلیق کند، چه اتفاقی برای سایتم میافتد؟
سرورتان همچنان کار میکند، دستنخورده و همچنان از طریقِ IP در دسترس؛ نام فقط از ریزالوشدن میایستد. از نظر فنی ثبتکننده وضعیتِ clientHold را اعمال میکند و دامنه زون را ترک میکند، معمولاً ظرفِ چند دقیقه، و به حکمِ دادگاه نیاز ندارد — یک بندِ استفادهٔ مجاز و یک شکایت نزدِ بسیاری از ثبتکنندهها کافی است. دقیقاً به همین دلیل است که ثبتکننده باید شرکتی متفاوت از میزبانتان باشد، و به همین دلیل مسیرِ پشتیبان — یک دامنهٔ دوم، یک آدرسِ onion، یا یک IP منتشرشده — باید پیش از آنکه به آن نیاز پیدا کنید وجود داشته باشد، نه بعدش.
