من از DNS چه میدانم؟

امروز داشتم یک ویدیو آموزشی نگاه میکردم و یه بخشی مرتبط با DNS بود. همینطور که استاد عزیز از دانشجو ها سوال میپرسید، من سعی میکردم که تو ذهنم جواب بدم. بالافاصله متوجه شدم که از جوابام ۸۰ درصد یا ۷۰ درصد مطمعنم. مثلا ساده ترین نمونه اش:

• سوال: وقتی کاربر divar.ir رو وارد میکنه، اولین قدم مرورگر چیه؟
• ذهن من: هوممم ۹۹ درصد مطمعنم که اول etc/hosts چک میشه

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

مشکل اینجاس که اگه شما از بک گراند برنامه نویسی داری میای احتمالا خیلی چیزارو به صورت تجربی بلدی، مثلا به صورت abstract میدونی DNS چیه و چطور کار میکنه، قبلا باهاش سرو کله زدی، ولی هیچوقت ارزششو نداشته که بری بشینی و دقیق بشی ببینی این چطور داره کار میکنه، ولی خب این توهم رو داری که آره من بلدم. ( من در مورد HTTP هم همین بودم، که بحثش جداست )

خلاصه کلام اینه که امشب نشستم و سعی کردم در سریع ترین زمان ممکن چند تا knowledge gap هامو پر بکنم و اینجا داکیومنتش کنم، شاید به کار تو هم اومد.

وقتی dig میزنم دقیقا چه اتفاقی میفته؟!

من همیشه تصور میکردم که dig با getaddrinfo کارو در میاره. اگه تو هم همچین فکری میکردی، بهت تبریک میگم! تو یک نوب هستی. 🎉

چیشد که اینو فهمیدم؟ من یه سرور لوکال همینجور ران داشتم که که resolve میشه به یه دامین لوکال به اسم http://iis.lab. این فایل etc/hosts منه: بعد هرکار میکردم dig اینو گردن نمیگرفت و میگفت که این NXDOMAIN عه. از من اصرار، از dig انکار: حالا همینو curl میزدم عین آدم کار میکرد:

رفتم بالاسر گراک و اونم خیلی مصمم میگفت نه حاجی همه چی درسته و باید از etc/hosts بخونه:

بعد ده پونزده دقیقه دیباگ و استیصال، برگشتم و فهمیدم که گراکم نوبه:

داستان ازین قراره که curl داره از getaddrinfo استفاده میکنه و getaddrinfo هم همون اول etc/hosts رو چک میکنه و اگه از etc/hosts نتونه resolve کنه، میره سراغ ادامه مراحل.

ولی dig برمیداره مستقیم میره بالاسر recursive resolver ( اگه نمیدونی این چیه جلوتر توضیح میدم ) و etc/hosts رو اسکیپ میکنه.

وقتی dig رو ران میکنی، این اتفاقات به ترتیب میفتن:

۱. کامند dig میاد و etc/resolv.con رو چک میکنه تا آی پی recursive resolver رو بگیره.

۲. بعدش dig یدونه پکت DNS query میسازه، که بای دیفالت recursive هست.

۴. در ادامه dig میاد و DNS query رو میفرسته برای recursive resolver

۵. در نهایت recurisve resolver میره و جواب رو پیدا میکنه و میده به dig ، و dig اونو نشون شما میده.

حالا این داستان توی مرورگر به کلی فرق میکنه، مثلا دیدی که dig نتونست iis.lab رو resolve کنه در حالی که توی کروم اوکیه:

خب، بذار ببینیم اینجا چه اتفاقی داره میفته! اگه داری از کروم استفاده میکنی الان این آدرسو باز کن chrome://settings/security و اسکرول کن به بخش Use Secure DNS ، این آپشن باید به صورت دیفالت برات فعال باشه:

من توی فایرفاکس هم از about:preferences#privacy چک کردم و آپشن Secure DNS فعال بود:

این Secure DNS قضیه اش چیه؟ خلاصه داستان اینه که مرورگر های مدرن میان فرآیند DNS resolution رو از طریق HTTPS انجام میدن که بهش DNS over HTTPS هم میگن، این Secure DNS و DoH جفتشون یه کانسپت هستن.

این DoH هم رفتارش مشابه با getaddrinfo هست و احترام اون etc/hosts شمارو رو نگه میداره. مرورگر یه همچین پروسه ای داره:

Browser ↓ Browser DNS cache ↓ Hosts file (via the OS) ↓ If no match: ↓ DoH Provider

اگه DoH هم غیرفعال کنی، مرورگر میاد از host name resolution سیستم عاملت استفاده میکنه که توصیه نمیشه.

حل کننده بازگشتی :)))

این recursive resolver رو که بالاتر دیدیم حالا بذار برات بازش کنم. این یک سروریه که فرآیند DNS lookup رو هندل میکنه ( مثلا ۸.۸.۸.۸ که برای گوگله، یا مثلا میره از کلادفلر میبینه و غیره ).

فرآیندش اینطوریه:

۱. شما یه recursive query میفرستی به recursive resolver و میگی مثلا divar.ir رو برای من resolve کن

۲. اون سرور recursive resolver اول میاد از cache خودش چک میکنه اگه تارگت تو cache باشه و expire نشده باشه، همونو به شما برمیگردونه.

۳. اگه cache میس بده، سرور میاد از root servers شروع میکنه ( اینکه اسمش روشه معلومه چکار میکنه. کلا ۱۳ تا ازینا تو دنیا هست و recursive resolver رو میفرسته بالاسر TLD servers، همیشه hop اول از root شروع میشه. )، یعنی اول از یه root server میپرسه که این divar.ir رو به کجا resolve کنم.

۴. اینجا root server میاد recursive resolver رو ریفر میکنه TLD server عه دات آی آر.

۵. حالا از سرورِ دات آی آر میپرسه که به کجا resolve کنم، و ریفر میشه به authoritative nameserver عه divar.ir ( آتریتیو نیم سرورِ دیوار دات آی آر )

۶. بالاخره از authoriative name server میپرسه و جواب آخرو میگیره. ( A record و این داستانا )

الان اگه این کامند dig +trace رو بزنی میتونی ببینی چه دهنی از recursive resolver سرویس میشه:

اینجا قدم به قدم میتونی ببینی که recursive resolver چطور از root server شروع میکنه و در نهایت به authoritative nameserver میرسه.

بررسی Authoritative Nameserver

این پدر صاحب بچه اس که zone file دامین دستشه ( تو بخش بعدی میگم که zone file چیه ) و میتونه جواب نهایی رو بهمون بده. مثلا شما اگه بدونی authoritative nameserver تارگتت چیه میتونی مستقیم ازش سوال بپرسی و اون پروسه recursive resolver رو بیخیال بشی.

اون بالاتر nameserver دیوار رو دیدیم ( @ns.sotoon53.com )، حالا من مستقیم میتونم از nameserver بپرسم که A Record رو بهم بده:

اینم بگم که بعضی اوقات جوابی که از recursive resolver میگیری با جوابی که مستقیم از nameserver میگیری شاید فرق کنه.

اون recursive resolver شاید جوابو از cache بخونه و دیتا فرش نباشه. مثلا TTL دیوار ۸۶۴۰۰ ثانیه اس که میشه ۲۴ ساعت. این TTL رو خود صاحب دامین روی authorative server ست میکنه و recursive resolver هم ازش پیروی میکنه، یعنی مثلا تو کیس دیوار، recursive resolver میاد هر ۲۴ ساعت دوباره query میزنه و cache خودشو آپدیت میکنه.

در نتیجه اگه توی ریکان ما مستقیم بریم بالاسر nameserver میتونیم جواب دقیق تری رو بگیریم.

رکورد های DNS کجا ذخیره میشن؟

این توضیحش یکم سخته ولی سعیمو میکنم، فرض بر اینکه DNS یک درخت باشه، هر یه شاخه از اون درخت یک zone حساب میشه.

حالا مسئولیت هر آن چه داخل این zone هست ( MX records, CNAMES, NS records و این داستانا ) با owner اون zone هست.

مثلا divar.ir یک zone هست، و زیرشاخه های divar.ir ( مثلا www.divar.ir, api.divar.ir و غیره ) معمولا متعلق به یک zone هستن.

داخل هر zone، اون zone file که بالاتر گفتم وجود داره که لیستی از تمام DNS record های اون zone هست:

• همه ساب دامین ها
• آی پی ها ( همون A Record )
• رکورد های MX یا همون Mail Servers
• رکورد های TXT
• و کلا DNS records های مرتبط با اون دامین

در واقع nameservers با استفاده از همین zone files به ما جواب میدن، بعلاوه اینکه zone owner حتی میتونه یک zone جدید برای مثلا shop.divar.ir ایجاد کنه و کنترل اون zone رو بده به یک تیم دیگه یا یک شرکت دیگه.

حالا بخش باحال ماجرا اینجاس که اگه ما یه دامپ ازین zone file بگیریم، احتمال داره به یک asset هایی برسیم که بقیه بهشون نرسیدن.

به این حرکت میگن zone transfer یا AXRF ، مثلا من روی دیوار تستش کردم:

همینطور که انتظار میرفت به ارور خوردم، چون به دلایل واضح امنیتی، سرور طوری کانفیگ شده که این دیتارو دست منو شما نده.

بررسی Canonical Name (CNAME)

این CNAME رو که قطعا دیدی و میدونی چکارس ولی اینجا یه توضیح ریزی میدم که اگه مثل من نوبی اذیت نشی.

این CNAME یک alias ( نام مستعار؟ ) برای یک host دیگه اس. یعنی CNAME بجای اینکه بیاد یه آی پی ( A Record ) به ما برگردونه، میاد یه hostname دیگه میده دستمون.

مثلا من coder بودم میدونم که این قضیه تو cloud خیلی کاربرد داره. فرض مثال شما یه وبسایت درست کردی و میخوای رو Vercel دپلوی کنی و دامین سایت شما xyz.myapp.com هستش.

اینجا شما میری وبسایتتو روی ورسل دپلوی میکنی و بعد CNAME ست میکنی که xyz.myapp.com اشاره کنه به xyz.vercel.app

بعد هر موقع یکی xyz.myapp.com رو باز کنه، DNS میاد و با استفاده از CNAME میبرتش به xyz.vercel.app

اینجا کاربر داره همون xyz.myapp.com رو توی مرورگرش میبینه ولی اپ شما رو زیرساخت ورسل هست.

ساب دامین تیک اور که شنیدی همینه، ببین شما این CNAME رو ست کردی، درسته؟

xyz.myapp.com -> xyz.vercel.app ( ino shoma claim kardi )

فکر کن شیش ماه بعد میای و به هر دلیلی وبسایتتو از ورسل دیلیت میکنی، ولی اون CNAME رو یادت میره که از DNS پاک کنی.

الان این xyz.vercel.app بی صاحب شده:

xyz.myapp.com -> xyz.vercel.app ( in bi sahebe )

حالا منِ هکر میرم یه پروژه جدید رو ورسل میسازم و این xyz.vercel.app بی صاحب رو claim میکنم برای خودم، ورسل هم بهم اجازه میده چون هیچکس دیگه ای این دامین رو claim نکرده.

حالا کل ترافیک xyz.myapp.com میاد دست من. من اینو رو ورسل تست نکردم حالا همینطور مثال زدم فقط 🫠

جمع بندی

وقتی شما dig میزنی، این میاد اول آمار recursive resolver رو در میاره، بعد یه پکت DNS query میسازه میفرسته بهش.

اینجا recursive resolver یه full lookup انجام میده، ولی چطور؟ فرآیندش اینه که میره اول از یه root server میپرسه، root server ریفر میکنه به TLD server مثل دات کام یا دات آی آر و در نهایت ریفر میشه به authorative name servers.

بعد authorative name servers میره zone file رو نگاه میکنه و جواب نهایی رو میده دست recurisve resolver.

بعد recursive resolver جواب نهایی رو با توجه به TTL، کش میکنه، و جوابو میده دست dig و dig هم اونو تحویل شما میده.

توی پنتست و باگ بانتی شما میتونی NS records رو در بیاری و مستقیم به authoritative nameservers تا این پروسه cache و recursive query رو کلا بایپس کنی.

اون zone transfer هم که گفتم باید یادت باشه، اگه dig axfr کار بده شاید به asset های خوبی برسی، البته که بعیده کسی همچین چیزیو misconfigure کنه ولی همینکه بدونی چنین چیزی هست خوبه.

در نهایت هم که فهمیدیم CNAME چیه و ساب دامین تیک اور چطور کار میکنه.

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

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

مرسی که خوندی، مراقب خودت باش، بوس بوس