DNS و DHCP چیست؟ - آموزش کامل با مثال و مقایسه تفاوت‌ها | قسمت 16 آموزش Embedded Ethernet

DNS چیست و چه کاربردی دارد؟

در لایه‌های بالاتر از لایه چهارم؛ پروتکل‌های بسیار زیادی تعریف شده‌اند که تعدادی بر اساس UDP کار می‌کنند (یعنی روی UDP پیاده‌سازی شده‌اند). از میان این پروتکل‌ها؛ دوتاشون خیلی معروف هستند و کاربرد زیادی دارند. اولی به نام DNS (Domain Name Service) شناخته میشه و دومی به نام DHCP (Dynamic Host Control Protocol)

تا اینجا دیدیم که هنگام برقراری یک ارتباط، دونستن آدرس IP مقصد ضروری هست و فرض کردیم که این آدرس رو داریم. در ابتدای پیدایش شبکه‌ها؛ چون تعداد IPها در یک شبکه داخلی کم بود؛ این وظیفه ادمین‌ها بود که IPها رو به‌صورت دستی تنظیم کنند.

با گسترش یک شبکه و در نتیجه گسترش فضای آدرس‌دهی و علاوه بر اون استفاده عمومی از شبکه‌ها توسط افراد غیرمتخصص؛ داشتن پروتکلی که بشه IP یک هاست رو به طور خودکار تنظیم کرد یا به دست آورد؛ ضروری به نظر می‌رسید. علاوه بر این، کار با اعداد (در آدرس IP) معمولاً سخت‌تر و نامفهوم‌تر از به‌کاربردن اسامی هست. هدف این بود که به‌جای استفاده از اعداد برای آدرس‌دهی؛ از اسم یا متن استفاده بشود. واضحه که برای کاربر، استفاده از آدرس یا اسمی مثل google.com بسیار راحت‌تر و مفهوم‌تر هست نسبت به آدرسی به شکل14.151.6.17؛ حفظ‌کردنش هم ساده‌تره به‌علاوه تعداد آدرس‌ها که زیاد بشه؛ استفاده از روش آدرس‌دهی عددی برای کاربر، بسیار مشکل میشه.

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

 در دهه‌های قبل از اختراع کامپیوتر و شبکه، در موارد مشابه، مثلاً در سیستم تلفن ثابت، راهکارهایی مثل چاپ کتابچه شماره‌تلفن‌ها یا استفاده از مرجع شماره‌تلفن‌ها (مثل شماره 118 در ایران) کار رو راه مینداخت. اما در دنیای کامپیوترها، این وظیفه هم به عهده خود کامپیوتر و پروتکل ها گذاشته شده. یک سیستمی (کامپیوتر، دیتابیس، سرور؛ سیستم خلاصه!) به اسم DNS سرور وجود داره که شما بهش اسم سایت رو میدید؛ سیستم موردنظر، آدرس IP متعلق به اون اسم رو بهتون میده. به عنوان مثال وقتی در جستجوگر اینترنت (Browser) مینویسید google.com ابتدا یک پیغام برای سرور DNS در شبکه ارسال میشه، اگر آدرس IP این سایت در جداول این سرور باشه.

فرایند کار DNS به زبان ساده

بهتون میده وگرنه این پیغام رو به یه DNS سرور دیگه میده تا اون بهتون جواب بده. بهرحال در نهایت شما IP اون سایت رو با این سرویس به دست خواهید آورد. ما بیشتر از این DNS رو توضیح نمیدیم و شما برای اطلاعات بیشتر میتونید به سند RFC 882 و بروزرسانی های اون مراجعه کنید.

آشنایی با پروتکل DHCP

و اما DHCP. پروتکل دیگه‌ای که بر روی UDP کار میکنه؛ DHCP هست که وظیفه‌اش، دریافت و اعمال تنظیمات یک کلاینت هست. این تنظیمات میتونه شامل خیلی موارد باشه؛ از دریافت آدرس IP تا دریافت فایل بوت (boot) کلاینت، آدرس سرور DNS، مقدار subnet mask، آدرس gateway و…

ضرورت استفاده از DHCP

جهت برآورده‌کردن این منظور؛ در ابتدا از پروتکلی بنام BOOTP (BOOT Protocol) استفاده می‌شد؛ اما در نهایت BOOTP با DHCP جایگزین شد. یکی از اصلی‌ترین دلایل تعریف استانداردهای BOOTP و DHCP این موضوع بود که تخصیص آدرس IP به کلاینت‌ها، کاملاً خودکار (اما با اعمال نظر ادمین شبکه) باشه تا احیاناً تداخل آدرس (دو یا چند سیستم با یک آی‌پی) در شبکه نداشته باشیم.

تا اینجای کار، ما (برنامه‌نویس) آدرس IP رو داخل کد به‌صورت ثابت نوشته بودیم؛ اما واضحه که این روش، روش درستی برای این کار نیست. فرض کنید در یک شبکه صدها سیستم وجود داشته باشه؛ آیا می‌خواهیم به‌صورت دستی، تک‌تک اون ها رو آدرس‌دهی کنیم؟ به‌علاوه، از امکانات یک شبکه، ممکنه تعداد بسیار زیادی سیستم، بخواهند استفاده کنند و ما با محدودیت آدرس مواجه باشیم؛ لذا در DHCP، تمهید لازم برای اختصاص موقت یک آدرس IP به یک هاست هم دیده شده. اگر قرار بود هر سیستمی یک آی‌پی دائمی داشته باشه؛ به سرعت با کمبود آدرس مواجه می‌شدیم.

وقتی یک ارتباط قطع میشه یا مهلت اجاره آدرس تموم میشه؛ سرور DHCP، از اون آی‌پی برای دستگاه‌های دیگه استفاده خواهد کرد. در یک ارتباط اینترنتی نیز اگر دقت کرده باشید؛ احتمالاً متوجه این موضوع شده‌اید که گاهی در حین ارتباط، آدرس IP شما تغییر میکنه. به این مفهوم اصطلاحاً lease Time  یا زمان اجاره گفته میشه. قبل از سرآمدن مهلت اجاره؛ هاست میهمان (کلاینت) باید تقاضای تمدید مهلت رو بکنه که ممکنه پذیرفته نشه؛ یا اگر پذیرفته بشه؛ یک آدرس جدید به هاست اختصاص داده بشه.

یک سؤال؛ الان میدونیم که DHCP از UDP استفاده میکنه. خود UDP هم بر روی پروتکل IP بنا شده؛ این سیستم که هنوز IP نداره، پس چطوری کار میکنه؟! (سیستمی که هنوز آدرس IP نداره؛ از پروتکل IP استفاده میکنه تا آدرس IP خودشو به دست بیاره!)

آدرس عمومی 255.255.255.255 در DHCP

در پروتکل IP هم مثل استاندارد Ethernet ii ؛ یک آدرس خاص داریم که تمام قسمت‌های اون با بیت های ‘1’ پر شده؛ پس مقدار این IP خاص هست 255.255.255.255 به این آدرس اصطلاحاً آدرس عمومی در لایه سوم گفته میشه. در پیاده‌سازی پروتکل IP و برای برقراری یک ارتباط DHCP ؛ سخت‌افزار شما (میکروکنترلر) ؛ باید بتونه بسته‌هایی با آدرس عمومی رو دریافت و پردازش کنه تا بتونه با استفاده از این پروتکل، آدرس IP خودش رو از DHCP server بگیره.

مراحل چهارگانه DORA در DHCP

فرایند یک ارتباط مبتنی بر DHCP و اختصاص آدرس IP و تنظیمات دیگه، در چهار مرحله اجرا میشه:

• اکتشاف Discovery (از طرف كلاينت)
• پیشنهاد Offer (از طرف سرور)
• درخواست Request (از طرف كلاينت)
• پذیرش Acknowledge يا عدم‌پذیرش NACK (از طرف سرور)

به این چهار مرحله اصطلاحاً DORA گفته میشه که سرنام چهار مرحله فوق هست. این فرایند با یک سؤال از طرف کلاینت شروع میشه:

“کسی هست بتونه به من IP بده؟ ترجیح من آی‌پی فلان هست!” ترجیح یک آدرس خاص؛ مال وقتیه که دستگاه از قبل در شبکه بوده و مدت‌زمان اجاره‌اش (Lease Time) تموم شده.

در جواب DHCP server میگه که “فلان آی‌پی رو دارم، میخوای؟”  البته قبلش ممکنه سرور با یک عملیات خاص مثلاً ping يا ARP بررسی کنه که در شبکه دستگاهی با آی‌پی پیشنهادی وجود نداشته باشه! كلاينت هم ممكنه قبل از درخواست خودش، همين كار رو بكنه.

یک نکته مهم هم اینکه در یک شبکه ممکنه چند DHCP server داشته باشیم و حتی ممکنه این سرورها با هم، همپوشانی آدرس داشته باشند؛ یعنی بخشی از محدوده آدرس‌دهی آنها یکسان باشه. در نتیجه، کلاینت ممکنه بعد از درخواست اولیه، چندین پیشنهاد دریافت کنه!

در مرحله سوم؛ کلاینت باید از بین جواب‌های رسیده از سرورهای احتمالی، یکی رو انتخاب کنه و به اون سرور جواب بده که “من فلان آی‌پی رو برمی‌دارم” (مابقی سرورها بدون جواب بمونن، داستان رو فراموش می‌کنند)

در مرحله آخر (چهارم) هم سرور یک پیغام به کلاینت میفرسته که بگه درخواست پذيرفته يا رد شده؛ هر جای این مراحل، عملیات دچار خطا بشه؛ باید از ابتدا شروع بشه. در نهایت هم معمولاً سرور، آدرس اختصاص‌یافته رو در جدولی ذخیره میکنه تا از اختصاص مجدد اون به یه سیستم دیگه جلوگیری کنه. کلاینت هم میتونه برای استفاده‌های بعدی آدرس سرور رو نگه داره.

در ابتدای فرایند؛ كلاينت فقط مك آدرس خودش رو داره. خودش كه آدرس آی‌پی نداره، هيچ! مك آدرس و آی‌پی آدرس سرور رو هم نداره پس پیغام مرحله اول یک پیغام عمومی (هم آی‌پی آدرس در لایه سوم و هم مک آدرس در لایه دوم) هست، اما در مراحل بعدی که کلاینت و سرور؛ آی‌پی و مک آدرس‌های هم رو دارند، ميتونند پیغام‌ها رو به‌صورت خصوصی ارسال کنند. البته در حالت خاصي كه كلاينت از قبل، آدرسي رو اجاره كرده باشه؛ داستان فرق ميكنه و چون اون ها همديگه رو می‌شناسند، ميتونن از ابتدا پيغام خصوصي (unicast) بفرستن.

روش‌های اختصاص IP در DHCP

تا الان مقدار آدرس IP رو به طور مستقیم در کد تعریف کرده بودیم، به این وضعیت اصطلاحاً Static IP میگن. با استفاده از پروتکل DHCP قادریم به سه گونه یا روش، مقدار آدرس IP كلاينت رو تعیین کنیم. در اولین حالت بنام Automatic Allocation یک آدرس دایمی به کلاینت داده میشه. در حالت دوم، سرور یک آدرس IP موقتی (برای مدت‌زمان مشخص) به کلاینت اختصاص میده. در این حالت، کلاینت میتونه قبل از سر اومدن زمان اجاره؛ این آدرس رو رها (Release) کنه یا اینکه درخواست تمدید بکنه. این حالت رو Dynamic Allocation میگن. در حالت سوم به نام Manual Allocation؛ اختصاص آدرس به طور مستقیم توسط ادمین شبکه تعیین میشه.

این حالت رو با حالت استاتیک نباید اشتباه گرفت. در این حالت، درخواست آدرس IP همچنان توسط پروتکل DHCP انجام میشه؛ اما آدرس، به طور خودکار توسط سرور اختصاص داده نمیشه؛ بلکه ادمین خودش آدرس رو مشخص میکنه. در دو حالت دیگه هم، بازهٔ آدرسی (range) که توسط سرور میتونه اختصاص پیدا کنه؛ عموماً توسط ادمین مشخص میشه. مثلاً ادمین مشخص میکنه که آدرس اختصاص‌یافته از 192.168.1.5 تا 192.168.1.150 انتخاب و پیشنهاد بشه. به این بازه در زبان شبکه، مخزن ( pool ) آدرس گفته میشه. در شبکه جهانی اینترنت، از نوع دوم یعنی Dynamic Allocation یا اختصاص پویا استفاده میشه.

ازآنجایی‌که پروتکل DHCP در لایه چهارم کار میکنه؛ دو پورت، 68 برای کلاینت و 67 برای سرور، جهت استفاده در این پروتکل اختصاص‌یافته‌اند.

اطلاعات کامل‌تری از پیاده‌سازی؛ روش‌ها، مفاهیم و الزامات پروتکل DHCP رو میتونید در سند RFC 1541 و ارجاعات اون پیدا کنید.

جزئیات هدر DHCP

و اما پیاده‌سازی در میکروکنترلر. ابتدا بریم هدر DHCP رو بررسی کنیم.

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

OP : نوع عملیات (Operation) رو مشخص میکنه. در پیام‌های ارسالی از کلاینت، این بخش دارای مقدار 0x01 به معناي “درخواست” و در بازگشت داراي مقدار 0x02 به معناي “پاسخ” خواهد بود. همچنين در بخش Options نيز گزینه‌ای برای مشخص‌کردن مراحل چهارگانه‌ای که گفته شد؛ وجود دارد.

بخش‌های اصلی هدر DHCP

• HType : Hardware Type یا نوع سخت‌افزار؛ برای اترنت 10Mb عدد 0x01 است.

• HLen : Hardware Address Length یا طول آدرس سخت‌افزاری که برای مک آدرس عدد 0x06 است.

• Hops : تعداد hopها یا همان روترهاي بين كلاينت و سرور را مشخص می‌کند و یادگار پروتکل BOOTP است. اين بخش در DHCP همواره 0x00 است.

• XID : یا شماره شناسایی کلاینت؛ شامل یک عدد تصادفی 4 بایتی است که در مرحله Discovery  توسط کلاینت انتخاب و ارسال میشود. بعد از آن سرور و خود کلاینت از این عدد برای شناسایی همدیگه استفاده میکنند. یادمون هست که گفتیم، ممکنه چندین سرور پاسخ بدهند یا همزمان چندین کلاینت در حال درخواست باشند.

• SECs : در این بخش که از سمت کلاینت نوشته می‌شود، ثانیه‌هایی که از شروع بوت کلاینت گذشته است، قرار می‌گیرد. از این بخش استفاده‌ای نمی‌کنیم و عدد 0x0000 را قرار می‌دهیم.

• Flags : تنها یک بیت (پرارزش‌ترین بیت) از این بخش 16 بیتی، تعریف و استفاده شده است. مابقی بیت ها رزرو شده و همواره صفر هستند. پرارزشترین بیت، به نام بیت B یا همان Broadcast تنها توسط کلاینت، در دو پیام discovery یا Request میتواند ست بشود که به سرور این پیغام را میدهد که پاسخ پیام های کلاینت را به صورت Broadcast یا همگانی (مک آدرس و آیپی آدرس با بیت های ‘1’ ) ارسال کند و بدین معنی است که در حال حاضر کلاینت نمیتواند پیام های خصوصی (unicast) را پردازش کند. فلسفه وجود این بیت هم بنظر واضحه دیگه؛ کلاینت هنوز آدرس نداره،پس از سرور میخواد که فعلا پاسخ پیام ها رو به صورت Broadcast برگردونه. اما خود کلاینت از اونجاییکه مک آدرس و آیپی آدرس سرور رو، در مرحله Offer دریافت کرده؛ از اون ها استفاده میکنه و جواب خودش در مرحله سوم (Request) رو بصورت unicast ارسال میکنه. نتیجه اینکه بخش Flags از طرف کلاینت با مقدار 0x8000 و از طرف سرور با مقدار 0x0000 ارسال میشود.

• CIAddr : یا Client Ip Address شامل 4 بایت برای آدرس آیپی کلاینت. این آدرس در واقع آدرس فعلی(قبلی) کلاینت هست و نه آدرس آیپی جدید. در مرحله اول و دوم مقدار این بخش 0x00000000 خواهد بود (مگر اینکه کلاینت از قبل در شبکه بوده و آدرسی داشته است). در مرحله سوم و چهارم، در این بخش مقدار آیپی اختصاص یافته قرار میگیره. توجه داشته باشد چنانچه بیت B از بخش Flags در مرحله یک توسط کلاینت ست نشده باشه؛ سرور میتونه در مرحله دوم و در هدر پروتکل IP خودش از این آدرس استفاده کنه و پیغام رو unicast بفرسته. شاید گیج کننده باشه. بهرحال ممکنه کلاینت از قبل تو شبکه بوده و آدرس داشته و مدت زمان اجاره ش تموم شده و الان درخواست آیپی جدید یا تمدید آدرس فعلی رو داره؛ از طرفی پیام ها خودشون روی پروتکل IP سوار هستند؛ لذا سرور (اگر بیت B ست نشود) میتونه پیغام رو مستقیم به آیپی فعلی بفرسته. ما حالت ساده رو در نظر میگیرم و فرض میکنیم در ابتدای کار، بردمون میخواد آیپی بگیره؛ لذا این بخش رو با 0x00 پر میکنیم و بیت B رو هم ست میکنیم، خلاص! به جاش باید آدرس آيپي عمومی 255.255.255.255 رو هم تو برنامه ميكرومون پردازش کنیم.

• YIAddr : Your(client) Ip Address در مرحله دوم و چهارم، سرور در اين قسمت آدرس آی‌پی پيشنهادي رو مينويسه. در مرحله اول و سوم اين قسمت توسط كلاينت با 0x00 پر ميشه.

• SIAddr : Server Ip Address در مرحله اول اين قسمت با 0x00 پر ميشه؛ اما در مراحل دو تا چهار در اين قسمت، آدرس آی‌پی سرور نوشته ميشه (در مرحله سوم كلاينت ممكنه چند پيشنهاد دريافت كنه و آدرس سرور انتخاب شده رو اينجا مينويسه؛ توجه داشته باشيد كه هم‌زمان در لايه سوم هم آدرس آی‌پی گيرنده همين هست).

• GIAddr : aGent Ip Addr يا Gateway Ip Addr ؛ آدرس عامل (agnet ، نماينده) باقيمانده از پروتكل BOOTP‌ و در تمام مراحل با 0x00‌ پر ميشه. توجه داشته باشيد كه براي سازگاري با پروتكل BOOTP‌؛ هدر تغيير خاصي نكرده تا سرورهاي DHCP قادر به راه‌اندازی دستگاه‌هایی كه هنوز با BOOTP كار می‌کنند؛ باشند.

• CHAddr‌: Client Hardware Address در تمامي مراحل چهارگانه، در 6 بايت ابتدايي اين قسمت مك آدرس كلاينت نوشته ميشه؛ مابقي بایت‌ها (Octet) با 0x00 پر ميشن. توجه داشته باشيد كه اين يه پروتكل عموميه كه ممكنه در شبکه‌هایی با آدرس‌های سخت‌افزاری با تعداد بايت متفاوت استفاده بشه لذا 16 بايت براي اين قسمت در نظر گرفته شده.

• SName يا Server Host Name: يك رشته خاتمه‌یافته با null (رشته‌های متني به فرمت زبان C) در اينجا ممكنه اسم هاست سرور نوشته بشه؛ اما عموماً اين قسمت و قسمت بعدي (با هم 192 بايت) با 0x00 پر ميشن مگر اينكه در قسمت Options جا کم بیاد و نياز به بایت‌های اضافي باشه كه از اين فضا استفاده ميشه (در جاي خودش ميگيم)

• File : در اين قسمت آدرس و نام فايل بوت كلاينت قرار ميگيره (نام فايل و نه خود فايل!). نام فایل‌ها هم رشته‌های خاتمه‌یافته با null‌ هستند. ممكنه کلاینت‌هایی از اين پروتكل استفاده بكنند كه علاوه بر تقاضاي آدرس آی‌پی و تنظیمات ديگه، نياز به دانلود فايلي براي بوت هم داشته باشند. اين قسمت هم معمولاً با 0x00 پر ميشه.

بخش Options در DHCP

بخش Options شامل گزینه‌های اختیاری است که ممکن است در ارتباط DHCP مورد نیاز باشند. این قسمت به فرم TLV (Type, Length, Value) ساخته می‌شود:

• 1 بایت برای نوع گزینه (Type)
• 1 بایت برای طول داده‌ها (Length) — طول داده‌های گزینه به‌جز این دو بایت
• N بایت داده‌های گزینه (Value)

دسترسی بیشتر از ۳۱۲ بایت

اگر ‌۳۱۲ بایتِ بخش گزینه‌ها کافی نباشد، می‌توان ادامه داده‌ها را در بخش sname یا file ذخیره کرد:

1. نوشتن از ابتدای بخش گزینه‌ها شروع می‌شود.
2. پس از پر شدن، ادامه از ابتدای sname نوشته می‌شود.
3. سپس با پایان آن، از ابتدای file استفاده می‌شود.

در کاربردهای معمول (مثل زمانی که فقط به دریافت IP نیاز است)، این قابلیت استفاده نمی‌شود.

اما یک پیاده‌سازی کامل DHCP باید تمام این امکان‌ها را رعایت کند.

تعداد آپشن‌ها

• لیست طولانی آپشن‌ها برای این پروتکل تعریف شده که در RFC و منابع آنلاین موجود است.
• در صورت کم بودن داده‌ها نسبت به ۳۱۲ بایت، پایان بخش گزینه‌ها را با آپشن 0xFF پر می‌کنیم.

نکته درباره Padding و آپشن‌ها

• بین گزینه‌ها می‌توان از آپشن 0x00 برای padding استفاده کرد.
• 0xFF به معنی پایان لیست گزینه‌ها است، نه 0x00.
• معمولاً padding طوری انجام می‌شود که گزینه‌ها در مرزهای مضرب ۴ قرار بگیرند تا پردازش گیرنده راحت‌تر باشد.