نام (NAME)

dhcpd.conf - پیکربندی سرویس‌دهنده dhcpd

توضیحات (DESCRIPTION)

فایل dhcpd.conf حاوی اطلاعات پیکربندی برای dhcpd، سرور DHCP کنسرسیوم سیستم‌های اینترنتی (ISC) است.

فایل dhcpd.conf یک فایل متنی اَسکی (ASCII) با قالب آزاد است. این فایل توسط تجزیه‌کنندهٔ بازگشتی-نزولی تعبیه‌شده در dhcpd پردازش می‌شود. این فایل ممکن است برای اهداف قالب‌بندی و خوانایی، حاوی فاصله‌گذاری‌ها (Tab) و خطوط خالی اضافی باشد. کلمات کلیدی در این فایل به بزرگی و کوچکی حروف حساس نیستند. توضیحات (کامنت‌ها) می‌توانند در هر کجای فایل (به‌جز درون نقل‌قول‌ها) قرار گیرند. توضیحات با نویسهٔ # آغاز می‌شوند و در انتهای همان خط پایان می‌یابند.

این فایل اساساً از فهرستی از دستورات تشکیل شده است. دستورات به دو دستهٔ کلی تقسیم می‌شوند — پارامترها و اعلانات.

دستورات پارامتر یا مشخص می‌کنند که کاری چگونه انجام شود (مثلاً یک اجاره برای چه مدتی ارائه شود)، یا اینکه کاری انجام شود یا خیر (مثلاً آیا dhcpd باید به کلاینت‌های ناشناخته آدرس اختصاص دهد)، یا اینکه چه پارامترهایی باید به کلاینت ارائه گردد (مثلاً استفاده از درگاه 220.177.244.7).

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

اعلانات مربوط به توپولوژی شبکه شامل اعلانات shared-network و subnet هستند. اگر قرار است به کلاینت‌های یک زیرشبکه به‌صورت پویا آدرس اختصاص داده شود، باید یک اعلان range درون اعلان subnet قرار گیرد. برای کلاینت‌هایی با آدرس‌های اختصاص‌یافته به‌صورت ایستا (استاتیک)، یا در راه‌اندازی‌هایی که فقط به کلاینت‌های شناخته‌شده سرویس‌دهی می‌شود، هر یک از این کلاینت‌ها باید دارای یک اعلان host باشند. اگر قرار است پارامترها به گروهی از اعلانات اعمال شوند که ارتباط آن‌ها صرفاً بر پایهٔ هر زیرشبکه نیست، می‌توان از اعلان group استفاده کرد.

برای هر زیرشبکه‌ای که به آن سرویس داده خواهد شد، و برای هر زیرشبکه‌ای که سرور DHCP به آن متصل است، باید یک اعلان subnet وجود داشته باشد که به dhcpd نحوهٔ تشخیص قرار داشتن یک آدرس در آن زیرشبکه را اعلام کند. وجود یک اعلان subnet برای هر زیرشبکه الزامی است، حتی اگر قرار نباشد هیچ آدرسی به‌صورت پویا در آن زیرشبکه تخصیص یابد.

برخی از راه‌اندازی‌ها دارای شبکه‌های فیزیکی هستند که بیش از یک زیرشبکهٔ IP روی آن‌ها کار می‌کند. برای مثال، اگر الزامی در سطح سازمان وجود داشته باشد که از ماسک‌های زیرشبکهٔ ۸ بیتی استفاده شود، اما بخشی با یک شبکهٔ فیزیکی اترنت مجزا آن‌قدر گسترش یابد که بیش از ۲۵۴ گره داشته باشد، ممکن است لازم باشد تا زمان افزودن یک شبکهٔ فیزیکی جدید، دو زیرشبکهٔ ۸ بیتی را روی همان اترنت اجرا کرد. در این حالت، اعلانات subnet برای این دو شبکه باید درون یک اعلان shared-network قرار گیرند.

توجه داشته باشید که حتی در صورت عدم وجود اعلان shared-network، یک اعلان خالی توسط سرور ایجاد می‌شود تا شامل subnet (و هرگونه پارامتر دارای حوزه که در subnet گنجانده شده) باشد. از نظر کاربردی، این بدان معناست که کلاینت‌های DHCP «بی‌وضعیت» (stateless) که به آدرس‌ها (و بنابراین به زیرشبکه‌ها) وابسته نیستند، همان پیکربندی را دریافت خواهند کرد که کلاینت‌های باوضعیت (stateful) دریافت می‌کنند.

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

هنگامی که قرار است یک کلاینت راه‌اندازی (بوت) شود، پارامترهای بوت آن با بررسی اعلان host آن کلاینت (در صورت وجود)، سپس بررسی اعلانات class منطبق با کلاینت، و در ادامه اعلانات pool، subnet و shared-network برای آدرس IP تخصیص‌یافته به کلاینت تعیین می‌شود. هر یک از این اعلانات درون یک حوزهٔ واژگانی (lexical scope) قرار می‌گیرند، و تمام اعلانات در حوزه‌های واژگانی با عمومیت بیشتر نیز برای اعلانات گزینه‌های کلاینت بررسی می‌شوند. حوزه‌ها هرگز دو بار در نظر گرفته نمی‌شوند، و اگر پارامترها در بیش از یک حوزه اعلان شده باشند، پارامتری که در خاص‌ترین حوزه اعلان شده است استفاده خواهد شد.

هنگامی که dhcpd تلاش می‌کند یک اعلان host برای یک کلاینت بیابد، ابتدا به دنبال یک اعلان host می‌گردد که دارای یک اعلان fixed-address باشد که آدرس IP معتبری را برای زیرشبکه یا شبکهٔ اشتراکی محل بوت کلاینت مشخص کرده باشد. اگر هیچ مدخلی از این نوع پیدا نکند، تلاش می‌کند مدخلی را بیابد که فاقد اعلان fixed-address باشد.

مثال‌ها (EXAMPLES)

یک فایل معمولی dhcpd.conf چیزی شبیه به این خواهد بود:

global parameters...
subnet 204.254.239.0 netmask 255.255.255.224 {
  subnet-specific parameters...
  range 204.254.239.10 204.254.239.30;
}
subnet 204.254.239.32 netmask 255.255.255.224 {
  subnet-specific parameters...
  range 204.254.239.42 204.254.239.62;
}
subnet 204.254.239.64 netmask 255.255.255.224 {
  subnet-specific parameters...
  range 204.254.239.74 204.254.239.94;
}
group {
  group-specific parameters...
  host zappo.test.isc.org {
    host-specific parameters...
  }
  host beppo.test.isc.org {
    host-specific parameters...
  }
  host harpo.test.isc.org {
    host-specific parameters...
  }
}
شکل ۱

توجه کنید که در ابتدای فایل، مکانی برای پارامترهای سراسری وجود دارد. این پارامترها ممکن است مواردی مانند نام دامنهٔ سازمان، نشانی‌های سرورهای نام (در صورتی که برای کل سازمان مشترک باشند) و مواردی از این دست باشند. بنابراین، برای مثال:

	option domain-name "isc.org";
	option domain-name-servers ns1.isc.org, ns2.isc.org;
شکل ۲

همان‌طور که در شکل ۲ مشاهده می‌کنید، می‌توانید نشانی‌های میزبان را در پارامترها با استفاده از نام‌های دامنهٔ آن‌ها به‌جای نشانی‌های عددی IP مشخص کنید. اگر یک نام میزبان مشخص به بیش از یک نشانی IP تفکیک شود (برای مثال، اگر آن میزبان دو رابط اترنت داشته باشد)، در صورت امکان، هر دو نشانی به کلاینت ارائه می‌شوند.

آشکارترین دلیل برای داشتن پارامترهای ویژهٔ زیرشبکه همان‌گونه که در شکل ۱ نشان داده شد، این است که هر زیرشبکه لزوماً روتر (مسیریاب) اختصاصی خود را دارد. بنابراین برای زیرشبکهٔ اول، برای مثال، باید خطی شبیه به این وجود داشته باشد:

option routers 204.254.239.1;

توجه داشته باشید که نشانی در اینجا به‌صورت عددی تعیین شده است. این کار الزامی نیست — اگر برای هر رابط روی روتر خود نام دامنهٔ متفاوتی دارید، کاملاً مجاز است که از نام دامنه برای آن رابط به‌جای نشانی عددی استفاده کنید. با این وجود، در بسیاری از موارد ممکن است تنها یک نام دامنه برای تمام نشانی‌های IP یک روتر وجود داشته باشد و در این صورت، استفاده از آن نام در اینجا مناسب نخواهد بود.

در شکل ۱ همچنین یک دستور group وجود دارد که پارامترهای مشترکی را برای مجموعه‌ای از سه میزبان — zappo، beppo و harpo — فراهم می‌کند. همان‌طور که می‌بینید، این میزبان‌ها همگی در دامنهٔ test.isc.org قرار دارند، بنابراین منطقی است که یک پارامتر ویژهٔ گروه، نام دامنهٔ ارائه‌شده به این میزبان‌ها را بازنویسی کند:

option domain-name "test.isc.org";

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

max-lease-time 120;
default-lease-time 120;

شاید متوجه شده باشید که در حالی که برخی از پارامترها با کلمهٔ کلیدی option شروع می‌شوند، برخی دیگر این‌گونه نیستند. پارامترهایی که با کلمهٔ کلیدی option شروع می‌شوند، متناظر با گزینه‌های واقعی DHCP هستند، در حالی که پارامترهایی که با کلمهٔ کلیدی option شروع نمی‌شوند، یا رفتار سرور DHCP را کنترل می‌کنند (مثلاً مدت زمان اجاره‌ای که dhcpd اعطا می‌کند)، یا پارامترهایی از کلاینت را مشخص می‌کنند که در پروتکل DHCP اختیاری نیستند (برای نمونه، server-name و filename).

در شکل ۱، هر میزبان دارای پارامترهای ویژهٔ میزبان (host-specific parameters) بود. این موارد می‌توانند شامل گزینه‌هایی مانند گزینهٔ hostname، نام فایلی برای بارگذاری (پارامتر filename) و نشانی سروری که فایل باید از آن بارگذاری شود (پارامتر next-server) باشند. به‌طور کلی، هر پارامتری می‌تواند در هر کجایی که پارامترها مجاز هستند درج شود، و بر اساس حوزه‌ای که در آن ظاهر شده است اعمال خواهد شد.

تصور کنید سایتی با تعداد زیادی پایانهٔ NCD X-Terminal دارید. این پایانه‌ها در مدل‌های مختلفی عرضه می‌شوند، و شما می‌خواهید فایل‌های بوت را برای هر مدل مشخص کنید. یک راه برای انجام این کار داشتن اعلانات host برای هر سرور و گروه‌بندی آن‌ها بر اساس مدل است:

group {
  filename "Xncd19r";
  next-server ncd-booter;
  host ncd1 { hardware ethernet 0:c0:c3:49:2b:57; }
  host ncd4 { hardware ethernet 0:c0:c3:80:fc:32; }
  host ncd8 { hardware ethernet 0:c0:c3:22:46:81; }
}
group {
  filename "Xncd19c";
  next-server ncd-booter;
  host ncd2 { hardware ethernet 0:c0:c3:88:2d:81; }
  host ncd3 { hardware ethernet 0:c0:c3:00:14:11; }
}
group {
  filename "XncdHMX";
  next-server ncd-booter;
  host ncd1 { hardware ethernet 0:c0:c3:11:90:23; }
  host ncd4 { hardware ethernet 0:c0:c3:91:a7:8; }
  host ncd8 { hardware ethernet 0:c0:c3:cc:a:8f; }
}

استخرهای آدرس (ADDRESS POOLS)

اعلانات pool و pool6 می‌توانند برای تعیین استخری از آدرس‌ها استفاده شوند که حتی روی همان بخش از شبکه یا زیرشبکه، رفتاری متفاوت با استخر دیگری از آدرس‌ها خواهد داشت. برای مثال، ممکن است بخواهید مجموعهٔ بزرگی از آدرس‌ها را برای اختصاص به کلاینت‌های DHCP ثبت‌شده در سرور DHCP خود فراهم کنید، در حالی که مجموعهٔ کوچک‌تری از آدرس‌ها را، احتمالاً با زمان‌های اجارهٔ کوتاه، برای کلاینت‌های ناشناخته در دسترس قرار دهید. اگر فایروال دارید، ممکن است بتوانید ترتیبی دهید که به آدرس‌های یک استخر اجازهٔ دسترسی به اینترنت داده شود، در حالی که آدرس‌های استخر دیگر دسترسی نداشته باشند، و بدین ترتیب کاربران را به ثبت کلاینت‌های DHCP خود تشویق کنید. برای انجام این کار، می‌توانید یک جفت اعلان pool تنظیم کنید:

subnet 10.0.0.0 netmask 255.255.255.0 {
  option routers 10.0.0.254;
  # Unknown clients get this pool.
  pool {
    option domain-name-servers bogus.example.com;
    max-lease-time 300;
    range 10.0.0.200 10.0.0.253;
    allow unknown-clients;
  }
  # Known clients get this pool.
  pool {
    option domain-name-servers ns1.example.com, ns2.example.com;
    max-lease-time 28800;
    range 10.0.0.5 10.0.0.199;
    deny unknown-clients;
  }
}

همچنین می‌توان زیرشبکه‌های کاملاً متفاوتی را برای کلاینت‌های شناخته‌شده و ناشناخته راه‌اندازی کرد — استخرهای آدرس در سطح شبکه‌های اشتراکی (shared networks) وجود دارند، بنابراین محدوده‌های آدرس درون اعلانات pool می‌توانند در زیرشبکه‌های مختلفی قرار داشته باشند.

همان‌طور که در مثال پیشین مشاهده می‌کنید، استخرها می‌توانند دارای فهرست‌های مجوزی باشند که کنترل می‌کند چه کلاینت‌هایی اجازهٔ دسترسی به استخر را دارند و چه کلاینت‌هایی ندارند. هر مدخل در فهرست مجوز یک استخر با کلمهٔ کلیدی allow یا deny معرفی می‌شود. اگر یک استخر دارای فهرست مجاز (permit list) باشد، تنها کلاینت‌هایی که با مدخل‌های خاص در این فهرست مطابقت داشته باشند، واجد شرایط دریافت آدرس از استخر خواهند بود. اگر یک استخر دارای فهرست منع (deny list) باشد، تنها کلاینت‌هایی که با هیچ‌یک از مدخل‌های فهرست منع مطابقت نداشته باشند واجد شرایط خواهند بود. اگر هر دو فهرست مجاز و منع برای یک استخر وجود داشته باشند، تنها به کلاینت‌هایی اجازهٔ دسترسی داده خواهد شد که با فهرست مجاز مطابقت داشته و با فهرست منع مطابقت نداشته باشند.

اعلان pool6 مشابه اعلان pool است. در حال حاضر این اعلان فقط درون یک اعلان subnet6 مجاز است و ممکن است مستقیماً در اعلان یک شبکهٔ اشتراکی گنجانده نشود. افزون بر دستور range6، این اعلان امکان گنجاندن دستور prefix6 را نیز فراهم می‌کند. شما می‌توانید دستورات range6 را برای هر دو مورد NA و TA و دستورات prefix6 را در یک دستور واحد pool6 بگنجانید.

تخصیص پویای آدرس (DYNAMIC ADDRESS ALLOCATION)

تخصیص آدرس در عمل تنها زمانی انجام می‌شود که کلاینت در وضعیت INIT باشد و یک پیام DHCPDISCOVER ارسال کرده باشد. اگر کلاینت تصور کند که یک اجارهٔ معتبر دارد و برای شروع یا تمدید آن اجاره یک پیام DHCPREQUEST بفرستد، سرور تنها سه گزینه پیش رو دارد — می‌تواند پیام DHCPREQUEST را نادیده بگیرد، یک DHCPNAK ارسال کند تا به کلاینت بگوید استفاده از آدرس را متوقف کند، یا یک DHCPACK بفرستد و به کلاینت اجازه دهد مدتی دیگر از آن آدرس استفاده نماید.

اگر سرور آدرسی را که کلاینت درخواست کرده بیابد و آن آدرس برای کلاینت در دسترس باشد، سرور یک DHCPACK ارسال خواهد کرد. اگر آدرس دیگر در دسترس نباشد، یا کلاینت مجاز به داشتن آن نباشد، سرور یک DHCPNAK ارسال می‌کند. اگر سرور اطلاعی از آن آدرس نداشته باشد، سکوت خواهد کرد، مگر اینکه آدرس برای بخشی از شبکه که کلاینت به آن متصل شده نادرست باشد و سرور برای آن بخش صاحب‌اختیار (authoritative) باشد؛ در این حالت سرور با وجود اینکه اطلاعی از آدرس ندارد، باز هم یک DHCPNAK ارسال خواهد نمود.

ممکن است یک اعلان host منطبق با شناسهٔ کلاینت وجود داشته باشد. اگر آن اعلان host شامل یک اعلان fixed-address باشد که آدرس IP معتبری را برای بخشی از شبکه که کلاینت به آن متصل است فهرست کرده باشد، سرور DHCP هرگز تخصیص پویای آدرس را انجام نخواهد داد. در این حالت، کلاینت ملزم است آدرس مشخص‌شده در اعلان host را دریافت کند. اگر کلاینت یک DHCPREQUEST برای آدرس دیگری ارسال کند، سرور با یک DHCPNAK پاسخ خواهد داد.

هنگامی که سرور DHCP یک آدرس جدید برای کلاینت تخصیص می‌دهد (به یاد داشته باشید این کار فقط زمانی رخ می‌دهد که کلاینت یک DHCPDISCOVER فرستاده باشد)، ابتدا بررسی می‌کند که آیا کلاینت از پیش یک اجارهٔ معتبر روی یک آدرس IP دارد یا خیر، یا اینکه آدرس IP قدیمی‌ای وجود دارد که کلاینت قبلاً داشته و هنوز به دیگری واگذار نشده است. در این حالت، سرور آن آدرس را انتخاب کرده و بررسی می‌کند که آیا کلاینت هنوز مجاز به استفاده از آن است یا خیر. اگر کلاینت دیگر مجاز به استفاده از آن نباشد، در صورتی که سرور تصور می‌کرد اجاره هنوز در حال استفاده است، آن را آزاد می‌کند — ارسال پیام DHCPDISCOVER از سوی کلاینت به سرور ثابت می‌کند که کلاینت دیگر از آن اجاره استفاده نمی‌کند.

اگر هیچ اجارهٔ موجودی یافت نشود، یا کلاینت از دریافت اجارهٔ موجود منع شده باشد، سرور در فهرست استخرهای آدرسِ بخشی از شبکه که کلاینت به آن متصل است، به دنبال اجاره‌ای می‌گردد که استفاده‌نشده باشد و کلاینت نیز مجاز به دریافت آن باشد. سرور تک‌تک اعلانات pool را به ترتیب بررسی می‌کند (تمام اعلانات range که خارج از اعلانات pool ظاهر می‌شوند در یک استخر منفرد بدون فهرست مجوز گروه‌بندی می‌شوند). اگر فهرست مجوز استخر اجازه دهد که آدرسی از آن استخر به کلاینت تخصیص یابد، استخر بررسی می‌شود تا مشخص گردد آیا آدرس در دسترسی وجود دارد یا خیر. در این صورت، آن آدرس به‌طور موقت به کلاینت اختصاص می‌یابد. در غیر این صورت، استخر بعدی آزموده می‌شود. اگر هیچ آدرسی پیدا نشود که بتوان آن را به کلاینت اختصاص داد، هیچ پاسخی برای کلاینت ارسال نمی‌شود.

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

سرور DHCP فهرست آدرس‌های IP موجود را از یک جدول هش (hash table) تولید می‌کند. این بدان معناست که آدرس‌ها با ترتیب مشخصی مرتب نشده‌اند، و بنابراین پیش‌بینی ترتیبی که سرور DHCP طبق آن آدرس‌های IP را تخصیص می‌دهد ممکن نیست. کاربران نسخه‌های قبلی سرور ISC DHCP ممکن است به این عادت کرده باشند که سرور DHCP آدرس‌های IP را به ترتیب صعودی تخصیص دهد، اما این امر دیگر ممکن نیست و هیچ راهی برای پیکربندی این رفتار در نسخهٔ ۳ سرور ISC DHCP وجود ندارد.

جلوگیری از تداخل آدرس IP (IP ADDRESS CONFLICT PREVENTION)

سرور DHCP قبل از تخصیص آدرس‌های IP به کلاینت‌ها، بررسی می‌کند که آیا آن‌ها در حال استفاده هستند یا خیر. این کار را با ارسال یک پیام درخواست پژواک ICMP (یا همان ICMP Echo request) به آدرس IP در حال تخصیص انجام می‌دهد. اگر در مدت یک ثانیه هیچ پاسخ پژواک ICMP دریافت نشود، فرض بر این گذاشته می‌شود که آدرس آزاد است. این کار تنها برای اجاره‌هایی انجام می‌شود که در دستورات range تعیین شده‌اند، و تنها زمانی که سرور DHCP تصور کند اجاره آزاد است — یعنی سرور DHCP یا همتای پشتیبان گرم (failover peer) آن، اجاره را در حال استفاده فهرست نکرده باشند.

اگر پاسخی به درخواست پژواک ICMP دریافت شود، سرور DHCP فرض می‌کند که خطای پیکربندی وجود دارد — آدرس IP توسط میزبانی در شبکه استفاده می‌شود که کلاینت DHCP نیست. سرور این آدرس را به‌عنوان متروکه (abandoned) علامت‌گذاری می‌کند و آن را به کلاینت‌ها اختصاص نخواهد داد. این اجاره حداقل به مدت چند ثانیه که در abandon-lease-time تعیین شده است در وضعیت متروکه باقی خواهد ماند.

اگر یک کلاینت DHCP سعی در دریافت یک آدرس IP داشته باشد اما هیچ آدرسی در دسترس نباشد، ولی آدرس‌های IP متروکه وجود داشته باشند، سرور DHCP تلاش می‌کند تا یک آدرس IP متروکه را بازیابی (reclaim) کند. این کار را با علامت‌گذاری یک آدرس IP به‌عنوان آزاد انجام داده و سپس همان بررسی درخواست پژواک ICMP را که پیش‌تر شرح داده شد اجرا می‌کند. اگر پاسخی به درخواست پژواک ICMP داده نشود، آدرس به کلاینت اختصاص می‌یابد.

سرور DHCP در صورتی که اولین آدرس IP که تلاش می‌کند بازیابی کند آزاد نباشد، در میان تمام آدرس‌های IP متروکه چرخش نمی‌کند. در عوض، زمانی که DHCPDISCOVER بعدی از سوی کلاینت دریافت شود، تخصیص جدیدی را با همان روش شرح داده شده در اینجا امتحان می‌کند، و معمولاً یک آدرس IP جدید را خواهد آزمود.

توازن و افزونگی دوندگی DHCP (DHCP FAILOVER)

این نسخه از سرور ISC DHCP از پروتکل پشتیبان گرم DHCP (failover) همان‌طور که در پیش‌نویس draft-ietf-dhc-failover-12.txt مستند شده است، پشتیبانی می‌کند. این یک سند نهایی پروتکل نیست، و ما آزمایش‌های هم‌کنش‌پذیری را با پیاده‌سازی‌های این پروتکل توسط سایر ارائه‌دهندگان انجام نداده‌ایم، بنابراین نباید فرض کنید که این پیاده‌سازی با استاندارد مطابقت دارد. اگر مایل به استفاده از پروتکل پشتیبان گرم هستید، اطمینان حاصل کنید که هر دو همتای پشتیبان گرم از نسخهٔ یکسانی از سرور ISC DHCP استفاده می‌کنند.

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

در زمان یک خرابی طولانی‌مدت، این امکان وجود دارد که به سرور باقی‌مانده اطلاع دهیم که سرور دیگر از کار افتاده است (down)، که در این صورت سرور باقی‌مانده (به مرور زمان) تمام آدرس‌هایی را که سرور دیگر برای تخصیص در اختیار داشت پس گرفته و شروع به استفادهٔ مجدد از آن‌ها می‌کند. به این کار قرار دادن سرور در وضعیت PARTNER-DOWN می‌گویند.

شما می‌توانید سرور را یا با استفاده از دستور omshell (1) یا با متوقف کردن سرور، ویرایش آخرین اعلان وضعیت پشتیبان گرم در فایل اجاره‌ها (leases file)، و راه‌اندازی مجدد سرور، در وضعیت PARTNER-DOWN قرار دهید. اگر از این روش اخیر استفاده می‌کنید، خط "my state" را به شکل زیر تغییر دهید:

failover peer name state {
my state partner-down;.
peer state state at date;
}

تنها تغییر دادن "my state" همان‌گونه که در بالا نشان داده شد، الزامی است.

هنگامی که سرور دیگر مجدداً بالا بیاید و برخط شود، باید به‌طور خودکار آفلاین بودن خود را تشخیص داده و یک به‌روزرسانی کامل از سروری که در وضعیت PARTNER-DOWN اجرا می‌شد درخواست کند، و سپس هر دو سرور مجدداً پردازش را در کنار هم از سر خواهند گرفت.

ممکن است وضعیت خطرناکی رخ دهد: اگر یک سرور را در وضعیت PARTNER-DOWN قرار دهید، و سپس *آن* سرور نیز از کار بیفتد، و سرور دیگر مجدداً بالا بیاید، سرور دیگر مطلع نخواهد بود که سرور اول در وضعیت PARTNER-DOWN قرار داشته است، و ممکن است آدرس‌هایی را که قبلاً توسط سرور دیگر صادر شده بودند به کلاینت‌های مختلفی اختصاص دهد، که در نتیجه منجر به تداخل آدرس‌های IP خواهد شد. بنابراین، پیش از قرار دادن یک سرور در وضعیت PARTNER-DOWN، کاملاً مطمئن شوید که سرور دیگر به‌طور خودکار راه‌اندازی مجدد نخواهد شد.

پروتکل پشتیبان گرم نقش سرور اصلی (primary) و نقش سرور ثانویه (secondary) را تعریف می‌کند. تفاوت‌هایی در نحوهٔ رفتار سرورهای اصلی و ثانویه وجود دارد، اما بیشتر تفاوت‌ها صرفاً مربوط به ایجاد روشی است تا هر همتا بتواند به شیوهٔ متفاوتی نسبت به دیگری عمل کند. بنابراین یک سرور باید به‌عنوان اصلی و دیگری به‌عنوان ثانویه پیکربندی شود، و چندان تفاوتی نمی‌کند که کدام‌یک کدام باشد.

راه‌اندازی پشتیبان گرم (FAILOVER STARTUP)

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

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

هنگامی که ارتباط برقرار شد، از همتا یک نسخهٔ کامل از پایگاه دادهٔ اجاره‌های آن همتا را درخواست می‌کند. همتا نیز پایگاه دادهٔ کامل خود را ارسال کرده و پیامی می‌فرستد که نشان می‌دهد کار تمام شده است. سرور خراب‌شده سپس تا زمانی که زمان MCLT سپری شود منتظر می‌ماند، و پس از سپری شدن MCLT، هر دو سرور گذار را به کارکرد عادی بازمی‌گردانند. این دورهٔ انتظار تضمین می‌کند هرگونه اجاره‌ای که سرور از کار افتاده در زمان قطع ارتباط با همتای خود ممکن است اعطا کرده باشد، منقضی شده باشد.

در حالی که سرور از کار افتاده در حال بازیابی است، شریک آن در وضعیت partner-down باقی می‌ماند، به این معنی که به تمام کلاینت‌ها سرویس‌دهی می‌کند. سرور خراب‌شده تا زمانی که گذار به کارکرد عادی را کامل نکرده باشد، هیچ سرویسی به کلاینت‌های DHCP ارائه نخواهد داد.

در صورتی که هر دو سرور تشخیص دهند که هرگز پیش از این با شریک خود ارتباط برقرار نکرده‌اند، هر دوی آن‌ها در این وضعیت بازیابی بالا می‌آیند و روندی را که همین الان شرح دادیم دنبال می‌کنند. در این حالت، تا زمانی که MCLT منقضی نشده باشد، هیچ سرویسی به کلاینت‌های DHCP ارائه نخواهد شد.

پیکربندی پشتیبان گرم (CONFIGURING FAILOVER)

به منظور پیکربندی پشتیبان گرم (failover)، باید اعلان یک همتا (peer declaration) را بنویسید که پروتکل پشتیبان گرم را پیکربندی کند، و همچنین باید ارجاعات به همتا را در هر اعلان استخر (pool declaration) که می‌خواهید برای آن پشتیبان گرم انجام دهید، بنویسید. لازم نیست برای همه استخرهای یک بخش شبکه مشخص، پشتیبان گرم انجام دهید. نباید به یک سرور بگویید که روی یک استخر آدرس خاص پشتیبان گرم انجام می‌دهد و به دیگری بگویید که انجام نمی‌دهد. نباید هیچ استخر آدرس مشترکی داشته باشید که روی آن پشتیبان گرم انجام ندهید. یک اعلان استخر که از پشتیبان گرم استفاده می‌کند، به شکل زیر خواهد بود:

pool {
	failover peer "foo";
	pool specific parameters
};

سرور در حال حاضر بررسی‌های صحت‌سنجی بسیار کمی انجام می‌دهد، بنابراین اگر آن را اشتباه پیکربندی کنید، به روش‌های عجیبی از کار می‌افتد. از این رو توصیه می‌کنم یا از پشتیبان گرم استفاده کنید یا اصلاً استفاده نکنید، اما استخرهای ترکیبی نسازید. همچنین، از یک فایل پیکربندی اصلی یکسان برای هر دو سرور استفاده کنید و یک فایل جداگانه داشته باشید که شامل اعلان همتا بوده و فایل اصلی را ضمیمه (include) کند. این کار به شما کمک می‌کند تا از عدم تطابق پیکربندی جلوگیری نمایید. با تکامل پیاده‌سازی ما، این مسئله کمتر مشکل‌ساز خواهد شد. یک نمونه فایل ساده dhcpd.conf برای یک سرور اصلی (primary) ممکن است به شکل زیر باشد:

failover peer "foo" {
  primary;
  address anthrax.rc.example.com;
  port 519;
  peer address trantor.rc.example.com;
  peer port 520;
  max-response-delay 60;
  max-unacked-updates 10;
  mclt 3600;
  split 128;
  load balance max seconds 3;
}
include "/etc/dhcpd.master";

دستورات موجود در اعلان همتا به شرح زیر است:

دستورات primary و secondary

دستور address

دستور peer address

دستور port

دستور peer port

دستور max-response-delay

دستور max-unacked-updates

دستور mclt

دستور split

دستور hba

hba ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:
    00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00;

hba aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:
    aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa:aa;
hba 55:55:55:55:55:55:55:55:55:55:55:55:55:55:55:55:
    55:55:55:55:55:55:55:55:55:55:55:55:55:55:55:55;

دستور load balance max seconds

دستور auto-partner-down

دستورات تعادل استخر پشتیبان گرم (Failover pool balance).

دسته‌بندی کلاینت‌ها (CLIENT CLASSING)

کلاینت‌ها را می‌توان به کلاس‌های مختلف دسته‌بندی کرد و بسته به کلاسی که در آن قرار دارند، رفتار متفاوتی با آن‌ها داشت. این تفکیک را می‌توان با یک عبارت شرطی یا با دستور match درون اعلان کلاس انجام داد. می‌توان محدودیتی برای کل تعداد کلاینت‌های درون یک کلاس یا زیرکلاس خاص که مجاز به داشتن اجاره‌نامه (lease) به صورت هم‌زمان هستند تعیین کرد، و همچنین می‌توان ایجاد خودکار زیرکلاس‌ها را بر اساس محتوای بسته ارسالی کلاینت مشخص نمود.

پشتیبانی از دسته‌بندی کلاینت‌های DHCPv6 در نسخه 4.3.0 اضافه شد. این سازوکار از همان قوانین DHCPv4 پیروی می‌کند، با این استثنا که پشتیبانی از کلاس‌های صورت‌حساب (billing classes) هنوز اضافه نشده است.

برای افزودن کلاینت‌ها به کلاس‌ها بر اساس ارزیابی شرطی، می‌توانید یک عبارت تطبیق (matching expression) را در اعلان کلاس مشخص کنید:

class "ras-clients" {
  match if substring (option dhcp-client-identifier, 1, 3) = "RAS";
}

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

توجه داشته باشید که چه از عبارات تطبیق استفاده کنید و چه از دستورات افزودن (یا هر دو) برای دسته‌بندی کلاینت‌ها، همیشه باید برای هر کلاسی که استفاده می‌کنید یک اعلان کلاس بنویسید. اگر هیچ دستور تطبیق یا دستور درون‌حوزه‌ای (in-scope) برای یک کلاس وجود نداشته باشد، اعلان باید به شکل زیر باشد:

class "ras-clients" {
}

زیرکلاس‌ها (SUBCLASSES)

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

class "allocation-class-1" {
  match pick-first-value (option dhcp-client-identifier, hardware);
}
class "allocation-class-2" {
  match pick-first-value (option dhcp-client-identifier, hardware);
}
subclass "allocation-class-1" 1:8:0:2b:4c:39:ad;
subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3;
subclass "allocation-class-1" 1:0:0:c4:aa:29:44;
subnet 10.0.0.0 netmask 255.255.255.0 {
  pool {
    allow members of "allocation-class-1";
    range 10.0.0.11 10.0.0.50;
  }
  pool {
    allow members of "allocation-class-2";
    range 10.0.0.51 10.0.0.100;
  }
}

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

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

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

subclass "allocation-class-2" 1:08:00:2b:a1:11:31 {
  option root-path "samsara:/var/diskless/alphapc";
  filename "/tftpboot/netbsd.alphapc-diskless";
}

در این مثال، ما از زیرکلاس‌سازی به عنوان روشی برای کنترل تخصیص آدرس بر مبنای هر کلاینت استفاده کرده‌ایم. با این حال، استفاده از زیرکلاس‌سازی به شیوه‌هایی که خاص کلاینت نیستند نیز امکان‌پذیر است؛ برای نمونه، استفاده از مقدار گزینه vendor-class-identifier برای تعیین مقادیری که باید در گزینه vendor-encapsulated-options ارسال شوند. نمونه‌ای از این کاربرد در بخش VENDOR ENCAPSULATED OPTIONS در صفحه راهنمای dhcp-options(5) نشان داده شده است.

محدودیت‌های مبتنی بر کلاس در تخصیص پویای آدرس (PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION)

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

class "limited-1" {
  lease limit 4;
}

این دستور کلاسی ایجاد می‌کند که در آن حداکثر چهار عضو می‌توانند به طور هم‌زمان دارای اجاره‌نامه باشند.

کلاس‌های پویا و خودکار (SPAWNING CLASSES)

اعلان یک کلاس خودکار (spawning class) امکان‌پذیر است. کلاس خودکار، کلاسی است که بر اساس آنچه کلاینت ارسال می‌کند، به طور خودکار زیرکلاس‌هایی تولید می‌نماید. دلیل ایجاد کلاس‌های خودکار، فراهم کردن امکان ساخت بی‌درنگ کلاس‌های با محدودیت اجاره بود. کاربرد مورد نظر در محیط مودم‌های کابلی است، جایی که ISP مایل است به کلاینت‌های حاضر در یک محل خاص بیش از یک آدرس IP اختصاص دهد، اما نمی‌خواهد زیرشبکه اختصاصی به آن‌ها بدهد یا تعداد نامحدودی آدرس IP از بخش شبکه‌ای که به آن متصل هستند در اختیارشان بگذارد.

بسیاری از سیستم‌های سرفصل (head-end) مودم‌های کابلی را می‌توان طوری پیکربندی کرد که هنگام بازپخش (relay) بسته‌های DHCP به سرور، گزینه Relay Agent Information را به آن‌ها اضافه کنند. این سیستم‌ها معمولاً یک گزینه circuit ID یا remote ID می‌افزایند که محل مشتری را به صورت یکتا مشخص می‌کند. برای بهره‌گیری از این قابلیت، می‌توانید اعلان کلاسی به شکل زیر بنویسید:

class "customer" {
  spawn with option agent.circuit-id;
  lease limit 4;
}

اکنون هر زمان که درخواستی از سوی محل مشتری برسد، گزینه circuit ID در جدول هش کلاس بررسی می‌شود. اگر زیرکلاسی منطبق با circuit ID پیدا شود، کلاینت در آن زیرکلاس دسته‌بندی شده و طبق آن با آن رفتار می‌شود. اگر زیرکلاسی منطبق بر circuit ID پیدا نشود، زیرکلاس جدیدی ایجاد شده و در فایل dhcpd.leases ثبت می‌گردد و کلاینت در این کلاس جدید طبقه‌بندی می‌شود. پس از آن‌که کلاینت دسته‌بندی شد، مطابق با قوانین کلاس با آن رفتار خواهد شد؛ از جمله، در این مورد، مشمول محدودیت چهار اجاره‌نامه برای هر محل می‌شود.

استفاده از سازوکار ایجاد خودکار زیرکلاس به گزینه‌های رله محدود نمی‌شود؛ این مثال خاص صرفاً به این دلیل آورده شده است که نسبتاً سرراست و ساده است.

ترکیب MATCH ،MATCH IF و SPAWN WITH (COMBINING MATCH, MATCH IF AND SPAWN WITH)

در برخی موارد، ممکن است استفاده از یک عبارت برای اختصاص کلاینت به یک کلاس خاص و عبارت دوم برای قرار دادن آن در یک زیرکلاس از آن کلاس مفید باشد. این کار با ترکیب دستورات match if و spawn with، یا دستورات match if و match انجام‌پذیر است. به عنوان مثال:

class "jr-cable-modems" {
  match if option dhcp-vendor-identifier = "jrcm";
  spawn with option agent.circuit-id;
  lease limit 4;
}
class "dv-dsl-modems" {
  match if option dhcp-vendor-identifier = "dvdsl";
  spawn with option agent.circuit-id;
  lease limit 16;
}

این قابلیت به شما امکان می‌دهد دو کلاس داشته باشید که هر دو عبارت spawn with یکسانی دارند، بدون آن‌که کلاینت‌های این دو کلاس با یکدیگر اشتباه گرفته شوند.

به‌روزرسانی پویای دی‌ان‌اس (DYNAMIC DNS UPDATES)

سرور DHCP توانایی به‌روزرسانی پویای سامانه نام دامنه (DNS) را دارد. در فایل‌های پیکربندی، می‌توانید نحوه به‌روزرسانی سامانه نام دامنه را مشخص کنید. این به‌روزرسانی‌ها با RFC 2136 سازگار هستند؛ بنابراین هر سرور DNS که از RFC 2136 پشتیبانی کند باید بتواند به‌روزرسانی‌های ارسال‌شده از سرور DHCP را بپذیرد.

دو طرح DNS پیاده‌سازی شده است. گزینه موقت (interim) بر پایه پیش‌نویس‌های اسناد DDNS استوار است، در حالی که گزینه استاندارد (standard) بر مبنای RFCهای مربوط به تعامل DHCP-DNS و DHCIDها پیاده‌سازی شده است. گزینه سوم، یعنی ad-hoc، منسوخ شده و اکنون از پایگاه کد حذف گردیده است. سرور DHCP باید طوری پیکربندی شود که از یکی از دو روش مورد پشتیبانی کنونی استفاده کند، یا اینکه اصلاً به‌روزرسانی DNS انجام ندهد.

نصب‌های جدید باید از گزینه standard استفاده کنند. در نصب‌های قدیمی‌تر ممکن است جهت سازگاری رو به عقب با پایگاه داده DNS تا زمان امکان به‌روزرسانی آن، تمایل به ادامه استفاده از گزینه interim وجود داشته باشد. این تنظیم را می‌توان با پارامتر پیکربندی ddns-update-style انجام داد.

طرح و الگوی به‌روزرسانی دی‌ان‌اس (THE DNS UPDATE SCHEME)

طرح‌های به‌روزرسانی موقت (interim) و استاندارد (standard) دی‌ان‌اس بیشتر بر اساس فعالیت‌های گروه IETF عمل می‌کنند. نسخه موقت بر پایه پیش‌نویس‌های در حال توسعه در آن زمان بود، در حالی که نسخه استاندارد بر مبنای RFCهای نهایی تدوین شده است. RFCهای استاندارد عبارتند از:

RFC 4701 (updated by RF5494)
RFC 4702
RFC 4703

و پیش‌نویس‌های متناظر آن‌ها عبارت بودند از:

draft-ietf-dnsext-dhcid-rr-??.txt
draft-ietf-dhc-fqdn-option-??.txt
draft-ietf-dhc-ddns-resolution-??.txt

چارچوب اساسی این دو طرح مشابه است و تفاوت مادی و اصلی آن‌ها در این است که در نسخه استاندارد از یک رکورد منبع DHCID RR استفاده می‌شود، در حالی که در نسخه‌های موقت از یک رکورد TXT RR استفاده می‌گردد. قالب رکورد TXT شباهت‌هایی به DHCID RR دارد اما معادل آن نیست (تفاوت MD5 در برابر SHA2، تفاوت طول فیلدها و غیره).

در این دو طرح، سرور DHCP لزوماً همیشه هر دو رکورد A و PTR را به‌روزرسانی نمی‌کند. گزینه FQDN شامل پرچمی است که در صورت ارسال توسط کلاینت، نشان می‌دهد که کلاینت تمایل دارد رکورد A خود را شخصاً به‌روز کند. در این حالت، سرور می‌تواند طوری پیکربندی شود که به خواسته کلاینت احترام بگذارد یا آن را نادیده بگیرد. این کار با دستور allow client-updates; یا دستور ignore client-updates; انجام می‌شود. به صورت پیش‌فرض، به‌روزرسانی‌های کلاینت مجاز است.

اگر سرور طوری پیکربندی شده باشد که به‌روزرسانی کلاینت را مجاز بداند، در صورتی که کلاینت یک نام دامنه کاملاً واجد شرایط (FQDN) در گزینه FQDN ارسال کند، سرور از همان نام ارسالی کلاینت در گزینه FQDN برای به‌روزرسانی رکورد PTR استفاده خواهد کرد. برای مثال، فرض کنیم کلاینت مهمانی از دامنه "radish.org" است که نام میزبان آن "jschmoe" می‌باشد. سرور مربوط به دامنه "example.org" است. کلاینت DHCP در گزینه FQDN مشخص می‌کند که FQDN آن "jschmoe.radish.org." است. همچنین نشان می‌دهد که می‌خواهد رکورد A خود را شخصاً به‌روزرسانی کند. بنابراین سرور DHCP تلاشی برای ایجاد رکورد A برای کلاینت نمی‌کند، اما یک رکورد PTR برای آدرس IP اختصاص‌یافته به کلاینت تنظیم می‌نماید که به jschmoe.radish.org اشاره دارد. به محض آن‌که کلاینت DHCP دارای یک آدرس IP شد، می‌تواند رکورد A خود را به‌روزرسانی کند، با این فرض که سرور DNS دامنه "radish.org" به آن اجازه چنین کاری را بدهد.

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

1. گزینه fqdn (در صورت وجود)
2. گزینه hostname (در صورت وجود)
3. گزینه نام میزبان پیکربندی‌شده (در صورت تعریف).

اگر این پیش‌فرض‌ها برای انتخاب نام میزبان مناسب نیستند، می‌توانید دستور دلخواه خود را برای تنظیم متغیر ddns-hostname بنویسید. در صورتی که هیچ‌یک از موارد فوق یافت نشود، اگر use-host-decl-names فعال باشد، سرور از نام اعلان میزبان (در صورت وجود) استفاده خواهد کرد.

سرور از نام دامنه اختصاصی خود برای کلاینت استفاده خواهد کرد. سپس هر دو رکورد A و PTR را با استفاده از نامی که برای کلاینت برگزیده است به‌روزرسانی می‌کند. اگر کلاینت یک نام دامنه کاملاً واجد شرایط در گزینه fqdn ارسال کند، سرور فقط از چپ‌ترین بخش نام دامنه استفاده می‌کند؛ در مثال بالا، "jschmoe" به جای "jschmoe.radish.org".

علاوه بر این، اگر دستورالعمل ignore client-updates; به کار رود، سرور پاسخی را در بسته DHCP با استفاده از گزینه FQDN ارسال می‌کند که به کلاینت القا می‌کند در صورت تمایل باید به‌روزرسانی‌های خود را شخصاً انجام دهد. با دستور deny client-updates;، پاسخی ارسال می‌شود که نشان می‌دهد کلاینت مجاز به انجام به‌روزرسانی نیست.

هر دو گزینه استاندارد و موقت همچنین شامل روشی هستند که به بیش از یک سرور DHCP اجازه می‌دهد پایگاه داده DNS را به‌روزرسانی کنند، بدون آنکه تصادفاً رکوردهای A که نباید حذف شوند را پاک کنند یا در افزودن رکوردهای A که باید اضافه شوند ناکام بمانند. در گزینه استاندارد، این روش به شرح زیر عمل می‌کند:

هنگامی که سرور DHCP اجاره‌نامه جدیدی به کلاینت صادر می‌کند، یک رشته متنی ایجاد می‌کند که هش SHA از شناسه کلاینت DHCP است (برای جزئیات به RFCهای 4701 و 4702 مراجعه کنید). فرآیند به‌روزرسانی تلاش می‌کند یک رکورد A با نام انتخابی سرور و یک رکورد DHCID حاوی رشته شناسه هش‌شده (hashid) اضافه کند. اگر این به‌روزرسانی موفقیت‌آمیز باشد، کار سرور به پایان رسیده است.

اگر به‌روزرسانی به دلیل وجود قبلی رکورد A با شکست مواجه شود، سرور DHCP تلاش می‌کند رکورد A را با این پیش‌شرط اضافه کند که باید یک رکورد DHCID با همان نامِ رکورد A جدید وجود داشته باشد و محتوای آن رکورد DHCID باید برابر با hashid باشد. اگر این به‌روزرسانی موفق شود، کلاینت دارای رکورد A و رکورد PTR خود خواهد بود. اگر ناموفق باشد، نامی که به کلاینت اختصاص داده شده (یا درخواست شده) در حال استفاده است و کلاینت نمی‌تواند از آن استفاده کند. در این مرحله، سرور DHCP از تلاش برای به‌روزرسانی DNS برای کلاینت صرف‌نظر می‌کند تا زمانی که کلاینت نام جدیدی را انتخاب کند.

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

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

طرح به‌روزرسانی موقت دی‌ان‌اس (interim) پیش از نهایی شدن RFCها نگاشته شد و کاملاً از آن‌ها پیروی نمی‌کند. RFCها خواهان یک نوع رکورد جدید DHCID RR هستند، در حالی که طرح موقت از یک رکورد TXT استفاده می‌کند. علاوه بر این، پیش‌نویس ddns-resolution از سرور DHCP می‌خواست که یک DHCID RR را روی رکورد PTR قرار دهد، اما روش به‌روزرسانی interim این کار را انجام نمی‌دهد. در RFC نهایی، این الزام تعدیل شد تا سرور بتواند به دلخواه یک DHCID RR به رکورد PTR اضافه کند.

دی‌ان‌اس پویا در محیط‌های پشته دوگانه (DDNS IN DUAL STACK ENVIRONMENTS)

همان‌طور که در بخش 5.2 از RFC 4703 شرح داده شده است، به منظور اجرای DDNS در محیط‌های پشته دوگانه (dual stack)، هم سرورهای IPv4 و هم IPv6 باید طوری پیکربندی شوند که از شیوه به‌روزرسانی استاندارد استفاده کنند و کلاینت‌های مشارکت‌کننده IPv4 حتماً باید مقادیر DUID را همان‌گونه که در بخش 6.1 از RFC 4361 توضیح داده شده است، در dhcp-client-identifierهای خود ارسال کنند.

به طور خلاصه، این سازوکار در نظر دارد از DUIDهای یکتای سراسری برای شناسایی هر دو نوع کلاینت‌های IPv4 و IPv6 استفاده کند؛ و در جایی که یک دستگاه هم اجاره‌نامه IPv4 و هم IPv6 دارد، با همان DUID یکسان شناسایی شود. این امر به کلاینت پشته دوگانه اجازه می‌دهد از همان FQDN یکسان برای هر دو نگاشت استفاده کند، در حالی که طبق قوانین تشخیص تداخل، از به‌روزرسانی‌های کلاینت‌های دیگر محافظت می‌شود.

با این حال، همه کلاینت‌های IPv4 این رفتار را پیاده‌سازی نکرده‌اند که این امر پشتیبانی از آن‌ها را در محیط‌های پشته دوگانه با مشکل مواجه می‌کند. برای رفع این مشکل، ISC DHCP (از نسخه 4.4.0) از حالت جدیدی از رفع تداخل DDNS تحت عنوان «حالت ترکیبی پشته دوگانه» یا Dual Stack Mixed Mode (به اختصار DSMM) پشتیبانی می‌کند.

مفهوم نهفته در DSMM نسبتاً ساده است. همه سرورهای DHCP مربوط به یک پروتکل (IPv4 یا v6) از یک سبک ddns-update-style (یا interim یا standard) استفاده می‌کنند در حالی که تمام سرورهای پروتکل «دیگر» از سبک ddns-update-style «دیگر» استفاده خواهند کرد. به این ترتیب، همه سرورهای یک پروتکل معین از همان نوع رکورد یکسان (TXT یا DHCID) برای ورودی‌های DHCID RR خود بهره می‌برند. این امر اجازه می‌دهد تشخیص تداخل درون هر پروتکل بدون تداخل با ورودی‌های پروتکل دیگر اعمال گردد.

اصلاحات DSMM اکنون تضمین می‌کند که سرورهای DSMM IPv4 فقط رکوردهای A، رکوردهای PTR مرتبط با آن‌ها و رکوردهای DHCID را تغییر می‌دهند، در حالی که سرورهای DSMM IPv6 تنها رکوردهای AAAA، رکوردهای PTR مرتبط با آن‌ها و رکوردهای DHCID را اصلاح می‌نمایند.

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

در حالی که تشخیص تداخل به طور پیش‌فرض فعال است، DSMM فعال نیست. برای فعال‌سازی DSMM، هر دو گزینه update-conflict-detection و ddns-dual-stack-mixed-mode باید برابر با true باشند.

محافظت از رکوردهای دی‌ان‌اس برای کلاینت‌های ایستا (PROTECTING DNS ENTRIES FOR STATIC CLIENTS)

محافظت از رکوردهایی که به صورت دستی برای کلاینت‌های ایستا ایجاد شده‌اند، بخشی درونی از سازوکار رفع تداخل است. طبق قوانین رفع تداخل، یک به‌روزرسان DNS مجاز نیست رکوردهای مستقیم (forward) دی‌ان‌اس را تغییر دهد مگر آنکه رکورد DHCID RR منطبقی برای کلاینتی که به‌روزرسانی برای او انجام می‌شود، وجود داشته باشد. بنابراین، هر رکورد مستقیم DNS که فاقد یک DHCID RR متناظر باشد، توسط چنین به‌روزرسانی قابل تغییر نیست.

در برخی محیط‌ها، ممکن است مطلوب باشد که تنها از این جنبه از رفع تداخل استفاده شود و به به‌روزرسان‌های DNS اجازه بازنویسی (overwrite) رکوردهای مربوط به کلاینت‌های پویا بدون توجه به اینکه کدام کلاینت مالک آن‌هاست داده شود. به عبارت دیگر، وجود یا عدم وجود یک DHCID RR برای تعیین اینکه آیا رکوردها قابل بازنویسی هستند یا خیر استفاده می‌شود؛ اینکه آیا کلاینت با مقدار داده DHCID RR مطابقت دارد یا خیر، اهمیتی ندارد. این رفتار که به صورت پیش‌فرض غیرفعال است، از طریق پارامتر ddns-guard-id-must-match قابل پیکربندی است. همانند DSMM، این رفتار فقط در صورتی قابل فعال‌سازی است که رفع تداخل فعال باشد. پیش از تصمیم به استفاده از این رفتار، باید جوانب آن با دقت سنجیده شود.

پارامتر دیگری نیز وجود دارد که می‌تواند همراه با DSMM استفاده شود: ddns-other-guard-is-dynamic. هنگامی که این پارامتر همراه با DSMM فعال باشد، سرور وجود یک DHCID RR از نوع سبک دیگر را به این معنی تلقی می‌کند که رکوردهای مستقیم DNS برای آن FQDN باید پویا باشند و می‌توان آن‌ها را بازنویسی کرد. به عنوان مثال، چنین سروری که از سبک interim استفاده می‌کند، در صورتی که فقط یک DHCID RR از نوع DHCID برای آن FQDN وجود داشته باشد، می‌تواند رکوردهای DNS آن FQDN را بازنویسی کند. در واقع، اگر رکوردهای پویایی برای یک پروتکل وجود داشته باشد، برای کنار زدن محافظت ایستای رکوردها برای پروتکل دیگر کافی است. این رفتار مستلزم بررسی و تامل دقیق پیش از استفاده است.

امنیت به‌روزرسانی پویای دی‌ان‌اس (DYNAMIC DNS UPDATE SECURITY)

هنگامی که سرور DNS خود را طوری تنظیم می‌کنید که به‌روزرسانی‌های ارسالی از سرور DHCP را بپذیرد، ممکن است آن را در معرض به‌روزرسانی‌های غیرمجاز قرار دهید. برای جلوگیری از این امر، باید از امضاهای TSIG استفاده کنید؛ روشی برای امضای رمزنگاری‌شده به‌روزرسانی‌ها با استفاده از یک کلید مخفی مشترک (shared secret key). تا زمانی که محرمانگی این کلید را حفظ کنید، به‌روزرسانی‌های شما نیز امن خواهند بود. با این حال، توجه داشته باشید که خود پروتکل DHCP هیچ‌گونه امنیتی فراهم نمی‌کند، و بنابراین کلاینت‌ها می‌توانند اطلاعاتی را به سرور DHCP ارسال کنند که سرور DHCP متعاقباً بر اساس محدودیت‌های شرح داده‌شده قبلی، از آن‌ها در به‌روزرسانی‌های خود استفاده نماید.

سرور DNS باید طوری پیکربندی شود که اجازه به‌روزرسانی را برای هر منطقه‌ای (zone) که سرور DHCP قرار است به‌روز کند، بدهد. برای مثال، فرض کنیم که به کلاینت‌های موجود در دامنه sneedville.edu آدرس‌هایی از زیرشبکه 10.10.17.0/24 اختصاص داده خواهد شد. در این صورت، شما به یک اعلان کلید برای کلید TSIG مورد استفاده، و همچنین به دو اعلان منطقه (یکی برای منطقه‌ای که شامل رکوردهای A است که به‌روزرسانی خواهند شد و دیگری برای منطقه‌ای که شامل رکوردهای PTR است) نیاز خواهید داشت؛ برای ISC BIND چیزی شبیه به این:

key DHCP_UPDATER {
  algorithm HMAC-MD5.SIG-ALG.REG.INT;
  secret pRP5FapFoJ95JEL06sv4PQ==;
};
zone "example.org" {
	type master;
	file "example.org.db";
	allow-update { key DHCP_UPDATER; };
};
zone "17.10.10.in-addr.arpa" {
	type master;
	file "10.10.17.db";
	allow-update { key DHCP_UPDATER; };
};

همچنین باید سرور DHCP خود را برای انجام به‌روزرسانی روی این منطقه‌ها پیکربندی کنید. برای این منظور، باید چیزی شبیه به موارد زیر را به فایل dhcpd.conf خود اضافه کنید:

key DHCP_UPDATER {
  algorithm HMAC-MD5.SIG-ALG.REG.INT;
  secret pRP5FapFoJ95JEL06sv4PQ==;
};
zone EXAMPLE.ORG. {
  primary 127.0.0.1;
  key DHCP_UPDATER;
}
zone 17.127.10.in-addr.arpa. {
  primary 127.0.0.1;
  key DHCP_UPDATER;
}

دستور primary آدرس IP کارساز نامی (name server) را مشخص می‌کند که اطلاعات منطقه آن قرار است به‌روزرسانی شود. علاوه بر دستور primary، دستورهای primary6، secondary و secondary6 نیز وجود دارند. دستور primary6 یک آدرس IPv6 را برای کارساز نام مشخص می‌کند. دستورهای ثانویه آدرس‌های اضافی برای کارسازهای نام فراهم می‌آورند تا در صورت عدم پاسخگویی کارساز اصلی استفاده شوند. تعداد کارسازهای نامی که کد DDNS قبل از تسلیم شدن تلاش می‌کند استفاده کند محدود است و در حال حاضر روی سه تنظیم شده است.

توجه داشته باشید که اعلان‌های منطقه باید با رکوردهای مرجع (authority) در کارساز نام شما مطابقت داشته باشند؛ در مثال بالا، باید یک رکورد SOA برای "example.org." و برای "17.10.10.in-addr.arpa." وجود داشته باشد. برای مثال، اگر زیردامنه "foo.example.org" بدون SOA جداگانه وجود داشت، نمی‌توانستید اعلان منطقه‌ای برای "foo.example.org." بنویسید. همچنین به یاد داشته باشید که نام‌های منطقه در پیکربندی DHCP شما باید به یک "." ختم شوند؛ این ساختار نحوی ترجیحی است. اگر نام منطقه خود را به "." ختم نکنید، سرور DHCP خودش آن را تشخیص می‌دهد. همچنین توجه داشته باشید که در پیکربندی DHCP، بر خلاف پیکربندی DNS، نام‌های منطقه درون علامت نقل‌قول (quotes) قرار نمی‌گیرند.

البته شما باید کلید مخفی اختصاصی خود را انتخاب کنید. توزیع ISC BIND 9 همراه با برنامه‌ای برای تولید کلیدهای مخفی به نام dnssec-keygen عرضه می‌شود. اگر از dnssec-keygen برنامه BIND 9 استفاده می‌کنید، کلید بالا به شکل زیر ساخته می‌شود:

dnssec-keygen -a HMAC-MD5 -b 128 -n USER DHCP_UPDATER

نام کلید، الگوریتم و مقدار مخفی (secret) باید دقیقاً با آنچه توسط سرور DNS استفاده می‌شود مطابقت داشته باشند. سرور DHCP در حال حاضر از الگوریتم‌های زیر پشتیبانی می‌کند:

HMAC-MD5
HMAC-SHA1
HMAC-SHA224
HMAC-SHA256
HMAC-SHA384
HMAC-SHA512

ممکن است بخواهید ثبت گزارش (logging) به‌روزرسانی‌های DNS را در سرور DNS خود فعال کنید. برای این کار، می‌توانید دستور ثبت گزارشی مشابه زیر بنویسید:

logging {
	channel update_debug {
		file "/var/log/update-debug.log";
		severity	debug 3;
		print-category	yes;
		print-severity	yes;
		print-time	yes;
	};
	channel security_info	{
		file	"/var/log/named-auth.info";
		severity	info;
		print-category	yes;
		print-severity	yes;
		print-time	yes;
	};
	category update { update_debug; };
	category security { security_info; };
};

پیش از راه‌اندازی کارساز نام، باید فایل‌های /var/log/named-auth.info و /var/log/update-debug.log را ایجاد کنید. برای اطلاعات بیشتر در خصوص پیکربندی ISC BIND، به مستندات همراه آن مراجعه کنید.

مرجع: رویدادها (REFERENCE: EVENTS)

سه نوع رویداد در رابطه با یک اجاره (lease) وجود دارد که می‌تواند رخ دهد، و این امکان وجود دارد که دستوراتی را اعلان کنید تا هنگام وقوع هر یک از این رویدادها اجرا شوند. این رویدادها عبارتند از رویداد تعهد (commit)، هنگامی که سرور تعهد یک اجاره مشخص را به یک کلاینت داده است؛ رویداد آزادسازی (release)، هنگامی که کلاینت سرور را از تعهد خود آزاد کرده است؛ و رویداد انقضا (expiry)، هنگامی که مدت تعهد منقضی می‌شود.

برای اعلان مجموعه‌ای از دستورات جهت اجرا هنگام وقوع یک رویداد، باید از دستور on به همراه نام رویداد استفاده کنید، و در ادامه مجموعه‌ای از دستورات برای اجرا در هنگام وقوع رویداد درون آکولاد قرار می‌گیرند.

مرجع: اعلان‌ها (REFERENCE: DECLARATIONS)

دستور include

include "filename";

دستور include برای خواندن یک فایل نام‌گذاری‌شده و پردازش محتویات آن فایل به گونه‌ای که گویی در محل دستور include درج شده است، استفاده می‌شود.

دستور shared-network

shared-network name {
  [ parameters ]
  [ declarations ]
}

دستور shared-network برای آگاه‌سازی سرور DHCP از این موضوع به کار می‌رود که برخی زیرشبکه‌های IP در واقع در یک شبکه فیزیکی یکسان مشترک هستند. هر زیرشبکه‌ای در یک شبکه مشترک باید درون یک دستور shared-network اعلان شود. پارامترهای مشخص‌شده در دستور shared-network هنگام راه‌اندازی (بوت) کلاینت‌ها در آن زیرشبکه‌ها استفاده خواهند شد، مگر اینکه پارامترهای ارائه‌شده در سطح زیرشبکه یا میزبان آن‌ها را بازنویسی کنند. اگر هر زیرشبکه‌ای در یک شبکه مشترک دارای آدرس‌های موجود برای تخصیص پویا باشد، آن آدرس‌ها در یک استخر مشترک برای آن شبکه اشتراکی جمع‌آوری شده و بر حسب نیاز به کلاینت‌ها اختصاص می‌یابند. هیچ راهی برای تشخیص این موضوع وجود ندارد که کلاینت باید در کدام زیرشبکه از یک شبکه اشتراکی راه‌اندازی شود.

مقدار Name باید نام شبکه اشتراکی باشد. این نام هنگام چاپ پیام‌های اشکال‌زدایی (دیباگ) استفاده می‌شود، بنابراین باید برای آن شبکه اشتراکی توصیفی و رسا باشد. این نام می‌تواند ساختار نحوی یک نام دامنه معتبر را داشته باشد (اگرچه هرگز به عنوان دامنه استفاده نخواهد شد)، یا می‌تواند هر نام دلخواهی باشد که درون گیومه محصور شده است.

دستور subnet

subnet subnet-number netmask netmask {
  [ parameters ]
  [ declarations ]
}

دستور subnet برای ارائه اطلاعات کافی به dhcpd استفاده می‌شود تا تشخیص دهد آیا یک آدرس IP در آن زیرشبکه قرار دارد یا خیر. همچنین می‌تواند برای ارائه پارامترهای اختصاصی زیرشبکه و مشخص کردن آدرس‌هایی که می‌توانند به طور پویا به کلاینت‌های بوت‌شده در آن زیرشبکه تخصیص یابند، به کار رود. چنین آدرس‌هایی با استفاده از اعلان range تعیین می‌شوند.

مقدار subnet-number باید یک آدرس IP یا نام دامنه‌ای باشد که به شماره زیرشبکه مورد توصیف ترجمه می‌شود. مقدار netmask باید یک آدرس IP یا نام دامنه‌ای باشد که به ماسک زیرشبکه (subnet mask) مورد نظر ترجمه می‌شود. شماره زیرشبکه، به همراه ماسک زیرشبکه، برای تعیین اینکه آیا یک آدرس IP مفروض در زیرشبکه مشخص‌شده قرار دارد یا خیر کافی هستند.

اگرچه همراه با هر اعلان زیرشبکه باید یک netmask ارائه شود، اما توصیه می‌شود چنانچه تفاوتی در ماسک‌های زیرشبکه در یک سایت وجود دارد، در هر اعلان زیرشبکه از یک دستور گزینه subnet-mask برای تنظیم ماسک زیرشبکه مطلوب استفاده شود؛ چرا که هر دستور گزینه subnet-mask، ماسک زیرشبکه اعلان‌شده در دستور subnet را بازنویسی خواهد کرد.

دستور subnet6

subnet6 subnet6-number {
  [ parameters ]
  [ declarations ]
}

دستور subnet6 برای ارائه اطلاعات کافی به dhcpd استفاده می‌شود تا تشخیص دهد آیا یک آدرس IPv6 در آن subnet6 قرار دارد یا خیر. همچنین می‌تواند برای ارائه پارامترهای اختصاصی زیرشبکه و تعیین آدرس‌هایی که می‌توانند به صورت پویا به کلاینت‌های بوت‌شده در آن زیرشبکه اختصاص یابند، استفاده شود.

مقدار subnet6-number باید یک شناسه شبکه IPv6 باشد که به صورت ip6-address/bits مشخص می‌شود.

دستور range

range [ dynamic-bootp ] low-address [ high-address];

برای هر زیرشبکه‌ای که آدرس‌ها در آن به طور پویا تخصیص می‌یابند، باید حداقل یک دستور range وجود داشته باشد. دستور range پایین‌ترین و بالاترین آدرس‌های IP را در یک محدوده مشخص می‌کند. تمام آدرس‌های IP موجود در محدوده باید در زیرشبکه‌ای باشند که دستور range در آن اعلان شده است. در صورتی که آدرس‌های موجود در محدوده مشخص‌شده علاوه بر کلاینت‌های DHCP بتوانند به طور پویا به کلاینت‌های BOOTP نیز تخصیص داده شوند، می‌توان فلگ dynamic-bootp را تعیین کرد. هنگام مشخص کردن یک آدرس تکی، می‌توان high-address را حذف کرد.

دستور range6

range6 low-address high-address;
range6 subnet6-number;
range6 subnet6-number temporary;
range6 address temporary;

برای هر زیرشبکه IPv6 (یا subnet6) که در آن آدرس‌ها به صورت پویا تخصیص می‌یابند، باید حداقل یک دستور range6 وجود داشته باشد. دستور range6 می‌تواند شامل پایین‌ترین و بالاترین آدرس‌های IPv6 در یک range6 باشد، یا از نمادگذاری CIDR به صورت ip6-address/bits استفاده کند. تمام آدرس‌های IP موجود در range6 باید در subnet6 مربوطه‌ای باشند که دستور range6 در آن اعلان شده است.

نگارش temporary پیشوند را (به طور پیش‌فرض روی ۶۴ بیت) برای آدرس‌های موقت (RFC 4941) در دسترس قرار می‌دهد. در هر درخواست با گزینه IA_TA، یک آدرس جدید به ازای هر پیشوند در شبکه اشتراکی محاسبه می‌شود. دستورات Release و Confirm آدرس‌های موقت را نادیده می‌گیرند.

هرگونه آدرس IPv6 که با استفاده از fixed-address6 به میزبان‌ها اختصاص یافته باشد، و همچنین آدرس‌های IPv6 موجود روی خود سرور، از range6 مستثنی می‌شوند.

دستور prefix6

prefix6 low-address high-address / bits;

دستور prefix6 معادل range6 برای تفویض پیشوند (Prefix Delegation - RFC 3633) است. پیشوندهایی با طول bits در فاصله بین low-address و high-address تخصیص می‌یابند.

هرگونه پیشوند IPv6 که با fixed-prefix6 به مدخل‌های ایستا (میزبان‌ها) داده شده باشد، از prefix6 مستثنی می‌شود.

این دستور در حال حاضر سراسری (global) است، اما باید دارای حوزه شبکه اشتراکی (shared-network scope) باشد.

دستور host

host hostname {
  [ parameters ]
  [ declarations ]
}

اعلان host روشی را برای سرور DHCP فراهم می‌کند تا یک کلاینت DHCP یا BOOTP را شناسایی کند. این قابلیت به سرور امکان می‌دهد تا اطلاعات پیکربندی شامل آدرس‌های ثابت یا در DHCPv6، پیشوندهای ثابت را برای یک کلاینت مشخص فراهم آورد.

اگر مطلوب باشد که یک کلاینت DHCP یا BOOTP بتواند در بیش از یک زیرشبکه با آدرس‌های ثابت v4 راه‌اندازی (بوت) شود، می‌توان بیش از یک آدرس را در اعلان fixed-address مشخص کرد، یا بیش از یک دستور host را متناظر با همان کلاینت تعیین نمود.

اعلان fixed-address6 برای آدرس‌های v6 استفاده می‌شود. در حال حاضر این اعلان تنها با یک آدرس منفرد کار می‌کند. برای چندین آدرس، چندین دستور host را مشخص کنید.

اگر پارامترهای راه‌اندازی اختصاصی کلاینت باید بر اساس شبکه‌ای که کلاینت به آن متصل است تغییر کنند، باید از چندین اعلان host استفاده شود. اعلان‌های host تنها در صورتی با یک کلاینت تطبیق داده می‌شوند که یکی از دستورات fixed-address آن‌ها روی زیرشبکه (یا شبکه اشتراکی) که کلاینت به آن متصل است قابل استفاده باشد. در مقابل، برای اینکه یک اعلان host با کلاینتی که در حال دریافت یک آدرس پویا است تطبیق یابد، نباید هیچ‌گونه دستور fixed-address داشته باشد. بنابراین ممکن است برای هر کلاینت مفروض به ترکیبی از اعلان‌های host نیاز داشته باشید... برخی دارای دستورات fixed-address و برخی دیگر بدون آن.

مقدار hostname باید نامی باشد که میزبان را شناسایی می‌کند. اگر گزینه hostname برای میزبان تعیین نشده باشد، از hostname استفاده می‌شود.

اعلان‌های Host با کلاینت‌های واقعی DHCP یا BOOTP از طریق تطبیق گزینه dhcp-client-identifier مشخص‌شده در اعلان host با شناسه ارائه‌شده توسط کلاینت تطبیق داده می‌شوند؛ یا اگر اعلان host یا کلاینت گزینه dhcp-client-identifier را ارائه ندهد، از طریق تطبیق پارامتر hardware در اعلان host با آدرس سخت‌افزاری شبکه (MAC) ارائه‌شده توسط کلاینت تطبیق می‌یابند. کلاینت‌های BOOTP به طور معمول گزینه dhcp-client-identifier را ارائه نمی‌دهند، بنابراین آدرس سخت‌افزاری باید برای تمام کلاینت‌هایی که ممکن است با پروتکل BOOTP بوت شوند، استفاده شود.

سرورهای DHCPv6 می‌توانند از پارامتر host-identifier option در اعلان host استفاده کرده و هر گزینه‌ای با مقدار ثابت را برای شناسایی میزبان‌ها تعیین کنند.

لطفاً توجه داشته باشید که تنها گزینه dhcp-client-identifier و آدرس سخت‌افزاری می‌توانند برای تطبیق یک اعلان میزبان استفاده شوند، یا پارامتر host-identifier option برای سرورهای DHCPv6. برای مثال، تطبیق دادن یک اعلان میزبان با گزینه host-name امکان‌پذیر نیست. علت این است که یکتا بودن گزینه host-name را برای هر کلاینت معین نمی‌توان تضمین کرد، در حالی که هم آدرس سخت‌افزاری و هم گزینه dhcp-client-identifier حداقل از نظر تئوری برای یک کلاینت معین تضمین‌شده هستند که یکتا باشند.

دستور group

group {
  [ parameters ]
  [ declarations ]
}

دستور group صرفاً برای اعمال یک یا چند پارامتر بر روی گروهی از اعلان‌ها به کار می‌رود. از آن می‌توان برای گروه‌بندی میزبان‌ها، شبکه‌های اشتراکی، زیرشبکه‌ها یا حتی سایر گروه‌ها استفاده کرد.

مرجع: ALLOW و DENY (REFERENCE: ALLOW AND DENY)

دستورات allow و deny می‌توانند برای کنترل پاسخ سرور DHCP به انواع مختلف درخواست‌ها استفاده شوند. کلمات کلیدی allow و deny بسته به زمینه کاربرد، در واقع معانی متفاوتی دارند. در زمینه یک استخر (pool)، این کلمات کلیدی را می‌توان برای ایجاد فهرست‌های کنترل دسترسی برای استخرهای تخصیص آدرس به کار برد. در سایر زمینه‌ها، این کلمات کلیدی صرفاً رفتار کلی سرور را در قبال کلاینت‌ها بر اساس حوزه (scope) کنترل می‌کنند. در زمینه‌های خارج از استخر، کلمه کلیدی ignore می‌تواند به جای کلمه کلیدی deny استفاده شود تا از ثبت گزارش (لاگ) درخواست‌های ردشده جلوگیری کند.

استفاده از ALLOW ،DENY و IGNORE در حوزه‌ها (ALLOW DENY AND IGNORE IN SCOPE)

کاربردهای زیر از allow و deny در هر حوزه‌ای کار خواهند کرد، اگرچه توصیه نمی‌شود که در اعلان‌های استخر استفاده شوند.

کلمه کلیدی unknown-clients

allow unknown-clients;
deny unknown-clients;
ignore unknown-clients;

فلگ unknown-clients برای تعیین این موضوع به dhcpd استفاده می‌شود که آیا آدرس‌ها را به طور پویا به کلاینت‌های ناشناخته اختصاص دهد یا خیر. تخصیص پویای آدرس به کلاینت‌های ناشناخته به طور پیش‌فرض مجاز (allow) است. کلاینت ناشناخته صرفاً کلاینتی است که هیچ اعلان میزبان (host declaration) ندارد.

استفاده از این گزینه اکنون منسوخ (deprecated) شده است. اگر سعی دارید دسترسی در شبکه خود را به کلاینت‌های شناخته‌شده محدود کنید، باید از deny unknown-clients; در داخل استخر آدرس خود استفاده کنید، همان‌طور که زیر عنوان «استفاده از ALLOW و DENY در اعلان‌های استخر» شرح داده شده است.

کلمه کلیدی bootp

allow bootp;
deny bootp;
ignore bootp;

فلگ bootp برای اعلام به dhcpd به کار می‌رود که آیا به پرس‌وجوهای bootp پاسخ دهد یا خیر. پرس‌وجوهای Bootp به طور پیش‌فرض مجاز (allow) هستند.

کلمه کلیدی booting

allow booting;
deny booting;
ignore booting;

فلگ booting برای اعلام به dhcpd به کار می‌رود که آیا به پرس‌وجوهای یک کلاینت خاص پاسخ دهد یا خیر. این کلمه کلیدی تنها زمانی معنا دارد که در یک اعلان میزبان ظاهر شود. به طور پیش‌فرض، بوت شدن مجاز (allow) است، اما اگر برای یک کلاینت خاص غیرفعال شود، آن کلاینت قادر به دریافت آدرس از سرور DHCP نخواهد بود.

کلمه کلیدی duplicates

allow duplicates;
deny duplicates;

اعلان‌های میزبان می‌توانند پیام‌های کلاینت را بر اساس گزینه «شناسه کلاینت DHCP» (DHCP Client Identifier) یا بر اساس نوع سخت‌افزار شبکه و آدرس MAC کلاینت مطابقت دهند. اگر از آدرس MAC استفاده شود، اعلان میزبان با هر کلاینتی که دارای آن آدرس MAC باشد مطابقت خواهد داشت - حتی کلاینت‌هایی با شناسه‌های کلاینت متفاوت. این حالت معمولاً رخ نمی‌دهد، اما زمانی ممکن است پیش بیاید که روی یک رایانه بیش از یک سیستم‌عامل نصب شده باشد - به عنوان مثال، مایکروسافت ویندوز و نت‌بی‌اس‌دی یا لینوکس.

فلگ duplicates به سرور DHCP اعلام می‌کند که اگر درخواستی از کلاینتی دریافت شود که با آدرس MAC یک اعلان میزبان مطابقت دارد، هرگونه اجاره دیگر متناظر با آن آدرس MAC باید توسط سرور دور انداخته شود، حتی اگر UID یکسان نباشد. این کار نقض پروتکل DHCP به شمار می‌آید، اما می‌تواند از اینکه کلاینت‌هایی که شناسه‌های کلاینت آن‌ها به طور منظم تغییر می‌کند چندین اجاره را به طور هم‌زمان نگه دارند، جلوگیری کند. به طور پیش‌فرض، موارد تکراری مجاز (allow) هستند.

کلمه کلیدی declines

allow declines;
deny declines;
ignore declines;

پیام DHCPDECLINE توسط کلاینت‌های DHCP برای نشان دادن این موضوع استفاده می‌شود که اجاره پیشنهادی سرور معتبر نیست. هنگامی که سرور یک DHCPDECLINE برای یک آدرس خاص دریافت می‌کند، به طور معمول آن آدرس را به فرض اینکه سامانه‌ای غیرمجاز در حال استفاده از آن است، رها (abandon) می‌کند. متأسفانه یک کلاینت مخرب یا دارای اشکال (buggy) می‌تواند با استفاده از پیام‌های DHCPDECLINE، استخر تخصیص سرور DHCP را کاملاً تخلیه کند. سرور در نهایت این اجاره‌ها را بازپس خواهد گرفت، اما نه در زمانی که کلاینت در حال مصرف سریع موجودی استخر است. این امر ممکن است باعث کوبش شدید (thrashing) در DNS شود، و همچنین سبب خواهد شد که سرور DHCP تخصیص آدرس‌های قبلی کلاینت‌های DHCP را فراموش کند.

فلگ declines به سرور DHCP اعلام می‌کند که آیا به پیام‌های DHCPDECLINE ترتیب اثر دهد یا خیر. اگر در یک حوزه مشخص روی deny یا ignore تنظیم شود، سرور DHCP به پیام‌های DHCPDECLINE پاسخ نخواهد داد.

فلگ declines تنها توسط سرورهای DHCPv4 پشتیبانی می‌شود. با توجه به فضای آدرس‌دهی وسیع IPv6 و محدودیت‌های داخلی اعمال‌شده توسط سازوکار تولید آدرس سرور، ما در حال حاضر وجود آن را برای سرورهای DHCPv6 ضروری نمی‌دانیم.

در حال حاضر، آدرس‌های رهاشدهٔ IPv6 به یکی از دو روش زیر بازپس‌گیری می‌شوند:
الف) کلاینت یک آدرس مشخص را تمدید کند:
اگر کلاینتی با یک DUID مشخص، یک درخواست DHCP REQUEST شامل آخرین
آدرس رهاشده توسط آن DUID ارسال کند، آدرس دوباره به همان کلاینت
تخصیص داده خواهد شد.

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

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

"Best match for DUID <XX> is an abandoned address, This may be a
result of multiple clients attempting to use this DUID"

که در آن <XX> مقدار واقعی DUID است که به صورت رشته‌ای از بایت‌ها با مقادیر هگزادسیمال و جداشده با دونقطه نشان داده شده است.

کلمه کلیدی client-updates

allow client-updates;
deny client-updates;

فلگ client-updates به سرور DHCP اعلام می‌کند که آیا تمایل کلاینت را برای انجام به‌روزرسانی مستقیم رکورد A خودش محترم بشمارد یا خیر. برای جزئیات، مستندات زیر عنوان «طرح به‌روزرسانی DNS» (THE DNS UPDATE SCHEME) را ببینید.

کلمه کلیدی leasequery

allow leasequery;
deny leasequery;

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

استفاده از ALLOW و DENY در اعلان‌های استخر (ALLOW AND DENY WITHIN POOL DECLARATIONS)

کاربردهای کلمات کلیدی allow و deny که در بخش قبل نشان داده شد، کم‌وبیش به همان شکل عمل می‌کنند، چه کلاینت در حال ارسال پیام DHCPDISCOVER باشد و چه پیام DHCPREQUEST - آدرسی به کلاینت تخصیص خواهد یافت (یا همان آدرس قبلی که درخواست کرده، یا یک آدرس جدید) و سپس آن آدرس آزمایش می‌شود تا بررسی شود آیا سپردن آن به کلاینت مجاز است یا خیر. اگر کلاینت آن را درخواست کرده باشد و مجاز نباشد، سرور یک پیام DHCPNAK ارسال می‌کند. در غیر این صورت، سرور صرفاً پاسخی به کلاینت نخواهد داد. اگر دادن آدرس به کلاینت مجاز باشد، سرور یک پیام DHCPACK ارسال خواهد کرد.

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

هنگامی که یک پیام DHCPREQUEST پردازش می‌شود، تخصیص آدرس صرفاً شامل جستجوی آدرسی است که کلاینت درخواست کرده و بررسی اینکه آیا آن آدرس همچنان برای کلاینت در دسترس است یا خیر. در صورتی که در دسترس باشد، سرور DHCP هم فهرست‌های مجاز (permit lists) استخر آدرس و هم دستورات allow و deny مرتبط در درون حوزه را بررسی می‌کند تا مطمئن شود سپردن اجاره به کلاینت بلامانع است. در مورد پیام DHCPDISCOVER، فرآیند تخصیص همان‌گونه که قبلاً در بخش «تخصیص آدرس» (ADDRESS ALLOCATION) توضیح داده شد انجام می‌شود.

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

known-clients;

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

unknown-clients;

در صورت تعیین، این دستور تخصیص از این استخر را به هر کلاینتی که هیچ اعلان میزبانی نداشته باشد (یعنی ناشناخته باشد) مجاز یا ممنوع می‌کند.

members of "class";

در صورت تعیین، این دستور تخصیص از این استخر را به هر کلاینتی که عضو کلاس نام‌برده باشد مجاز یا ممنوع می‌کند.

dynamic bootp clients;

در صورت تعیین، این دستور تخصیص از این استخر را به هر کلاینت bootp مجاز یا ممنوع می‌کند.

authenticated clients;

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

unauthenticated clients;

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

all clients;

در صورت تعیین، این دستور تخصیص از این استخر را به تمام کلاینت‌ها مجاز یا ممنوع می‌کند. از این دستور می‌توان زمانی استفاده کرد که بخواهید به دلیلی یک اعلان استخر بنویسید اما آن را به صورت ذخیره نگه دارید، یا هنگامی که قصد دارید شبکه خود را به سرعت شماره‌گذاری مجدد (renumber) کنید، و بنابراین می‌خواهید سرور تمام کلاینت‌هایی را که از این استخر به آن‌ها آدرس تخصیص داده شده است، وادار کند که در نوبت بعدی تمدید، فوراً آدرس‌های جدیدی دریافت کنند.

after time;

در صورت تعیین، این دستور تخصیص از این استخر را پس از یک تاریخ مشخص مجاز یا ممنوع می‌کند. از این دستور می‌توان زمانی استفاده کرد که می‌خواهید کلاینت‌ها را از یک استخر به استخر دیگری منتقل کنید. سرور زمان معمول اجاره را به گونه‌ای تنظیم می‌کند که آخرین زمان انقضا در تاریخ مشخص‌شده + min-lease-time باشد. یک مقدار کوتاه برای min-lease-time باعث اعمال یکباره تغییرات می‌شود، در حالی که مقدار طولانی‌تر min-lease-time امکان تغییر تدریجی را فراهم می‌آورد. مقدار time یا بر حسب ثانیه از مبدأ زمان یونیکس (epoch) است، یا یک رشته زمانی UTC مانند: 4 2007/08/24 09:14:32 یا رشته‌ای با افست منطقه زمانی بر حسب ثانیه مانند: 4 2007/08/24 11:14:32 -7200

مرجع: پارامترها (REFERENCE: PARAMETERS)

دستور abandon-lease-time

دستور adaptive-lease-time-threshold

دستور always-broadcast

دستور always-reply-rfc1048

دستور authoritative

دستور boot-unknown-clients

دستور check-secs-byte-order

1. مقدار dhcp-cache-threshold بزرگ‌تر از صفر باشد
2. اجاره‌نامه فعلی فعال باشد
3. درصد سپری‌شده از مدت‌زمان اجاره کمتر از dhcp-cache-threshold باشد
4. اطلاعات کلاینت ارائه‌شده در تمدید، هیچ‌یک از موارد زیر را تغییر ندهد:
   a. اطلاعات DNS و فعال بودن به‌روزرسانی‌های DNS
   b. کلاس صورت‌حساب که اجاره با آن مرتبط است (فقط IPv4)
   c. اعلان میزبان مرتبط با اجاره (فقط IPv4)
   d. شناسه کلاینت - این اتفاق ممکن است زمانی رخ دهد که کلاینت بدون
      شناسه کلاینت بوت شود و سپس در درخواست‌های بعدی شروع به استفاده از آن کند. (فقط IPv4)

local7.debug /var/log/dhcpd.log

subnet 3000::/64 {
	# pool A
	pool6 {
		:
	}
	# pool B
	pool6 {
		:
	}
	# pool C
	pool6 {
		:
	}
}

    group {
      use-host-decl-names on;
      host joe {
        hardware ethernet 08:00:2b:4c:29:32;
        fixed-address joe.example.com;
      }
    }
معادل است با:
      host joe {
        hardware ethernet 08:00:2b:4c:29:32;
        fixed-address joe.example.com;
        option host-name "joe";
      }

تنظیم مقادیر پارامترها با استفاده از عبارات (SETTING PARAMETER VALUES USING EXPRESSIONS)

گاهی اوقات تنظیم مقدار یک پارامتر سرور DHCP بر مبنای مقداری که توسط کلاینت ارسال شده است مفید می‌باشد. برای این کار می‌توانید از ارزیابی عبارات استفاده کنید. صفحه راهنمای dhcp-eval(5) نحوه نوشتن عبارات را توصیف می‌کند. برای انتساب نتیجه یک ارزیابی به یک پارامتر، آن را به شکل زیر تعریف نمایید:

my-parameter = expression ;

برای نمونه:

ddns-hostname = binary-to-ascii (16, 8, "-",
                                 substring (hardware, 1, 6));

اجاره‌های رزروشده (RESERVED LEASES)

اغلب سودمند است که یک نشانی منفرد را به صورت تقریباً همیشگی به یک کلاینت اختصاص داد. دستورات host همراه با بندهای fixed-address تا حدودی به همین منظور وجود دارند، اما از آنجا که هدف از دستورات host نزدیک شدن به یک «پیکربندی ایستا» است، از این نقص رنج می‌برند که در سلسله‌ای از دیگر سرویس‌های سرور، نظیر DNS پویا، failover، «رویدادهای on» و غیره مورد ارجاع واقع نمی‌شوند.

اگر یک اجاره پویای استاندارد، مانند آنچه از هر دستور range حاصل می‌شود، با برچسب «reserved» (رزروشده) علامت‌گذاری شود، سرور این اجاره را تنها به کلاینتی که با آن مشخص شده است (خواه با شناسه کلاینت یا نشانی سخت‌افزاری) تخصیص خواهد داد.

در عمل، این بدان معناست که اجاره از ماشین وضعیت عادی پیروی می‌کند، زمانی که کلاینت به آن متصل می‌شود وارد وضعیت ACTIVE می‌گردد، منقضی می‌شود یا آزاد می‌گردد، و هر رویداد یا سرویسی که به طور معمول در طول این رویدادها ارائه می‌شود مانند سایر اجاره‌های پویا به طور عادی پردازش می‌گردد. تنها تفاوت این است که سرورهای failover با اجاره‌های رزروشده هنگام ورود به وضعیت‌های FREE یا BACKUP رفتار خاصی دارند - هر سرور اجاره را در وضعیتی اعمال می‌کند که مجاز به تخصیص از آن باشد - و این اجاره‌ها در صف تخصیص به سایر کلاینت‌ها قرار نمی‌گیرند. در عوض آن‌ها تنها از طریق هویت کلاینت قابل «یافتن» هستند. در نتیجه، اجاره منحصراً به کلاینت بازگشتی پیشنهاد داده می‌شود.

احتمالاً باید مراقبت شود تا اطمینان حاصل گردد که کلاینت در یک زیرشبکه مشخص تنها دارای یک اجاره است که با آن شناسایی می‌شود.

اجاره‌ها می‌توانند از طریق OMAPI یا از طریق گزینه پیکربندی «infinite-is-reserved» (در صورتی که با محیط و ترکیب کلاینت‌های شما تناسب داشته باشد) به صورت «reserved» تنظیم گردند.

همچنین باید متذکر شد که با اجاره‌های دارای برچسب «reserved» عملاً مشابه اجاره‌های دارای علامت «bootp» رفتار می‌شود.

مرجع: دستورات OPTION (REFERENCE: OPTION STATEMENTS)

دستورات گزینه DHCP در صفحه راهنمای dhcp-options(5) مستند شده‌اند.

مرجع: عبارات (REFERENCE: EXPRESSIONS)

عبارات مورد استفاده در دستورات گزینه DHCP و سایر نقاط در صفحه راهنمای dhcp-eval(5) مستند شده‌اند.

همچنین ببینید (SEE ALSO)

dhcpd(8), dhcpd.leases(5), dhcp-options(5), dhcp-eval(5), RFC2132, RFC2131.

نویسندگان (AUTHORS)

dhcpd.conf(5) توسط ISC نگهداری می‌شود. اطلاعات درباره Internet Systems Consortium را می‌توانید در https://www.isc.org بیابید.