عملیات عملی
لایههای بالای سرور شما: دامنه، CDN و ترانزیت
میزبان شما تنها یکی از سه لایه است؛ رجیستری بالای سر شما میتواند با یک حکم دادگاه نام شما را از فایل zone بیرون بکشد، پروکسیای که جلوی شماست هر شکایتی را به همراه آدرس مبدأتان به میزبان شما ارجاع میدهد، و هیچکدام در حوزهٔ قضایی میزبان شما قرار ندارند.
16 دقیقه مطالعه منتشرشده 28 اوت 2026 بررسیشده امروز
انتخاب اینکه سرور کجا قرار داشته باشد، تنها یکی از سه تصمیم است، و بهندرت همان تصمیمی است که نتیجه را رقم میزند. بالای سرور، نامی نشسته که شخص دیگری آن را اداره میکند. جلوی سرور نیز، در بیشتر سایتها، یک پروکسی معکوس نشسته که باز هم شخص دیگری آن را اداره میکند. هیچکدام از این دو تابع سیاست میزبان شما نیستند، هیچکدام در حوزهٔ قضایی میزبان شما قرار ندارند، و هر دو میتوانند از سوی دادگاهی که هیچ دسترسیای به میزبان شما ندارد، به اقدام مکلف شوند. این همان بخشی از پشته است که میزبانی offshore آن را پوشش نمیدهد، و ارزشش را دارد که دقیقاً بدانید کجا متوقف میشود.
سه لایه، سه مالک متفاوت
سایتی که اصلاً در دسترس باشد، دستکم به سه کسبوکار جداگانه وابسته است، و این سه بهطور مستقل از هم از کار میافتند.
نام. یک ثبتکنندهٔ دامنه آن را به شما فروخته؛ یک رجیستری پسوندی را که نام شما زیر آن قرار دارد اداره میکند. دو شرکت، معمولاً دو کشور، و دومی هرگز نامی از شما نشنیده است.
جلو. اگر چیزی از طرف شما پاسخ میدهد — یک CDN، یک پروکسی معکوس، یک لبهٔ anycast — همین چیز است که اتصال بازدیدکنندگان شما را پیش از آنکه به سرورتان برسد، پایان میدهد. بنابراین بهحکم ساختار خود، آدرس مبدأ شما را میداند، و شکایتها به دست او میرسد.
سیم و دستگاه. میزبان شما، اپراتورهای ترانزیت او، مرکز داده، و بازهٔ آدرسی که سرور شما درون آن قرار دارد. این همان لایهای است که مردم برای انتخابش خرید میکنند، و تنها لایه از این سه است که حوزه قضایی میزبانی واقعاً بر آن حکم میراند.
عادتی که ارزش ترککردن دارد، این است که اینها را یک خرید واحد بینگاریم. اینها سهتا هستند، و سپردن هر سه به یک دست — یا به یک نظام حقوقی — دقیقاً همان راهی است که یک حکم واحد همهچیز را یکجا از کار میاندازد.
قانون اروپا پیشتر این نقشه را کشیده، و نقشهٔ مفیدی هم هست. قانون خدمات دیجیتال (DSA) واسطهها را به سه گونه تقسیم میکند: انتقال صرف، ذخیرهسازی موقت و میزبانی. بند 29 مقدمه، رجیستریهای دامنهٔ سطح بالا، ثبتکنندههای دامنه، حلکنندههای DNS و مراجع صدور گواهی را در دستهٔ انتقال صرف قرار میدهد، و CDNها و پروکسیهای معکوس را در دستهٔ ذخیرهسازی موقت. هر سه گونه میتوانند دستور مادهٔ 9 برای اقدام علیه محتوای غیرقانونی و دستور مادهٔ 10 برای تحویل اطلاعات را دریافت کنند. معافبودن از مسئولیت به معنای معافبودن از دستورها نیست.
دامنه: ثبتکنندهٔ دامنه، و رجیستری بالای سر آن
ثبتکنندهٔ دامنهٔ شما همان فروشگاه است. رجیستری همان عمدهفروشی است که پسوند را اداره میکند، و همان لایهای است که تقریباً هیچکس پیش از خرید بررسیاش نمیکند.
چه چیزی یک ثبتکنندهٔ دامنه را به حرکت وامیدارد
از 5 آوریل 2024، ثبتکنندههای دامنهٔ معتبر، وظیفهای قراردادی برای اقدام در برابر چیزی دارند که ICANN آن را DNS Abuse مینامد: هرگاه شواهد قابلاقدامی در دست داشته باشند، باید بیدرنگ تدابیر کاهشی معقولی را که برای مختلکردن نام لازم است، به کار بگیرند. نیمهٔ سودمند این قاعده، تعریف آن است. DNS Abuse یعنی بدافزار، باتنت، فیشینگ، فارمینگ، و هرزنامهای که وسیلهٔ انتقال یکی از موارد دیگر باشد. محتوای وبسایت خارج از این دامنه است، و کپیرایت هم — بهروشنی — خارج از آن است.
این را آستانهای بدانید، نه دلگرمیای. این قاعده به شما میگوید شکایت باید چه شکلی داشته باشد تا ثبتکنندهٔ دامنهٔ شما مکلف به حرکت شود؛ و همچنین به شما میگوید هر چیزی که بیرون از آن فهرست باشد، باید در قالب دستوری از دادگاه یا یک مرجع برسد، که کندتر، قابلبررسیتر و قابلاعتراضتر است. دانستن هر دو نیمه، پیش از دریافت شکایتی که در راه است، ارزشمند است.
رجیستری چه میتواند بکند، و کجا میایستد
یک رجیستری تنها یک اهرم دارد، اما اهرمی مطلق: میتواند وضعیتی روی نام شما تنظیم کند که آن را از zone بیرون میبرد. از آن پس، نام برای هیچکس، در هیچکجا resolve نمیشود، فارغ از اینکه ثبتکنندهٔ دامنهٔ شما چه فکر میکند و سرور شما کجاست. هیچ چیز در لایهٔ میزبانی این را کاهش نمیدهد، چون هیچ چیز در لایهٔ میزبانی درگیر آن نیست.
این امر نظری نیست. در ژوئن 2026 یک دادگاه ناحیهای در تگزاس حکم توقیفی (writ of attachment) صادر کرد و به Verisign — که .com را اداره میکند — دستور داد motherless.com را به وضعیت registry hold ببرد. اپراتور آن سایت شرکتی لوکزامبورگی بود که حکم دادگاهی در تگزاس، ذیل قانون احراز سن آن ایالت، را نادیده گرفته بود؛ این دستور سپردن وثیقهای به مبلغ 9.14 میلیون دلار را شرط بازگرداندن نام تعیین کرد. آن سایت در تگزاس میزبانی نمیشد و آن شرکت هم در تگزاس نبود. نام در .com بود، و .com را شرکتی آمریکایی، تحت حوزهٔ قضایی ایالات متحده، اداره میکند. همین کافی بود.
درس کلیای که میتوان گرفت، دربارهٔ آن پرونده نیست. این است که پسوندی که انتخاب میکنید، خود یک انتخاب حوزهٔ قضایی است، درست مانند کشوری که سرورتان در آن قرار دارد، و بیشتر مردم آن را از سر عادت انتخاب میکنند. بپرسید چه کسی آن پسوند را اداره میکند، تحت کدام قانون، و آیا آن نظام حقوقی رویهٔ صادرکردن دستور به رجیستریها را دارد یا نه. سپس تصمیم بگیرید آیا میخواهید تنها نام شما آنجا باشد یا نه.
حریم خصوصی روی نام، دربارهٔ انتشار است، نه دانستن
پنهانسازی در WHOIS و RDAP، جمعآوری انبوه و جستوجوی تصادفی را متوقف میکند. اما ثبتکنندهٔ دامنهٔ شما را بیاطلاع نمیکند: اعتبارنامهاش او را مکلف میکند دادههای ثبت را نگه دارد، و او هم مانند هر کس دیگری، آن دادهها را تحت فرایند قانونی افشا میکند. یک سرویس حریم خصوصی جلوی رکورد، تنظیمی برای انتشار است، نه یک سپر — و ثبتکنندهای که هرگز چیزی از شما نپرسیده، نمیتواند چیزی را که ندارد افشا کند، که ویژگیای کاملاً متفاوت است و تنها ویژگیای که ارزش پرداخت هزینهاش را دارد.
دامنه تنها بخشی از این پشته است که یک حکم واحد میتواند آن را همهجا، همزمان، خاموش کند. سرورها جایگزین میشوند، آدرسها چرخانده میشوند، پروکسیها در عرض یک بعدازظهر تعویض میشوند. اما نامی که در رجیستری نگه داشته شده، بهسادگی resolve شدن را متوقف میکند، و هر پیوندی که هرکس تابهحال به شما داده، در همان ثانیه از کار میافتد.
پروکسی جلویی: چه چیزی را حذف میکند، چه چیزی را ارجاع میدهد
یک CDN یک واسط ذخیرهساز موقت است. سایت شما را بهطور پایدار ذخیره نمیکند، پس «فایل را بردار» معمولاً کاری نیست که از دستش برآید. کاری که از دستش برمیآید، این است که پروکسیکردن شما را متوقف کند — که برای سایتی که برای در دسترسماندن و خاموشنگهداشتن مبدأ خود به آن پروکسی وابسته است، در یک حرکت، هم یک حذف است و هم یک افشا.
رفتار جالبتر، همان رفتار روزمره است، و بزرگترین ارائهدهنده آن را بهروشنی منتشر کرده است. با دریافت یک گزارش سوءاستفاده دربارهٔ سایتی که تنها پروکسیاش میکند، شکایت شما را به اپراتور سایت و به ارائهدهندهٔ میزبانی ارجاع میدهد، و آدرس IP مبدأ محتوای موردبحث را در اختیار ارائهدهندهٔ میزبانی میگذارد. هر دوی اینها نقلقولی از سیاست سوءاستفادهٔ خود آن شرکت هستند، و درست خلاف چیزیاند که خریداران گمان میکنند بابتش پول میدهند.
پس پروکسی، حائلی میان شما و بخش رسیدگی به سوءاستفادهٔ میزبانتان نیست. یک پیک است. شکایت را نزد میزبان شما میبرد، و دقیقاً به میزبان شما میگوید کدام دستگاه را نگاه کند. اگر میزبان خود را بهخاطر شیوهٔ رسیدگیاش به شکایتها انتخاب کردهاید، مشکلی نیست — شکایت درست همانجایی میرسد که میخواستید برسد. اما اگر پروکسی را به این امید انتخاب کردهاید که شکایت همانجا متوقف شود، اینطور نمیشود.
مستندات همان ارائهدهنده، تعهدی هم بر عهدهٔ شما میگذارد: نگهداشتن آدرس تماس سوءاستفادهای که بهطور فعال مدیریت و پایش میشود، و پاسخدادن به هر اعلان گزارش سوءاستفاده در عرض بیستوچهار ساعت. پاسخندادن بهموقع میتواند به حذف یا مسدودشدن محتوای گزارششده، و به تعلیق یا خاتمهٔ حساب بینجامد. واسطهای که نمیتواند محتوای شما را حذف کند، با این حال برای خودش یک بند حذف و یک ساعت شمارش معکوس نوشته است.
یک استثنا اهمیت دارد. آنجا که همان شرکت خودش هم میزبانی میکند — فضای ذخیرهٔ شیءمحورش، بستر بدونسرورش، محصولات رسانه و صفحاتش — برای آن محتوا یک ارائهدهندهٔ میزبانی است، خودش هم به همین صراحت میگوید، و محتوا را طی فرایندی از نوع اخطار-و-حذف با امکان اخطار متقابل، به شکلی که قانون ایالات متحده مقرر میکند، حذف میکند. دو محصول از یک فروشنده، دو پاسخ کاملاً متفاوت. بدانید واقعاً از کدامیک استفاده میکنید.
یک پروکسی جلوی میزبانی offshore، آن آرایش را offshoreتر نمیکند. این پروکسی شرکتی دیگر را در کشوری دیگر، تابع نظامی حقوقی دیگر، به ماجرا اضافه میکند — شرکتی که بهصورت قراردادی متعهد شده هر چه دریافت میکند را به همراه آدرس مبدأ شما به میزبانتان ارجاع دهد.
آنچه یک CDN پنهان نمیکند، و مبدأها چگونه پیدا میشوند
بسیاری از افراد یک پروکسی جلوی سرورشان میگذارند، به یک دلیل: نگهداشتن آدرس مبدأ بیرون از اینترنت عمومی. ارزش دانستن دارد که این کار در عمل چقدر خوب جواب میدهد، و پاسخ صادقانه این است که تا وقتی یکی از پنج اشتباه معمول آن را خنثی نکند، جواب میدهد. هیچکدام از اینها عجیبوغریب نیستند؛ فروشندگان پروکسی خودشان آنها را مستند کردهاند.
رکوردهایی که پیش از جابهجایی منتشر کردهاید. DNS عمومی است و بایگانی میشود. تقریباً هر سایتی که پشت یک پروکسی رفته، آدرس پیش از جابهجاییاش، برای همیشه، در یک مجموعهدادهٔ تاریخی جایی نشسته است. راهنمای خود فروشنده هم همین است که پس از onboarding آدرس مبدأ را بچرخانید — اگر این کار را نکردهاید، جابهجایی فقط ظاهری بوده است.
رکوردهایی که بدون پروکسی رها کردهاید. یک زیردامنه که مستقیم به دستگاه اشاره کند کافی است: mail، ftp، cpanel، dev، staging، vpn، یا میزبان پایشی که یکبار راه انداختید و فراموش کردید. هر رکورد داخل zone را بازبینی کنید، نه فقط آنهایی را که یادتان هست ساختهاید.
ایمیلی که از دستگاه بیرون میرود. اگر مبدأ ایمیل ارسال کند، آدرس آن در هدرها سفر میکند. پیامی به آدرسی که وجود ندارد بفرستید، و bounce آن، آدرس را با خودش میآورد. ایمیل باید روی دستگاهی دیگر باشد، نه همان دستگاهی که میخواهید ساکت نگهش دارید.
شفافیت گواهیها (certificate transparency). هر گواهیای که بهطور عمومی مورد اعتماد است، به همراه نامهایی که پوشش میدهد، ثبت میشود. این لاگها آدرسی تحویل نمیدهند، اما فهرست کاملی از زیردامنههایی که باید امتحان کرد را تحویل میدهند، از جمله همانهایی که فکر میکردید خصوصیاند.
اسکن سراسری. کل فضای آدرسها پیوسته اسکن و بر پایهٔ آنچه پاسخ میدهد، نمایه میشود. صفحهای متمایز که از یک آدرس برهنه سرو شود، یک جستوجوی پایگاهداده است، نه یک تحقیق.
راهحلها بهخوبی شناختهشدهاند، و ارزشش را دارد که به ترتیب قدرت انجامشان دهید، نه به ترتیب راحتی.
- یک تونل فقط-خروجی. مبدأ اتصالی به سمت لبه باز میکند و روی هیچچیز گوش نمیدهد. پورتی برای پیداکردن وجود ندارد، پس آدرس حتی اگر لو برود هم دیگر جذاب نیست. این تنها گزینهٔ این فهرست است که به درستتنظیمکردن یک قاعده وابسته نیست.
- mTLS از سمت لبه. مبدأ فقط به کلاینتی پاسخ میدهد که گواهی پروکسی را ارائه کند. ممکن است آدرس لو برود؛ اما پاسخ نمیدهد. قوی است، و حتی وقتی آدرس عمومی میشود هم دوام میآورد.
- فایروال به بازههای منتشرشدهٔ پروکسی. بهتر از هیچی است و پیادهسازیاش آسان، اما این بازهها تغییر میکنند، و مقایسهٔ خود فروشنده هم این رویکرد را در برابر spoofing آسیبپذیر میداند. آن را کفی بدانید، نه یک راهحل.
- نظموترتیب روزمره. از وقتی پشت لبه قرار گرفتید آدرس مبدأ را بچرخانید، ایمیل را از روی دستگاه بردارید، و پس از هر تغییر، رکوردهای بدون پروکسی را بازبینی کنید. بیشتر افشاشدنها یکی از همین سه مورد است، نه یک حملهٔ زیرکانه.
یک پروکسی مبدأ را از غریبهای با یک مرورگر پنهان میکند. اما مبدأ را از خود پروکسی پنهان نمیکند — که بهحکم تعریف، آن را میداند، و که با دریافت یک شکایت، متعهد است به ارائهدهندهٔ میزبانی شما بگوید آن مبدأ چیست.
زیر دستگاه: ترانزیت، پیشوند آدرس، مرکز داده
زیر سرور شما، یک دسته طرف دیگر هم هست، و معمولاً همانهاییاند که یک میزبان کمترین تمایل را دارد دربارهٔ آنها صحبت کند.
اپراتورهای ترانزیت. میزبان شما اتصال را از کسی میخرد. آن اپراتورها بخش رسیدگی به سوءاستفاده، قرارداد و میزان ریسکپذیری خودشان را دارند، و اپراتوری که تصمیم بگیرد شما دردسرسازید، میتواند تصمیم را جای میزبانتان بگیرد. بپرسید چند اپراتور وجود دارد — یکیبودن، هم یک نقطهٔ واحد سیاستگذاری است و هم یک نقطهٔ واحد شکست — و پرسش تیزتر را هم بپرسید: آیا میزبان شما فهرستهای انسداد سمت اپراتور را، بیسروصدا، روی ترافیک شما میپذیرد؟
پیشوند آدرسی که بهاشتراک میگذارید. نظامهای اعتبارسنجی روی بازههای آدرس کار میکنند، نه روی مشتریها. شما همسایههای خود را به ارث میبرید، و بدون اینکه بدانید کیستند، به ارث میبرید. این هزینهٔ ملموس ارائهدهندهای است که خودش را پناهگاهی برای هر چیزی معرفی میکند: فهرستهای انسداد به آن بازه میرسند، و ایمیل شما و فراخوانهای APIتان درون همان بازهاند.
مرکز داده و سختافزار. کابینت اجارهای یعنی یک صاحبخانه با سیاست سوءاستفادهٔ خودش که بهطور نامرئی بالای سر میزبان شما نشسته، و هر لایهای بالای میزبان شما، طرف دیگری است که میتواند به دلایلی که هرگز نخواهید دید، شما را خاتمه دهد.
چون هدف این راهنما پاسخگو کردن هر لایه است، این لایه را هم با همان معیارها بیان میکنیم. دو اپراتور ترانزیت، متعادلشده با BGP، بیست گیگابیت ترکیبی، به سمت کیشیناو. فیلترینگ لایهٔ 3 و لایهٔ 4 بالادست هر پورت، برای همه، بدون هیچچیزی برای خرید. فهرستهای انسداد سمت اپراتور روی ترافیک مشتری پذیرفته نمیشوند: اگر چیزی باید مسدود شود، دادگاه آن را میگوید و ما به شما اطلاع میدهیم. سختافزار، در یک کشور، متعلق به همان شرکتی است که از او میخرید نه اجارهای — جزئیات در صفحهٔ شبکه و صفحهٔ مرکز داده آمده است.
و شکاف را هم بهروشنی بگوییم: ما دامنه نمیفروشیم، و پروکسیای که جلوی سرورتان میگذارید را هم اداره نمیکنیم. آن دو لایه از آن خودتاناند. هر آنچه در بالا دربارهٔ رجیستریها و دربارهٔ شکایتهای ارجاعشده گفته شد، دقیقاً همانطور که نوشته شده دربارهٔ شما هم صدق میکند، و هیچ حوزه قضایی میزبانی — از جمله حوزهٔ ما — کلمهای از آن را تغییر نمیدهد.
سپردن سه لایه به سه دست متفاوت
کل این راهنما به چند تصمیم ساده تقلیل مییابد، و هیچکدامشان هزینهای ندارد.
- سه لایه، سه تأمینکننده، سه خانوادهٔ حقوقی. نگهداشتن نام، لبه و سرور در دست یک شرکت، فقط یک حکم با نابودی کامل فاصله دارد. در سه دست، یک حکم علیه هرکدام، آن دو تای دیگر را کارآمد نگه میدارد و به شما زمان میدهد.
- از هر لایه همان سه پرسش را بپرسید. چه چیزی را میتوان مجبورتان کرد ارجاع دهید، چه چیزی را حذف کنید، و چه چیزی را افشا کنید؟ اینها مستقل از هم شکست میخورند، و تأمینکنندهای که هر سه را در یک جمله پاسخ میدهد، پرسش را نفهمیده است.
- طوری پیکربندی کنید که گویی پروکسی ارجاع میدهد، چون واقعاً میدهد. فرض کنید هر شکایتی، همراه با آدرس مبدأ شما، به میزبانتان میرسد. اگر این نتیجه مشکلساز است، راهحل در لایهٔ میزبانی یا در چیزی است که منتشر میکنید — نه در افزودن یک واسطهٔ دیگر.
- مبدأ را درست ببندید. تونل فقط-خروجی یا mTLS؛ ایمیل روی دستگاهی دیگر؛ چرخاندن آدرس پس از onboarding؛ بازبینی رکوردهای بدون پروکسی. چهار مورد، همه خستهکننده، و تقریباً همهٔ افشاشدنهای واقعی را میپوشانند.
- با نام همچون تنها نقطهٔ شکست خود رفتار کنید، و برایش برنامه داشته باشید. بدانید کدام رجیستری پسوند شما را اداره میکند و تحت کدام قانون. نامی دوم، با پسوندی دیگر، نزد ثبتکنندهای دیگر نگه دارید، و از پیش بدانید چگونه به مردم میگویید از آن استفاده کنند.
هیچکدام از اینها استدلالی علیه گذاشتن پروکسی جلوی سرورتان نیست، و هیچکدام هم استدلالی علیه میزبانی offshore نیست — ما منبع عجیبی برای هرکدام از این دو استدلال بودیم. آنچه این متن میگوید این است که این سه لایه سه خرید جداگانهاند با سه شیوهٔ شکست جداگانه، و آن لایهای که بیشتر مردم سختگیرانهترین بررسی را رویش انجام میدهند، همان لایهای نیست که بیشترین احتمال را دارد به کارشان پایان دهد. اگر میخواهید همان لایهای را که خودمان اداره میکنیم، در همین معیار بسنجید، ارقام سهماهه و صفحهٔ مجریان قانون جاییاند که میتوانید آن را بررسی کنید.
نوشتهشده توسط مهندسانی که این پلتفرم را اداره میکنند، و بازبینیشده در امروز. اگر چیزی اینجا اشتباه یا قدیمی است، آن را از پنل مشتری بگویید — نیمی از این موارد از همانجا آمدهاند.
