سایت اصلی بالا می‌آید، اما shop.example.com یا staging.example.com خطای DNS_PROBE_FINISHED_NXDOMAIN میدهد یا به صفحهٔ پیش‌فرض هاست می‌افتد. مشکل تقریباً همیشه یکی از سه چیز است: رکورد DNS ساخته نشده، رکورد ساخته شده ولی در Zone اشتباه، یا VirtualHost روی سرور برای آن نام تعریف نشده. این متن دقیقاً همان مسیری است که باید طی کنید، به‌علاوهٔ دو تله‌ای که کمتر کسی سر وقت به آن‌ها می‌رسد: گواهی SSL و زیردامنه‌های رهاشده.
زیردامنه در DNS چه چیزی است و کجا ثبت میشود
زیردامنه یک نام میزبان است، نه یک دامنهٔ مستقل. یعنی در Zone فایل دامنهٔ والد به‌صورت یک رکورد A یا CNAME نوشته میشود. اگر DNS را از پنل هاستینگ مدیریت می‌کنید، معمولاً فرم ساده‌ای می‌بینید؛ اگر از سرویس DNS جدا استفاده می‌کنید، باید خودتان رکورد را بنویسید:
shop 3600 IN A 185.xx.xx.xx
staging 3600 IN CNAME shop.example.com.
* 3600 IN A 185.xx.xx.xxنکتهٔ اول: در فایل Zone، نام میزبان را بدون دامنهٔ والد می‌نویسید. نوشتن shop.example.com. IN A ... در Zone دامنهٔ example.com باعث میشود رکوردی به نام shop.example.com.example.com ساخته شود. این خطا در پنل‌های گرافیکی رخ نمی‌دهد، ولی وقتی فایل Zone را دستی می‌نویسید یا از API استفاده می‌کنید، زیاد دیده میشود. علامت تشخیصش هم ساده است: dig shop.example.com جواب NXDOMAIN میدهد در حالی که رکورد در فایل هست.
نکتهٔ دوم: CNAME را روی ریشهٔ دامنه (@) نگذارید. استاندارد DNS این را ممنوع کرده و بعضی Resolverها بی‌سروصدا نادیده‌اش می‌گیرند. برای ریشه از A استفاده کنید.
رکورد wildcard: راحت، ولی با یک شرط
رکورد * هر نامی را که رکورد اختصاصی نداشته باشد به یک IP میفرستد. برای محیط‌های تست که مدام زیردامنهٔ تصادفی می‌سازید عالی است. ولی دو محدودیت دارد که در عمل آزار میدهد. اول اینکه wildcard فقط یک سطح را پوشش میدهد: *.example.com نام a.b.example.com را جواب نمی‌دهد. دوم اینکه اگر بعداً بخواهید زیردامنهای را عمداً از دسترس خارج کنید، نمی‌توانید؛ چون wildcard همه‌چیز را می‌گیرد. تنها راه، ساختن یک رکورد صریح با مقدار نامعتبر است که خودش یک بدهی فنی میشود.
گواهی SSL برای زیردامنه: اینجا اشتباه می‌کنند
گواهی SSL روی دامنهٔ اصلی هیچ کاری برای زیردامنه نمی‌کند. اگر برای example.com گواهی گرفته‌اید و shop.example.com را روی همان سرور بالا آورده‌اید، مرورگر برای زیردامنه خطای NET::ERR_CERT_COMMON_NAME_INVALID میدهد. این خطا در لاگ سرور دیده نمی‌شود چون درخواست هرگز به اپلیکیشن نمی‌رسد؛ دست‌کم TLS هندشیک شکسته است. خیلی‌ها ساعت‌ها لاگ Nginx را می‌خوانند و چیزی پیدا نمی‌کنند.
سه راه دارید:
| روش | پوشش | هزینهٔ واقعی |
|---|---|---|
| گواهی جدا برای هر زیردامنه | دقیق و کنترل‌شده | تمدید و اتوماسیون برای هر کدام جداگانه |
| گواهی wildcard | *.example.com یک سطح | نیاز به اعتبارسنجی DNS و انتشار رکورد TXT |
| گواهی چنددامنه‌ای (SAN) | فهرست مشخصی از نام‌ها | هر زیردامنهٔ جدید یعنی صدور مجدد گواهی |
اگر تعداد زیردامنهها ثابت و کم است، SAN را انتخاب می‌کنم؛ ساده‌تر و قابل پیش‌بینی‌تر است. اگر مدام زیردامنه می‌سازید و حذف می‌کنید، wildcard به‌صرفه است، به شرطی که اتوماسیون تمدیدش را درست ببندید. با Certbot این کار به یک دستور با پرچم --manual --preferred-challenges dns نیاز دارد و چون DNS را دستی تأیید می‌کنید، تمدید خودکار از کار می‌افتد. اینجا اشتباه می‌کنند: گواهی wildcard می‌گیرند، سه ماه بعد تمدید دستی یادشان می‌رود، و صبح دوشنبه همهٔ زیردامنهها همزمان خطای گواهی می‌دهند.
VirtualHost و ServerAlias
بعد از DNS و SSL، نوبت وبسرور است. در Nginx باید server_name را کامل بنویسید:
server {
listen 443 ssl;
server_name shop.example.com;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
root /var/www/shop;
}اگر زیردامنه را در server_name نگذارید، Nginx آن را به اولین VirtualHost روی همان پورت میفرستد. نتیجه: سایت اصلی را می‌بینید، ولی با آدرس زیردامنه. این دقیقاً همان حالتی است که کاربر فکر میکند DNS خراب است، در حالی که DNS سالم است و مشکل در سرور است. با curl -I https://shop.example.com و نگاه کردن به هدر Server و محتوای برگشتی سریع مشخص میشود.
زیردامنهٔ رهاشده چطور به نفوذ منجر میشود
این بخش را جدی بگیرید. زیردامنهای مثل old-panel.example.com را سال قبل به یک سرور ابری اشاره داده‌اید. آن سرور را خالی کرده‌اید، ولی رکورد DNS را پاک نکرده‌اید. حالا هر کسی می‌تواند همان IP را بگیرد و محتوایی روی old-panel.example.com بالا بیاورد که از نظر مرورگر کاملاً معتبر است. اگر روی دامنهٔ اصلی کوکی با دامنهٔ .example.com ست کرده باشید، آن کوکی به این زیردامنه هم می‌رود. این کلاس حمله اسم دارد: Subdomain Takeover.
علائمش را در لاگ نمی‌بینید. معمولاً از بیرون خبردار می‌شوید. برای پیدا کردنشان، فهرست زیردامنهها را از گواهی‌های شفافیت (Certificate Transparency) بیرون بکشید و هر کدام را با dig +short چک کنید. هر رکوردی که به IP یا سرویس خارجی اشاره میکند و دیگر مال شما نیست، باید همان روز حذف شود. اگر تعداد زیردامنهها زیاد است، این کار را به یک اسکریپت cron بسپارید و هفتگی اجرا کنید.
یک نکتهٔ جانبی: اگر از وردپرس مالتی‌سایت با زیردامنه استفاده می‌کنید، هر سایت جدید یک زیردامنهٔ تازه است و همین موضوع مدیریت DNS و SSL را پیچیده میکند. پیش از انتخاب این معماری، تحلیل هزینه و فایدهٔ وردپرس مالتی‌سایت را بخوانید؛ در بسیاری از موارد چند نصب جدا کم‌دردسرتر است.
چک‌لیست عملی راه‌اندازی
- رکورد
AیاCNAMEرا در Zone دامنهٔ والد بسازید و باdig shop.example.com +shortتأیید کنید. - گواهی SSL مناسب را بگیرید و تاریخ انقضا را در مانیتورینگ بگذارید، نه در تقویم ذهنی‌تان.
server_nameرا در وبسرور اضافه کنید و باcurl -Iپاسخ درست را ببینید.- اگر وردپرس است، آدرس سایت را در دیتابیس به‌روز کنید؛ در غیر این صورت ریدایرکت حلقه‌ای می‌گیرید.
- یک تسک زمان‌بندی‌شده برای بازبینی زیردامنه‌های بی‌استفاده بگذارید.
برای راه‌اندازی سریع‌تر، هاست لینوکس امکان تعریف زیردامنه و نصب گواهی را از همان پنل میدهد و لازم نیست فایل Zone را دستی بنویسید. اگر روی وردپرس کار می‌کنید و می‌خواهید محیط تست را جدا کنید، راه‌اندازی استیجینگ وردپرس مسیر امن‌تری نشان میدهد تا زیردامنهٔ تست به دامنهٔ اصلی وصل نشود. برای دستورهای ترمینالی هم مستندات سرورنت مرجع سریع‌تری است.
و اگر فقط می‌خواهید بدانید الان چند زیردامنه دارید و کدامشان مرده‌اند، ابزارهای رایگان نقطهٔ شروع خوبی است. کاری که این هفته باید بکنید یک چیز است: فهرست زیردامنهها را بیرون بکشید و هر رکوردی که به سرویس خارجی اشاره میکند و دیگر مال شما نیست را حذف کنید. بقیهٔ کارها بعداً هم میشود انجام داد؛ این یکی نه.
پرسش‌های پرتکرار
آیا زیردامنه به خرید دامنهٔ جدید نیاز دارد؟
نه. زیردامنه بخشی از دامنهٔ والد است و در همان Zone ثبت میشود. فقط باید رکورد DNS بسازید و روی سرور برایش VirtualHost تعریف کنید. هزینهٔ اضافهای بابت خود نام پرداخت نمیکنید، ولی اگر گواهی SSL جدا لازم باشد، آن هزینه جداست.
چرا زیردامنهام باز میشود ولی سایت اصلی را نشان میدهد؟
چون رکورد DNS درست است اما وبسرور نام میزبان را نمیشناسد و درخواست را به اولین VirtualHost روی آن پورت میفرستد. کافی است server_name را در Nginx یا ServerAlias را در Apache اضافه کنید و سرویس را ریاستارت کنید.
گواهی wildcard برای همهٔ زیردامنهها کار میکند؟
فقط یک سطح را پوشش میدهد. *.example.com نام shop.example.com را پوشش میدهد ولی a.shop.example.com را نه. برای سطح دوم به گواهی جداگانه یا رکورد wildcard جداگانه نیاز دارید.
چطور بفهمم زیردامنهای رهاشده و خطرناک است؟
با dig +short نامزیردامنه مقدار رکورد را ببینید. اگر به IP یا سرویس ابری اشاره میکند که دیگر در اختیار شما نیست، همان رکورد را حذف کنید. برای اطمینان، فهرست زیردامنهها را از Certificate Transparency بیرون بکشید و همه را یکبار مرور کنید.
دیدگاه‌ها ۰
هنوز دیدگاهی ثبت نشده؛ اولین نفر باشید!