تحلیل DNS از شروع تا انجام

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

stub resolver هوشمند نیست

سیستم‌عامل شما DNS resolution واقعی را به تنهایی انجام نمی‌دهد. یک stub resolver اجرا می‌کند، یک کد نازک که فقط query شما را به هر DNS server تنظیم‌شده‌ای در /etc/resolv.conf بر روی Linux یا در تنظیمات network adapter شما بر روی Windows ارسال می‌کند. با این دستور خود را بررسی کنید:

cat /etc/resolv.conf

آن فایل معمولاً به router شما (مثل 192.168.1.1)، resolver ISP شما، یا یک resolver عمومی مثل 1.1.1.1 یا 8.8.8.8 اشاره می‌کند. stub resolver هیچ logic cache خاص خود ندارد فراتر از آنچه سیستم‌عامل یا یک daemon محلی مثل systemd-resolved فراهم می‌کند.

recursive resolver کار واقعی را انجام می‌دهد

هنگامی که query شما به یک recursive resolver می‌رسد، آن سرور وظیفه یافتن پاسخ را برعهده می‌گیرد، حتی اگر بخواهد از چندین سرور دیگر سؤال کند. اگر پاسخ قبلاً از یک جستجوی قبلی در cache باشد، فوری به شما برگردانده می‌شود. TTL را با این دستور بررسی کنید:

dig example.com

به ANSWER SECTION نگاه کنید — عددی که قبل از نوع record است (مثل 300 قبل از A)، TTL در ثانیه است. این مدت زمانی است که resolver‌ها می‌توانند record را در cache نگه دارند قبل از اینکه دوباره سؤال کنند.

اگر چیزی در cache نباشد، recursive resolver شروع به رفتن در سلسله‌مراتب DNS از root می‌کند.

root، TLD، و authoritative server‌ها

13 آدرس root server وجود دارد (a.root-servers.net تا m.root-servers.net)، هر کدام با بسیاری از ماشین‌های فیزیکی از طریق anycast routing پشتیبانی می‌شود. root server نمی‌داند example.com کجا قرار دارد، اما می‌داند کدام سرور‌ها .com را مدیریت می‌کنند، بنابراین یک referral برمی‌گرداند.

سپس resolver از یک .com TLD server سؤال می‌کند، که باز هم جواب نهایی را نمی‌داند اما می‌داند کدام nameserver‌ها برای example.com مختص هستند. می‌توانید این delegation را خودتان ببینید:

dig +trace example.com

آن دستور هر hop را نشان می‌دهد: root، سپس TLD، سپس authoritative nameserver‌های domain، و پایان با A یا AAAA record واقعی. این بهترین دستور برای فهم DNS به‌صورت بصری به‌جای نظری است.

authoritative nameserver آخرین ایستگاه است. این سروری است که صاحب domain واقعاً تنظیم کرده است، اغلب از طریق DNS panel یک registrar یا سرویسی مثل Route 53 یا Cloudflare DNS. این تنها سرور در کل زنجیره است که جواب واقعی، canonical دارد به‌جای کپی cached شده یا یک referral.

نوع record‌هایی که واقعاً با آنها مواجه می‌شوید

A record یک نام را به یک آدرس IPv4 نگاشت می‌کند، AAAA همینکار را برای IPv6 انجام می‌دهد. CNAME یک نام را به نام دیگری اشاره می‌کند نه یک IP، که این روش است که CDN‌هایی مثل Cloudflare یا Fastly ترافیک را بدون노شاندن IP‌های خام هدایت می‌کنند. MX record‌ها mail routing را مدیریت می‌کنند، و TXT record‌ها متن دلخواه را حمل می‌کنند، در حال حاضر بیشتر برای SPF، DKIM، و string‌های domain verification استفاده می‌شود. NS record‌ها به جهان می‌گویند کدام سرور‌ها برای یک zone مختص هستند، و این نوع record است که delegation را اساساً ممکن می‌کند.

caching واقعاً کجا اتفاق می‌افتد

Caching به‌صورت همزمان در چندین لایه اتفاق می‌افتد: خود مرورگر (Chrome دارای DNS cache خود است که در chrome://net-internals/#dns قابل‌مشاهده است)، OS resolver cache، local router، و recursive resolver upstream. این دلیل است که DNS change می‌تواند به‌نظر فوری بر روی یک دستگاه کار کند و چندین ساعت طول بکشد تا بر روی دستگاه دیگری ظاهر شود — شما از same cache استفاده نمی‌کنید.

هنگامی که TTL یک record را قبل از یک migration برنامه‌ریزی‌شده کاهش می‌دهید، شما بلافاصله چیزی را سریع‌تر نمی‌کنید. شما فقط پنجره‌ای را کاهش می‌دهید که در آن data کهنه می‌تواند ماند پس از اینکه change واقعاً اتفاق افتاده باشد. این کار را حداقل یک TTL cycle قبل انجام دهید، نه پنج دقیقه قبل از cutover.

چرا این برای troubleshooting اهمیت دارد

هنگامی که یک سایت دسترسی‌ناپذیر است، dig +trace دقیقاً می‌گوید کدام لایه شکسته است: یک مشکل root/TLD کاملاً متفاوت از authoritative server نادرست یا cache کهنه بر روی ماشین شما به‌نظر می‌رسد. مقایسه dig example.com با یک resolver شناخته‌شده‌ی درست، مثل dig example.com @1.1.1.1، مشخص می‌کند که آیا مشکل local resolver شما است یا setup DNS واقعی domain.

DNS از بیرون ساده به‌نظر می‌رسد چون معمولاً کمتر از 100ms حل می‌شود و کسی به آن فکر نمی‌کند. در زیرسطح، این یک distributed، cached، hierarchical query system است که تقریباً بدون تغییر ساختار از دهه 1980 اجرا می‌شود، که یک استدلال خوب برای این است که طراحی اصلی چقدر خوب پایدار ماند.

اگر می‌خواهید با این موضوع جلوتر بروید، Korra Studio دارای segment‌های مرتبط بر روی DEFENSE_GRID است که DNS security extensions، DNS tunneling به‌عنوان یک exfiltration technique، و ساخت resolver خود از صفر در Python را پوشش می‌دهد.