آموزش اتصال آی پی به دی ان اس

آموزش اتصال آی پی به دی ان اس

حدود ۹ دقیقه مطالعه

برای اتصال یک آی‌پی به دامنه، باید در زون DNS آن دامنه یک رکورد A بسازید که نام دامنه را به آدرس IPv4 سرور اشاره دهد؛ اگر سرور آدرس IPv6 هم دارد، همین کار با رکورد AAAA انجام می‌شود. مهم‌ترین نکته این است که این رکورد باید دقیقاً در همان جایی ساخته شود که نیم‌سرورهای فعلی دامنه به آن اشاره می‌کنند؛ نه لزوماً در پنل شرکت ثبت‌کننده دامنه. اگر زون را خودتان روی ویندوز نگه می‌دارید، راه‌اندازی DNS Server در ویندوز سرور ساخت همین رکوردها را از ابتدا نشان می‌دهد.

قدم صفر: بدانید زون DNS دامنه کجا مدیریت می‌شود

بیشتر خطاهای این کار از همین‌جا شروع می‌شود: کاربر رکورد A را در یک پنل می‌سازد، اما دامنه در عمل از نیم‌سرور دیگری جواب می‌گیرد و تغییر هیچ اثری ندارد. پس اول ببینید دامنه روی چه نیم‌سروری نشسته است:

dig NS example.com +short

خروجی این دستور به شما می‌گوید زون واقعی کجاست. سه حالت رایج وجود دارد:

  • نیم‌سرور شرکت ثبت‌کننده دامنه: رکوردها را در بخش DNS Management یا Zone Editor همان پنل دامنه وارد کنید. در سی‌پنل دو نسخه ساده و پیشرفته از این ابزار وجود دارد و نسخه ساده در Simple DNS Zone Editor معرفی شده است.
  • نیم‌سرور شرکت میزبان: زون روی سرور هاست یا سرور مجازی شماست و باید از داخل سی‌پنل، دایرکت‌ادمین یا WHM ویرایش شود.
  • سرویس DNS مستقل: زون روی یک سرویس جداگانه مدیریت می‌شود. اگر می‌خواهید مدیریت DNS را از هاست جدا کنید تا با جابه‌جایی سرور، رکوردها دست‌نخورده بمانند، استفاده از یک سرویس هاست DNS منطقی‌ترین کار است.

تا وقتی نیم‌سرور دامنه را تغییر نداده‌اید، رکوردهایی که در پنل جدید می‌سازید صرفاً آماده‌سازی هستند و هنوز پاسخ‌گوی درخواست‌ها نیستند.

رکورد A و رکورد AAAA چه تفاوتی دارند

رکورد A یک نام را به آدرس IPv4 نگاشت می‌کند و رکورد AAAA همان نام را به آدرس IPv6؛ برای نمونه IPv4: 192.0.2.10 و IPv6: 2001:db8::10. این دو مکمل یکدیگرند، نه جایگزین هم. اگر سرور شما IPv6 دارد و رکورد AAAA اشتباه یا قدیمی باشد، کاربران دارای IPv6 به مقصد اشتباه می‌روند در حالی که بقیه کاربران مشکلی نمی‌بینند؛ این یکی از گیج‌کننده‌ترین حالت‌های عیب‌یابی است. اگر سرور IPv6 فعال ندارد، رکورد AAAA نسازید.

نکته دیگر اینکه دامنه اصلی (ریشه یا @) طبق استاندارد نمی‌تواند رکورد CNAME داشته باشد؛ برای ریشه باید از A یا AAAA استفاده کنید. بعضی سرویس‌دهنده‌ها امکاناتی با نام ALIAS یا ANAME ارائه می‌کنند که رفتار مشابهی می‌سازند، اما این‌ها استاندارد یکسانی ندارند و وجودشان به سرویس‌دهنده بستگی دارد.

ساخت رکورد A در سی‌پنل و دایرکت‌ادمین

ابتدا آی‌پی مقصد را از پنل مدیریت سرور بردارید. اگر روی سرور مجازی ابری یا سرور اختصاصی کار می‌کنید، این آی‌پی همان آدرسی است که برای اتصال SSH استفاده می‌کنید. عوض کردن خودِ آی‌پی اصلی سرور کار جداگانه‌ای است و در تغییر primary IP سرور سی پنل آمده است. بعد از برداشتن آی‌پی:

  • سی‌پنل: وارد بخش Zone Editor شوید (در نسخه‌های قدیمی‌تر با عنوان Simple DNS Zone یا Advanced DNS Zone Editor)، گزینه افزودن رکورد A را بزنید، در فیلد Name نام دامنه یا زیردامنه و در فیلد مقدار (بسته به نسخه با عنوان Address یا Record) آی‌پی سرور را وارد کنید.
  • دایرکت‌ادمین: از بخش DNS Management زون دامنه را باز کنید، نوع رکورد را روی A بگذارید و همان دو مقدار Name و Value را وارد کنید.
  • WHM: برای مدیر سرور، بخش Edit DNS Zone همین کار را برای همه دامنه‌های روی سرور انجام می‌دهد.

در فیلد Name، علامت @ یا خالی گذاشتن آن معمولاً به معنی خود دامنه است. اگر نام کامل را وارد می‌کنید، حواستان به نقطه انتهایی باشد؛ نوشتن example.com بدون نقطه در بعضی پنل‌ها به example.com.example.com تبدیل می‌شود. اگر پس از تغییر رکوردها نسخه www سایت بالا نمی‌آید، رفع مشکل باز نشدن سایت با www بعد از تغییر DNS را ببینید.

www، زیردامنه و رکورد Wildcard

رکورد A روی دامنه اصلی، به‌طور خودکار شامل www نمی‌شود. برای www یا باید یک رکورد A جداگانه با همان آی‌پی بسازید یا یک رکورد CNAME که به دامنه اصلی اشاره کند. برای زیردامنه‌ها هم همین منطق برقرار است: هر زیردامنه رکورد خودش را می‌خواهد.

اگر می‌خواهید همه زیردامنه‌های تعریف‌نشده به یک آی‌پی برسند، رکورد wildcard با نام * این کار را انجام می‌دهد. این کار برای پنل‌های چند مستأجری مفید است، اما باعث می‌شود هر نام تصادفی هم به سرور شما برسد؛ پس فقط وقتی از آن استفاده کنید که برنامه سمت سرور برای این حالت آماده باشد.

نیم‌سرور اختصاصی روی نام خود دامنه: Child Host و رکورد Glue

تا اینجا نام‌ها را به آی‌پی وصل کردیم. حالت خاصی هم وجود دارد که در آن خودِ نیم‌سرور باید به آی‌پی وصل شود: وقتی می‌خواهید نیم‌سرورهایتان را با نام همان دامنه بسازید (مثل ns1.example.com)، یک حلقه به وجود می‌آید؛ برای پیدا کردن آی‌پی ns1.example.com باید از زون example.com پرسید، اما آدرس آن زون هنوز معلوم نیست. راه‌حل این است که نام نیم‌سرور را در پنل ثبت‌کننده دامنه به آی‌پی معرفی کنید تا رجیستری یک رکورد glue بسازد و ریزالورها بدون ورود به آن حلقه، آی‌پی نیم‌سرور را پیدا کنند.

این قابلیت در پنل‌های مختلف نام‌های متفاوتی دارد: Child Host، Child Name Server، Register a Nameserver، Private Nameserver یا Host Records؛ همه یک کار می‌کنند. دقت کنید که این کار فقط وقتی لازم است که نام نیم‌سرور زیرمجموعه همان دامنه باشد. اگر قرار است از نیم‌سرورهای شرکت میزبان استفاده کنید که نام دامنه دیگری دارند، به چایلد هاست نیازی ندارید و فقط باید همان نام‌ها را به‌عنوان نیم‌سرور دامنه ثبت کنید؛ این سناریو در تهیه فضای میزبانی جدا از دامنه توضیح داده شده است.

ساخت Child Host در پنل دامنه

مراحل زیر برای پنل مدیریت دامنه (Resello) در ناحیه کاربری آنلاین سرور است؛ در سایر رجیسترارها هم ترتیب کار تقریباً همین است و فقط نام منوها فرق می‌کند:

  1. وارد ناحیه کاربری شوید و از قسمت Products گزینه Domains را انتخاب کنید.
  2. دامنه مورد نظر را در فهرست دامنه‌ها پیدا کرده و بازش کنید.
  3. بخش Child Hosts را باز کنید و روی Create کلیک کنید.
  4. در فیلد Hostname نام نیم‌سرور (برای مثال dns1 یا ns1) و در فیلد Address آی‌پی سرور خود را وارد کنید، سپس Save را بزنید.
  5. همین مرحله را برای نیم‌سرور دوم (dns2 یا ns2) هم تکرار کنید. بیشتر رجیستری‌ها برای یک دامنه حداقل دو نیم‌سرور می‌خواهند.

یک نکته درباره فیلد Hostname: بعضی پنل‌ها فقط پیشوند را می‌خواهند (ns1) و خودشان نام دامنه را به آن اضافه می‌کنند، و بعضی دیگر نام کامل را می‌خواهند (ns1.example.com). راهنمای کنار همان فیلد یا نمونه‌ای که پنل نشان می‌دهد تکلیف را روشن می‌کند؛ اگر اشتباه وارد شود، نامی مثل ns1.example.com.example.com ساخته می‌شود که هیچ‌وقت resolve نخواهد شد.

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

انتخاب Domains از منوی Products در پنل مدیریت دامنه

بخش Child Hosts و دکمه Create برای ساخت چایلد نیم‌سرور

وارد کردن Hostname و Address برای ثبت چایلد نیم‌سرور

کارهایی که بعد از ساخت چایلد هاست باقی می‌ماند

ثبت چایلد هاست به‌تنهایی کافی نیست؛ سه کار دیگر هم لازم است:

  • رکورد A داخل زون: در همان زون example.com باید رکوردهای A برای ns1 و ns2 با همان آی‌پی‌ها وجود داشته باشد تا اطلاعات رجیستری و زون با هم یکسان بماند.
  • ست کردن نیم‌سرور دامنه: در بخش نیم‌سرورهای دامنه، ns1.example.com و ns2.example.com را به‌عنوان نیم‌سرور انتخاب کنید. تا این کار انجام نشود، چایلد هاست فقط یک تعریف بلااستفاده در رجیستری است. این آخرین مرحله است، نه اولین مرحله: اگر نیم‌سرور دامنه را پیش از آنکه سرویس DNS روی آن آی‌پی واقعاً بالا باشد و زون کامل دامنه (رکوردهای A، MX و بقیه) را جواب بدهد عوض کنید، سایت و ایمیل دامنه به‌کلی از دسترس خارج می‌شوند و برگشتن از آن هم به‌اندازه TTL نیم‌سرورها طول می‌کشد. پیش از تعویض، با dig A example.com @ns1.example.com و dig MX example.com @ns1.example.com مطمئن شوید نیم‌سرور جدید پاسخ درست می‌دهد.
  • هماهنگ نگه‌داشتن آی‌پی: اگر بعداً آی‌پی سرور عوض شد، باید هم آی‌پی چایلد هاست در پنل دامنه و هم رکوردهای A داخل زون را تغییر دهید. تغییر فقط یکی از این دو، عیب‌یابی سختی درست می‌کند چون بخشی از ریزالورها آی‌پی قدیمی glue را در کش دارند.

برای بررسی نتیجه، این دستور باید آی‌پی نیم‌سرور را برگرداند و dig +trace هم باید نشان دهد که رجیستری همان آی‌پی را به‌عنوان glue تحویل می‌دهد:

dig +short A ns1.example.com
dig +trace example.com

دو نکته عملی دیگر: تغییرات glue در سطح رجیستری انجام می‌شود و ممکن است کمی دیرتر از رکوردهای معمولی زون در همه‌جا دیده شود؛ و بیشتر رجیستری‌ها اجازه حذف یک چایلد هاست را تا وقتی دامنه‌ای از آن به‌عنوان نیم‌سرور استفاده می‌کند نمی‌دهند، پس برای حذف، اول نیم‌سرور دامنه‌ها را عوض کنید و بعد سراغ حذف بروید.

TTL چیست و چه عددی مناسب است

TTL مدت‌زمانی است (برحسب ثانیه) که ریزالورها اجازه دارند پاسخ را در کش نگه دارند. مقدار پیش‌فرض بسته به پنل فرق می‌کند و مقادیری مثل ۳۶۰۰ (یک ساعت) یا ۱۴۴۰۰ (چهار ساعت) رایج‌اند. قاعده عملی ساده است: چند ساعت قبل از تغییر آی‌پی، TTL را روی عدد کوچکی مثل ۳۰۰ ثانیه بگذارید تا کش‌های قدیمی سریع منقضی شوند، تغییر را انجام دهید، و بعد از پایدار شدن اوضاع دوباره آن را بالا ببرید. اگر بعد از تغییر آی‌پی به فکر کم کردن TTL بیفتید، دیگر دیر است؛ کش‌ها با مقدار قبلی ذخیره شده‌اند.

در سناریوهای پیشرفته‌تر که می‌خواهید کاربران هر منطقه به نزدیک‌ترین سرور برسند، به‌جای یک رکورد A ثابت از پاسخ‌دهی مبتنی بر موقعیت جغرافیایی مثل جئو DNS استفاده می‌شود.

بررسی نتیجه با dig و nslookup

ساده‌ترین بررسی:

  • dig +short A example.com — آی‌پی نهایی را نشان می‌دهد.
  • dig +short AAAA example.com — همین کار برای IPv6.
  • dig A example.com @ns1.example.com — پرسش مستقیم از نیم‌سرور مقصد، بدون دخالت کش.
  • dig +trace example.com — کل مسیر از ریشه تا نیم‌سرور نهایی را نشان می‌دهد و برای پیدا کردن ناسازگاری بین رجیستری و زون عالی است.
  • در ویندوز: nslookup -type=A example.com 8.8.8.8

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

اگر تغییر اعمال نشد

پیش از هر کاری کش سیستم خودتان را خالی کنید:

  • ویندوز: ipconfig /flushdns
  • لینوکس با systemd-resolved: resolvectl flush-caches (در توزیع‌های قدیمی‌تر همین کار با systemd-resolve --flush-caches انجام می‌شد و امروز جای خود را به resolvectl داده است)
  • مک: sudo dscacheutil -flushcache و بلافاصله بعد از آن sudo killall -HUP mDNSResponder؛ در نسخه‌های امروزی macOS اجرای دستور اول به‌تنهایی کافی نیست.

مرورگرها هم کش DNS جدا دارند؛ تست با dig همیشه قابل اتکاتر از تازه‌سازی صفحه است. بررسی کنید رکورد A تکراری با آی‌پی قدیمی باقی نمانده باشد، چون در آن صورت ترافیک بین دو آی‌پی تقسیم می‌شود و رفتار سایت متناوب به نظر می‌رسد.

چند نکته تکمیلی

رکورد A فقط نام را به آی‌پی می‌رساند؛ اینکه سرور آن نام را بشناسد وظیفه وب‌سرور است، پس دامنه باید در Nginx یا Apache هم به‌عنوان ServerName یا server_name تعریف شده باشد. Reverse DNS یا رکورد PTR هم در زون دامنه شما نیست و باید توسط مالک آی‌پی، یعنی سرویس‌دهنده سرور، تنظیم شود؛ این مورد مخصوصاً برای سرورهای ایمیل اهمیت دارد. اگر جلوی سرور CDN یا پروکسی دارید، رکورد A باید به آدرس همان سرویس اشاره کند نه به آی‌پی واقعی سرور. در نهایت، صدور گواهی SSL معمولاً به اعتبارسنجی دامنه وابسته است، پس منطقی است اول رکورد A به‌درستی resolve شود و بعد سراغ گواهی بروید.

اگر در حال انتقال یک سایت فعال هستید و می‌خواهید بدون قطعی این کار انجام شود، تیم پشتیبانی فنی می‌تواند ترتیب کارها و مقادیر TTL را با شما هماهنگ کند.

آموزش‌های مرتبط