.\" dhcpd.conf.5 .\" .\" Copyright (C) 2004-2022 Internet Systems Consortium, Inc. ("ISC") .\" Copyright (c) 1996-2003 by Internet Software Consortium .\" .\" This Source Code Form is subject to the terms of the Mozilla Public .\" License, v. 2.0. If a copy of the MPL was not distributed with this .\" file, You can obtain one at http://mozilla.org/MPL/2.0 .\" .\" THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES .\" WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF .\" MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR .\" ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES .\" WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN .\" ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT .\" OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. .\" .\" Internet Systems Consortium, Inc. .\" PO Box 360 .\" Newmarket, NH 03857 USA .\" .\" https://www.isc.org .\" .\" This software has been written for Internet Systems Consortium .\" by Ted Lemon in cooperation with Vixie Enterprises and Nominum, Inc. .\" .\" Support and other services are available for ISC products - see .\" https://www.isc.org for more information or to learn more about ISC. .\" .\" $Id: dhcpd.conf.5,v 1.114 2012/04/02 22:47:35 sar Exp $ .\" .TH dhcpd.conf 5 .SH "نام (NAME)" dhcpd.conf \- پیکربندی سرویس‌دهنده dhcpd .SH "توضیحات (DESCRIPTION)" فایل dhcpd.conf حاوی اطلاعات پیکربندی برای .IR dhcpd ، سرور DHCP کنسرسیوم سیستم‌های اینترنتی (ISC) است. .PP فایل dhcpd.conf یک فایل متنی اَسکی (ASCII) با قالب آزاد است. این فایل توسط تجزیه‌کنندهٔ بازگشتی-نزولی تعبیه‌شده در dhcpd پردازش می‌شود. این فایل ممکن است برای اهداف قالب‌بندی و خوانایی، حاوی فاصله‌گذاری‌ها (Tab) و خطوط خالی اضافی باشد. کلمات کلیدی در این فایل به بزرگی و کوچکی حروف حساس نیستند. توضیحات (کامنت‌ها) می‌توانند در هر کجای فایل (به‌جز درون نقل‌قول‌ها) قرار گیرند. توضیحات با نویسهٔ # آغاز می‌شوند و در انتهای همان خط پایان می‌یابند. .PP این فایل اساساً از فهرستی از دستورات تشکیل شده است. دستورات به دو دستهٔ کلی تقسیم می‌شوند — پارامترها و اعلانات. .PP دستورات پارامتر یا مشخص می‌کنند که کاری چگونه انجام شود (مثلاً یک اجاره برای چه مدتی ارائه شود)، یا اینکه کاری انجام شود یا خیر (مثلاً آیا dhcpd باید به کلاینت‌های ناشناخته آدرس اختصاص دهد)، یا اینکه چه پارامترهایی باید به کلاینت ارائه گردد (مثلاً استفاده از درگاه 220.177.244.7). .PP از اعلانات برای توصیف توپولوژی شبکه، توصیف کلاینت‌های موجود در شبکه، ارائهٔ آدرس‌هایی که می‌توانند به کلاینت‌ها تخصیص داده شوند، یا اعمال گروهی از پارامترها به مجموعه‌ای از اعلانات استفاده می‌شود. در هر گروه از پارامترها و اعلانات، تمام پارامترها باید پیش از تعریف هرگونه اعلان وابسته به آن‌ها مشخص شوند. .PP اعلانات مربوط به توپولوژی شبکه شامل اعلانات \fIshared-network\fR و \fIsubnet\fR هستند. اگر قرار است به کلاینت‌های یک زیرشبکه به‌صورت پویا آدرس اختصاص داده شود، باید یک اعلان \fIrange\fR درون اعلان \fIsubnet\fR قرار گیرد. برای کلاینت‌هایی با آدرس‌های اختصاص‌یافته به‌صورت ایستا (استاتیک)، یا در راه‌اندازی‌هایی که فقط به کلاینت‌های شناخته‌شده سرویس‌دهی می‌شود، هر یک از این کلاینت‌ها باید دارای یک اعلان \fIhost\fR باشند. اگر قرار است پارامترها به گروهی از اعلانات اعمال شوند که ارتباط آن‌ها صرفاً بر پایهٔ هر زیرشبکه نیست، می‌توان از اعلان \fIgroup\fR استفاده کرد. .PP برای هر زیرشبکه‌ای که به آن سرویس داده خواهد شد، و برای هر زیرشبکه‌ای که سرور DHCP به آن متصل است، باید یک اعلان \fIsubnet\fR وجود داشته باشد که به dhcpd نحوهٔ تشخیص قرار داشتن یک آدرس در آن زیرشبکه را اعلام کند. وجود یک اعلان \fIsubnet\fR برای هر زیرشبکه الزامی است، حتی اگر قرار نباشد هیچ آدرسی به‌صورت پویا در آن زیرشبکه تخصیص یابد. .PP برخی از راه‌اندازی‌ها دارای شبکه‌های فیزیکی هستند که بیش از یک زیرشبکهٔ IP روی آن‌ها کار می‌کند. برای مثال، اگر الزامی در سطح سازمان وجود داشته باشد که از ماسک‌های زیرشبکهٔ ۸ بیتی استفاده شود، اما بخشی با یک شبکهٔ فیزیکی اترنت مجزا آن‌قدر گسترش یابد که بیش از ۲۵۴ گره داشته باشد، ممکن است لازم باشد تا زمان افزودن یک شبکهٔ فیزیکی جدید، دو زیرشبکهٔ ۸ بیتی را روی همان اترنت اجرا کرد. در این حالت، اعلانات \fIsubnet\fR برای این دو شبکه باید درون یک اعلان \fIshared-network\fR قرار گیرند. .PP توجه داشته باشید که حتی در صورت عدم وجود اعلان \fIshared-network\fR، یک اعلان خالی توسط سرور ایجاد می‌شود تا شامل \fIsubnet\fR (و هرگونه پارامتر دارای حوزه که در \fIsubnet\fR گنجانده شده) باشد. از نظر کاربردی، این بدان معناست که کلاینت‌های DHCP «بی‌وضعیت» (stateless) که به آدرس‌ها (و بنابراین به زیرشبکه‌ها) وابسته نیستند، همان پیکربندی را دریافت خواهند کرد که کلاینت‌های باوضعیت (stateful) دریافت می‌کنند. .PP برخی مراکز ممکن است دارای بخش‌هایی باشند که کلاینت‌های آن‌ها روی بیش از یک زیرشبکه قرار دارند، اما مطلوب باشد که به آن کلاینت‌ها مجموعهٔ یکنواختی از پارامترها ارائه شود که با آنچه به کلاینت‌های سایر بخش‌ها در همان زیرشبکه داده می‌شود متفاوت باشد. برای کلاینت‌هایی که به‌طور صریح با اعلانات \fIhost\fR اعلان می‌شوند، این اعلانات را می‌توان همراه با پارامترهای مشترک آن بخش، درون یک اعلان \fIgroup\fR گنجاند. برای کلاینت‌هایی که آدرس‌های آن‌ها به‌صورت پویا تخصیص می‌یابد، می‌توان از اعلانات کلاس و اعلانات شرطی برای گروه‌بندی تخصیص پارامترها بر اساس اطلاعاتی که کلاینت ارسال می‌کند استفاده نمود. .PP هنگامی که قرار است یک کلاینت راه‌اندازی (بوت) شود، پارامترهای بوت آن با بررسی اعلان \fIhost\fR آن کلاینت (در صورت وجود)، سپس بررسی اعلانات \fIclass\fR منطبق با کلاینت، و در ادامه اعلانات \fIpool\fR، \fIsubnet\fR و \fIshared-network\fR برای آدرس IP تخصیص‌یافته به کلاینت تعیین می‌شود. هر یک از این اعلانات درون یک حوزهٔ واژگانی (lexical scope) قرار می‌گیرند، و تمام اعلانات در حوزه‌های واژگانی با عمومیت بیشتر نیز برای اعلانات گزینه‌های کلاینت بررسی می‌شوند. حوزه‌ها هرگز دو بار در نظر گرفته نمی‌شوند، و اگر پارامترها در بیش از یک حوزه اعلان شده باشند، پارامتری که در خاص‌ترین حوزه اعلان شده است استفاده خواهد شد. .PP هنگامی که dhcpd تلاش می‌کند یک اعلان \fIhost\fR برای یک کلاینت بیابد، ابتدا به دنبال یک اعلان \fIhost\fR می‌گردد که دارای یک اعلان \fIfixed-address\fR باشد که آدرس IP معتبری را برای زیرشبکه یا شبکهٔ اشتراکی محل بوت کلاینت مشخص کرده باشد. اگر هیچ مدخلی از این نوع پیدا نکند، تلاش می‌کند مدخلی را بیابد که فاقد اعلان \fIfixed-address\fR باشد. .SH "مثال‌ها (EXAMPLES)" .PP یک فایل معمولی dhcpd.conf چیزی شبیه به این خواهد بود: .nf .I global parameters... subnet 204.254.239.0 netmask 255.255.255.224 { \fIsubnet-specific parameters...\fR range 204.254.239.10 204.254.239.30; } subnet 204.254.239.32 netmask 255.255.255.224 { \fIsubnet-specific parameters...\fR range 204.254.239.42 204.254.239.62; } subnet 204.254.239.64 netmask 255.255.255.224 { \fIsubnet-specific parameters...\fR range 204.254.239.74 204.254.239.94; } group { \fIgroup-specific parameters...\fR host zappo.test.isc.org { \fIhost-specific parameters...\fR } host beppo.test.isc.org { \fIhost-specific parameters...\fR } host harpo.test.isc.org { \fIhost-specific parameters...\fR } } .ce 1 شکل ۱ .fi .PP توجه کنید که در ابتدای فایل، مکانی برای پارامترهای سراسری وجود دارد. این پارامترها ممکن است مواردی مانند نام دامنهٔ سازمان، نشانی‌های سرورهای نام (در صورتی که برای کل سازمان مشترک باشند) و مواردی از این دست باشند. بنابراین، برای مثال: .nf option domain-name "isc.org"; option domain-name-servers ns1.isc.org, ns2.isc.org; .ce 1 شکل ۲ .fi .PP همان‌طور که در شکل ۲ مشاهده می‌کنید، می‌توانید نشانی‌های میزبان را در پارامترها با استفاده از نام‌های دامنهٔ آن‌ها به‌جای نشانی‌های عددی IP مشخص کنید. اگر یک نام میزبان مشخص به بیش از یک نشانی IP تفکیک شود (برای مثال، اگر آن میزبان دو رابط اترنت داشته باشد)، در صورت امکان، هر دو نشانی به کلاینت ارائه می‌شوند. .PP آشکارترین دلیل برای داشتن پارامترهای ویژهٔ زیرشبکه همان‌گونه که در شکل ۱ نشان داده شد، این است که هر زیرشبکه لزوماً روتر (مسیریاب) اختصاصی خود را دارد. بنابراین برای زیرشبکهٔ اول، برای مثال، باید خطی شبیه به این وجود داشته باشد: .nf option routers 204.254.239.1; .fi .PP توجه داشته باشید که نشانی در اینجا به‌صورت عددی تعیین شده است. این کار الزامی نیست — اگر برای هر رابط روی روتر خود نام دامنهٔ متفاوتی دارید، کاملاً مجاز است که از نام دامنه برای آن رابط به‌جای نشانی عددی استفاده کنید. با این وجود، در بسیاری از موارد ممکن است تنها یک نام دامنه برای تمام نشانی‌های IP یک روتر وجود داشته باشد و در این صورت، استفاده از آن نام در اینجا مناسب نخواهد بود. .PP در شکل ۱ همچنین یک دستور \fIgroup\fR وجود دارد که پارامترهای مشترکی را برای مجموعه‌ای از سه میزبان — zappo، beppo و harpo — فراهم می‌کند. همان‌طور که می‌بینید، این میزبان‌ها همگی در دامنهٔ test.isc.org قرار دارند، بنابراین منطقی است که یک پارامتر ویژهٔ گروه، نام دامنهٔ ارائه‌شده به این میزبان‌ها را بازنویسی کند: .nf option domain-name "test.isc.org"; .fi .PP همچنین، با توجه به دامنه‌ای که در آن هستند، این‌ها احتمالاً ماشین‌های آزمایشی می‌باشند. اگر بخواهیم سازوکار اجاره‌دهی DHCP را بیازماییم، ممکن است مهلت انقضای اجاره را کمی کوتاه‌تر از حالت پیش‌فرض تنظیم کنیم: .nf max-lease-time 120; default-lease-time 120; .fi .PP شاید متوجه شده باشید که در حالی که برخی از پارامترها با کلمهٔ کلیدی \fIoption\fR شروع می‌شوند، برخی دیگر این‌گونه نیستند. پارامترهایی که با کلمهٔ کلیدی \fIoption\fR شروع می‌شوند، متناظر با گزینه‌های واقعی DHCP هستند، در حالی که پارامترهایی که با کلمهٔ کلیدی option شروع نمی‌شوند، یا رفتار سرور DHCP را کنترل می‌کنند (مثلاً مدت زمان اجاره‌ای که dhcpd اعطا می‌کند)، یا پارامترهایی از کلاینت را مشخص می‌کنند که در پروتکل DHCP اختیاری نیستند (برای نمونه، server-name و filename). .PP در شکل ۱، هر میزبان دارای پارامترهای ویژهٔ میزبان (\fIhost-specific parameters\fR) بود. این موارد می‌توانند شامل گزینه‌هایی مانند گزینهٔ \fIhostname\fR، نام فایلی برای بارگذاری (پارامتر \fIfilename\fR) و نشانی سروری که فایل باید از آن بارگذاری شود (پارامتر \fInext-server\fR) باشند. به‌طور کلی، هر پارامتری می‌تواند در هر کجایی که پارامترها مجاز هستند درج شود، و بر اساس حوزه‌ای که در آن ظاهر شده است اعمال خواهد شد. .PP تصور کنید سایتی با تعداد زیادی پایانهٔ NCD X-Terminal دارید. این پایانه‌ها در مدل‌های مختلفی عرضه می‌شوند، و شما می‌خواهید فایل‌های بوت را برای هر مدل مشخص کنید. یک راه برای انجام این کار داشتن اعلانات host برای هر سرور و گروه‌بندی آن‌ها بر اساس مدل است: .nf 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; } } .fi .SH "استخرهای آدرس (ADDRESS POOLS)" .PP اعلانات \fBpool\fR و \fBpool6\fR می‌توانند برای تعیین استخری از آدرس‌ها استفاده شوند که حتی روی همان بخش از شبکه یا زیرشبکه، رفتاری متفاوت با استخر دیگری از آدرس‌ها خواهد داشت. برای مثال، ممکن است بخواهید مجموعهٔ بزرگی از آدرس‌ها را برای اختصاص به کلاینت‌های DHCP ثبت‌شده در سرور DHCP خود فراهم کنید، در حالی که مجموعهٔ کوچک‌تری از آدرس‌ها را، احتمالاً با زمان‌های اجارهٔ کوتاه، برای کلاینت‌های ناشناخته در دسترس قرار دهید. اگر فایروال دارید، ممکن است بتوانید ترتیبی دهید که به آدرس‌های یک استخر اجازهٔ دسترسی به اینترنت داده شود، در حالی که آدرس‌های استخر دیگر دسترسی نداشته باشند، و بدین ترتیب کاربران را به ثبت کلاینت‌های DHCP خود تشویق کنید. برای انجام این کار، می‌توانید یک جفت اعلان pool تنظیم کنید: .PP .nf 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; } } .fi .PP همچنین می‌توان زیرشبکه‌های کاملاً متفاوتی را برای کلاینت‌های شناخته‌شده و ناشناخته راه‌اندازی کرد — استخرهای آدرس در سطح شبکه‌های اشتراکی (shared networks) وجود دارند، بنابراین محدوده‌های آدرس درون اعلانات pool می‌توانند در زیرشبکه‌های مختلفی قرار داشته باشند. .PP همان‌طور که در مثال پیشین مشاهده می‌کنید، استخرها می‌توانند دارای فهرست‌های مجوزی باشند که کنترل می‌کند چه کلاینت‌هایی اجازهٔ دسترسی به استخر را دارند و چه کلاینت‌هایی ندارند. هر مدخل در فهرست مجوز یک استخر با کلمهٔ کلیدی .I allow یا \fIdeny\fR معرفی می‌شود. اگر یک استخر دارای فهرست مجاز (permit list) باشد، تنها کلاینت‌هایی که با مدخل‌های خاص در این فهرست مطابقت داشته باشند، واجد شرایط دریافت آدرس از استخر خواهند بود. اگر یک استخر دارای فهرست منع (deny list) باشد، تنها کلاینت‌هایی که با هیچ‌یک از مدخل‌های فهرست منع مطابقت نداشته باشند واجد شرایط خواهند بود. اگر هر دو فهرست مجاز و منع برای یک استخر وجود داشته باشند، تنها به کلاینت‌هایی اجازهٔ دسترسی داده خواهد شد که با فهرست مجاز مطابقت داشته و با فهرست منع مطابقت نداشته باشند. .PP اعلان \fBpool6\fR مشابه اعلان \fBpool\fR است. در حال حاضر این اعلان فقط درون یک اعلان \fBsubnet6\fR مجاز است و ممکن است مستقیماً در اعلان یک شبکهٔ اشتراکی گنجانده نشود. افزون بر دستور \fBrange6\fR، این اعلان امکان گنجاندن دستور \fBprefix6\fR را نیز فراهم می‌کند. شما می‌توانید دستورات \fBrange6\fR را برای هر دو مورد NA و TA و دستورات \fBprefix6\fR را در یک دستور واحد \fBpool6\fR بگنجانید. .SH "تخصیص پویای آدرس (DYNAMIC ADDRESS ALLOCATION)" تخصیص آدرس در عمل تنها زمانی انجام می‌شود که کلاینت در وضعیت INIT باشد و یک پیام DHCPDISCOVER ارسال کرده باشد. اگر کلاینت تصور کند که یک اجارهٔ معتبر دارد و برای شروع یا تمدید آن اجاره یک پیام DHCPREQUEST بفرستد، سرور تنها سه گزینه پیش رو دارد — می‌تواند پیام DHCPREQUEST را نادیده بگیرد، یک DHCPNAK ارسال کند تا به کلاینت بگوید استفاده از آدرس را متوقف کند، یا یک DHCPACK بفرستد و به کلاینت اجازه دهد مدتی دیگر از آن آدرس استفاده نماید. .PP اگر سرور آدرسی را که کلاینت درخواست کرده بیابد و آن آدرس برای کلاینت در دسترس باشد، سرور یک DHCPACK ارسال خواهد کرد. اگر آدرس دیگر در دسترس نباشد، یا کلاینت مجاز به داشتن آن نباشد، سرور یک DHCPNAK ارسال می‌کند. اگر سرور اطلاعی از آن آدرس نداشته باشد، سکوت خواهد کرد، مگر اینکه آدرس برای بخشی از شبکه که کلاینت به آن متصل شده نادرست باشد و سرور برای آن بخش صاحب‌اختیار (authoritative) باشد؛ در این حالت سرور با وجود اینکه اطلاعی از آدرس ندارد، باز هم یک DHCPNAK ارسال خواهد نمود. .PP ممکن است یک اعلان host منطبق با شناسهٔ کلاینت وجود داشته باشد. اگر آن اعلان host شامل یک اعلان fixed-address باشد که آدرس IP معتبری را برای بخشی از شبکه که کلاینت به آن متصل است فهرست کرده باشد، سرور DHCP هرگز تخصیص پویای آدرس را انجام نخواهد داد. در این حالت، کلاینت \fIملزم\fR است آدرس مشخص‌شده در اعلان host را دریافت کند. اگر کلاینت یک DHCPREQUEST برای آدرس دیگری ارسال کند، سرور با یک DHCPNAK پاسخ خواهد داد. .PP هنگامی که سرور DHCP یک آدرس جدید برای کلاینت تخصیص می‌دهد (به یاد داشته باشید این کار فقط زمانی رخ می‌دهد که کلاینت یک DHCPDISCOVER فرستاده باشد)، ابتدا بررسی می‌کند که آیا کلاینت از پیش یک اجارهٔ معتبر روی یک آدرس IP دارد یا خیر، یا اینکه آدرس IP قدیمی‌ای وجود دارد که کلاینت قبلاً داشته و هنوز به دیگری واگذار نشده است. در این حالت، سرور آن آدرس را انتخاب کرده و بررسی می‌کند که آیا کلاینت هنوز مجاز به استفاده از آن است یا خیر. اگر کلاینت دیگر مجاز به استفاده از آن نباشد، در صورتی که سرور تصور می‌کرد اجاره هنوز در حال استفاده است، آن را آزاد می‌کند — ارسال پیام DHCPDISCOVER از سوی کلاینت به سرور ثابت می‌کند که کلاینت دیگر از آن اجاره استفاده نمی‌کند. .PP اگر هیچ اجارهٔ موجودی یافت نشود، یا کلاینت از دریافت اجارهٔ موجود منع شده باشد، سرور در فهرست استخرهای آدرسِ بخشی از شبکه که کلاینت به آن متصل است، به دنبال اجاره‌ای می‌گردد که استفاده‌نشده باشد و کلاینت نیز مجاز به دریافت آن باشد. سرور تک‌تک اعلانات pool را به ترتیب بررسی می‌کند (تمام اعلانات .I range که خارج از اعلانات pool ظاهر می‌شوند در یک استخر منفرد بدون فهرست مجوز گروه‌بندی می‌شوند). اگر فهرست مجوز استخر اجازه دهد که آدرسی از آن استخر به کلاینت تخصیص یابد، استخر بررسی می‌شود تا مشخص گردد آیا آدرس در دسترسی وجود دارد یا خیر. در این صورت، آن آدرس به‌طور موقت به کلاینت اختصاص می‌یابد. در غیر این صورت، استخر بعدی آزموده می‌شود. اگر هیچ آدرسی پیدا نشود که بتوان آن را به کلاینت اختصاص داد، هیچ پاسخی برای کلاینت ارسال نمی‌شود. .PP اگر آدرسی پیدا شود که کلاینت مجاز به داشتن آن باشد، و قبلاً هرگز به هیچ کلاینتی اختصاص نیافته باشد، آن آدرس بلافاصله به کلاینت تخصیص می‌یابد. اگر آدرس برای تخصیص در دسترس باشد ولی قبلاً به کلاینت دیگری اختصاص یافته بوده باشد، سرور به این امید که آدرسی بیابد که قبلاً هرگز به کلاینتی تخصیص داده نشده است، به جستجو ادامه می‌دهد. .PP سرور DHCP فهرست آدرس‌های IP موجود را از یک جدول هش (hash table) تولید می‌کند. این بدان معناست که آدرس‌ها با ترتیب مشخصی مرتب نشده‌اند، و بنابراین پیش‌بینی ترتیبی که سرور DHCP طبق آن آدرس‌های IP را تخصیص می‌دهد ممکن نیست. کاربران نسخه‌های قبلی سرور ISC DHCP ممکن است به این عادت کرده باشند که سرور DHCP آدرس‌های IP را به ترتیب صعودی تخصیص دهد، اما این امر دیگر ممکن نیست و هیچ راهی برای پیکربندی این رفتار در نسخهٔ ۳ سرور ISC DHCP وجود ندارد. .SH "جلوگیری از تداخل آدرس IP (IP ADDRESS CONFLICT PREVENTION)" سرور DHCP قبل از تخصیص آدرس‌های IP به کلاینت‌ها، بررسی می‌کند که آیا آن‌ها در حال استفاده هستند یا خیر. این کار را با ارسال یک پیام درخواست پژواک ICMP (یا همان ICMP Echo request) به آدرس IP در حال تخصیص انجام می‌دهد. اگر در مدت یک ثانیه هیچ پاسخ پژواک ICMP دریافت نشود، فرض بر این گذاشته می‌شود که آدرس آزاد است. این کار تنها برای اجاره‌هایی انجام می‌شود که در دستورات range تعیین شده‌اند، و تنها زمانی که سرور DHCP تصور کند اجاره آزاد است — یعنی سرور DHCP یا همتای پشتیبان گرم (failover peer) آن، اجاره را در حال استفاده فهرست نکرده باشند. .PP اگر پاسخی به درخواست پژواک ICMP دریافت شود، سرور DHCP فرض می‌کند که خطای پیکربندی وجود دارد — آدرس IP توسط میزبانی در شبکه استفاده می‌شود که کلاینت DHCP نیست. سرور این آدرس را به‌عنوان متروکه (abandoned) علامت‌گذاری می‌کند و آن را به کلاینت‌ها اختصاص نخواهد داد. این اجاره حداقل به مدت چند ثانیه که در abandon-lease-time تعیین شده است در وضعیت متروکه باقی خواهد ماند. .PP اگر یک کلاینت DHCP سعی در دریافت یک آدرس IP داشته باشد اما هیچ آدرسی در دسترس نباشد، ولی آدرس‌های IP متروکه وجود داشته باشند، سرور DHCP تلاش می‌کند تا یک آدرس IP متروکه را بازیابی (reclaim) کند. این کار را با علامت‌گذاری یک آدرس IP به‌عنوان آزاد انجام داده و سپس همان بررسی درخواست پژواک ICMP را که پیش‌تر شرح داده شد اجرا می‌کند. اگر پاسخی به درخواست پژواک ICMP داده نشود، آدرس به کلاینت اختصاص می‌یابد. .PP سرور DHCP در صورتی که اولین آدرس IP که تلاش می‌کند بازیابی کند آزاد نباشد، در میان تمام آدرس‌های IP متروکه چرخش نمی‌کند. در عوض، زمانی که DHCPDISCOVER بعدی از سوی کلاینت دریافت شود، تخصیص جدیدی را با همان روش شرح داده شده در اینجا امتحان می‌کند، و معمولاً یک آدرس IP جدید را خواهد آزمود. .SH "توازن و افزونگی دوندگی DHCP (DHCP FAILOVER)" این نسخه از سرور ISC DHCP از پروتکل پشتیبان گرم DHCP (failover) همان‌طور که در پیش‌نویس draft-ietf-dhc-failover-12.txt مستند شده است، پشتیبانی می‌کند. این یک سند نهایی پروتکل نیست، و ما آزمایش‌های هم‌کنش‌پذیری را با پیاده‌سازی‌های این پروتکل توسط سایر ارائه‌دهندگان انجام نداده‌ایم، بنابراین نباید فرض کنید که این پیاده‌سازی با استاندارد مطابقت دارد. اگر مایل به استفاده از پروتکل پشتیبان گرم هستید، اطمینان حاصل کنید که هر دو همتای پشتیبان گرم از نسخهٔ یکسانی از سرور ISC DHCP استفاده می‌کنند. .PP پروتکل پشتیبان گرم به دو سرور DHCP (و نه بیشتر از دو) اجازه می‌دهد تا یک استخر آدرس مشترک را به اشتراک بگذارند. هر سرور در هر زمان مشخص، حدود نیمی از آدرس‌های IP موجود در استخر را برای تخصیص در اختیار خواهد داشت. اگر یکی از سرورها از کار بیفتد، سرور دیگر به تمدید اجاره‌ها از استخر ادامه خواهد داد، و آدرس‌های جدید را از همان حدود نصف آدرس‌های در دسترسی که در هنگام قطع ارتباط با سرور دیگر در اختیار داشت، تخصیص می‌دهد. .PP در زمان یک خرابی طولانی‌مدت، این امکان وجود دارد که به سرور باقی‌مانده اطلاع دهیم که سرور دیگر از کار افتاده است (down)، که در این صورت سرور باقی‌مانده (به مرور زمان) تمام آدرس‌هایی را که سرور دیگر برای تخصیص در اختیار داشت پس گرفته و شروع به استفادهٔ مجدد از آن‌ها می‌کند. به این کار قرار دادن سرور در وضعیت PARTNER-DOWN می‌گویند. .PP شما می‌توانید سرور را یا با استفاده از دستور .B omshell (1) یا با متوقف کردن سرور، ویرایش آخرین اعلان وضعیت پشتیبان گرم در فایل اجاره‌ها (leases file)، و راه‌اندازی مجدد سرور، در وضعیت PARTNER-DOWN قرار دهید. اگر از این روش اخیر استفاده می‌کنید، خط "my state" را به شکل زیر تغییر دهید: .PP .nf .B failover peer "\fIname\fB" state { .B my state partner-down;. .B peer state \fIstate\fB at \fIdate\fB; .B } .fi .PP تنها تغییر دادن "my state" همان‌گونه که در بالا نشان داده شد، الزامی است. .PP هنگامی که سرور دیگر مجدداً بالا بیاید و برخط شود، باید به‌طور خودکار آفلاین بودن خود را تشخیص داده و یک به‌روزرسانی کامل از سروری که در وضعیت PARTNER-DOWN اجرا می‌شد درخواست کند، و سپس هر دو سرور مجدداً پردازش را در کنار هم از سر خواهند گرفت. .PP ممکن است وضعیت خطرناکی رخ دهد: اگر یک سرور را در وضعیت PARTNER-DOWN قرار دهید، و سپس *آن* سرور نیز از کار بیفتد، و سرور دیگر مجدداً بالا بیاید، سرور دیگر مطلع نخواهد بود که سرور اول در وضعیت PARTNER-DOWN قرار داشته است، و ممکن است آدرس‌هایی را که قبلاً توسط سرور دیگر صادر شده بودند به کلاینت‌های مختلفی اختصاص دهد، که در نتیجه منجر به تداخل آدرس‌های IP خواهد شد. بنابراین، پیش از قرار دادن یک سرور در وضعیت PARTNER-DOWN، کاملاً .I مطمئن شوید که سرور دیگر به‌طور خودکار راه‌اندازی مجدد نخواهد شد. .PP پروتکل پشتیبان گرم نقش سرور اصلی (primary) و نقش سرور ثانویه (secondary) را تعریف می‌کند. تفاوت‌هایی در نحوهٔ رفتار سرورهای اصلی و ثانویه وجود دارد، اما بیشتر تفاوت‌ها صرفاً مربوط به ایجاد روشی است تا هر همتا بتواند به شیوهٔ متفاوتی نسبت به دیگری عمل کند. بنابراین یک سرور باید به‌عنوان اصلی و دیگری به‌عنوان ثانویه پیکربندی شود، و چندان تفاوتی نمی‌کند که کدام‌یک کدام باشد. .SH "راه‌اندازی پشتیبان گرم (FAILOVER STARTUP)" هنگامی که سروری راه‌اندازی می‌شود که قبلاً با همتای پشتیبان گرم خود ارتباطی برقرار نکرده است، باید پیش از اینکه بتواند به کلاینت‌ها سرویس‌دهی کند، ارتباط با همتای خود را برقرار کرده و با آن همگام شود. این اتفاق می‌تواند به این دلیل رخ دهد که شما تازه سرورهای DHCP خود را برای نخستین بار برای پشتیبان گرم پیکربندی کرده‌اید، یا به این دلیل که یکی از سرورهای پشتیبان گرم شما دچار خرابی فاجعه‌باری شده و پایگاه داده‌اش را از دست داده است. .PP فرآیند بازیابی اولیه به‌گونه‌ای طراحی شده است که تضمین کند وقتی یکی از همتایان پشتیبان گرم پایگاه داده‌اش را از دست داده و سپس مجدداً همگام‌سازی می‌شود، هرگونه اجاره‌ای که سرور از کار افتاده پیش از خرابی اعطا کرده بود، محترم شمرده خواهد شد. هنگامی که سرور از کار افتاده راه‌اندازی می‌شود، متوجه می‌شود که هیچ وضعیت ذخیره‌شده‌ای از پشتیبان گرم ندارد، و تلاش می‌کند تا با همتای خود تماس برقرار کند. .PP هنگامی که ارتباط برقرار شد، از همتا یک نسخهٔ کامل از پایگاه دادهٔ اجاره‌های آن همتا را درخواست می‌کند. همتا نیز پایگاه دادهٔ کامل خود را ارسال کرده و پیامی می‌فرستد که نشان می‌دهد کار تمام شده است. سرور خراب‌شده سپس تا زمانی که زمان MCLT سپری شود منتظر می‌ماند، و پس از سپری شدن MCLT، هر دو سرور گذار را به کارکرد عادی بازمی‌گردانند. این دورهٔ انتظار تضمین می‌کند هرگونه اجاره‌ای که سرور از کار افتاده در زمان قطع ارتباط با همتای خود ممکن است اعطا کرده باشد، منقضی شده باشد. .PP در حالی که سرور از کار افتاده در حال بازیابی است، شریک آن در وضعیت partner-down باقی می‌ماند، به این معنی که به تمام کلاینت‌ها سرویس‌دهی می‌کند. سرور خراب‌شده تا زمانی که گذار به کارکرد عادی را کامل نکرده باشد، هیچ سرویسی به کلاینت‌های DHCP ارائه نخواهد داد. .PP در صورتی که هر دو سرور تشخیص دهند که هرگز پیش از این با شریک خود ارتباط برقرار نکرده‌اند، هر دوی آن‌ها در این وضعیت بازیابی بالا می‌آیند و روندی را که همین الان شرح دادیم دنبال می‌کنند. در این حالت، تا زمانی که MCLT منقضی نشده باشد، هیچ سرویسی به کلاینت‌های DHCP ارائه نخواهد شد. .SH "پیکربندی پشتیبان گرم (CONFIGURING FAILOVER)" به منظور پیکربندی پشتیبان گرم (failover)، باید اعلان یک همتا (peer declaration) را بنویسید که پروتکل پشتیبان گرم را پیکربندی کند، و همچنین باید ارجاعات به همتا را در هر اعلان استخر (pool declaration) که می‌خواهید برای آن پشتیبان گرم انجام دهید، بنویسید. لازم نیست برای همه استخرهای یک بخش شبکه مشخص، پشتیبان گرم انجام دهید. نباید به یک سرور بگویید که روی یک استخر آدرس خاص پشتیبان گرم انجام می‌دهد و به دیگری بگویید که انجام نمی‌دهد. نباید هیچ استخر آدرس مشترکی داشته باشید که روی آن پشتیبان گرم انجام ندهید. یک اعلان استخر که از پشتیبان گرم استفاده می‌کند، به شکل زیر خواهد بود: .PP .nf pool { failover peer "foo"; \fIpool specific parameters\fR }; .fi .PP سرور در حال حاضر بررسی‌های صحت‌سنجی بسیار کمی انجام می‌دهد، بنابراین اگر آن را اشتباه پیکربندی کنید، به روش‌های عجیبی از کار می‌افتد. از این رو توصیه می‌کنم یا از پشتیبان گرم استفاده کنید یا اصلاً استفاده نکنید، اما استخرهای ترکیبی نسازید. همچنین، از یک فایل پیکربندی اصلی یکسان برای هر دو سرور استفاده کنید و یک فایل جداگانه داشته باشید که شامل اعلان همتا بوده و فایل اصلی را ضمیمه (include) کند. این کار به شما کمک می‌کند تا از عدم تطابق پیکربندی جلوگیری نمایید. با تکامل پیاده‌سازی ما، این مسئله کمتر مشکل‌ساز خواهد شد. یک نمونه فایل ساده dhcpd.conf برای یک سرور اصلی (primary) ممکن است به شکل زیر باشد: .PP .nf 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"; .fi .PP دستورات موجود در اعلان همتا به شرح زیر است: .PP دستورات .I primary و .I secondary .RS 0.25i .PP [ \fBprimary\fR | \fBsecondary\fR ]\fB;\fR .PP این دستور مشخص می‌کند که سرور اصلی (primary) است یا ثانویه (secondary)، همان‌طور که پیش‌تر در بخش DHCP FAILOVER توضیح داده شد. .RE .PP دستور .I address .RS 0.25i .PP .B address \fIaddress\fR\fB;\fR .PP دستور \fBaddress\fR آدرس IP یا نام DNS را مشخص می‌کند که سرور باید برای اتصالات از سوی همتای پشتیبان گرم خود روی آن گوش فرادهد، و همچنین مقداری که باید برای شناسه سرور در پروتکل پشتیبان گرم DHCP استفاده شود. از آنجا که این مقدار به عنوان شناسه استفاده می‌شود، نمی‌توان آن را حذف کرد. .RE .PP دستور .I peer address .RS 0.25i .PP .B peer address \fIaddress\fR\fB;\fR .PP دستور \fBpeer address\fR آدرس IP یا نام DNS را مشخص می‌کند که سرور باید برای ارسال پیام‌های پشتیبان گرم، جهت دسترسی به همتای پشتیبان گرم خود به آن متصل شود. .RE .PP دستور .I port .RS 0.25i .PP .B port \fIport-number\fR\fB;\fR .PP دستور \fBport\fR پورت TCP را تعیین می‌کند که سرور باید برای اتصالات از جانب همتای پشتیبان گرم خود به آن گوش دهد. این دستور می‌تواند حذف شود که در این صورت به طور پیش‌فرض از پورت ۶۴۷ اختصاص‌یافته توسط IANA استفاده خواهد شد. .RE .PP دستور .I peer port .RS 0.25i .PP .B peer port \fIport-number\fR\fB;\fR .PP دستور \fBpeer port\fR پورت TCP را تعیین می‌کند که سرور باید برای ارسال پیام‌های پشتیبان گرم جهت ارتباط با همتای خود به آن متصل گردد. این دستور می‌تواند حذف شود که در این صورت به طور پیش‌فرض از پورت ۶۴۷ اختصاص‌یافته توسط IANA استفاده خواهد شد. .RE .PP دستور .I max-response-delay .RS 0.25i .PP .B max-response-delay \fIseconds\fR\fB;\fR .PP دستور \fBmax-response-delay\fR به سرور DHCP می‌گوید چند ثانیه می‌تواند بدون دریافت پیام از همتای پشتیبان گرم سپری شود قبل از آنکه فرض کند اتصال قطع شده است. این عدد باید آن‌قدر کوچک باشد که یک اختلال گذرا در شبکه که اتصال را قطع می‌کند منجر به قطع ارتباط سرورها برای مدت طولانی نشود، اما آن‌قدر بزرگ باشد که سرور مدام در حال برقراری و قطع اتصالات نباشد. مشخص کردن این پارامتر الزامی است. .RE .PP دستور .I max-unacked-updates .RS 0.25i .PP .B max-unacked-updates \fIcount\fR\fB;\fR .PP دستور \fBmax-unacked-updates\fR به سرور DHCP راه دور می‌گوید پیش از دریافت یک BNDACK از سیستم محلی، چه تعداد پیام BNDUPD می‌تواند ارسال کند. ما تجربه عملیاتی کافی برای بیان اینکه چه مقداری برای آن مناسب است نداریم، اما به نظر می‌رسد مقدار ۱۰ کارآمد باشد. مشخص کردن این پارامتر الزامی است. .RE .PP دستور .I mclt .RS 0.25i .PP .B mclt \fIseconds\fR\fB;\fR .PP دستور \fBmclt\fR مقدار Maximum Client Lead Time را تعریف می‌کند. این پارامتر باید روی سرور اصلی تعیین شود و نباید روی سرور ثانویه مشخص گردد. این مدت زمانی است که یک اجاره (lease) می‌تواند توسط هر یک از همتاهای پشتیبان گرم بدون تماس با دیگری تمدید شود. هر چه این مقدار طولانی‌تر تنظیم شود، زمان بیشتری طول می‌کشد تا سرور در حال اجرا بتواند پس از انتقال به وضعیت PARTNER-DOWN آدرس‌های IP را بازیابی کند. هر چه کوتاه‌تر تنظیم شود، سرورهای شما در زمانی که ارتباطشان قطع است بار کاری بیشتری را متحمل خواهند شد. مقداری در حدود ۳۶۰۰ احتمالاً معقول است، اما مجدداً به یاد داشته باشید که ما هیچ تجربه عملیاتی واقعی با آن نداریم. .RE .PP دستور .I split .RS 0.25i .PP .B split \fIbits\fR\fB;\fR .PP دستور split تقسیم‌بندی بین سرور اصلی و ثانویه را به منظور توزیع بار (load balancing) مشخص می‌کند. هر زمان که یک کلاینت یک درخواست DHCP ارسال می‌کند، سرور DHCP یک تابع درهم‌سازی (hash) روی شناسه کلاینت اجرا می‌کند که به مقداری بین ۰ تا ۲۵۵ می‌انجامد. این مقدار به عنوان یک اندیس در یک فیلد ۲۵۶ بیتی استفاده می‌شود. اگر بیت در آن اندیس یک (set) باشد، سرور اصلی مسئول است. اگر بیت در آن اندیس یک نباشد، سرور ثانویه مسئول است. مقدار \fBsplit\fR تعیین می‌کند که چه تعداد از بیت‌های ابتدایی برابر یک باشند. بنابراین، در عمل، مقادیر بالاتر split باعث می‌شود سرور اصلی به کلاینت‌های بیشتری نسبت به سرور ثانویه پاسخ دهد و مقادیر پایین‌تر عکس این عمل می‌کنند. مقادیر مجاز بین ۰ تا ۲۵۶ (شامل هر دو) هستند که معقول‌ترین آنها ۱۲۸ است. توجه داشته باشید که مقدار ۰ سرور ثانویه را مسئول تمام کلاینت‌ها می‌کند و مقدار ۲۵۶ سرور اصلی را مسئول تمام کلاینت‌ها می‌سازد. .RE .PP دستور .I hba .RS 0.25i .PP .B hba \fIcolon-separated-hex-list\fB;\fR .PP دستور hba تقسیم‌بندی بین سرور اصلی و ثانویه را به جای یک حد آستانه (cutoff)، به صورت یک نقشه بیتی (bitmap) تعیین می‌کند که از نظر تئوری امکان کنترل دقیق‌تری را فراهم می‌سازد. با این حال، در عمل احتمالاً نیازی به چنین کنترل دقیقی وجود ندارد. یک نمونه دستور hba: .PP .nf 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; .fi .PP این معادل دستور \fBsplit 128;\fR و کاملاً یکسان با آن است. دو مثال زیر نیز معادل یک \fBsplit\fR با مقدار ۱۲۸ هستند، اما یکسان نیستند: .PP .nf 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; .fi .PP آن‌ها معادلند، زیرا نیمی از بیت‌ها ۰ و نیمی ۱ تنظیم شده‌اند (0xa و 0x5 به ترتیب در مبنای دو معادل ۱۰۱۰ و ۰۱۰۱ هستند) و در نتیجه کلاینت‌ها را تقریباً به طور مساوی بین سرورها تقسیم می‌کنند. آن‌ها یکسان نیستند، زیرا کلاینت‌های واقعی که تحت توزیع بار به هر سرور هدایت می‌شوند در هر مثال متفاوت خواهند بود. .PP شما باید فقط یکی از دستورات \fBsplit\fR یا \fBhba\fR را تعریف کنید، و هرگز نباید هر دو را داشته باشید. برای اکثر موارد، کنترل دقیقی که \fBhba\fR ارائه می‌دهد ضروری نیست و باید از \fBsplit\fR استفاده شود. .RE .PP دستور .I load balance max seconds .RS 0.25i .PP .B load balance max seconds \fIseconds\fR\fB;\fR .PP این دستور به شما امکان می‌دهد یک حد آستانه پیکربندی کنید که پس از آن توزیع بار غیرفعال می‌شود. این آستانه بر اساس تعداد ثانیه‌های سپری‌شده از زمان ارسال اولین پیام DHCPDISCOVER یا DHCPREQUEST توسط کلاینت است، و تنها با کلاینت‌هایی کار می‌کند که فیلد \fIsecs\fR را به درستی پیاده‌سازی کرده باشند — خوشبختانه اکثر کلاینت‌ها این کار را انجام می‌دهند. ما توصیه می‌کنیم این مقدار را روی عددی مانند ۳ یا ۵ تنظیم کنید. تأثیر این تنظیم آن است که اگر یکی از همتاهای پشتیبان گرم در وضعیتی قرار گیرد که به پیام‌های پشتیبان گرم پاسخ می‌دهد اما به برخی درخواست‌های کلاینت‌ها پاسخ نمی‌دهد، همتای دیگر هم‌زمان با تلاش مجدد کلاینت‌ها، بار مشتریان آن را به طور خودکار بر عهده می‌گیرد. .PP با تنظیم این مقدار روی ۰ در هر دو همتا، می‌توان توزیع بار بین همتاها را غیرفعال کرد. به خاطر داشته باشید که این به معنای آن است که هر دو همتا به تمامی پیام‌های DHCPDISCOVER یا DHCPREQUEST پاسخ خواهند داد. .RE .PP دستور .I auto-partner-down .RS 0.25i .PP .B auto-partner-down \fIseconds\fR\fB;\fR .PP این دستور به سرور فرمان می‌دهد هنگام ورود به وضعیت ارتباط قطع‌شده (communications-interrupted؛ هرگونه شرایط قطع تماس با همتای راه دور پشتیبان گرم) یک تاخیر زمانی را آغاز کند. پس از به پایان رسیدن تایمر، سرور به طور خودکار وارد وضعیت partner-down می‌شود. این امر به سرور اجازه می‌دهد پس از منقضی شدن تایمر STOS+MCLT، اجاره‌ها را از استخر اجاره‌های آزاد شریک (همتا) تخصیص دهد، که در صورتی که شریک در آن زمان در واقع در حال فعالیت باشد می‌تواند خطرناک باشد (دو سرور تخصیص‌های متناقض صادر خواهند کرد). .PP قبل از فعال کردن این ویژگی بسیار با دقت فکر کنید. وضعیت‌های partner-down و communications-interrupted به طور عمدی از یکدیگر تفکیک شده‌اند زیرا شرایطی وجود دارد که در آن یک سرور پشتیبان گرم ممکن است در برقراری ارتباط با همتای خود ناموفق باشد، اما همچنان توانایی دریافت و پاسخگویی به درخواست‌های کلاینت‌های DHCP را داشته باشد. به طور کلی، این ویژگی فقط باید در استقرارهایی استفاده شود که سرورهای پشتیبان گرم مستقیماً به یکدیگر متصل هستند، مانند یک پیوند فیزیکی اختصاصی ("یک کابل تپش قلب"). .PP مقدار صفر ویژگی auto-partner-down را غیرفعال می‌کند (که حالت پیش‌فرض نیز هست)، و هر مقدار مثبت نشان‌دهنده زمان بر حسب ثانیه برای انتظار قبل از ورود خودکار به وضعیت partner-down است. .RE .PP دستورات تعادل استخر پشتیبان گرم (Failover pool balance). .RS 0.25i .PP \fBmax-lease-misbalance \fIpercentage\fR\fB;\fR \fBmax-lease-ownership \fIpercentage\fR\fB;\fR \fBmin-balance \fIseconds\fR\fB;\fR \fBmax-balance \fIseconds\fR\fB;\fR .PP این نسخه از سرور DHCP، تعادل استخر را طبق یک زمان‌بندی ارزیابی می‌کند، نه بر حسب تقاضا در زمان تخصیص اجاره‌ها. رویکرد دوم زمانی که عدم تعادل استخر به اشباع کامل می‌رسید تا حدی ناکارآمد ظاهر می‌شد \(em زمانی که هر سرور با کمبود اجاره برای تخصیص مواجه می‌شد، توانایی خود را نیز برای متوجه شدن اینکه منابعش به پایان رسیده از دست می‌داد. .PP برای درک تعادل استخر، ابتدا باید برخی عناصر عملکرد آن تعریف شوند. اول، اجاره‌های \'free\' و \'backup\' وجود دارند. هر دوی این‌ها به عنوان \'اجاره‌های وضعیت آزاد\' (free state leases) شناخته می‌شوند. در این سند \'free\' و \'backup\' همان \'وضعیت‌های آزاد\' هستند. تفاوت در این است که تنها سرور اصلی می‌تواند از اجاره‌های \'free\' تخصیص دهد مگر در شرایط خاص، و تنها سرور ثانویه می‌تواند اجاره‌های \'backup\' را تخصیص دهد. .PP هنگامی که تعادل استخر انجام می‌شود، تنها انتظار منطقی ارائه یک تقسیم‌بندی ۵۰/۵۰ از اجاره‌های وضعیت آزاد میان دو سرور است. این بدان دلیل است که صرف‌نظر از بار نسبی وارد شده بر دو سرور، هیچ‌کس نمی‌تواند پیش‌بینی کند کدام سرور از کار خواهد افتاد، بنابراین دادن نیمی از اجاره‌ها به هر سرور، به هر دو سرور میزان یکسانی از \'تحمل خرابی\' می‌دهد. از این رو، هیچ راهی برای پیکربندی رفتاری متفاوت، به جز چند پنجره بسیار کوچک که به زودی شرح خواهیم داد، وجود ندارد. .PP اولین چیزی که در هر اجرای برقراری تعادل استخر محاسبه می‌شود، مقداری است که به آن \'lts\' یا "Leases To Send" (اجاره‌های ارسالی) می‌گویند. این مقدار به سادگی تفاضل تعداد اجاره‌های free و backup تقسیم بر دو است. برای سرور ثانویه، تفاضل اجاره‌های backup و free تقسیم بر دو است. مقدار حاصل دارای علامت است: اگر مثبت باشد، انتظار می‌رود سرور محلی اجاره‌هایی را واگذار کند تا تعادل ۵۰/۵۰ حفظ شود. اگر منفی باشد، سرور راه دور باید برای متعادل کردن استخر، اجاره‌هایی ارسال کند. به محض اینکه مقدار lts به صفر برسد، استخر کاملاً متعادل است (با اختلاف حداکثر یک اجاره در صورت فرد بودن مجموع اجاره‌های وضعیت آزاد). .PP رویکرد فعلی هنوز تا حدی ترکیبی از رویکرد قدیمی است که با وجود دستور \fBmax-lease-misbalance\fR مشخص می‌شود. این پارامتر آنچه را که در نسخه‌های قبلی مقدار ثابت ۱۰٪ بود پیکربندی می‌کند: اگر مقدار lts کمتر از حاصل‌ضرب (free+backup) در درصد \fBmax-lease-misbalance\fR باشد، در این صورت سرور از متعادل‌سازی استخر مربوطه صرف‌نظر می‌کند (به خود زحمت انتقال هیچ اجاره‌ای را نمی‌دهد، حتی اگر بعضی اجاره‌ها "باید" منتقل شوند). با این حال، مفهوم این مقدار تا حدودی بار اضافی نیز دارد، به این ترتیب که تخمین زمان اقدام برای متعادل‌سازی استخر را نیز کنترل می‌کند (که ممکن است سپس از آن هم صرف‌نظر شود). قدیمی‌ترین اجاره‌ها در وضعیت‌های free و backup بررسی می‌شوند. مدت زمانی که آن‌ها در صف‌های مربوط به خود قرار داشته‌اند به عنوان برآوردی به کار می‌رود تا نشان دهد احتمالاً چقدر زمان می‌برد تا اجاره‌های بالای فهرست مصرف شوند (و در نتیجه، چقدر طول می‌کشد تا تمام اجاره‌ها در آن وضعیت استفاده شوند). این درصد مستقیماً در این زمان ضرب می‌شود و اگر در بازه مقادیر پیکربندی‌شده \fBmin-balance\fR و \fBmax-balance\fR قرار گیرد، در زمان‌بندی جای داده می‌شود. زمان بررسی زمان‌بندی‌شده استخر فقط به سمت کاهش تغییر می‌کند و هرگز افزایش نمی‌یابد. در نهایت، اگر lts در جهت منفی بیش از دو برابر این عدد باشد، سرور محلی دچار \'وحشت\' (\'panic\') شده و یک پیام POOLREQ از پروتکل پشتیبان گرم مخابره می‌کند، به این امید که سیستم راه دور برای اقدام بیدار شود. .PP به محض اینکه مقدار lts همان‌طور که در بالا شرح داده شد از درصد \fBmax-lease-misbalance\fR کل اجاره‌های وضعیت آزاد فراتر رود، اجاره‌ها به سرور راه دور منتقل می‌شوند. این کار در دو مرحله انجام می‌پذیرد. .PP در مرحله اول، فقط اجاره‌هایی که جدیدترین کلاینت متصل به آنها — بر اساس الگوریتم توزیع بار (به دستورات پیکربندی \fBsplit\fR و \fBhba\fR در بالا مراجعه کنید) — توسط سرور راه دور سرویس‌دهی می‌شده است، به همتا واگذار می‌شوند. این مرحله اول با اشتیاق به واگذاری اجاره‌ها ادامه می‌دهد و به ازای هر کدام مقدار lts را یک واحد کاهش می‌دهد، تا زمانی که مقدار lts به مقدار منفی حاصل‌ضرب کل تعداد اجاره‌ها در درصد \fBmax-lease-ownership\fR برسد. بنابراین از طریق این مقدار است که می‌توانید عدم تعادل کوچکی را در استخرهای اجاره مجاز بدانید — به منظور دادن سهمی بیش از ۵۰/۵۰ از اجاره‌ها به همتا به این امید که کلاینت‌های آن روزی بازگردند و توسط همتا (که به طور عادی فعالیت می‌کند) تخصیص داده شوند. این فرآیند تحت عنوان \'MAC Address Affinity\' شناخته می‌شود، اما این نام‌گذاری تا حدودی نادرست است: این فرآیند به طور مساوی برای گزینه‌های DHCP Client Identifier نیز اعمال می‌شود. همچنین توجه داشته باشید که پیوند (affinity) زمانی که اجاره‌ها از حالت \'expired\' یا \'released\' وارد وضعیت \'free\' می‌شوند نیز اعمال می‌گردد. در این حالت نیز اگر سرور ثانویه از قبل بیش از سهم خود داشته باشد، اجاره‌ها از free به backup منتقل نخواهند شد. .PP ورود به مرحله دوم تنها در صورتی رخ می‌دهد که مرحله اول نتواند مقدار lts را به زیر حاصل‌ضرب کل تعداد اجاره‌های وضعیت آزاد در درصد \fBmax-lease-ownership\fR کاهش دهد. در این مرحله، قدیمی‌ترین اجاره‌ها بدون هیچ توجهی به الگوریتم توزیع بار به همتا واگذار می‌شوند و این روند تا زمانی که lts به زیر این مقدار سقوط کند ادامه می‌یابد. به این ترتیب، سرور محلی نیز با رضایت درصد کمی از اجاره‌هایی را که معمولاً طبق توزیع بار به خودش می‌رسید حفظ خواهد کرد. .PP بنابراین، مقدار \fBmax-lease-misbalance\fR به عنوان یک درگاه رفتاری عمل می‌کند. مقادیر کوچک‌تر باعث می‌شوند اجاره‌های بیشتری با گذشت زمان تغییر وضعیت دهند تا استخرها متعادل شوند، و مقادیر بزرگ‌تر میزان تغییرات را کاهش می‌دهند (اما اگر هجوم ناگهانی برای درخواست اجاره رخ دهد ممکن است به قحطی استخر منجر شود). .PP مقدار \fBmax-lease-ownership\fR امکان انحراف جزئی (درصدی) را در تعادل اجاره‌ها به میزان درصدی از کل تعداد اجاره‌های وضعیت آزاد فراهم می‌آورد. .PP در نهایت، \fBmin-balance\fR و \fBmax-balance\fR اطمینان حاصل می‌کنند که رویداد تعادل‌بخشی زمان‌بندی‌شده در یک بازه زمانی معقول رخ دهد (تا به عنوان مثال، وجود یک اجاره آزاد متعلق به ۷ سال پیش آن را مختل نکند). .PP مقادیر معقول برای درصدها بین ۰ تا ۱۰۰ (شامل هر دو) قرار دارند، اما مقادیر بالای ۵۰ تفاوتی با یکدیگر ندارند (به محض اینکه lts از ۵۰٪ اجاره‌های وضعیت آزاد فراتر رود، بنابراین یک سرور باید ۱۰۰٪ اجاره‌ها را در وضعیت آزاد مربوط به خود داشته باشد). توصیه می‌شود مقداری برای \fBmax-lease-ownership\fR انتخاب شود که کمتر از مقدار انتخاب‌شده برای \fBmax-lease-misbalance\fR باشد. مقدار پیش‌فرض \fBmax-lease-ownership\fR برابر ۱۰، و پیش‌فرض \fBmax-lease-misbalance\fR برابر ۱۵ است. .PP مقادیر معقول برای زمان‌های \fBmin-balance\fR و \fBmax-balance\fR نیز از ۰ تا (2^32)-1 (یا حد مقدار time_t محلی شما) متغیر است، اما به ترتیب دارای مقادیر پیش‌فرض ۶۰ و ۳۶۰۰ هستند (تا رویدادهای تعادل در بازه بین ۱ دقیقه و ۱ ساعت قرار گیرند). .RE .SH "دسته‌بندی کلاینت‌ها (CLIENT CLASSING)" کلاینت‌ها را می‌توان به کلاس‌های مختلف دسته‌بندی کرد و بسته به کلاسی که در آن قرار دارند، رفتار متفاوتی با آن‌ها داشت. این تفکیک را می‌توان با یک عبارت شرطی یا با دستور .B match درون اعلان کلاس انجام داد. می‌توان محدودیتی برای کل تعداد کلاینت‌های درون یک کلاس یا زیرکلاس خاص که مجاز به داشتن اجاره‌نامه (lease) به صورت هم‌زمان هستند تعیین کرد، و همچنین می‌توان ایجاد خودکار زیرکلاس‌ها را بر اساس محتوای بسته ارسالی کلاینت مشخص نمود. .PP پشتیبانی از دسته‌بندی کلاینت‌های DHCPv6 در نسخه 4.3.0 اضافه شد. این سازوکار از همان قوانین DHCPv4 پیروی می‌کند، با این استثنا که پشتیبانی از کلاس‌های صورت‌حساب (billing classes) هنوز اضافه نشده است. .PP برای افزودن کلاینت‌ها به کلاس‌ها بر اساس ارزیابی شرطی، می‌توانید یک عبارت تطبیق (matching expression) را در اعلان کلاس مشخص کنید: .PP .nf class "ras-clients" { match if substring (option dhcp-client-identifier, 1, 3) = "RAS"; } .fi .PP لطفاً توجه داشته باشید مقادیری که در عبارات تطبیق استفاده می‌شوند تنها می‌توانند از داده‌ها یا گزینه‌هایی برگرفته شوند که بخشی از بسته کلاینت هستند. استفاده از مقادیری که از طریق یک یا چند دستور اجرایی ساخته می‌شوند ممکن نیست. این امر ناشی از آن است که طبقه‌بندی کلاینت قبل از اجرای هرگونه دستوری انجام می‌گیرد. تلاش برای چنین کاری نتایج نامعینی به همراه خواهد داشت. .PP توجه داشته باشید که چه از عبارات تطبیق استفاده کنید و چه از دستورات افزودن (یا هر دو) برای دسته‌بندی کلاینت‌ها، همیشه باید برای هر کلاسی که استفاده می‌کنید یک اعلان کلاس بنویسید. اگر هیچ دستور تطبیق یا دستور درون‌حوزه‌ای (in-scope) برای یک کلاس وجود نداشته باشد، اعلان باید به شکل زیر باشد: .PP .nf class "ras-clients" { } .fi .SH "زیرکلاس‌ها (SUBCLASSES)" .PP علاوه بر کلاس‌ها، اعلان زیرکلاس‌ها (subclasses) نیز امکان‌پذیر است. یک زیرکلاس، کلاسی با همان نام یک کلاس معمولی است، اما دارای یک عبارت تطبیق فرعی مشخص است که برای تطبیق سریع هش می‌شود. این ویژگی در اصل یک ترفند افزایش سرعت است؛ تفاوت اصلی میان پنج کلاس با عبارت‌های تطبیق و یک کلاس با پنج زیرکلاس در این است که یافتن زیرکلاس‌ها بسیار سریع‌تر خواهد بود. سازوکار زیرکلاس‌ها به صورت زیر است: .PP .nf 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; } } .fi .PP داده‌ای که پس از نام کلاس در اعلان زیرکلاس می‌آید، یک مقدار ثابت است که در ارزیابی عبارت تطبیق کلاس به کار می‌رود. هنگام انجام تطبیق کلاس، سرور عبارت تطبیق را ارزیابی کرده و سپس نتیجه را در جدول هش جستجو می‌کند. در صورت یافتن تطابق، کلاینت عضو هر دو مورد یعنی کلاس و زیرکلاس در نظر گرفته می‌شود. .PP زیرکلاس‌ها را می‌توان با یا بدون حوزه (scope) اعلان کرد. در مثال بالا، تنها هدف از زیرکلاس این است که به برخی کلاینت‌ها اجازه دسترسی به یک استخر آدرس داده شود، در حالی که به سایر کلاینت‌ها دسترسی به استخر دیگری اختصاص یابد؛ بنابراین این زیرکلاس‌ها بدون حوزه اعلان شده‌اند. اگر بخشی از هدف زیرکلاس تعریف مقادیر پارامترهای متفاوت برای برخی کلاینت‌ها باشد، ممکن است بخواهید برخی زیرکلاس‌ها را همراه با حوزه اعلان کنید. .PP در مثال بالا، اگر کلاینت خاصی داشتید که بر خلاف بیشتر کلاینت‌ها به پارامترهای پیکربندی نیاز داشت، می‌توانستید اعلان زیرکلاس زیر را برای آن کلاینت بنویسید: .PP .nf subclass "allocation-class-2" 1:08:00:2b:a1:11:31 { option root-path "samsara:/var/diskless/alphapc"; filename "/tftpboot/netbsd.alphapc-diskless"; } .fi .PP در این مثال، ما از زیرکلاس‌سازی به عنوان روشی برای کنترل تخصیص آدرس بر مبنای هر کلاینت استفاده کرده‌ایم. با این حال، استفاده از زیرکلاس‌سازی به شیوه‌هایی که خاص کلاینت نیستند نیز امکان‌پذیر است؛ برای نمونه، استفاده از مقدار گزینه vendor-class-identifier برای تعیین مقادیری که باید در گزینه vendor-encapsulated-options ارسال شوند. نمونه‌ای از این کاربرد در بخش VENDOR ENCAPSULATED OPTIONS در صفحه راهنمای .B dhcp-options(5) نشان داده شده است. .SH "محدودیت‌های مبتنی بر کلاس در تخصیص پویای آدرس (PER-CLASS LIMITS ON DYNAMIC ADDRESS ALLOCATION)" .PP شما می‌توانید برای تعداد کلاینت‌هایی در یک کلاس که می‌توان به آن‌ها اجاره‌نامه تخصیص داد، محدودیت مشخص کنید. اثر این کار دشوار ساختن دریافت آدرس برای کلاینت جدیدی از آن کلاس خواهد بود. هنگامی که یک کلاس با چنین محدودیتی به سقف مجاز خود برسد، تنها راهی که یک کلاینت جدید در آن کلاس می‌تواند اجاره‌نامه دریافت کند این است که یکی از کلاینت‌های موجود اجاره‌نامه خود را رها کند؛ چه از طریق منقضی شدن آن و چه با ارسال بسته DHCPRELEASE. کلاس‌های دارای محدودیت اجاره به صورت زیر مشخص می‌شوند: .PP .nf class "limited-1" { lease limit 4; } .fi .PP این دستور کلاسی ایجاد می‌کند که در آن حداکثر چهار عضو می‌توانند به طور هم‌زمان دارای اجاره‌نامه باشند. .SH "کلاس‌های پویا و خودکار (SPAWNING CLASSES)" .PP اعلان یک .I کلاس خودکار (spawning class)\fR امکان‌پذیر است. کلاس خودکار، کلاسی است که بر اساس آنچه کلاینت ارسال می‌کند، به طور خودکار زیرکلاس‌هایی تولید می‌نماید. دلیل ایجاد کلاس‌های خودکار، فراهم کردن امکان ساخت بی‌درنگ کلاس‌های با محدودیت اجاره بود. کاربرد مورد نظر در محیط مودم‌های کابلی است، جایی که ISP مایل است به کلاینت‌های حاضر در یک محل خاص بیش از یک آدرس IP اختصاص دهد، اما نمی‌خواهد زیرشبکه اختصاصی به آن‌ها بدهد یا تعداد نامحدودی آدرس IP از بخش شبکه‌ای که به آن متصل هستند در اختیارشان بگذارد. .PP بسیاری از سیستم‌های سرفصل (head-end) مودم‌های کابلی را می‌توان طوری پیکربندی کرد که هنگام بازپخش (relay) بسته‌های DHCP به سرور، گزینه Relay Agent Information را به آن‌ها اضافه کنند. این سیستم‌ها معمولاً یک گزینه circuit ID یا remote ID می‌افزایند که محل مشتری را به صورت یکتا مشخص می‌کند. برای بهره‌گیری از این قابلیت، می‌توانید اعلان کلاسی به شکل زیر بنویسید: .PP .nf class "customer" { spawn with option agent.circuit-id; lease limit 4; } .fi .PP اکنون هر زمان که درخواستی از سوی محل مشتری برسد، گزینه circuit ID در جدول هش کلاس بررسی می‌شود. اگر زیرکلاسی منطبق با circuit ID پیدا شود، کلاینت در آن زیرکلاس دسته‌بندی شده و طبق آن با آن رفتار می‌شود. اگر زیرکلاسی منطبق بر circuit ID پیدا نشود، زیرکلاس جدیدی ایجاد شده و در فایل .B dhcpd.leases ثبت می‌گردد و کلاینت در این کلاس جدید طبقه‌بندی می‌شود. پس از آن‌که کلاینت دسته‌بندی شد، مطابق با قوانین کلاس با آن رفتار خواهد شد؛ از جمله، در این مورد، مشمول محدودیت چهار اجاره‌نامه برای هر محل می‌شود. .PP استفاده از سازوکار ایجاد خودکار زیرکلاس به گزینه‌های رله محدود نمی‌شود؛ این مثال خاص صرفاً به این دلیل آورده شده است که نسبتاً سرراست و ساده است. .SH "ترکیب MATCH ،MATCH IF و SPAWN WITH (COMBINING MATCH, MATCH IF AND SPAWN WITH)" .PP در برخی موارد، ممکن است استفاده از یک عبارت برای اختصاص کلاینت به یک کلاس خاص و عبارت دوم برای قرار دادن آن در یک زیرکلاس از آن کلاس مفید باشد. این کار با ترکیب دستورات \fBmatch if\fR و \fBspawn with\fR، یا دستورات \fBmatch if\fR و \fBmatch\fR انجام‌پذیر است. به عنوان مثال: .PP .nf 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; } .fi .PP این قابلیت به شما امکان می‌دهد دو کلاس داشته باشید که هر دو عبارت \fBspawn with\fR یکسانی دارند، بدون آن‌که کلاینت‌های این دو کلاس با یکدیگر اشتباه گرفته شوند. .SH "به‌روزرسانی پویای دی‌ان‌اس (DYNAMIC DNS UPDATES)" .PP سرور DHCP توانایی به‌روزرسانی پویای سامانه نام دامنه (DNS) را دارد. در فایل‌های پیکربندی، می‌توانید نحوه به‌روزرسانی سامانه نام دامنه را مشخص کنید. این به‌روزرسانی‌ها با RFC 2136 سازگار هستند؛ بنابراین هر سرور DNS که از RFC 2136 پشتیبانی کند باید بتواند به‌روزرسانی‌های ارسال‌شده از سرور DHCP را بپذیرد. .PP دو طرح DNS پیاده‌سازی شده است. گزینه موقت (interim) بر پایه پیش‌نویس‌های اسناد DDNS استوار است، در حالی که گزینه استاندارد (standard) بر مبنای RFCهای مربوط به تعامل DHCP-DNS و DHCIDها پیاده‌سازی شده است. گزینه سوم، یعنی ad-hoc، منسوخ شده و اکنون از پایگاه کد حذف گردیده است. سرور DHCP باید طوری پیکربندی شود که از یکی از دو روش مورد پشتیبانی کنونی استفاده کند، یا اینکه اصلاً به‌روزرسانی DNS انجام ندهد. .PP نصب‌های جدید باید از گزینه standard استفاده کنند. در نصب‌های قدیمی‌تر ممکن است جهت سازگاری رو به عقب با پایگاه داده DNS تا زمان امکان به‌روزرسانی آن، تمایل به ادامه استفاده از گزینه interim وجود داشته باشد. این تنظیم را می‌توان با پارامتر پیکربندی .I ddns-update-style انجام داد. .SH "طرح و الگوی به‌روزرسانی دی‌ان‌اس (THE DNS UPDATE SCHEME)" طرح‌های به‌روزرسانی موقت (interim) و استاندارد (standard) دی‌ان‌اس بیشتر بر اساس فعالیت‌های گروه IETF عمل می‌کنند. نسخه موقت بر پایه پیش‌نویس‌های در حال توسعه در آن زمان بود، در حالی که نسخه استاندارد بر مبنای RFCهای نهایی تدوین شده است. RFCهای استاندارد عبارتند از: .PP .nf .ce 3 RFC 4701 (updated by RF5494) RFC 4702 RFC 4703 .fi .PP و پیش‌نویس‌های متناظر آن‌ها عبارت بودند از: .PP .nf .ce 3 draft-ietf-dnsext-dhcid-rr-??.txt draft-ietf-dhc-fqdn-option-??.txt draft-ietf-dhc-ddns-resolution-??.txt .fi .PP چارچوب اساسی این دو طرح مشابه است و تفاوت مادی و اصلی آن‌ها در این است که در نسخه استاندارد از یک رکورد منبع DHCID RR استفاده می‌شود، در حالی که در نسخه‌های موقت از یک رکورد TXT RR استفاده می‌گردد. قالب رکورد TXT شباهت‌هایی به DHCID RR دارد اما معادل آن نیست (تفاوت MD5 در برابر SHA2، تفاوت طول فیلدها و غیره). .PP در این دو طرح، سرور DHCP لزوماً همیشه هر دو رکورد A و PTR را به‌روزرسانی نمی‌کند. گزینه FQDN شامل پرچمی است که در صورت ارسال توسط کلاینت، نشان می‌دهد که کلاینت تمایل دارد رکورد A خود را شخصاً به‌روز کند. در این حالت، سرور می‌تواند طوری پیکربندی شود که به خواسته کلاینت احترام بگذارد یا آن را نادیده بگیرد. این کار با دستور \fIallow client-updates;\fR یا دستور \fIignore client-updates;\fR انجام می‌شود. به صورت پیش‌فرض، به‌روزرسانی‌های کلاینت مجاز است. .PP اگر سرور طوری پیکربندی شده باشد که به‌روزرسانی کلاینت را مجاز بداند، در صورتی که کلاینت یک نام دامنه کاملاً واجد شرایط (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" به آن اجازه چنین کاری را بدهد. .PP اگر سرور طوری پیکربندی شده باشد که به‌روزرسانی‌های کلاینت را مجاز نداند، یا اگر کلاینت نخواهد به‌روزرسانی را شخصاً انجام دهد، سرور صرفاً نامی را برای کلاینت انتخاب خواهد کرد. به طور پیش‌فرض، سرور نام را از میان سه مقدار زیر انتخاب می‌کند: .PP 1. گزینه \fBfqdn\fR (در صورت وجود) 2. گزینه hostname (در صورت وجود) 3. گزینه نام میزبان پیکربندی‌شده (در صورت تعریف). .PP اگر این پیش‌فرض‌ها برای انتخاب نام میزبان مناسب نیستند، می‌توانید دستور دلخواه خود را برای تنظیم متغیر ddns-hostname بنویسید. در صورتی که هیچ‌یک از موارد فوق یافت نشود، اگر use-host-decl-names فعال باشد، سرور از نام اعلان میزبان (در صورت وجود) استفاده خواهد کرد. .PP سرور از نام دامنه اختصاصی خود برای کلاینت استفاده خواهد کرد. سپس هر دو رکورد A و PTR را با استفاده از نامی که برای کلاینت برگزیده است به‌روزرسانی می‌کند. اگر کلاینت یک نام دامنه کاملاً واجد شرایط در گزینه \fBfqdn\fR ارسال کند، سرور فقط از چپ‌ترین بخش نام دامنه استفاده می‌کند؛ در مثال بالا، "jschmoe" به جای "jschmoe.radish.org". .PP علاوه بر این، اگر دستورالعمل \fIignore client-updates;\fR به کار رود، سرور پاسخی را در بسته DHCP با استفاده از گزینه FQDN ارسال می‌کند که به کلاینت القا می‌کند در صورت تمایل باید به‌روزرسانی‌های خود را شخصاً انجام دهد. با دستور \fIdeny client-updates;\fR، پاسخی ارسال می‌شود که نشان می‌دهد کلاینت مجاز به انجام به‌روزرسانی نیست. .PP هر دو گزینه استاندارد و موقت همچنین شامل روشی هستند که به بیش از یک سرور DHCP اجازه می‌دهد پایگاه داده DNS را به‌روزرسانی کنند، بدون آنکه تصادفاً رکوردهای A که نباید حذف شوند را پاک کنند یا در افزودن رکوردهای A که باید اضافه شوند ناکام بمانند. در گزینه استاندارد، این روش به شرح زیر عمل می‌کند: .PP هنگامی که سرور DHCP اجاره‌نامه جدیدی به کلاینت صادر می‌کند، یک رشته متنی ایجاد می‌کند که هش SHA از شناسه کلاینت DHCP است (برای جزئیات به RFCهای 4701 و 4702 مراجعه کنید). فرآیند به‌روزرسانی تلاش می‌کند یک رکورد A با نام انتخابی سرور و یک رکورد DHCID حاوی رشته شناسه هش‌شده (hashid) اضافه کند. اگر این به‌روزرسانی موفقیت‌آمیز باشد، کار سرور به پایان رسیده است. .PP اگر به‌روزرسانی به دلیل وجود قبلی رکورد A با شکست مواجه شود، سرور DHCP تلاش می‌کند رکورد A را با این پیش‌شرط اضافه کند که باید یک رکورد DHCID با همان نامِ رکورد A جدید وجود داشته باشد و محتوای آن رکورد DHCID باید برابر با hashid باشد. اگر این به‌روزرسانی موفق شود، کلاینت دارای رکورد A و رکورد PTR خود خواهد بود. اگر ناموفق باشد، نامی که به کلاینت اختصاص داده شده (یا درخواست شده) در حال استفاده است و کلاینت نمی‌تواند از آن استفاده کند. در این مرحله، سرور DHCP از تلاش برای به‌روزرسانی DNS برای کلاینت صرف‌نظر می‌کند تا زمانی که کلاینت نام جدیدی را انتخاب کند. .PP سرور همچنین به‌روزرسانی‌ها را خیلی تهاجمی انجام نمی‌دهد. از آنجا که هر به‌روزرسانی DNS مستلزم یک رفت‌وبرگشت به سرور DNS است، انجام به‌روزرسانی‌ها هزینه‌بر است، حتی اگر واقعاً پایگاه داده DNS را تغییر ندهند. بنابراین سرور DHCP پیگیری می‌کند که آیا در گذشته رکورد را به‌روزرسانی کرده است یا خیر (این اطلاعات روی اجاره‌نامه ذخیره می‌شود) و تلاشی برای به‌روزرسانی رکوردهایی که فکر می‌کند قبلاً به‌روزرسانی کرده است انجام نمی‌دهد. .PP این موضوع می‌تواند به مواردی منجر شود که در آن سرور DHCP رکوردی را اضافه می‌کند و سپس آن رکورد از طریق سازوکار دیگری حذف می‌شود، اما سرور هرگز دوباره DNS را به‌روزرسانی نمی‌کند چون فکر می‌کند داده‌ها از قبل در آنجا وجود دارند. در این حالت می‌توان با مداخله مدیر سیستم، داده‌ها را از اجاره‌نامه حذف کرد؛ پس از انجام این کار، در تمدید بعدی کلاینت، DNS به‌روزرسانی خواهد شد. .PP طرح به‌روزرسانی موقت دی‌ان‌اس (interim) پیش از نهایی شدن RFCها نگاشته شد و کاملاً از آن‌ها پیروی نمی‌کند. RFCها خواهان یک نوع رکورد جدید DHCID RR هستند، در حالی که طرح موقت از یک رکورد TXT استفاده می‌کند. علاوه بر این، پیش‌نویس ddns-resolution از سرور DHCP می‌خواست که یک DHCID RR را روی رکورد PTR قرار دهد، اما روش به‌روزرسانی \fIinterim\fR این کار را انجام نمی‌دهد. در RFC نهایی، این الزام تعدیل شد تا سرور بتواند به دلخواه یک DHCID RR به رکورد PTR اضافه کند. .PP .SH "دی‌ان‌اس پویا در محیط‌های پشته دوگانه (DDNS IN DUAL STACK ENVIRONMENTS)" همان‌طور که در بخش 5.2 از RFC 4703 شرح داده شده است، به منظور اجرای DDNS در محیط‌های پشته دوگانه (dual stack)، هم سرورهای IPv4 و هم IPv6 باید طوری پیکربندی شوند که از شیوه به‌روزرسانی استاندارد استفاده کنند و کلاینت‌های مشارکت‌کننده IPv4 حتماً باید مقادیر DUID را همان‌گونه که در بخش 6.1 از RFC 4361 توضیح داده شده است، در dhcp-client-identifierهای خود ارسال کنند. .PP به طور خلاصه، این سازوکار در نظر دارد از DUIDهای یکتای سراسری برای شناسایی هر دو نوع کلاینت‌های IPv4 و IPv6 استفاده کند؛ و در جایی که یک دستگاه هم اجاره‌نامه IPv4 و هم IPv6 دارد، با همان DUID یکسان شناسایی شود. این امر به کلاینت پشته دوگانه اجازه می‌دهد از همان FQDN یکسان برای هر دو نگاشت استفاده کند، در حالی که طبق قوانین تشخیص تداخل، از به‌روزرسانی‌های کلاینت‌های دیگر محافظت می‌شود. .PP با این حال، همه کلاینت‌های IPv4 این رفتار را پیاده‌سازی نکرده‌اند که این امر پشتیبانی از آن‌ها را در محیط‌های پشته دوگانه با مشکل مواجه می‌کند. برای رفع این مشکل، ISC DHCP (از نسخه 4.4.0) از حالت جدیدی از رفع تداخل DDNS تحت عنوان «حالت ترکیبی پشته دوگانه» یا Dual Stack Mixed Mode (به اختصار DSMM) پشتیبانی می‌کند. .PP مفهوم نهفته در DSMM نسبتاً ساده است. همه سرورهای DHCP مربوط به یک پروتکل (IPv4 یا v6) از یک سبک ddns-update-style (یا interim یا standard) استفاده می‌کنند در حالی که تمام سرورهای پروتکل «دیگر» از سبک ddns-update-style «دیگر» استفاده خواهند کرد. به این ترتیب، همه سرورهای یک پروتکل معین از همان نوع رکورد یکسان (TXT یا DHCID) برای ورودی‌های DHCID RR خود بهره می‌برند. این امر اجازه می‌دهد تشخیص تداخل درون هر پروتکل بدون تداخل با ورودی‌های پروتکل دیگر اعمال گردد. .PP اصلاحات DSMM اکنون تضمین می‌کند که سرورهای DSMM IPv4 فقط رکوردهای A، رکوردهای PTR مرتبط با آن‌ها و رکوردهای DHCID را تغییر می‌دهند، در حالی که سرورهای DSMM IPv6 تنها رکوردهای AAAA، رکوردهای PTR مرتبط با آن‌ها و رکوردهای DHCID را اصلاح می‌نمایند. .PP توجه داشته باشید که DSMM یک راه‌حل کامل و بی‌نقص نیست، بلکه یک مصالحه است که در صورت رعایت قوانین DSMM توسط تمامی به‌روزرسان‌های مشارکت‌کننده در DNS، می‌تواند به خوبی عمل کند. مانند هر چیز دیگری در زندگی، کارکرد آن فقط به همان اندازه خوب است که مشارکت‌کنندگان در آن درست رفتار کنند. .PP در حالی که تشخیص تداخل به طور پیش‌فرض فعال است، DSMM فعال نیست. برای فعال‌سازی DSMM، هر دو گزینه update-conflict-detection و ddns-dual-stack-mixed-mode باید برابر با true باشند. .PP .SH "محافظت از رکوردهای دی‌ان‌اس برای کلاینت‌های ایستا (PROTECTING DNS ENTRIES FOR STATIC CLIENTS)" محافظت از رکوردهایی که به صورت دستی برای کلاینت‌های ایستا ایجاد شده‌اند، بخشی درونی از سازوکار رفع تداخل است. طبق قوانین رفع تداخل، یک به‌روزرسان DNS مجاز نیست رکوردهای مستقیم (forward) دی‌ان‌اس را تغییر دهد مگر آنکه رکورد DHCID RR منطبقی برای کلاینتی که به‌روزرسانی برای او انجام می‌شود، وجود داشته باشد. بنابراین، هر رکورد مستقیم DNS که فاقد یک DHCID RR متناظر باشد، توسط چنین به‌روزرسانی قابل تغییر نیست. .PP در برخی محیط‌ها، ممکن است مطلوب باشد که تنها از این جنبه از رفع تداخل استفاده شود و به به‌روزرسان‌های DNS اجازه بازنویسی (overwrite) رکوردهای مربوط به کلاینت‌های پویا بدون توجه به اینکه کدام کلاینت مالک آن‌هاست داده شود. به عبارت دیگر، وجود یا عدم وجود یک DHCID RR برای تعیین اینکه آیا رکوردها قابل بازنویسی هستند یا خیر استفاده می‌شود؛ اینکه آیا کلاینت با مقدار داده DHCID RR مطابقت دارد یا خیر، اهمیتی ندارد. این رفتار که به صورت پیش‌فرض غیرفعال است، از طریق پارامتر ddns-guard-id-must-match قابل پیکربندی است. همانند DSMM، این رفتار فقط در صورتی قابل فعال‌سازی است که رفع تداخل فعال باشد. پیش از تصمیم به استفاده از این رفتار، باید جوانب آن با دقت سنجیده شود. .PP پارامتر دیگری نیز وجود دارد که می‌تواند همراه با DSMM استفاده شود: ddns-other-guard-is-dynamic. هنگامی که این پارامتر همراه با DSMM فعال باشد، سرور وجود یک DHCID RR از نوع سبک دیگر را به این معنی تلقی می‌کند که رکوردهای مستقیم DNS برای آن FQDN باید پویا باشند و می‌توان آن‌ها را بازنویسی کرد. به عنوان مثال، چنین سروری که از سبک interim استفاده می‌کند، در صورتی که فقط یک DHCID RR از نوع DHCID برای آن FQDN وجود داشته باشد، می‌تواند رکوردهای DNS آن FQDN را بازنویسی کند. در واقع، اگر رکوردهای پویایی برای یک پروتکل وجود داشته باشد، برای کنار زدن محافظت ایستای رکوردها برای پروتکل دیگر کافی است. این رفتار مستلزم بررسی و تامل دقیق پیش از استفاده است. .PP .SH "امنیت به‌روزرسانی پویای دی‌ان‌اس (DYNAMIC DNS UPDATE SECURITY)" .PP هنگامی که سرور DNS خود را طوری تنظیم می‌کنید که به‌روزرسانی‌های ارسالی از سرور DHCP را بپذیرد، ممکن است آن را در معرض به‌روزرسانی‌های غیرمجاز قرار دهید. برای جلوگیری از این امر، باید از امضاهای TSIG استفاده کنید؛ روشی برای امضای رمزنگاری‌شده به‌روزرسانی‌ها با استفاده از یک کلید مخفی مشترک (shared secret key). تا زمانی که محرمانگی این کلید را حفظ کنید، به‌روزرسانی‌های شما نیز امن خواهند بود. با این حال، توجه داشته باشید که خود پروتکل DHCP هیچ‌گونه امنیتی فراهم نمی‌کند، و بنابراین کلاینت‌ها می‌توانند اطلاعاتی را به سرور DHCP ارسال کنند که سرور DHCP متعاقباً بر اساس محدودیت‌های شرح داده‌شده قبلی، از آن‌ها در به‌روزرسانی‌های خود استفاده نماید. .PP سرور DNS باید طوری پیکربندی شود که اجازه به‌روزرسانی را برای هر منطقه‌ای (zone) که سرور DHCP قرار است به‌روز کند، بدهد. برای مثال، فرض کنیم که به کلاینت‌های موجود در دامنه sneedville.edu آدرس‌هایی از زیرشبکه 10.10.17.0/24 اختصاص داده خواهد شد. در این صورت، شما به یک اعلان کلید برای کلید TSIG مورد استفاده، و همچنین به دو اعلان منطقه (یکی برای منطقه‌ای که شامل رکوردهای A است که به‌روزرسانی خواهند شد و دیگری برای منطقه‌ای که شامل رکوردهای PTR است) نیاز خواهید داشت؛ برای ISC BIND چیزی شبیه به این: .PP .nf 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; }; }; .fi .PP همچنین باید سرور DHCP خود را برای انجام به‌روزرسانی روی این منطقه‌ها پیکربندی کنید. برای این منظور، باید چیزی شبیه به موارد زیر را به فایل dhcpd.conf خود اضافه کنید: .PP .nf 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; } .fi .PP دستور \fIprimary\fR آدرس IP کارساز نامی (name server) را مشخص می‌کند که اطلاعات منطقه آن قرار است به‌روزرسانی شود. علاوه بر دستور \fIprimary\fR، دستورهای \fIprimary6\fR، \fIsecondary\fR و \fIsecondary6\fR نیز وجود دارند. دستور \fIprimary6\fR یک آدرس IPv6 را برای کارساز نام مشخص می‌کند. دستورهای ثانویه آدرس‌های اضافی برای کارسازهای نام فراهم می‌آورند تا در صورت عدم پاسخگویی کارساز اصلی استفاده شوند. تعداد کارسازهای نامی که کد DDNS قبل از تسلیم شدن تلاش می‌کند استفاده کند محدود است و در حال حاضر روی سه تنظیم شده است. .PP توجه داشته باشید که اعلان‌های منطقه باید با رکوردهای مرجع (authority) در کارساز نام شما مطابقت داشته باشند؛ در مثال بالا، باید یک رکورد SOA برای "example.org." و برای "17.10.10.in-addr.arpa." وجود داشته باشد. برای مثال، اگر زیردامنه "foo.example.org" بدون SOA جداگانه وجود داشت، نمی‌توانستید اعلان منطقه‌ای برای "foo.example.org." بنویسید. همچنین به یاد داشته باشید که نام‌های منطقه در پیکربندی DHCP شما باید به یک "." ختم شوند؛ این ساختار نحوی ترجیحی است. اگر نام منطقه خود را به "." ختم نکنید، سرور DHCP خودش آن را تشخیص می‌دهد. همچنین توجه داشته باشید که در پیکربندی DHCP، بر خلاف پیکربندی DNS، نام‌های منطقه درون علامت نقل‌قول (quotes) قرار نمی‌گیرند. .PP البته شما باید کلید مخفی اختصاصی خود را انتخاب کنید. توزیع ISC BIND 9 همراه با برنامه‌ای برای تولید کلیدهای مخفی به نام dnssec-keygen عرضه می‌شود. اگر از dnssec-keygen برنامه BIND 9 استفاده می‌کنید، کلید بالا به شکل زیر ساخته می‌شود: .PP .nf dnssec-keygen -a HMAC-MD5 -b 128 -n USER DHCP_UPDATER .fi .PP نام کلید، الگوریتم و مقدار مخفی (secret) باید دقیقاً با آنچه توسط سرور DNS استفاده می‌شود مطابقت داشته باشند. سرور DHCP در حال حاضر از الگوریتم‌های زیر پشتیبانی می‌کند: .nf HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512 .fi .PP ممکن است بخواهید ثبت گزارش (logging) به‌روزرسانی‌های DNS را در سرور DNS خود فعال کنید. برای این کار، می‌توانید دستور ثبت گزارشی مشابه زیر بنویسید: .PP .nf 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; }; }; .fi .PP پیش از راه‌اندازی کارساز نام، باید فایل‌های /var/log/named-auth.info و /var/log/update-debug.log را ایجاد کنید. برای اطلاعات بیشتر در خصوص پیکربندی ISC BIND، به مستندات همراه آن مراجعه کنید. .SH "مرجع: رویدادها (REFERENCE: EVENTS)" .PP سه نوع رویداد در رابطه با یک اجاره (lease) وجود دارد که می‌تواند رخ دهد، و این امکان وجود دارد که دستوراتی را اعلان کنید تا هنگام وقوع هر یک از این رویدادها اجرا شوند. این رویدادها عبارتند از رویداد تعهد (commit)، هنگامی که سرور تعهد یک اجاره مشخص را به یک کلاینت داده است؛ رویداد آزادسازی (release)، هنگامی که کلاینت سرور را از تعهد خود آزاد کرده است؛ و رویداد انقضا (expiry)، هنگامی که مدت تعهد منقضی می‌شود. .PP برای اعلان مجموعه‌ای از دستورات جهت اجرا هنگام وقوع یک رویداد، باید از دستور \fBon\fR به همراه نام رویداد استفاده کنید، و در ادامه مجموعه‌ای از دستورات برای اجرا در هنگام وقوع رویداد درون آکولاد قرار می‌گیرند. .SH "مرجع: اعلان‌ها (REFERENCE: DECLARATIONS)" .PP .B دستور .I include .PP .nf \fBinclude\fR \fI"filename"\fR\fB;\fR .fi .PP دستور \fIinclude\fR برای خواندن یک فایل نام‌گذاری‌شده و پردازش محتویات آن فایل به گونه‌ای که گویی در محل دستور include درج شده است، استفاده می‌شود. .PP .B دستور .I shared-network .PP .nf \fBshared-network\fR \fIname\fR \fB{\fR [ \fIparameters\fR ] [ \fIdeclarations\fR ] \fB}\fR .fi .PP دستور \fIshared-network\fR برای آگاه‌سازی سرور DHCP از این موضوع به کار می‌رود که برخی زیرشبکه‌های IP در واقع در یک شبکه فیزیکی یکسان مشترک هستند. هر زیرشبکه‌ای در یک شبکه مشترک باید درون یک دستور \fIshared-network\fR اعلان شود. پارامترهای مشخص‌شده در دستور \fIshared-network\fR هنگام راه‌اندازی (بوت) کلاینت‌ها در آن زیرشبکه‌ها استفاده خواهند شد، مگر اینکه پارامترهای ارائه‌شده در سطح زیرشبکه یا میزبان آن‌ها را بازنویسی کنند. اگر هر زیرشبکه‌ای در یک شبکه مشترک دارای آدرس‌های موجود برای تخصیص پویا باشد، آن آدرس‌ها در یک استخر مشترک برای آن شبکه اشتراکی جمع‌آوری شده و بر حسب نیاز به کلاینت‌ها اختصاص می‌یابند. هیچ راهی برای تشخیص این موضوع وجود ندارد که کلاینت باید در کدام زیرشبکه از یک شبکه اشتراکی راه‌اندازی شود. .PP مقدار .I Name باید نام شبکه اشتراکی باشد. این نام هنگام چاپ پیام‌های اشکال‌زدایی (دیباگ) استفاده می‌شود، بنابراین باید برای آن شبکه اشتراکی توصیفی و رسا باشد. این نام می‌تواند ساختار نحوی یک نام دامنه معتبر را داشته باشد (اگرچه هرگز به عنوان دامنه استفاده نخواهد شد)، یا می‌تواند هر نام دلخواهی باشد که درون گیومه محصور شده است. .PP .B دستور .I subnet .PP .nf \fBsubnet\fR \fIsubnet-number\fR \fBnetmask\fR \fInetmask\fR \fB{\fR [ \fIparameters\fR ] [ \fIdeclarations\fR ] \fB}\fR .fi .PP دستور \fIsubnet\fR برای ارائه اطلاعات کافی به dhcpd استفاده می‌شود تا تشخیص دهد آیا یک آدرس IP در آن زیرشبکه قرار دارد یا خیر. همچنین می‌تواند برای ارائه پارامترهای اختصاصی زیرشبکه و مشخص کردن آدرس‌هایی که می‌توانند به طور پویا به کلاینت‌های بوت‌شده در آن زیرشبکه تخصیص یابند، به کار رود. چنین آدرس‌هایی با استفاده از اعلان \fIrange\fR تعیین می‌شوند. .PP مقدار .I subnet-number باید یک آدرس IP یا نام دامنه‌ای باشد که به شماره زیرشبکه مورد توصیف ترجمه می‌شود. مقدار .I netmask باید یک آدرس IP یا نام دامنه‌ای باشد که به ماسک زیرشبکه (subnet mask) مورد نظر ترجمه می‌شود. شماره زیرشبکه، به همراه ماسک زیرشبکه، برای تعیین اینکه آیا یک آدرس IP مفروض در زیرشبکه مشخص‌شده قرار دارد یا خیر کافی هستند. .PP اگرچه همراه با هر اعلان زیرشبکه باید یک netmask ارائه شود، اما توصیه می‌شود چنانچه تفاوتی در ماسک‌های زیرشبکه در یک سایت وجود دارد، در هر اعلان زیرشبکه از یک دستور گزینه subnet-mask برای تنظیم ماسک زیرشبکه مطلوب استفاده شود؛ چرا که هر دستور گزینه subnet-mask، ماسک زیرشبکه اعلان‌شده در دستور subnet را بازنویسی خواهد کرد. .PP .B دستور .I subnet6 .PP .nf \fBsubnet6\fR \fIsubnet6-number\fR \fB{\fR [ \fIparameters\fR ] [ \fIdeclarations\fR ] \fB}\fR .fi .PP دستور \fIsubnet6\fR برای ارائه اطلاعات کافی به dhcpd استفاده می‌شود تا تشخیص دهد آیا یک آدرس IPv6 در آن subnet6 قرار دارد یا خیر. همچنین می‌تواند برای ارائه پارامترهای اختصاصی زیرشبکه و تعیین آدرس‌هایی که می‌توانند به صورت پویا به کلاینت‌های بوت‌شده در آن زیرشبکه اختصاص یابند، استفاده شود. .PP مقدار .I subnet6-number باید یک شناسه شبکه IPv6 باشد که به صورت ip6-address/bits مشخص می‌شود. .PP .B دستور .I range .PP .nf .B range\fR [ \fBdynamic-bootp\fR ] \fIlow-address\fR [ \fIhigh-address\fR]\fB;\fR .fi .PP برای هر زیرشبکه‌ای که آدرس‌ها در آن به طور پویا تخصیص می‌یابند، باید حداقل یک دستور \fIrange\fR وجود داشته باشد. دستور range پایین‌ترین و بالاترین آدرس‌های IP را در یک محدوده مشخص می‌کند. تمام آدرس‌های IP موجود در محدوده باید در زیرشبکه‌ای باشند که دستور \fIrange\fR در آن اعلان شده است. در صورتی که آدرس‌های موجود در محدوده مشخص‌شده علاوه بر کلاینت‌های DHCP بتوانند به طور پویا به کلاینت‌های BOOTP نیز تخصیص داده شوند، می‌توان فلگ \fIdynamic-bootp\fR را تعیین کرد. هنگام مشخص کردن یک آدرس تکی، می‌توان \fIhigh-address\fR را حذف کرد. .PP .B دستور .I range6 .PP .nf .B range6\fR \fIlow-address\fR \fIhigh-address\fR\fB;\fR .B range6\fR \fIsubnet6-number\fR\fB;\fR .B range6\fR \fIsubnet6-number\fR \fBtemporary\fR\fB;\fR .B range6\fR \fIaddress\fR \fBtemporary\fR\fB;\fR .fi .PP برای هر زیرشبکه IPv6 (یا subnet6) که در آن آدرس‌ها به صورت پویا تخصیص می‌یابند، باید حداقل یک دستور \fIrange6\fR وجود داشته باشد. دستور \fIrange6\fR می‌تواند شامل پایین‌ترین و بالاترین آدرس‌های IPv6 در یک \fIrange6\fR باشد، یا از نمادگذاری CIDR به صورت ip6-address/bits استفاده کند. تمام آدرس‌های IP موجود در \fIrange6\fR باید در subnet6 مربوطه‌ای باشند که دستور \fIrange6\fR در آن اعلان شده است. .PP نگارش \fItemporary\fR پیشوند را (به طور پیش‌فرض روی ۶۴ بیت) برای آدرس‌های موقت (RFC 4941) در دسترس قرار می‌دهد. در هر درخواست با گزینه IA_TA، یک آدرس جدید به ازای هر پیشوند در شبکه اشتراکی محاسبه می‌شود. دستورات Release و Confirm آدرس‌های موقت را نادیده می‌گیرند. .PP هرگونه آدرس IPv6 که با استفاده از \fIfixed-address6\fR به میزبان‌ها اختصاص یافته باشد، و همچنین آدرس‌های IPv6 موجود روی خود سرور، از \fIrange6\fR مستثنی می‌شوند. .PP .PP .B دستور .I prefix6 .PP .nf .B prefix6\fR \fIlow-address\fR \fIhigh-address\fR \fB/\fR \fIbits\fR\fB;\fR .fi .PP دستور \fIprefix6\fR معادل \fIrange6\fR برای تفویض پیشوند (Prefix Delegation - RFC 3633) است. پیشوندهایی با طول \fIbits\fR در فاصله بین \fIlow-address\fR و \fIhigh-address\fR تخصیص می‌یابند. .PP هرگونه پیشوند IPv6 که با \fIfixed-prefix6\fR به مدخل‌های ایستا (میزبان‌ها) داده شده باشد، از \fIprefix6\fR مستثنی می‌شود. .PP این دستور در حال حاضر سراسری (global) است، اما باید دارای حوزه شبکه اشتراکی (shared-network scope) باشد. .PP .B دستور .I host .PP .nf \fBhost\fR \fIhostname\fR { [ \fIparameters\fR ] [ \fIdeclarations\fR ] \fB}\fR .fi .PP اعلان .B host روشی را برای سرور DHCP فراهم می‌کند تا یک کلاینت DHCP یا BOOTP را شناسایی کند. این قابلیت به سرور امکان می‌دهد تا اطلاعات پیکربندی شامل آدرس‌های ثابت یا در DHCPv6، پیشوندهای ثابت را برای یک کلاینت مشخص فراهم آورد. .PP اگر مطلوب باشد که یک کلاینت DHCP یا BOOTP بتواند در بیش از یک زیرشبکه با آدرس‌های ثابت v4 راه‌اندازی (بوت) شود، می‌توان بیش از یک آدرس را در اعلان .I fixed-address مشخص کرد، یا بیش از یک دستور .B host را متناظر با همان کلاینت تعیین نمود. .PP اعلان .I fixed-address6 برای آدرس‌های v6 استفاده می‌شود. در حال حاضر این اعلان تنها با یک آدرس منفرد کار می‌کند. برای چندین آدرس، چندین دستور .B host را مشخص کنید. .PP اگر پارامترهای راه‌اندازی اختصاصی کلاینت باید بر اساس شبکه‌ای که کلاینت به آن متصل است تغییر کنند، باید از چندین اعلان .B host استفاده شود. اعلان‌های .B host تنها در صورتی با یک کلاینت تطبیق داده می‌شوند که یکی از دستورات .I fixed-address آن‌ها روی زیرشبکه (یا شبکه اشتراکی) که کلاینت به آن متصل است قابل استفاده باشد. در مقابل، برای اینکه یک اعلان .B host با کلاینتی که در حال دریافت یک آدرس پویا است تطبیق یابد، نباید هیچ‌گونه دستور .I fixed-address داشته باشد. بنابراین ممکن است برای هر کلاینت مفروض به ترکیبی از اعلان‌های .B host نیاز داشته باشید... برخی دارای دستورات .I fixed-address و برخی دیگر بدون آن. .PP مقدار .I hostname باید نامی باشد که میزبان را شناسایی می‌کند. اگر گزینه \fIhostname\fR برای میزبان تعیین نشده باشد، از \fIhostname\fR استفاده می‌شود. .PP اعلان‌های \fIHost\fR با کلاینت‌های واقعی DHCP یا BOOTP از طریق تطبیق گزینه \fRdhcp-client-identifier\fR مشخص‌شده در اعلان \fIhost\fR با شناسه ارائه‌شده توسط کلاینت تطبیق داده می‌شوند؛ یا اگر اعلان \fIhost\fR یا کلاینت گزینه \fRdhcp-client-identifier\fR را ارائه ندهد، از طریق تطبیق پارامتر \fIhardware\fR در اعلان \fIhost\fR با آدرس سخت‌افزاری شبکه (MAC) ارائه‌شده توسط کلاینت تطبیق می‌یابند. کلاینت‌های BOOTP به طور معمول گزینه \fIdhcp-client-identifier\fR را ارائه نمی‌دهند، بنابراین آدرس سخت‌افزاری باید برای تمام کلاینت‌هایی که ممکن است با پروتکل BOOTP بوت شوند، استفاده شود. .PP سرورهای DHCPv6 می‌توانند از پارامتر \fIhost-identifier option\fR در اعلان \fIhost\fR استفاده کرده و هر گزینه‌ای با مقدار ثابت را برای شناسایی میزبان‌ها تعیین کنند. .PP لطفاً توجه داشته باشید که .B تنها گزینه \fIdhcp-client-identifier\fR و آدرس سخت‌افزاری می‌توانند برای تطبیق یک اعلان میزبان استفاده شوند، یا پارامتر \fIhost-identifier option\fR برای سرورهای DHCPv6. برای مثال، تطبیق دادن یک اعلان میزبان با گزینه \fIhost-name\fR امکان‌پذیر نیست. علت این است که یکتا بودن گزینه host-name را برای هر کلاینت معین نمی‌توان تضمین کرد، در حالی که هم آدرس سخت‌افزاری و هم گزینه \fIdhcp-client-identifier\fR حداقل از نظر تئوری برای یک کلاینت معین تضمین‌شده هستند که یکتا باشند. .PP .B دستور .I group .PP .nf \fBgroup\fR { [ \fIparameters\fR ] [ \fIdeclarations\fR ] \fB}\fR .fi .PP دستور group صرفاً برای اعمال یک یا چند پارامتر بر روی گروهی از اعلان‌ها به کار می‌رود. از آن می‌توان برای گروه‌بندی میزبان‌ها، شبکه‌های اشتراکی، زیرشبکه‌ها یا حتی سایر گروه‌ها استفاده کرد. .SH "مرجع: ALLOW و DENY (REFERENCE: ALLOW AND DENY)" دستورات .I allow و .I deny می‌توانند برای کنترل پاسخ سرور DHCP به انواع مختلف درخواست‌ها استفاده شوند. کلمات کلیدی allow و deny بسته به زمینه کاربرد، در واقع معانی متفاوتی دارند. در زمینه یک استخر (pool)، این کلمات کلیدی را می‌توان برای ایجاد فهرست‌های کنترل دسترسی برای استخرهای تخصیص آدرس به کار برد. در سایر زمینه‌ها، این کلمات کلیدی صرفاً رفتار کلی سرور را در قبال کلاینت‌ها بر اساس حوزه (scope) کنترل می‌کنند. در زمینه‌های خارج از استخر، کلمه کلیدی .I ignore می‌تواند به جای کلمه کلیدی .I deny استفاده شود تا از ثبت گزارش (لاگ) درخواست‌های ردشده جلوگیری کند. .PP .SH "استفاده از ALLOW ،DENY و IGNORE در حوزه‌ها (ALLOW DENY AND IGNORE IN SCOPE)" کاربردهای زیر از allow و deny در هر حوزه‌ای کار خواهند کرد، اگرچه توصیه نمی‌شود که در اعلان‌های استخر استفاده شوند. .PP .B کلمه کلیدی .I unknown-clients .PP \fBallow unknown-clients;\fR \fBdeny unknown-clients;\fR \fBignore unknown-clients;\fR .PP فلگ \fBunknown-clients\fR برای تعیین این موضوع به dhcpd استفاده می‌شود که آیا آدرس‌ها را به طور پویا به کلاینت‌های ناشناخته اختصاص دهد یا خیر. تخصیص پویای آدرس به کلاینت‌های ناشناخته به طور پیش‌فرض مجاز (\fBallow\fR) است. کلاینت ناشناخته صرفاً کلاینتی است که هیچ اعلان میزبان (host declaration) ندارد. .PP استفاده از این گزینه اکنون منسوخ (\fIdeprecated\fR) شده است. اگر سعی دارید دسترسی در شبکه خود را به کلاینت‌های شناخته‌شده محدود کنید، باید از \fBdeny unknown-clients;\fR در داخل استخر آدرس خود استفاده کنید، همان‌طور که زیر عنوان «استفاده از ALLOW و DENY در اعلان‌های استخر» شرح داده شده است. .PP .B کلمه کلیدی .I bootp .PP \fBallow bootp;\fR \fBdeny bootp;\fR \fBignore bootp;\fR .PP فلگ \fBbootp\fR برای اعلام به dhcpd به کار می‌رود که آیا به پرس‌وجوهای bootp پاسخ دهد یا خیر. پرس‌وجوهای Bootp به طور پیش‌فرض مجاز (\fBallow\fR) هستند. .PP .B کلمه کلیدی .I booting .PP \fBallow booting;\fR \fBdeny booting;\fR \fBignore booting;\fR .PP فلگ \fBbooting\fR برای اعلام به dhcpd به کار می‌رود که آیا به پرس‌وجوهای یک کلاینت خاص پاسخ دهد یا خیر. این کلمه کلیدی تنها زمانی معنا دارد که در یک اعلان میزبان ظاهر شود. به طور پیش‌فرض، بوت شدن مجاز (\fBallow\fR) است، اما اگر برای یک کلاینت خاص غیرفعال شود، آن کلاینت قادر به دریافت آدرس از سرور DHCP نخواهد بود. .PP .B کلمه کلیدی .I duplicates .PP \fBallow duplicates;\fR \fBdeny duplicates;\fR .PP اعلان‌های میزبان می‌توانند پیام‌های کلاینت را بر اساس گزینه «شناسه کلاینت DHCP» (DHCP Client Identifier) یا بر اساس نوع سخت‌افزار شبکه و آدرس MAC کلاینت مطابقت دهند. اگر از آدرس MAC استفاده شود، اعلان میزبان با هر کلاینتی که دارای آن آدرس MAC باشد مطابقت خواهد داشت \- حتی کلاینت‌هایی با شناسه‌های کلاینت متفاوت. این حالت معمولاً رخ نمی‌دهد، اما زمانی ممکن است پیش بیاید که روی یک رایانه بیش از یک سیستم‌عامل نصب شده باشد \- به عنوان مثال، مایکروسافت ویندوز و نت‌بی‌اس‌دی یا لینوکس. .PP فلگ \fBduplicates\fR به سرور DHCP اعلام می‌کند که اگر درخواستی از کلاینتی دریافت شود که با آدرس MAC یک اعلان میزبان مطابقت دارد، هرگونه اجاره دیگر متناظر با آن آدرس MAC باید توسط سرور دور انداخته شود، حتی اگر UID یکسان نباشد. این کار نقض پروتکل DHCP به شمار می‌آید، اما می‌تواند از اینکه کلاینت‌هایی که شناسه‌های کلاینت آن‌ها به طور منظم تغییر می‌کند چندین اجاره را به طور هم‌زمان نگه دارند، جلوگیری کند. به طور پیش‌فرض، موارد تکراری مجاز (\fBallow\fR) هستند. .PP .B کلمه کلیدی .I declines .PP \fBallow declines;\fR \fBdeny declines;\fR \fBignore declines;\fR .PP پیام DHCPDECLINE توسط کلاینت‌های DHCP برای نشان دادن این موضوع استفاده می‌شود که اجاره پیشنهادی سرور معتبر نیست. هنگامی که سرور یک DHCPDECLINE برای یک آدرس خاص دریافت می‌کند، به طور معمول آن آدرس را به فرض اینکه سامانه‌ای غیرمجاز در حال استفاده از آن است، رها (abandon) می‌کند. متأسفانه یک کلاینت مخرب یا دارای اشکال (buggy) می‌تواند با استفاده از پیام‌های DHCPDECLINE، استخر تخصیص سرور DHCP را کاملاً تخلیه کند. سرور در نهایت این اجاره‌ها را بازپس خواهد گرفت، اما نه در زمانی که کلاینت در حال مصرف سریع موجودی استخر است. این امر ممکن است باعث کوبش شدید (thrashing) در DNS شود، و همچنین سبب خواهد شد که سرور DHCP تخصیص آدرس‌های قبلی کلاینت‌های DHCP را فراموش کند. .PP فلگ \fBdeclines\fR به سرور DHCP اعلام می‌کند که آیا به پیام‌های DHCPDECLINE ترتیب اثر دهد یا خیر. اگر در یک حوزه مشخص روی \fBdeny\fR یا \fBignore\fR تنظیم شود، سرور DHCP به پیام‌های DHCPDECLINE پاسخ نخواهد داد. .PP فلگ \fBdeclines\fR تنها توسط سرورهای DHCPv4 پشتیبانی می‌شود. با توجه به فضای آدرس‌دهی وسیع IPv6 و محدودیت‌های داخلی اعمال‌شده توسط سازوکار تولید آدرس سرور، ما در حال حاضر وجود آن را برای سرورهای DHCPv6 ضروری نمی‌دانیم. .PP در حال حاضر، آدرس‌های رهاشدهٔ IPv6 به یکی از دو روش زیر بازپس‌گیری می‌شوند: الف) کلاینت یک آدرس مشخص را تمدید کند: اگر کلاینتی با یک DUID مشخص، یک درخواست DHCP REQUEST شامل آخرین آدرس رهاشده توسط آن DUID ارسال کند، آدرس دوباره به همان کلاینت تخصیص داده خواهد شد. ب) در دومین راه‌اندازی مجدد پس از رها شدن آدرس. هنگامی که یک آدرس رها می‌شود، هم به این صورت در فایل اجاره ثبت می‌شود و هم در حافظه سرور تا راه‌اندازی مجدد سرور به عنوان رهاشده نگهداری می‌شود. پس از راه‌اندازی مجدد، سرور فایل اجاره را پردازش کرده و تمام آدرس‌هایی که آخرین وضعیت شناخته‌شده آن‌ها رهاشده است در حافظه حفظ می‌شوند، اما مجدداً در فایل اجاره بازنویسی نخواهند شد. این بدان معناست که در راه‌اندازی مجدد بعدی سرور، آدرس‌های رهاشده در فایل اجاره مشاهده نخواهند شد و بنابراین هیچ رکوردی از آن‌ها به عنوان رهاشده در حافظه وجود نخواهد داشت و به عنوان آدرس آزاد برای تخصیص تلقی می‌شوند. .PP تعداد کل آدرس‌های یک استخر که برای یک مقدار DUID معین در دسترس هستند، به طور داخلی توسط سازوکار تولید آدرس سرور محدود شده است. اگر بر اثر پیکربندی اشتباه، چندین کلاینت از یک DUID یکسان استفاده کنند، آن‌ها برای دریافت همان آدرس‌ها رقابت خواهند کرد و باعث می‌شوند سرور خیلی سریع به این محدودیت داخلی برسد. این محدودیت داخلی این نوع فعالیت را جداسازی می‌کند تا محدوده آدرس برای سایر مقادیر DUID به پایان نرسد. ظاهر شدن لاگ خطای زیر می‌تواند نشانه‌ای از این وضعیت باشد: "Best match for DUID is an abandoned address, This may be a result of multiple clients attempting to use this DUID" که در آن مقدار واقعی DUID است که به صورت رشته‌ای از بایت‌ها با مقادیر هگزادسیمال و جداشده با دونقطه نشان داده شده است. .PP .B کلمه کلیدی .I client-updates .PP \fBallow client-updates;\fR \fBdeny client-updates;\fR .PP فلگ \fBclient-updates\fR به سرور DHCP اعلام می‌کند که آیا تمایل کلاینت را برای انجام به‌روزرسانی مستقیم رکورد A خودش محترم بشمارد یا خیر. برای جزئیات، مستندات زیر عنوان «طرح به‌روزرسانی DNS» (THE DNS UPDATE SCHEME) را ببینید. .PP .B کلمه کلیدی .I leasequery .PP \fBallow leasequery;\fR \fBdeny leasequery;\fR .PP فلگ \fBleasequery\fR به سرور DHCP اعلام می‌کند که آیا به بسته‌های DHCPLEASEQUERY پاسخ دهد یا خیر. پاسخ به یک بسته DHCPLEASEQUERY شامل اطلاعاتی در مورد یک اجاره مشخص است، مانند اینکه چه زمانی صادر شده و چه زمانی منقضی خواهد شد. به طور پیش‌فرض، سرور به این بسته‌ها پاسخ نخواهد داد. .SH "استفاده از ALLOW و DENY در اعلان‌های استخر (ALLOW AND DENY WITHIN POOL DECLARATIONS)" .PP کاربردهای کلمات کلیدی allow و deny که در بخش قبل نشان داده شد، کم‌وبیش به همان شکل عمل می‌کنند، چه کلاینت در حال ارسال پیام DHCPDISCOVER باشد و چه پیام DHCPREQUEST \- آدرسی به کلاینت تخصیص خواهد یافت (یا همان آدرس قبلی که درخواست کرده، یا یک آدرس جدید) و سپس آن آدرس آزمایش می‌شود تا بررسی شود آیا سپردن آن به کلاینت مجاز است یا خیر. اگر کلاینت آن را درخواست کرده باشد و مجاز نباشد، سرور یک پیام DHCPNAK ارسال می‌کند. در غیر این صورت، سرور صرفاً پاسخی به کلاینت نخواهد داد. اگر دادن آدرس به کلاینت مجاز باشد، سرور یک پیام DHCPACK ارسال خواهد کرد. .PP انگیزه اصلی در اعلان‌های استخر (pool)، داشتن استخرهای تخصیص آدرس با سیاست‌های تخصیص متفاوت است. ممکن است دسترسی یک کلاینت به یک استخر رد شود، اما اجازه دسترسی به استخر دیگری در همان قطعه شبکه به آن داده شود. برای اینکه این سازوکار کار کند، کنترل دسترسی باید در حین تخصیص آدرس انجام شود، نه پس از اتمام تخصیص آدرس. .PP هنگامی که یک پیام DHCPREQUEST پردازش می‌شود، تخصیص آدرس صرفاً شامل جستجوی آدرسی است که کلاینت درخواست کرده و بررسی اینکه آیا آن آدرس همچنان برای کلاینت در دسترس است یا خیر. در صورتی که در دسترس باشد، سرور DHCP هم فهرست‌های مجاز (permit lists) استخر آدرس و هم دستورات allow و deny مرتبط در درون حوزه را بررسی می‌کند تا مطمئن شود سپردن اجاره به کلاینت بلامانع است. در مورد پیام DHCPDISCOVER، فرآیند تخصیص همان‌گونه که قبلاً در بخش «تخصیص آدرس» (ADDRESS ALLOCATION) توضیح داده شد انجام می‌شود. .PP هنگام اعلان فهرست‌های مجاز برای استخرهای تخصیص آدرس، ساختارهای نحوی زیر پس از کلمات کلیدی allow یا deny شناخته می‌شوند: .PP \fBknown-clients;\fR .PP در صورت تعیین، این دستور تخصیص از این استخر را به هر کلاینتی که دارای اعلان میزبان باشد (یعنی شناخته‌شده باشد) مجاز یا ممنوع می‌کند. یک کلاینت در صورتی شناخته‌شده تلقی می‌شود که در \fIهر\fR حوزه‌ای اعلان میزبان داشته باشد، نه فقط در حوزه جاری. .PP \fBunknown-clients;\fR .PP در صورت تعیین، این دستور تخصیص از این استخر را به هر کلاینتی که هیچ اعلان میزبانی نداشته باشد (یعنی ناشناخته باشد) مجاز یا ممنوع می‌کند. .PP \fBmembers of "\fRclass\fB";\fR .PP در صورت تعیین، این دستور تخصیص از این استخر را به هر کلاینتی که عضو کلاس نام‌برده باشد مجاز یا ممنوع می‌کند. .PP \fBdynamic bootp clients;\fR .PP در صورت تعیین، این دستور تخصیص از این استخر را به هر کلاینت bootp مجاز یا ممنوع می‌کند. .PP \fBauthenticated clients;\fR .PP در صورت تعیین، این دستور تخصیص از این استخر را به هر کلاینتی که با استفاده از پروتکل احراز هویت DHCP تأیید هویت شده باشد مجاز یا ممنوع می‌کند. این ویژگی هنوز پشتیبانی نمی‌شود. .PP \fBunauthenticated clients;\fR .PP در صورت تعیین، این دستور تخصیص از این استخر را به هر کلاینتی که با استفاده از پروتکل احراز هویت DHCP تأیید هویت نشده باشد مجاز یا ممنوع می‌کند. این ویژگی هنوز پشتیبانی نمی‌شود. .PP \fBall clients;\fR .PP در صورت تعیین، این دستور تخصیص از این استخر را به تمام کلاینت‌ها مجاز یا ممنوع می‌کند. از این دستور می‌توان زمانی استفاده کرد که بخواهید به دلیلی یک اعلان استخر بنویسید اما آن را به صورت ذخیره نگه دارید، یا هنگامی که قصد دارید شبکه خود را به سرعت شماره‌گذاری مجدد (renumber) کنید، و بنابراین می‌خواهید سرور تمام کلاینت‌هایی را که از این استخر به آن‌ها آدرس تخصیص داده شده است، وادار کند که در نوبت بعدی تمدید، فوراً آدرس‌های جدیدی دریافت کنند. .PP \fBafter \fItime\fR\fB;\fR .PP در صورت تعیین، این دستور تخصیص از این استخر را پس از یک تاریخ مشخص مجاز یا ممنوع می‌کند. از این دستور می‌توان زمانی استفاده کرد که می‌خواهید کلاینت‌ها را از یک استخر به استخر دیگری منتقل کنید. سرور زمان معمول اجاره را به گونه‌ای تنظیم می‌کند که آخرین زمان انقضا در تاریخ مشخص‌شده + min-lease-time باشد. یک مقدار کوتاه برای min-lease-time باعث اعمال یکباره تغییرات می‌شود، در حالی که مقدار طولانی‌تر min-lease-time امکان تغییر تدریجی را فراهم می‌آورد. مقدار \fItime\fR یا بر حسب ثانیه از مبدأ زمان یونیکس (epoch) است، یا یک رشته زمانی UTC مانند: 4 2007/08/24 09:14:32 یا رشته‌ای با افست منطقه زمانی بر حسب ثانیه مانند: 4 2007/08/24 11:14:32 -7200 .SH "مرجع: پارامترها (REFERENCE: PARAMETERS)" دستور .I abandon-lease-time .RS 0.25i .PP .B abandon-lease-time \fItime\fR\fB;\fR .PP مقدار .I time باید حداکثر مدت زمانی (به ثانیه) باشد که یک اجاره‌نامه رهاشده IPv4 برای انتساب به یک کلاینت غیرقابل دسترس باقی می‌ماند. اجاره‌نامه‌های رهاشده تنها در صورتی به کلاینت‌ها پیشنهاد داده خواهند شد که هیچ اجاره‌نامه آزادی وجود نداشته باشد. در صورت تعریف نشدن، زمان پیش‌فرض رهاسازی اجاره‌نامه ۸۶۴۰۰ ثانیه (۲۴ ساعت) است. توجه داشته باشید که زمان رهاسازی برای یک اجاره‌نامه معین در طول راه‌اندازی‌های مجدد سرور حفظ می‌شود. این پارامتر فقط می‌تواند در حوزه سراسری (global scope) تنظیم شود و تنها یک بار هنگام راه‌اندازی سرور ارزیابی می‌گردد. .PP مقادیر کمتر از شصت ثانیه توصیه نمی‌شوند زیرا این مقدار کمتر از آستانه بررسی پینگ (ping check) است و می‌تواند باعث شود اجاره‌هایی که یک‌بار رها شده‌اند اما از آن زمان به وضعیت آزاد بازگشته‌اند، قبل از پیشنهاد شدن پینگ نشوند. اگر زمان درخواستی بزرگ‌تر از 0x7FFFFFFF - 1 باشد یا مجموع زمان فعلی به اضافه زمان رهاسازی بزرگ‌تر از 0x7FFFFFFF گردد، به عنوان بی‌نهایت در نظر گرفته می‌شود. .RE .PP دستور .I adaptive-lease-time-threshold .RS 0.25i .PP .B adaptive-lease-time-threshold \fIpercentage\fR\fB;\fR .PP هنگامی که تعداد اجاره‌نامه‌های تخصیص‌یافته در یک استخر (pool) از \fIpercentage\fR مشخص‌شده در این دستور فراتر رود، سرور DHCP مدت‌زمان اجاره را برای کلاینت‌های جدید درون این استخر به \fImin-lease-time\fR ثانیه کاهش می‌دهد. کلاینت‌هایی که اجاره‌های از قبل معتبر (طولانی) خود را تمدید می‌کنند، حداقل زمان باقی‌مانده از اجاره فعلی را دریافت می‌کنند. از آنجا که اجاره‌ها سریع‌تر منقضی می‌شوند، سرور ممکن است سریع‌تر بازیابی شود یا کاملاً از اتمام ظرفیت استخر جلوگیری کند. به محض اینکه تعداد اجاره‌های تخصیص‌یافته به زیر این آستانه برسد، سرور به زمان‌های عادی اجاره بازمی‌گردد. درصدهای معتبر بین ۱ و ۹۹ هستند. .RE .PP دستور .I always-broadcast .RS 0.25i .PP .B always-broadcast \fIflag\fR\fB;\fR .PP هر دو پروتکل DHCP و BOOTP کلاینت‌های DHCP و BOOTP را ملزم می‌کنند که بیت برودکست (broadcast bit) را در فیلد فلگ‌های هدر پیام BOOTP تنظیم کنند. متأسفانه برخی از کلاینت‌های DHCP و BOOTP این کار را انجام نمی‌دهند، و بنابراین ممکن است پاسخ‌هایی از سرور DHCP دریافت نکنند. با تنظیم این فلگ روی \'on\' برای حوزه مربوطه، می‌توان سرور DHCP را وادار کرد که همیشه پاسخ‌های خود را به کلاینت‌ها برودکست کند؛ حوزه‌های مربوطه می‌توانند داخل یک دستور شرطی، به عنوان پارامتری برای یک کلاس، یا به عنوان پارامتری برای یک اعلان میزبان (host) باشند. برای جلوگیری از ایجاد ترافیک برودکست اضافی روی شبکه شما، توصیه می‌کنیم استفاده از این گزینه را به کمترین تعداد کلاینت ممکن محدود کنید. برای مثال، مشخص است که کلاینت DHCP مایکروسافت، و همچنین کلاینت‌های OpenTransport و ISC DHCP این مشکل را ندارند. .RE .PP دستور .I always-reply-rfc1048 .RS 0.25i .PP .B always-reply-rfc1048 \fIflag\fR\fB;\fR .PP برخی از کلاینت‌های BOOTP انتظار پاسخ‌هایی به سبک RFC1048 را دارند، اما هنگام ارسال درخواست‌های خود از RFC1048 پیروی نمی‌کنند. می‌توانید متوجه شوید که کلاینتی این مشکل را دارد اگر گزینه‌هایی را که برای آن پیکربندی کرده‌اید دریافت نمی‌کند و در لاگ سرور با هر BOOTREQUEST ثبت‌شده، پیام "(non-rfc1048)" چاپ می‌شود. .PP اگر می‌خواهید گزینه‌های rfc1048 را به چنین کلاینتی ارسال کنید، می‌توانید گزینه .B always-reply-rfc1048 را در اعلان میزبان آن کلاینت تنظیم کنید، و سرور DHCP با یک فیلد گزینه‌های ارائه‌دهنده (vendor options) به سبک RFC-1048 پاسخ خواهد داد. این فلگ می‌تواند در هر حوزه‌ای تنظیم شود و بر تمام کلاینت‌های تحت پوشش آن حوزه تأثیر خواهد گذاشت. .RE .PP دستور .I authoritative .RS 0.25i .PP .B authoritative; .PP .B not authoritative; .PP سرور DHCP به‌طور معمول فرض می‌کند که درستی اطلاعات پیکربندی درباره یک سگمنت شبکه مشخص، قطعی نیست و سرور در قبال آن معتبر و تام‌الاختیار (authoritative) نیست. این به این دلیل است که اگر کاربری ناوارد یک سرور DHCP را بدون درک کامل نحوه پیکربندی آن نصب کند، پیام‌های نامعتبر DHCPNAK را به کلاینت‌هایی که آدرس‌ها را از یک سرور DHCP قانونی در شبکه دریافت کرده‌اند ارسال نکند. .PP مدیران شبکه‌ای که سرورهای DHCP معتبر (authoritative) را برای شبکه‌های خود راه‌اندازی می‌کنند، باید همیشه \fBauthoritative;\fR را در بالای فایل پیکربندی خود بنویسند تا نشان دهند که سرور DHCP \fIباید\fR به کلاینت‌هایی با پیکربندی نادرست پیام‌های DHCPNAK ارسال کند. اگر این کار انجام نشود، کلاینت‌ها پس از تغییر زیرشبکه‌ها تا زمانی که اجاره قبلی آن‌ها منقضی نشود قادر به دریافت آدرس IP صحیح نخواهند بود، که این امر ممکن است زمان بسیار زیادی به طول بینجامد. .PP معمولاً نوشتن \fBauthoritative;\fR در بالاترین سطح فایل باید کافی باشد. با این حال، اگر قرار است یک سرور DHCP به گونه‌ای تنظیم شود که از برخی شبکه‌ها که نسبت به آن‌ها معتبر است و برخی شبکه‌ها که نسبت به آن‌ها معتبر نیست آگاه باشد، ممکن است مناسب‌تر باشد که اختیارات به ازای هر سگمنت شبکه (per-network-segment) اعلان شود. .PP توجه داشته باشید که خاص‌ترین حوزه‌ای که مفهوم مرجعیت و اعتبار در آن معنی پیدا می‌کند، سگمنت فیزیکی شبکه است \- چه یک دستور shared-network باشد یا یک دستور subnet که داخل یک دستور shared-network قرار ندارد. مشخص کردن اینکه سرور برای برخی از زیرشبکه‌ها در یک شبکه مشترک معتبر است اما برای سایرین معتبر نیست، یا تعیین اینکه سرور برای برخی از اعلان‌های میزبان معتبر است و برای برخی دیگر معتبر نیست، بی‌معنی است. .PP برای اینکه سرور به پیام‌های DHCPINFORM پاسخ دهد، آن‌ها باید با زیرشبکه‌هایی مطابقت داشته باشند که سرور بر آن‌ها اختیار دارد؛ در غیر این صورت نادیده گرفته شده و در لاگ ثبت خواهند شد. برای به حداقل رساندن تأثیر بر حجم لاگ، تنها اولین و سپس هر صدمین رخداد یک DHCPINFORM نادیده‌گرفته‌شده لاگ می‌شود. .RE .PP دستور \fIboot-unknown-clients\fR .RS 0.25i .PP .B boot-unknown-clients \fIflag\fB;\fR .PP اگر دستور \fIboot-unknown-clients\fR وجود داشته باشد و مقداری برابر با \fIfalse\fR یا \fIoff\fR داشته باشد، کلاینت‌هایی که هیچ اعلان .I host (میزبانی) برای آن‌ها وجود ندارد مجاز به دریافت آدرس‌های IP نخواهند بود. اگر این دستور وجود نداشته باشد یا مقداری برابر با \fItrue\fR یا \fIon\fR داشته باشد، کلاینت‌های بدون اعلان میزبان مجاز به دریافت آدرس‌های IP خواهند بود، تا زمانی که آن آدرس‌ها توسط دستورات .I allow و \fIdeny\fR درون اعلان‌های \fIpool\fR آن‌ها محدود نشده باشند. .RE .PP دستور \fIcheck-secs-byte-order\fR .RS 0.25i .PP .B check-secs-byte-order \fIflag\fB;\fR .PP هنگامی که \fIcheck-secs-byte-order\fR فعال باشد، سرور کلاینت‌های DHCPv4 را که ترتیب بایت‌ها را در فیلد secs به نادرستی انجام می‌دهند بررسی می‌کند. این فیلد باید در ترتیب بایت شبکه (network byte order) باشد اما برخی کلاینت‌ها آن را اشتباه می‌گذارند. با فعال بودن این پارامتر، سرور فیلد secs را بررسی می‌کند و اگر نادرست به نظر برسد (بایت بالایی غیر صفر و بایت پایینی صفر)، جای بایت‌ها را معکوس (swap) می‌کند. حالت پیش‌فرض غیرفعال است. این پارامتر تنها هنگام انجام توزیع بار در failover کاربرد دارد. (پیش از این، این رفتار باید در زمان پیکربندی کامپایل از طریق --enable-secs-byteorder فعال می‌شد). .PP دستور \fIdb-time-format\fR .RS 0.25i .PP .B db-time-format \fR[ \fIdefault\fR | \fIlocal\fR ] \fB;\fR .PP نرم‌افزار سرور DHCP هنگام نوشتن اجاره‌ها در فضای ذخیره‌سازی پایدار، چندین برچسب زمانی را خروجی می‌دهد. این پارامتر پیکربندی یکی از دو قالب خروجی را انتخاب می‌کند. قالب \fIdefault\fR روز، تاریخ و زمان را به وقت UTC چاپ می‌کند، در حالی که قالب \fIlocal\fR ثانیه‌های سپری‌شده از مبدأ زمانی سیستم (seconds-since-epoch) را چاپ کرده و به شکل مفیدی روز و زمان را در منطقه زمانی سیستم درون یک کامنت ارائه می‌دهد. قالب‌های زمانی به تفصیل در صفحه راهنمای dhcpd.leases(5) شرح داده شده‌اند. .RE .PP دستور \fIddns-hostname\fR .RS 0.25i .PP .B ddns-hostname \fIname\fB;\fR .PP پارامتر \fIname\fR باید نام میزبانی (hostname) باشد که در تنظیم رکوردهای A و PTR کلاینت استفاده خواهد شد. اگر هیچ \fIddns-hostname\fR در حوزه مشخص نشده باشد، سرور نام میزبان را به طور خودکار، با استفاده از الگوریتمی که برای هر یک از روش‌های مختلف به‌روزرسانی متفاوت است، استخراج خواهد کرد. .RE .PP دستور \fIddns-domainname\fR .RS 0.25i .PP .B ddns-domainname \fIname\fB;\fR .PP پارامتر \fIname\fR باید نام دامنه‌ای باشد که برای تشکیل یک نام دامنه کاملاً واجد شرایط (FQDN) به نام میزبان کلاینت الحاق می‌شود. .RE .PP دستور \fIddns-dual-stack-mixed-mode\fR .RS 0.25i .PP .B ddns-dual-stack-mixed-mode \fIflag\fB;\fR .PP پارامتر \fIddns-dual-stack-mixed-mode\fR کنترل می‌کند که آیا سرور قواعد Dual Stack Mixed Mode را در طول حل تعارض DDNS اعمال کند یا خیر. این پارامتر به‌طور پیش‌فرض غیرفعال (off) است، هیچ تأثیری ندارد مگر اینکه update-conflict-detection فعال باشد، و فقط می‌تواند در حوزه سراسری مشخص شود. .RE .PP دستور \fIddns-guard-id-must-match\fR .RS 0.25i .PP .B ddns-guard-id-must-match \fIflag\fB;\fR .PP پارامتر \fIddns-guard-id-must-match\fR کنترل می‌کند که آیا شناسه کلاینت درون یک DHCID RR باید با شناسه کلاینتِ به‌روزرسانی DNS مطابقت داشته باشد تا اجازه بازنویسی ورودی‌های DNS مرتبط با آن DHCID RR داده شود یا خیر. حل تعارض مناسب نیازمند تطبیق شناسه است و فقط پس از بررسی دقیق باید غیرفعال شود. در صورت غیرفعال بودن، به هر به‌روزرسان DNS اجازه داده می‌شود ورودی‌های DNS دارای DHCID RR مرتبط را بدون در نظر گرفتن هویت کلاینت بازنویسی کند. این پارامتر به‌طور پیش‌فرض فعال (on) است، هیچ تأثیری ندارد مگر اینکه update-conflict-detection فعال باشد، و فقط می‌تواند در حوزه سراسری مشخص شود. .RE .PP دستورات \fIddns-local-address4\fR و \fIddns-local-address6\fR .RS 0.25i .PP .B ddns-local-address4 \fIaddress\fB;\fR .PP .B ddns-local-address6 \fIaddress\fB;\fR .PP پارامتر \fIaddress\fR باید آدرس محلی IPv4 یا IPv6 باشد که سرور باید به عنوان آدرس مبدأ هنگام ارسال درخواست‌های به‌روزرسانی DDNS استفاده کند. .RE .PP دستور \fIddns-other-guard-is-dynamic\fR .RS 0.25i .PP .B ddns-other-guard-is-dynamic \fIflag\fB;\fR .PP پارامتر \fIddns-other-guard-is-dynamic\fR کنترل می‌کند که آیا سروری که DSMM را اجرا می‌کند، وجود DHCID RR سبک به‌روزرسانی دیگر را به عنوان نشانه‌ای بر امکان بازنویسی ورودی‌های DNS در نظر می‌گیرد یا خیر. این پارامتر تنها باید پس از بررسی دقیق فعال شود، زیرا به ورودی‌های DNS که در غیر این صورت به عنوان ایستا محافظت می‌شدند اجازه می‌دهد در موارد خاصی بازنویسی شوند. این پارامتر به‌طور پیش‌فرض غیرفعال (off) است، هیچ تأثیری ندارد مگر اینکه ddns-dual-stack-mixed-mode فعال باشد، و فقط می‌تواند در حوزه سراسری مشخص شود. .RE .PP دستور \fIddns-rev-domainname\fR .RS 0.25i .PP .B ddns-rev-domainname \fIname\fB;\fR .PP پارامتر \fIname\fR باید نام دامنه‌ای باشد که برای تولید نامی جهت استفاده در رکورد PTR کلاینت، به آدرس IP معکوس‌شده کلاینت الحاق می‌شود. به طور پیش‌فرض این مقدار "in-addr.arpa." است، اما پیش‌فرض را می‌توان در اینجا بازنویسی (override) کرد. .PP آدرس IP معکوس‌شده‌ای که این نام دامنه به آن الحاق می‌شود همیشه آدرس IP کلاینت در نماد چهارگانه نقطه‌دار (dotted quad notation) به صورت معکوس است \- برای مثال، اگر آدرس IP اختصاص‌یافته به کلاینت 10.17.92.74 باشد، آدرس IP معکوس‌شده 74.92.17.10 خواهد بود. بنابراین به کلاینتی با آن آدرس IP به‌طور پیش‌فرض یک رکورد PTR به صورت 10.17.92.74.in-addr.arpa. داده می‌شود. .RE .PP پارامتر \fIddns-update-style\fR .RS 0.25i .PP .B ddns-update-style \fIstyle\fB;\fR .PP پارامتر .I style باید یکی از مقادیر \fBstandard\fR، \fBinterim\fR یا \fBnone\fR باشد. دستور \fIddns-update-style\fR تنها در حوزه بیرونی معنادار است \- این دستور پس از خواندن فایل dhcpd.conf یک بار ارزیابی می‌شود، نه هر بار که به کلاینتی یک آدرس IP اختصاص می‌یابد، بنابراین هیچ راهی برای استفاده از سبک‌های مختلف به‌روزرسانی DNS برای کلاینت‌های متفاوت وجود ندارد. مقدار پیش‌فرض \fBnone\fR است. .RE .PP .B دستور .I ddns-updates .RS 0.25i .PP \fBddns-updates \fIflag\fR\fB;\fR .PP پارامتر \fIddns-updates\fR کنترل می‌کند که آیا سرور هنگام تأیید اجاره، برای انجام به‌روزرسانی DNS تلاش کند یا خیر. اگر سرور نباید در یک حوزه خاص برای انجام به‌روزرسانی‌ها تلاش کند، این پارامتر را روی \fIoff\fR تنظیم کنید. پارامتر \fIddns-updates\fR به‌طور پیش‌فرض فعال (on) است. برای غیرفعال کردن به‌روزرسانی‌های DNS در تمام حوزه‌ها، ترجیح داده می‌شود که از دستور \fIddns-update-style\fR استفاده کرده و سبک را روی \fInone\fR قرار دهید. .RE .PP دستور .I default-lease-time .RS 0.25i .PP .B default-lease-time \fItime\fR\fB;\fR .PP مقدار .I time باید مدت‌زمانی به ثانیه باشد که در صورت عدم درخواست زمان انقضای خاص توسط کلاینتِ متقاضی اجاره، به اجاره‌نامه اختصاص داده می‌شود. این پارامتر برای هر دو نوع اجاره DHCPv4 و DHCPv6 استفاده می‌شود (در DHCPv6 با عنوان "valid lifetime" نیز شناخته می‌شود). مقدار پیش‌فرض ۴۳۲۰۰ ثانیه است. .RE .PP دستورات .I delayed-ack و .I max-ack-delay .RS 0.25i .PP .B delayed-ack \fIcount\fR\fB;\fR .PP .B max-ack-delay \fImicroseconds\fR\fB;\fR .PP مقدار .I count باید یک مقدار عدد صحیح از صفر تا 2^16-1 باشد و پیش‌فرض آن 0 است، که به معنی غیرفعال بودن این قابلیت است. در غیر این صورت، مقدار 28 می‌تواند یک نقطه شروع معقول برای بسیاری از پیکربندی‌ها باشد (اندازه SO_SNDBUF تقسیم بر 576 بایت). این شمارش نشان‌دهنده حداکثر تعداد پاسخ‌های DHCPv4 است که در صف ارسال تا پس از یک رویداد ثبت پایگاه داده (database commit) معلق می‌مانند. در صورت رسیدن به این عدد، یک رویداد ثبت در دیتابیس (که معمولاً منجر به فراخوانی fsync() شده و موجب کاهش کارایی می‌شود) انجام خواهد شد و بسته‌های پاسخ پس از آن به صورت دسته‌ای ارسال می‌گردند. این کار دستورالعمل RFC2131 مبنی بر این که «فضای ذخیره‌سازی پایدار» باید قبل از پاسخ دادن به کلاینت‌ها به‌روزرسانی شود را حفظ می‌کند. چنانچه سوکت‌های DHCPv4 «خشک شوند» (تابع select() بلافاصله بدون هیچ سوکت خواندنی بازگردد)، ثبت انجام شده و تمام بسته‌های موجود در صف ارسال می‌شوند. .PP به همین ترتیب، \fImicroseconds\fR مشخص می‌کند که چه تعداد میکروثانیه مجاز است بین صف‌بندی یک بسته در انتظار fsync و اجرای fsync سپری شود. مقادیر معتبر از 0 تا 2^32-1 متغیر است و مقدار پیش‌فرض آن ۲۵۰,۰۰۰ (۱/۴ ثانیه) است. .PP ویژگی delayed-ack به‌طور پیش‌فرض در زمان کامپایل گنجانده شده است، اما می‌توان آن را در زمان کامپایل با \'./configure --disable-delayed-ack\' غیرفعال کرد. لطفاً توجه داشته باشید که ویژگی delayed-ack در حال حاضر با پشتیبانی از DHCPv4-over-DHCPv6 سازگار نیست، بنابراین هنگامی که یک آرگومان خط فرمان پورت 4to6 این مورد را در سرور فعال می‌کند، مقدار delayed-ack به 0 بازنشانی می‌شود. .RE .PP دستور .I dhcp-cache-threshold .RS 0.25i .PP .B dhcp-cache-threshold \fIpercentage\fB;\fR .PP دستور \fIdhcp-cache-threshold\fR یک پارامتر عدد صحیح با مقادیر مجاز بین 0 و 100 می‌گیرد. مقدار پیش‌فرض 25 (۲۵٪ از مدت‌زمان اجاره) است. این پارامتر درصدی از کل مدت‌زمان اجاره را بیان می‌کند (که از ابتدای آن اندازه‌گیری می‌شود)، که در طول آن تلاش کلاینت برای تمدید اجاره‌اش منجر به دریافت همان اجاره قبلاً اختصاص‌یافته خواهد شد، نه یک اجاره تمدیدشده. این ویژگی هم برای IPv4 و هم برای IPv6 و تا سطح استخر (pool) و برای هر سه نوع استخر IPv6 شامل NA، TA و PD پشتیبانی می‌شود. .PP کلاینت‌هایی که مکرراً برای تمدید تلاش می‌کنند می‌توانند باعث شوند سرور دیتابیس را به طور مکرر به‌روزرسانی کرده و بنویسد که منجر به تأثیر منفی بر کارایی سرور می‌شود. دستور \fIdhcp-cache-threshold\fR به سرور DHCP دستور می‌دهد تا از به‌روزرسانی بیش از حد مکرر اجاره‌ها خودداری کند و در نتیجه مانع از این رفتار شود. در عوض، سرور با همان اجاره‌نامه (یعنی استفاده مجدد از آن) بدون هیچ‌گونه تغییری پاسخ می‌دهد، به جز CLTT (آخرین زمان ارسال کلاینت یا Client Last Transmission Time) و برای IPv4: مدت‌زمان اجاره ارسال‌شده به کلاینت به اندازه طول عمر اجاره کوتاه‌تر می‌شود در حالی که برای IPv6: طول عمر معتبر و ترجیحی ارسال‌شده به کلاینت به اندازه طول عمر اجاره کوتاه‌تر می‌شوند. هیچ‌یک از این تغییرات نیازی به نوشتن اجاره‌نامه روی دیسک ندارد. .PP هنگامی که یک اجاره‌نامه موجود با یک کلاینت تمدیدکننده مطابقت پیدا کند، در صورتی که تمامی شرایط زیر برقرار باشد، مجدداً استفاده خواهد شد: .nf 1. مقدار dhcp-cache-threshold بزرگ‌تر از صفر باشد 2. اجاره‌نامه فعلی فعال باشد 3. درصد سپری‌شده از مدت‌زمان اجاره کمتر از dhcp-cache-threshold باشد 4. اطلاعات کلاینت ارائه‌شده در تمدید، هیچ‌یک از موارد زیر را تغییر ندهد: a. اطلاعات DNS و فعال بودن به‌روزرسانی‌های DNS b. کلاس صورت‌حساب که اجاره با آن مرتبط است (فقط IPv4) c. اعلان میزبان مرتبط با اجاره (فقط IPv4) d. شناسه کلاینت \- این اتفاق ممکن است زمانی رخ دهد که کلاینت بدون شناسه کلاینت بوت شود و سپس در درخواست‌های بعدی شروع به استفاده از آن کند. (فقط IPv4) .fi .PP در حالی که داده‌های اجاره‌نامه هنگام استفاده مجدد روی دیسک نوشته نمی‌شوند، سرور همچنان هرگونه دستور on-commit را اجرا خواهد کرد. .PP توجه داشته باشید که اگر گزینه‌هایی که کلاینت یا عامل رله (relay agent) ارسال می‌کند تغییر کنند، اجاره می‌تواند مجدداً استفاده شود. این تغییرات تا زمانی که کلاینت پس از رسیدن به زمان آستانه تمدید کند، در پایگاه‌های داده درون حافظه یا روی دیسک ثبت نخواهند شد. .RE .PP دستور .I do-forward-updates .RS 0.25i .PP .B do-forward-updates \fIflag\fB;\fR .PP دستور \fIdo-forward-updates\fR به سرور DHCP مشخص می‌کند که آیا هنگام دریافت یا تمدید اجاره توسط کلاینت، باید برای به‌روزرسانی رکورد A کلاینت DHCP تلاش کند یا خیر. این دستور هیچ تأثیری ندارد مگر اینکه به‌روزرسانی‌های DNS فعال باشند. به‌روزرسانی‌های رو به جلو (forward updates) به‌طور پیش‌فرض فعال هستند. اگر از این دستور برای غیرفعال کردن به‌روزرسانی‌های رو به جلو استفاده شود، سرور DHCP هرگز برای به‌روزرسانی رکورد A کلاینت تلاش نخواهد کرد، و تنها در صورتی برای به‌روزرسانی رکورد PTR کلاینت اقدام خواهد کرد که کلاینت یک FQDN ارائه دهد که باید با استفاده از گزینه \fBfqdn\fR در رکورد PTR قرار گیرد. اگر به‌روزرسانی‌های رو به جلو فعال باشند، سرور DHCP همچنان به تنظیمات فلگ \fBclient-updates\fR پایبند خواهد بود. .RE .PP دستور .I dont-use-fsync .RS 0.25i .PP .B dont-use-fsync \fIflag\fB;\fR .PP دستور \fIdont-use-fsync\fR به سرور DHCP مشخص می‌کند که آیا هنگام نوشتن اجاره‌ها در فایل اجاره، باید fsync() را فراخوانی کند یا خیر. به‌طور پیش‌فرض و اگر فلگ روی false تنظیم شده باشد، سرور \fBحتماً\fR fsync() را فراخوانی خواهد کرد. جلوگیری از فراخوانی fsync() ممکن است کارایی سرور را افزایش دهد، اما این ریسک را نیز به همراه دارد که اجاره‌نامه پس از صدور برای کلاینت و قبل از توقف سرور، به‌درستی روی دیسک نوشته نشود. این امر می‌تواند منجر به صدور اجاره‌های تکراری برای کلاینت‌های مختلف شود. استفاده از این گزینه \fBتوصیه نمی‌شود\fR. .RE.PP دستور .I dynamic-bootp-lease-cutoff .RS 0.25i .PP .B dynamic-bootp-lease-cutoff \fIdate\fB;\fR .PP دستور \fIdynamic-bootp-lease-cutoff\fR زمان پایان را برای تمامی اجاره‌هایی که به‌صورت پویا به کلاینت‌های BOOTP اختصاص یافته‌اند تنظیم می‌کند. از آنجا که کلاینت‌های BOOTP راهکاری برای تمدید اجاره ندارند و مطلع نیستند که ممکن است اجاره‌هایشان منقضی شود، به‌طور پیش‌فرض dhcpd اجاره‌های نامحدود به تمامی کلاینت‌های BOOTP اختصاص می‌دهد. با این حال، در برخی شرایط ممکن است تعیین یک تاریخ انقضا (قطع) برای تمام اجاره‌های BOOTP منطقی باشد؛ برای مثال، پایان یک دوره آموزشی یا ساعتی در شب که یک مرکز بسته شده و همه دستگاه‌ها باید خاموش شوند. .PP مقدار .I Date باید تاریخی باشد که تمام اجاره‌های اختصاص‌یافته‌ی BOOTP در آن به پایان می‌رسند. تاریخ به شکل زیر مشخص می‌شود: .PP .ce 1 W YYYY/MM/DD HH:MM:SS .PP مقدار W روز هفته است که به‌صورت عددی از صفر (یکشنبه) تا شش (شنبه) مشخص می‌شود. YYYY سال به همراه قرن است. MM ماه است که به‌صورت عددی از ۱ تا ۱۲ بیان می‌شود. DD روز ماه است که از ۱ شمارش می‌شود. HH ساعت از صفر تا ۲۳ است. MM دقیقه و SS ثانیه است. زمان همیشه بر اساس ساعت هماهنگ جهانی (UTC) است، نه زمان محلی. .RE .PP دستور .I dynamic-bootp-lease-length .RS 0.25i .PP .B dynamic-bootp-lease-length\fR \fIlength\fR\fB;\fR .PP دستور \fIdynamic-bootp-lease-length\fR برای تنظیم مدت‌زمان اجاره‌هایی که به‌طور پویا به کلاینت‌های BOOTP تخصیص داده می‌شوند به کار می‌رود. در برخی مراکز، ممکن است بتوان فرض کرد که اگر دارنده یک اجاره در طول یک بازه زمانی مشخص از BOOTP یا DHCP برای دریافت آدرس خود استفاده نکرده باشد، آن اجاره دیگر در حال استفاده نیست. این بازه در \fIlength\fR برحسب تعداد ثانیه‌ها مشخص می‌شود. اگر کلاینتی در طول دوره انقضا با استفاده از BOOTP راه‌اندازی مجدد شود، مدت‌زمان اجاره به اندازه \fIlength\fR بازنشانی می‌گردد؛ بنابراین کلاینت BOOTP که به اندازه کافی راه‌اندازی شود هرگز اجاره خود را از دست نخواهد داد. ناگفته نماند که این پارامتر باید با نهایت احتیاط تنظیم شود. .RE .PP دستور .I echo-client-id .RS 0.25i .PP .B echo-client-id\fR \fIflag\fR\fB;\fR .PP دستور \fIecho-client-id\fR برای فعال یا غیرفعال کردن رفتار منطبق با استاندارد RFC 6842 استفاده می‌شود. اگر دستور echo-client-id وجود داشته باشد و مقدار آن true یا on باشد، و یک پیام DHCP DISCOVER یا REQUEST دریافت شود که حاوی گزینه شناسه کلاینت (کد گزینه ۶۱) باشد، سرور طبق RFC 6842 این گزینه را در پاسخ خود (DHCP ACK یا NAK) کپی می‌کند. به عبارت دیگر، اگر کلاینت این گزینه را بفرستد، آن را بازپس خواهد گرفت. به‌طور پیش‌فرض، این فلگ خاموش است و شناسه‌های کلاینت به کلاینت بازتاب داده نمی‌شوند. .RE .PP دستور .I filename .RS 0.25i .PP .B filename\fR \fB"\fR\fIfilename\fR\fB";\fR .PP از دستور \fIfilename\fR می‌توان برای تعیین نام فایل راه‌اندازی اولیه که قرار است توسط کلاینت بارگذاری شود استفاده کرد. مقدار .I filename باید نام فایلی باشد که برای پروتکل انتقال فایل مورد استفاده کلاینت جهت بارگذاری فایل قابل تشخیص باشد. .RE .PP اعلان .I fixed-address .RS 0.25i .PP .B fixed-address address\fR [\fB,\fR \fIaddress\fR ... ]\fB;\fR .PP اعلان \fIfixed-address\fR برای تخصیص یک یا چند آدرس IP ثابت به یک کلاینت به کار می‌رود. این اعلان فقط باید در یک اعلان \fIhost\fR ظاهر شود. اگر بیش از یک آدرس ارائه شود، کلاینت هنگام راه‌اندازی، آدرسی را دریافت می‌کند که متناظر با شبکه‌ای باشد که کلاینت روی آن راه‌اندازی می‌شود. اگر هیچ‌یک از آدرس‌های موجود در دستور \fIfixed-address\fR برای شبکه‌ای که کلاینت به آن متصل است معتبر نباشد، آن کلاینت با اعلان \fIhost\fR حاوی این اعلان \fIfixed-address\fR تطبیق داده نمی‌شود. هر \fIaddress\fR در اعلان \fIfixed-address\fR باید یک آدرس IP یا یک نام دامنه باشد که به یک یا چند آدرس IP تحلیل می‌شود. .RE .PP اعلان .I fixed-address6 .RS 0.25i .PP .B fixed-address6 ip6-address\fR ;\fR .PP اعلان \fIfixed-address6\fR برای تخصیص یک آدرس IPv6 ثابت به یک کلاینت به کار می‌رود. این اعلان تنها باید در یک اعلان \fIhost\fR ظاهر شود. .RE .PP اعلان .I fixed-prefix6 .RS 0.25i .PP .B fixed-prefix6\fR \fIlow-address\fR \fB/\fR \fIbits\fR\fB;\fR .PP اعلان \fIfixed-prefix6\fR برای تخصیص یک پیشوند IPv6 ثابت به یک کلاینت به کار می‌رود. این اعلان فقط باید در یک اعلان \fIhost\fR ظاهر شود، اما چندین دستور \fIfixed-prefix6\fR می‌توانند در یک اعلان \fIhost\fR منفرد قرار گیرند. .PP مقدار \fIlow-address\fR شروع پیشوند و \fIbits\fR اندازه پیشوند را برحسب بیت مشخص می‌کند. .PP اگر چندین پیشوند برای یک مدخل میزبان مشخص وجود داشته باشد، سرور پیشوندی را انتخاب می‌کند که با اندازه پیشوند درخواستی مطابقت داشته باشد یا اگر هیچ‌کدام مطابقت نداشته باشند، اولین مورد را برمی‌گزیند. .PP اگر چندین اعلان \fIhost\fR وجود داشته باشد، سرور تلاش خواهد کرد اعلانی را انتخاب کند که در آن \fIfixed-address6\fR با زیرشبکه کلاینت مطابقت داشته باشد. اگر هیچ‌یک تطابق نداشته باشند، اعلانی را برمی‌گزیند که فاقد دستور \fIfixed-address6\fR باشد. .PP نکته مهم: بر خلاف آدرس ثابت، پیشوند ثابت برای ارائه شدن نیازی به مطابقت با یک زیرشبکه ندارد. این ویژگی به شما اجازه می‌دهد پیشوندی را به کلاینتی ارائه دهید که خارج از زیرشبکه‌ای است که کلاینت روی آن درخواستش را به سرور ارسال می‌کند. .RE .PP دستور .I get-lease-hostnames .RS 0.25i .PP .B get-lease-hostnames\fR \fIflag\fR\fB;\fR .PP دستور \fIget-lease-hostnames\fR برای این استفاده می‌شود که به dhcpd اعلام کند آیا نام دامنه متناظر با هر آدرس IP در استخر اجاره (lease pool) را جستجو کرده و از آن آدرس برای گزینه DHCP به نام \fIhostname\fR استفاده کند یا خیر. اگر \fIflag\fR برابر با true باشد، این جستجو برای تمام آدرس‌های موجود در حوزه جاری انجام می‌شود. به‌طور پیش‌فرض، یا در صورتی که \fIflag\fR برابر با false باشد، هیچ جستجویی انجام نمی‌شود. .RE .PP دستور .I hardware .RS 0.25i .PP .B hardware \fIhardware-type hardware-address\fB;\fR .PP برای شناسایی یک کلاینت BOOTP، آدرس سخت‌افزاری شبکه آن باید با استفاده از یک بند \fIhardware\fR در دستور .I host اعلان شود. .I hardware-type باید نام یک نوع رابط سخت‌افزاری فیزیکی باشد. در حال حاضر تنها انواع .B ethernet و .B token-ring شناسایی می‌شوند، گرچه پشتیبانی از نوع سخت‌افزاری .B fddi (و موارد دیگر) نیز مطلوب خواهد بود. مقدار .I hardware-address باید مجموعه‌ای از هشت‌بیتی‌های (اکتت‌های) هگزادسیمال (اعداد از 0 تا ff) باشد که با دونقطه از هم جدا شده‌اند. از دستور \fIhardware\fR می‌توان برای کلاینت‌های DHCP نیز استفاده کرد. .RE .PP دستور .I host-identifier option .RS 0.25i .PP .B host-identifier option \fIoption-name option-data\fB;\fR .PP یا .PP .B host-identifier v6relopt \fInumber option-name option-data\fB;\fR .PP این دستور کلاینت DHCPv6 را در دستور .I host شناسایی می‌کند. .I option-name هر گزینه‌ای است، و .I option-data مقداری برای آن گزینه است که کلاینت ارسال خواهد کرد. مقدار .I option-data باید یک مقدار ثابت باشد. در حالت v6relopts، عدد اضافی نشان‌دهنده رله‌ای است که باید برای نام گزینه و مقدار مشخص‌شده بررسی شود. این مقادیر مانند مقادیر گزینه v6relay هستند. عدد 0 نشان‌دهنده عدم اقدام (no-op) است، ۱ رله‌ی نزدیک‌تر به کلاینت، ۲ رله بعدی و به همین ترتیب است. مقادیری که بزرگتر از حداکثر تعداد رله‌ها (در حال حاضر ۳۲) باشند، صرف‌نظر از عدد دقیق، نزدیک‌ترین رله به سرور را نشان می‌دهند. .RE .PP دستور .I ignore-client-uids .RS 0.25i .PP .B ignore-client-uids \fIflag\fB;\fR .PP اگر دستور \fIignore-client-uids\fR وجود داشته باشد و مقدار آن \fItrue\fR یا \fIon\fR باشد، شناسه یکتای UID برای کلاینت‌ها ثبت نخواهد شد. اگر این دستور وجود نداشته باشد یا مقدار آن \fIfalse\fR یا \fIoff\fR باشد، شناسه UID کلاینت‌ها ثبت خواهد شد. .RE .PP دستور .I infinite-is-reserved .RS 0.25i .PP .B infinite-is-reserved \fIflag\fB;\fR .PP نرم‌افزار ISC DHCP اکنون از اجاره‌های «رزروشده» (\'reserved\') پشتیبانی می‌کند. بخش «اجاره‌های رزروشده» (RESERVED LEASES) را در ادامه ببینید. اگر این \fIflag\fR روشن (on) باشد، سرور به‌طور خودکار اجاره‌های تخصیص‌یافته به کلاینت‌هایی را که زمان اجاره نامحدود (0xffffffff) درخواست کرده‌اند رزرو خواهد کرد. .PP مقدار پیش‌فرض off (خاموش) است. .RE .PP دستور .I lease-file-name .RS 0.25i .PP .B lease-file-name \fIname\fB;\fR .PP .I Name که در آن \fIname\fR نام فایل اجاره سرور DHCP است. به‌طور پیش‌فرض این مقدار DBDIR/dhcpd.leases است. این دستور \fBباید\fR در دامنه بیرونی (outer scope) فایل پیکربندی ظاهر شود؛ اگر در دامنه دیگری ظاهر شود هیچ اثری نخواهد داشت. مقدار باید مسیر مطلق فایل مورد استفاده باشد. ترتیب اولویتی که سرور برای نام فایل اجاره استفاده می‌کند به این شرح است: .PP 1. دستور \fBlease-file-name\fR در فایل پیکربندی. 2. فلگ خط فرمان \fB\-lf\fR. 3. متغیر محیطی \fBPATH_DHCPD_DB\fR. .RE .PP دستور .I dhcpv6-lease-file-name .RS 0.25i .PP .B dhcpv6-lease-file-name \fIname\fB;\fR .PP که در آن \fIname\fR نام فایل اجاره سرور DHCP در زمان اجرای DHCPv6 است. به‌طور پیش‌فرض این مقدار DBDIR/dhcpd6.leases است. این دستور \fBباید\fR در دامنه بیرونی فایل پیکربندی ظاهر شود؛ اگر در دامنه دیگری ظاهر شود هیچ اثری نخواهد داشت. مقدار باید مسیر مطلق فایلی باشد که استفاده می‌شود. ترتیب اولویتی که سرور برای نام فایل اجاره به کار می‌برد به شرح زیر است: .PP 1. دستور \fBdhcpv6-lease-file-name\fR در فایل پیکربندی. 2. فلگ خط فرمان \fB\-lf\fR. 3. متغیر محیطی \fBPATH_DHCPD6_DB\fR. .RE .PP پارامتر .I lease-id-format .RS 0.25i .PP .B lease-id-format \fIformat\fB;\fR .PP پارامتر \fIformat\fR باید \fBoctal\fR یا \fBhex\fR باشد. این پارامتر تعیین‌کننده قالب مورد استفاده برای نوشتن برخی مقادیر در فایل‌های اجاره است. در قالب پیش‌فرض یعنی octal (هشت‌هشتی)، مقادیر به‌صورت رشته‌های داخل گیومه نوشته می‌شوند که در آن‌ها نویسه‌های غیرقابل‌چاپ به‌صورت دنباله‌های گریز هشت‌هشتی نمایش داده می‌شوند؛ یک نویسه بک‌اسلش که به دنبال آن سه رقم هشت‌هشتی می‌آید. هنگامی که قالب hex (شانزده‌شانزدهی) مشخص شود، مقادیر به‌صورت دنباله‌ای بدون گیومه از جفت‌ارقام هگزادسیمال که با دونقطه از هم جدا شده‌اند نوشته می‌شوند. در حال حاضر مقادیری که بر اساس lease-id-format نوشته می‌شوند عبارتند از server-duid، مقدار uid (اجاره‌های DHCPv4)، و IAID_DUID (اجاره‌های DHCPv6). توجه داشته باشید که سرور به‌طور خودکار مقادیر را در هر دو قالب می‌خواند. .RE .PP دستور .I limit-addrs-per-ia .RS 0.25i .PP .B limit-addrs-per-ia \fInumber\fB;\fR .PP به‌طور پیش‌فرض، سرور DHCPv6 کلاینت‌ها را به یک IAADDR به ازای هر گزینه IA محدود می‌کند، به این معنی که یک آدرس تعلق می‌گیرد. اگر مایلید به کلاینت‌ها اجازه دهید چندین آدرس را به‌طور همزمان در اختیار داشته باشند، عدد \fInumber\fR بزرگ‌تری را در اینجا تنظیم کنید. .PP توجه داشته باشید که در حال حاضر روشی برای پیکربندی سرور جهت وادار کردن کلاینت به پیکربندی با یک آدرس IP به ازای هر زیرشبکه در یک شبکه مشترک وجود ندارد. این موضوع به کارهای آینده واگذار شده است. .RE .PP دستور .I local-port .RS 0.25i .PP .B local-port \fIport\fB;\fR .PP این دستور باعث می‌شود سرور DHCP به‌جای پورت ۶۷، روی پورت UDP مشخص‌شده در \fIport\fR به درخواست‌های DHCP گوش دهد. .RE .PP دستور .I local-address .RS 0.25i .PP .B local-address \fIaddress\fB;\fR .PP این دستور باعث می‌شود سرور DHCP به درخواست‌های DHCP ارسال‌شده به \fIaddress\fR مشخص گوش دهد، نه به درخواست‌های ارسالی به تمام آدرس‌ها. از آنجا که سرویس‌دهی به کلاینت‌های DHCP با اتصال مستقیم به این معنی است که سرور باید به درخواست‌های ارسال‌شده به آدرس برودکست تمام‌یک (all-ones IP address) پاسخ دهد، در صورتی که کلاینت‌ها روی شبکه‌های متصل مستقیم باشند نمی‌توان از این گزینه استفاده کرد؛ این گزینه از نظر عملی تنها برای سروری کاربرد دارد که تمام کلاینت‌های آن از طریق یونیکست (unicast)، مانند عامل‌های رله DHCP، در دسترس هستند. .PP نکته: این دستور تنها در صورتی موثر است که سرور با استفاده از دستور تعریف USE_SOCKETS #define کامپایل شده باشد؛ که این امر در تعداد کمی از سیستم‌های عامل پیش‌فرض است و برای سایر سیستم‌ها باید در زمان کامپایل صریحاً انتخاب شود. اگر خطوطی با این فرمت را در زمان راه‌اندازی مشاهده کنید، می‌توانید مطمئن شوید که سرور شما با USE_SOCKETS کامپایل شده است: .PP Listening on Socket/eth0 .PP همچنین توجه داشته باشید از آنجا که این دستور تمامی سوکت‌های DHCP را با ()bind به آدرس مشخص متصل می‌کند، در یک دیمن در هر زمان مشخص تنها می‌توان از یک آدرس پشتیبانی کرد. .RE .PP دستورهای .I local-address6 و .I bind-local-address6 .RS 0.25i .PP .B local-address6 \fIaddress\fB;\fR .PP .B bind-local-address6 \fIflag\fB;\fR .PP دستور \fIlocal-address6\fR باعث می‌شود سرور DHCP بسته‌های IPv6 را به‌گونه‌ای ارسال کند که مبدأ آن‌ها \fIaddress\fR مشخص‌شده‌ی IPv6 باشد، به‌جای آنکه اجازه دهد کرنل فیلد آدرس مبدأ را پر کند. .PP هنگامی که \fIbind-local-address6\fR وجود داشته باشد و مقدار آن true یا on باشد، سوکت‌های سرویس نیز به \fIaddress\fR متصل (bind) می‌شوند. .PP به‌طور پیش‌فرض، مقدار \fIaddress\fR آدرس تعریف‌نشده است و \fIbind-local-address6\fR غیرفعال است؛ هر دوی آن‌ها تنها می‌توانند در دامنه سراسری (global scope) تنظیم شوند. .RE .PP دستور .I log-facility .RS 0.25i .PP .B log-facility \fIfacility\fB;\fR .PP این دستور باعث می‌شود سرور DHCP پس از خواندن فایل dhcpd.conf تمام ثبت وقایع خود را روی تسهیلات لاگ (log facility) مشخص‌شده انجام دهد. به‌طور پیش‌فرض سرور DHCP وقایع را در تسهیلات daemon ثبت می‌کند. تسهیلات لاگ ممکن شامل auth، authpriv، cron، daemon، ftp، kern، lpr، mail، mark، news، ntp، security، syslog، user، uucp و local0 تا local7 هستند. تمام این تسهیلات روی همه سیستم‌ها موجود نیستند و ممکن است تسهیلات دیگری نیز روی سایر سیستم‌ها وجود داشته باشد. .PP علاوه بر تنظیم این مقدار، ممکن است لازم باشد فایل .I syslog.conf خود را برای پیکربندی ثبت وقایع سرور DHCP ویرایش کنید. برای مثال، می‌توانید خطی مانند این اضافه کنید: .PP .nf local7.debug /var/log/dhcpd.log .fi .PP ساختار نگارشی فایل \fIsyslog.conf\fR ممکن است در برخی سیستم‌های عامل متفاوت باشد — برای اطمینان به صفحه راهنمای \fIsyslog.conf\fR مراجعه کنید. برای اینکه syslog شروع به ثبت وقایع در فایل جدید کند، ابتدا باید فایل را با مالکیت و مجوزهای دسترسی صحیح ایجاد کنید (معمولاً همان مالک و مجوزهای فایل /var/log/messages یا /usr/adm/messages شما مناسب خواهد بود) و یک سیگنال SIGHUP به syslogd ارسال کنید. برخی سیستم‌ها از چرخش فایل لاگ با استفاده از یک اسکریپت شل یا برنامه‌ای به نام newsyslog یا logrotate پشتیبانی می‌کنند و شما می‌توانید این مورد را نیز پیکربندی کنید تا فایل لاگ شما به‌طور مهارنشدنی رشد نکند. .PP از آنجا که تنظیم \fIlog-facility\fR توسط فایل dhcpd.conf کنترل می‌شود، پیام‌های لاگی که هنگام تجزیه فایل dhcpd.conf یا پیش از تجزیه آن چاپ می‌شوند، در تسهیلات لاگ پیش‌فرض ثبت می‌گردند. برای جلوگیری از این موضوع، فایل README همراه با این توزیع را ببینید که در آن نحوه تغییر تسهیلات لاگ پیش‌فرض شرح داده شده است (اشکال: این موضوع در کجای README ذکر شده است؟). هنگامی که از این پارامتر استفاده می‌شود، سرور DHCP پیام راه‌اندازی خود را یک بار دیگر پس از تجزیه فایل پیکربندی چاپ می‌کند تا لاگ تا حد امکان کامل باشد. .RE .PP دستورهای .I log-threshold-high و .I log-threshold-low .RS 0.25i .PP .B log-threshold-high \fIpercentage\fB;\fR .PP .B log-threshold-low \fIpercentage\fB;\fR .PP دستورهای \fIlog-threshold-low\fR و \fIlog-threshold-high\fR برای کنترل زمان ارسال پیام در مورد میزان استفاده از استخر (pool) به کار می‌روند. مقدار هر دوی آن‌ها درصدی از استخر است که در حال استفاده می‌باشد. اگر آستانه بالا 0 باشد یا مشخص نشده باشد، هیچ پیامی تولید نخواهد شد. اگر آستانه بالا تعیین شود، پس از اینکه میزان استفاده از استخر از آن سطح فراتر رفت، پیامی صادر می‌شود. پس از آن، تا زمانی که میزان مصرف استخر به زیر آستانه پایین نرسد، پیام دیگری ثبت نخواهد شد. اگر آستانه پایین مشخص نشود، مقدار پیش‌فرض آن صفر خواهد بود. .PP یک حالت خاص زمانی رخ می‌دهد که آستانه پایین بالاتر از آستانه بالا تنظیم شده باشد. در این حالت، هر بار که اجاره‌ای تایید (acknowledge) شود و میزان استفاده از استخر بالاتر از آستانه بالا باشد، پیامی ایجاد خواهد شد. .PP توجه داشته باشید که ثبت گزارش آستانه برای زیرشبکه‌های اشتراکی (shared subnets) که تعداد کل آدرس‌های آن‌ها بیشتر از (2^64)-1 باشد، به صورت خودکار غیرفعال خواهد شد. سرور در هنگام راه‌اندازی، در صورت غیرفعال شدن لاگ‌گیری آستانه، پیامی در گزارش ثبت می‌کند که در زیر نشان داده شده است: "Threshold logging disabled for shared subnet of ranges: " این مورد احتمالاً هیچ تاثیر عملی در زمان اجرا نخواهد داشت، زیرا بعید است پردازنده‌ها بتوانند از سروری پشتیبانی کنند که عملاً به چنین تعداد عظیمی از اجاره‌ها برسد. .RE .PP دستور .I max-lease-time .RS 0.25i .PP .B max-lease-time \fItime\fR\fB;\fR .PP .I Time باید حداکثر مدت‌زمان (بر حسب ثانیه) باشد که به یک اجاره (lease) اختصاص می‌یابد. در صورت عدم تعریف، مقدار پیش‌فرض حداکثر زمان اجاره ۸۶۴۰۰ است. تنها استثنا در این مورد، طول اجاره‌های پویای BOOTP است که توسط کلاینت تعیین نمی‌شوند و به این حداکثر محدود نمی‌گردند. .RE .PP دستور .I min-lease-time .RS 0.25i .PP .B min-lease-time \fItime\fR\fB;\fR .PP .I Time باید حداقل مدت‌زمان (بر حسب ثانیه) باشد که به یک اجاره اختصاص می‌یابد. مقدار پیش‌فرض، کمترین مقدار بین ۳۰۰ ثانیه یا \fBmax-lease-time\fR است. .RE .PP دستور .I min-secs .RS 0.25i .PP .B min-secs \fIseconds\fR\fB;\fR .PP .I Seconds باید حداقل تعداد ثانیه‌هایی باشد که از شروع تلاش کلاینت برای دریافت یک اجاره جدید سپری شده است، پیش از آنکه سرور DHCP به درخواست آن پاسخ دهد. تعداد ثانیه‌ها بر اساس گزارش ارائه‌شده توسط کلاینت است و حداکثر مقداری که کلاینت می‌تواند گزارش کند ۲۵۵ ثانیه می‌باشد. به طور کلی، تنظیم این مقدار روی ۱ باعث می‌شود که سرور DHCP به نخستین درخواست کلاینت پاسخ ندهد، اما همواره به درخواست دوم آن پاسخ دهد. .PP این دستور می‌تواند برای راه‌اندازی یک سرور DHCP ثانویه به کار رود که هرگز آدرسی را به کلاینت پیشنهاد نمی‌دهد، مگر اینکه ابتدا به سرور اصلی فرصت انجام این کار داده شده باشد. اگر سرور اصلی از کار افتاده باشد، کلاینت به سرور ثانویه متصل می‌شود، اما در غیر این صورت کلاینت‌ها باید همواره به سرور اصلی متصل گردند. توجه داشته باشید که این موضوع به خودی خود به سرور اصلی و سرور ثانویه اجازه نمی‌دهد که یک استخر از آدرس‌های قابل تخصیص پویا را به اشتراک بگذارند. .RE .PP دستور .I next-server .RS 0.25i .PP .B next-server\fR \fIserver-name\fR\fB;\fR .PP دستور \fInext-server\fR برای مشخص کردن آدرس میزبان سروری به کار می‌رود که فایل بوت اولیه (مشخص‌شده در دستور \fIfilename\fR) باید از آن بارگیری شود. \fIServer-name\fR باید یک آدرس IP عددی یا یک نام دامنه باشد. .RE .PP دستور .I omapi-port .RS 0.25i .PP .B omapi-port\fR \fIport\fR\fB;\fR .PP دستور \fIomapi-port\fR باعث می‌شود سرور DHCP روی پورت مشخص‌شده به اتصالات OMAPI گوش فرا دهد. این دستور برای فعال کردن پروتکل OMAPI الزامی است؛ پروتکلی که برای بررسی و اصلاح وضعیت سرور DHCP در حین اجرا به کار می‌رود. .RE .PP دستور .I one-lease-per-client .RS 0.25i .PP .B one-lease-per-client \fIflag\fR\fB;\fR .PP اگر این پرچم فعال باشد، هر زمان که یک کلاینت یک درخواست DHCPREQUEST برای یک اجاره خاص ارسال کند، سرور به طور خودکار سایر اجاره‌هایی را که در اختیار کلاینت است آزاد خواهد کرد. این رفتار فرض می‌کند که وقتی کلاینت یک DHCPREQUEST ارسال می‌کند، هر اجاره‌ای را که در DHCPREQUEST ذکر نشده فراموش کرده است - یعنی کلاینت تنها یک رابط شبکه دارد .I و اجاره‌هایی را که در شبکه‌هایی که در حال حاضر به آن‌ها متصل نیست در اختیار دارد، به خاطر نمی‌آورد. هیچ‌یک از این فرضیات تضمین‌شده یا قابل اثبات نیستند، بنابراین توصیه می‌کنیم در استفاده از این دستور احتیاط کنید. .RE .PP دستور .I persist-eui-64-leases .RS 0.25i .PP .B persist-eui-64-leases \fIflag\fR\fB;\fR .PP هنگامی که این پرچم فعال باشد، سرور اجاره‌های مبتنی بر EUI-64 را در فایل اجاره‌ها می‌نویسد. از آنجا که چنین اجاره‌هایی همواره فقط برای یک مقدار DUID واحد معتبر هستند، می‌توان استدلال کرد که نوشتن آن‌ها در فایل اجاره‌ها ضروری نیست و عدم انجام این کار ممکن است مزایای عملکردی به همراه داشته باشد. برای جزئیات بیشتر در مورد تخصیص آدرس مبتنی بر EUI-64، به دستور \fIuse-eui-64\fR مراجعه کنید. این پرچم به طور پیش‌فرض فعال است و فقط در دامنه سراسری (global scope) قابل تنظیم می‌باشد. .RE .PP دستور .I pid-file-name .RS 0.25i .PP .B pid-file-name .I name\fR\fB;\fR .PP .I Name باید نام فایل شناسه فرآیند (PID) سرور DHCP باشد. این فایلی است که شناسه فرآیند سرور DHCP هنگام راه‌اندازی سرور در آن ذخیره می‌شود. به طور پیش‌فرض، این فایل RUNDIR/dhcpd.pid است. همانند دستور \fIlease-file-name\fR، این دستور نیز باید در دامنه بیرونی فایل پیکربندی قرار گیرد. ترتیب اولویت مورد استفاده توسط سرور به شرح زیر است: .PP 1. دستور \fBpid-file-name\fR در فایل پیکربندی. 2. فلگ خط فرمان \fB-lf\fR. 3. متغیر محیطی \fBPATH_DHCPD_PID\fR. .PP دستور .I dhcpv6-pid-file-name .RS 0.25i .PP .B dhcpv6-pid-file-name \fIname\fB;\fR .PP .I Name نام فایل pid است که فقط و فقط در صورتی استفاده می‌شود که سرور در حالت DHCPv6 در حال اجرا باشد. به طور پیش‌فرض، این فایل DBDIR/dhcpd6.pid است. این دستور، همانند \fIpid-file-name\fR، \fBباید\fR در دامنه بیرونی فایل پیکربندی قرار گیرد. ترتیب اولویت مورد استفاده توسط سرور به شرح زیر است: .PP 1. دستور \fBdhcpv6-pid-file-name\fR در فایل پیکربندی. 2. فلگ خط فرمان \fB-lf\fR. 3. متغیر محیطی \fBPATH_DHCPD6_PID\fR. .PP .RE .PP دستور .I ping-check .RS 0.25i .PP .B ping-check .I flag\fR\fB;\fR .PP هنگامی که سرور DHCP در حال بررسی تخصیص پویای یک آدرس IP به یک کلاینت است، ابتدا یک درخواست ICMP Echo (یک \fIping\fR) به آدرسی که قرار است اختصاص یابد ارسال می‌کند. سرور یک ثانیه منتظر می‌ماند و اگر هیچ پاسخ ICMP Echo دریافت نشود، آدرس را تخصیص می‌دهد. اگر پاسخی شنیده \fIشود\fR، اجاره رها (abandoned) می‌شود و سرور به کلاینت پاسخ نمی‌دهد. اجاره برای حداقل مدت‌زمان مشخص‌شده در abandon-lease-time (بر حسب ثانیه) در وضعیت رهاشده باقی خواهد ماند. .PP اگر هیچ آدرس آزادی وجود نداشته باشد اما آدرس‌های IP رهاشده موجود باشند، سرور DHCP بدون در نظر گرفتن مقدار abandon-lease-time تلاش خواهد کرد یک آدرس IP رهاشده را بازپس‌گیری (reclaim) کند. .PP این \fIping check\fR یک تاخیر پیش‌فرض یک‌ثانیه‌ای در پاسخ به پیام‌های DHCPDISCOVER ایجاد می‌کند، که می‌تواند برای برخی کلاینت‌ها مشکل‌ساز باشد. این تاخیر پیش‌فرض یک‌ثانیه‌ای را می‌توان با استفاده از پارامتر ping-timeout پیکربندی کرد. از پارامتر پیکربندی ping-check می‌توان برای کنترل این بررسی استفاده کرد - اگر مقدار آن false باشد، هیچ بررسی پینگی انجام نمی‌شود. .RE .PP دستور .I ping-cltt-secs .RS 0.25i .PP .B ping-cltt-secs .I seconds\fR\fB;\fR .PP سرور در صورتی بررسی پینگ را انجام خواهد داد که تمامی شرایط زیر برقرار باشند: .PP 1. بررسی پینگ فعال باشد. .PP 2. سرور در حال پاسخ‌گویی به یک DISCOVER باشد. .PP 3. اجاره‌ای که قرار است پیشنهاد شود، نه ایستا باشد و نه فعال (یعنی همچنان یک اجاره معتبر باشد). .PP 4. و هر یک از موارد زیر برقرار باشد: a. این نخستین پیشنهاد این اجاره باشد (مقدار CLTT برابر 0 باشد). b. اجاره به کلاینتی غیر از مالک پیشین آن پیشنهاد شود. c. اجاره به مالک پیشین آن پیشنهاد شود و بیش از \fBping-cltt-secs\fR ثانیه از CLTT اجاره اولیه سپری شده باشد. d. اجاره رها شده باشد و سرور در حال تلاش برای بازپس‌گیری مجدد آن باشد. .PP دستور \fBping-cltt-secs\fR به کاربر امکان می‌دهد مدت‌زمانی را که باید پس از CLTT سپری شود تا بررسی پینگ انجام شود، مشخص کند. مقدار پیش‌فرض شصت ثانیه است. .RE .PP دستور .I ping-timeout .RS 0.25i .PP .B ping-timeout .I seconds\fR\fB;\fR .PP اگر سرور DHCP به دلیل true بودن دستور ping-check تشخیص دهد که باید یک درخواست ICMP echo (یک \fIping\fR) ارسال کند، ping-timeout به شما امکان می‌دهد پیکربندی کنید که سرور DHCP چند ثانیه باید منتظر دریافت پاسخ ICMP Echo بماند. اگر پیش از پایان مهلت زمانی (timeout)، هیچ پاسخ ICMP Echo دریافت نشود، سرور آدرس را تخصیص می‌دهد. اگر پاسخی شنیده \fIشود\fR، اجاره رها می‌گردد و سرور به کلاینت پاسخ نمی‌دهد. اگر مقداری تنظیم نشود، پیش‌فرض ping-timeout برابر ۱ ثانیه است. (همچنین ping-timeout-ms را در زیر ببینید) .RE .PP دستور .I ping-timeout-ms .RS 0.25i .PP .B ping-timeout-ms .I milliseconds\fR\fB;\fR .PP به شما امکان می‌دهد مهلت زمانی پینگ را به جای ثانیه بر حسب میلی‌ثانیه تعیین کنید. اگر این مقدار بزرگ‌تر از صفر باشد، سرور از آن به جای ping-timeout استفاده خواهد کرد. مقدار پیش‌فرض صفر است. .RE .PP دستور .I preferred-lifetime .RS 0.25i .PP .B preferred-lifetime .I seconds\fR\fB;\fR .PP آدرس‌های IPv6 دارای طول‌عمرهای «معتبر» (valid) و «ترجیحی» (preferred) هستند. طول‌عمر معتبر تعیین می‌کند که یک اجاره در چه زمانی منقضی تلقی می‌شود و دیگر قابل استفاده نخواهد بود. طول‌عمر ترجیحی یک وضعیت توصیه‌ای (advisory) است تا به برنامه‌ها کمک کند از این آدرس به آدرس‌های معتبر فعلی جابه‌جا شوند (در صورتی که همچنان سوکت‌های باز TCP یا موارد مشابه وجود داشته باشد). .PP طول‌عمر ترجیحی به طور پیش‌فرض برابر با ۵/۸ مدت‌زمان پیش‌فرض اجاره است. .RE .PP دستور .I prefix-length-mode .RS 0.25i .PP .B prefix-length-mode .I mode\fR\fB;\fR .PP طبق RFC 3633، کلاینت‌های DHCPv6 می‌توانند هنگام درخواست پیشوندها، با قرار دادن گزینه IA_PD Prefix در گزینه IA_PD، اولویت‌های خود را مشخص کنند. از جمله اولویت‌هایی که می‌توان منتقل کرد، «prefix-length» است. هنگامی که این مقدار غیرصفر باشد، طول مورد نظر کلاینت برای پیشوندهای پیشنهادی را مشخص می‌کند. این RFC بیان می‌کند که سرورها «می‌توانند از این اطلاعات برای انتخاب پیشوند(ها) استفاده کنند»، اما هیچ قاعده خاصی را برای انجام این کار مشخص نمی‌کند. دستور prefix-length-mode می‌تواند برای تعیین قواعد انتخاب پیشوند مورد استفاده توسط سرور، هنگامی که کلاینت‌ها یک مقدار prefix-length غیرصفر ارسال می‌کنند، به کار رود. پارامتر mode باید یکی از مقادیر \fBignore\fR، \fBprefer\fR، \fBexact\fR، \fBminimum\fR یا \fBmaximum\fR باشد که در آن: .PP 1. ignore \- طول درخواستی نادیده گرفته می‌شود. سرور اولین پیشوند در دسترس را پیشنهاد خواهد داد. .PP 2. prefer \- سرور اولین پیشوند در دسترسی را که طولی برابر با طول درخواستی دارد پیشنهاد می‌دهد. اگر هیچ موردی یافت نشود، اولین پیشوند در دسترس با هر طولی را پیشنهاد خواهد کرد. این رفتار پیش‌فرض است. .PP 3. exact \- سرور اولین پیشوند در دسترسی را که دقیقاً همان طول درخواستی را دارد پیشنهاد می‌دهد. اگر موردی یافت نشود، وضعیتی را بازمی‌گرداند که نشان‌دهنده در دسترس نبودن هیچ پیشوندی است. .PP 4. minimum \- سرور اولین پیشوند در دسترسی را با همان طول درخواستی پیشنهاد می‌دهد. اگر موردی یافت نشود، اولین پیشوند در دسترسی را بازمی‌گرداند که طول آن بزرگ‌تر از (مثلاً طولانی‌تر از) مقدار درخواستی باشد. اگر هیچ‌یک از آن‌ها یافت نشود، وضعیتی را بازمی‌گرداند که نشان‌دهنده در دسترس نبودن هیچ پیشوندی است. به عنوان مثال، اگر کلاینت طولی معادل 60/ درخواست کند و سرور پیشوندهایی با طول 56/ و 64/ در دسترس داشته باشد، پیشوندی با طول 64/ را پیشنهاد خواهد داد. .PP 5. maximum \- سرور اولین پیشوند در دسترسی را با همان طول درخواستی پیشنهاد می‌دهد. اگر موردی یافت نشود، اولین پیشوند در دسترسی را بازمی‌گرداند که طول آن کمتر از (مثلاً کوتاه‌تر از) مقدار درخواستی باشد. اگر هیچ‌یک از آن‌ها یافت نشود، وضعیتی را بازمی‌گرداند که نشان‌دهنده در دسترس نبودن هیچ پیشوندی است. به عنوان مثال، اگر کلاینت طولی معادل 60/ درخواست کند و سرور پیشوندهایی با طول 56/ و 64/ در دسترس داشته باشد، پیشوندی با طول 56/ را پیشنهاد خواهد داد. .PP به طور کلی «اولین در دسترس» بر اساس ترتیبی تعیین می‌شود که استخرها در پیکربندی سرور تعریف شده‌اند. برای مثال، اگر یک زیرشبکه با سه استخر پیشوند A، B و C تعریف شده باشد: .PP .nf subnet 3000::/64 { # pool A pool6 { : } # pool B pool6 { : } # pool C pool6 { : } } .fi .PP آنگاه استخرها به ترتیب A، B و C بررسی خواهند شد. برای حالت‌های \fBprefer\fR، \fBminimum\fR و \fBmaximum\fR این ممکن است به معنای بررسی دو باره استخرها با همان ترتیب باشد. در مرحله نخست، بررسی برای یافتن یک پیشوند در دسترس با دقیقاً همان طول ترجیحی انجام می‌شود. اگر موردی یافت نشود، مرحله دوم با شروع از استخر A اما با معیارهای طول تنظیم‌شده مناسب انجام می‌پذیرد. .RE .PP دستور .I release-on-roam .RS 0.25i .PP .B release-on-roam \fIflag\fB;\fR .PP در صورت فعال بودن و هنگامی که سرور dhcpd تشخیص دهد که یک کلاینت DHCPv6 (ترکیب IAID+DUID) به یک شبکه جدید منتقل (roam) شده است، اجاره‌های قبلی روی شبکه پیشین را آزاد کرده و پیامی در لاگ مشابه زیر صادر می‌کند: "Client: roamed to new network, releasing lease:
" سرور تمامی مراحل یکسانی را انجام خواهد داد که معمولاً هنگام آزادسازی صریح یک اجاره توسط کلاینت رخ می‌دهد. هنگامی که release-on-roam غیرفعال باشد (حالت پیش‌فرض)، سرور چنین اجاره‌هایی را تا زمان انقضای آن‌ها یا راه‌اندازی مجدد سرور غیرقابل دسترس نگه می‌دارد. کلاینت‌هایی که به اجاره در چندین شبکه نیاز دارند، باید یک IAID یکتا در هر IA ارائه دهند. این پارامتر فقط در سطح سراسری (global) قابل تعیین است. .RE .PP دستور .I remote-port .RS 0.25i .PP .B remote-port \fIport\fB;\fR .PP این دستور باعث می‌شود سرور DHCP به جای پورت ۶۸، پاسخ‌های DHCP را از طریق پورت UDP مشخص‌شده در \fIport\fR به کلاینت‌های DHCP ارسال کند. در صورتی که پاسخ UDP به یک رله DHCP ارسال شود، سرور عموماً از مقدار پیکربندی \fBlocal-port\fR استفاده می‌کند. با این حال، چنانچه نشانی رله DHCP برابر با 127.0.0.1 باشد، سرور DHCP پاسخ خود را به مقدار پیکربندی \fBremote-port\fR ارسال می‌نماید. این قابلیت معمولاً فقط برای مقاصد آزمایشی مفید است و از این مقدار پیکربندی عموماً نباید استفاده شود. .RE .PP دستور .I server-identifier .RS 0.25i .PP .B server-identifier \fIhostname\fR\fB;\fR .PP دستور server-identifier می‌تواند برای تعریف مقداری که در گزینه شناسه سرور DHCP (DHCP Server Identifier) برای یک حوزه معین ارسال می‌شود به کار رود. مقدار مشخص‌شده \fBباید\fR یک نشانی IP برای سرور DHCP باشد و باید توسط تمام کلاینت‌هایی که توسط یک حوزه خاص سرویس‌دهی می‌شوند قابل دسترسی باشد. .PP استفاده از دستور server-identifier توصیه نمی‌شود \- تنها دلیل استفاده از آن، اجبار به ارسال مقداری غیر از مقدار پیش‌فرض در شرایطی است که مقدار پیش‌فرض نادرست باشد. مقدار پیش‌فرض، نخستین نشانی IP مرتبط با رابط شبکه فیزیکی است که درخواست از طریق آن دریافت شده است. .PP حالت معمول که در آن دستور \fIserver-identifier\fR باید ارسال شود زمانی است که یک رابط فیزیکی بیش از یک نشانی IP داشته باشد، و نشانی‌ای که به طور پیش‌فرض ارسال می‌شود برای برخی یا همه کلاینت‌های سرویس‌گیرنده از آن رابط مناسب نباشد. مورد متداول دیگر زمانی است که یک نام مستعار (alias) به منظور داشتن یک نشانی IP پایدار برای سرور DHCP تعریف شده باشد و تمایل بر این باشد که کلاینت‌ها هنگام ارتباط با سرور از این نشانی IP استفاده کنند. .PP ارائه مقداری برای گزینه dhcp-server-identifier معادل استفاده از دستور server-identifier است. .RE .PP دستور .I server-id-check .RS 0.25i .PP .B server-id-check \fIflag\fR\fB;\fR .PP دستور server-id-check برای کنترل این موضوع به کار می‌رود که آیا سرور حاضر در ساختار failover، پیش از پردازش درخواست، مطابقت مقدار گزینه dhcp-server-identifier را در درخواست‌های DHCP REQUEST دریافتی با شناسه سرور بررسی کند یا خیر. بررسی شناسه سرور به صورت پیش‌فرض غیرفعال است. تنظیم این پرچم بررسی شناسه را فعال می‌کند و پس از آن سرور فقط درخواست‌های منطبق را پردازش خواهد کرد. توجه داشته باشید که تنظیم این پرچم باید میان شرکای failover سازگار و یکسان باشد. .PP مگر در صورت بازنویسی با استفاده از دستور server-identifier، مقداری که سرور به عنوان شناسه خود استفاده می‌کند نخستین نشانی IP مرتبط با رابط فیزیکی شبکه خواهد بود که درخواست از طریق آن وارد شده است. .PP به منظور کاهش سربار زمان اجرا، سرور گزینه شناسه سرور را تنها در حوزه‌های سراسری (global) و زیرشبکه (subnet) بررسی می‌کند. پیکربندی‌های پیچیده ممکن است به شناسه‌های سرور متفاوتی برای این بررسی و در زمان تعیین شناسه سرور برای یک بسته پاسخ منجر شود، که مانع از پاسخ‌گویی سرور خواهد شد. .PP کاربرد اصلی این گزینه زمانی است که یک کلاینت درخواستی را به صورت همگانی (broadcast) ارسال می‌کند اما نیاز دارد که پاسخ حتماً از سوی یک همتای failover مشخص دریافت شود. نمونه‌ای از این حالت زمانی است که یک کلاینت در حالی که اجاره‌اش هنوز فعال است راه‌اندازی مجدد می‌شود \- در این شرایط معمولاً هر دو سرور پاسخ می‌دهند. بیشتر اوقات کلاینت شناسه سرور را بررسی نمی‌کند و می‌تواند از هر یک از پاسخ‌ها استفاده کند. با این حال، اگر کلاینت شناسه سرور را بررسی کند، چنانچه پاسخ از همتای اشتباه آمده باشد ممکن است آن را رد کند. اگر زمان‌بندی به شکلی باشد که اغلب همتای «اشتباه» ابتدا پاسخ دهد، ممکن است کلاینت تا مدتی نتواند نشانی دریافت کند. .PP پیش از فعال‌سازی این گزینه باید احتیاط لازم به عمل آید. .PP .RE .PP دستور .I server-duid .RS 0.25i .PP .B server-duid \fILLT\fR [ \fIhardware-type\fR \fItimestamp\fR \fIhardware-address\fR ] \fB;\fR .B server-duid \fIEN\fR \fIenterprise-number\fR \fIenterprise-identifier\fR \fB;\fR .B server-duid \fILL\fR [ \fIhardware-type\fR \fIhardware-address\fR ] \fB;\fR .PP دستور server-duid شناسه DUID سرور را پیکربندی می‌کند. می‌توانید یکی از گزینه‌های LLT (نشانی پیوند محلی به علاوه زمان)، EN (سازمانی یا enterprise)، یا LL (نشانی پیوند محلی) را انتخاب کنید. .PP اگر LLT یا LL را انتخاب کنید، می‌توانید محتوای دقیق DUID را مشخص نمایید. در غیر این صورت سرور یک DUID از نوع مشخص‌شده تولید خواهد کرد. .PP اگر EN را انتخاب نمایید، باید enterprise number (شماره سازمانی) و enterprise-identifier (شناسه سازمانی) را درج کنید. .PP اگر دستور server-duid در فایل اجاره (lease file) وجود داشته باشد، بر دستور server-duid موجود در فایل پیکربندی اولویت خواهد داشت و گزینه dhcp6.server-id در فایل پیکربندی هر دوی آن‌ها را بازنویسی خواهد کرد. .PP نوع پیش‌فرض server-duid برابر با LLT است. .RE .PP دستور .I server-name .RS 0.25i .PP .B server-name "\fIname\fB";\fR .PP دستور \fIserver-name\fR می‌تواند برای آگاه ساختن کلاینت از نام سروری که از آن بوت می‌شود به کار رود. \fIName\fR باید نامی باشد که به کلاینت ارائه خواهد شد. .RE .PP دستور .I dhcpv6-set-tee-times .RS 0.25i .PP .B dhcpv6-set-tee-times\fR \fIflag\fR\fB;\fR .PP دستور \fIdhcpv6-set-tee-times\fR امکان تنظیم T1 و T2 را روی مقادیر توصیه‌شده در RFC 3315 (بخش ۲۲.۴) فراهم می‌کند. هنگام تنظیم T1 و T2، سرور به ترتیب از dhcp-renewal-time و dhcp-rebinding-time استفاده خواهد کرد. مقدار صفر به کلاینت می‌گوید که می‌تواند مقدار مورد نظر خود را انتخاب کند. هنگامی که این گزینه‌ها تعریف نشده باشند، مقادیر روی صفر تنظیم خواهند شد مگر آنکه دستور سراسری \fIdhcpv6-set-tee-times\fR فعال باشد. وقتی این گزینه فعال باشد، زمان‌ها مطابق با توصیه بخش ۲۲.۴ سند RFC 3315 محاسبه می‌شوند: مقدار T1 برابر با 0.5 برابر کوتاه‌ترین طول عمر ترجیحی (preferred lifetime) در پاسخ تنظیم خواهد شد. اگر «کوتاه‌ترین» طول عمر ترجیحی 0xFFFFFFFF باشد، T1 برابر با 0xFFFFFFFF تنظیم می‌شود. مقدار T2 برابر با 0.8 برابر کوتاه‌ترین طول عمر ترجیحی در پاسخ تنظیم خواهد شد. اگر «کوتاه‌ترین» طول عمر ترجیحی 0xFFFFFFFF باشد، T2 برابر با 0xFFFFFFFF تنظیم می‌شود. به یاد داشته باشید که در صورت کوچک بودن بیش از حد طول عمر اجاره‌ها، محاسبات فوق باعث برابر شدن این دو مقدار خواهد شد. برای مثال، یک طول عمر اجاره ۹ ثانیه‌ای منجر به T1 = T2 = 4 ثانیه می‌شود، که سبب می‌گردد کلاینت‌ها تنها درخواست‌های rebind ارسال کنند. در چنین حالتی احتمالاً بهتر است مقادیر به صورت صریح تعریف شوند. توجه داشته باشید که dhcpv6-set-tee-times برای دوره گذار در نظر گرفته شده و به احتمال زیاد در نسخه‌های آینده حذف خواهد شد. پس از حذف، رفتار سرور این خواهد بود که در صورت وجود، از مقادیر پیکربندی‌شده استفاده کند یا آن‌ها را مطابق با RFC محاسبه نماید. اگر خواهان مقادیر صفر هستید، آن‌ها را به عنوان صفر تعریف کنید. .RE .PP دستور .I site-option-space .RS 0.25i .PP .B site-option-space "\fIname\fB";\fR .PP دستور \fIsite-option-space\fR می‌تواند برای تعیین اینکه گزینه‌های محلی سایت (site-local) از کدام فضای گزینه‌ای برگرفته شوند استفاده شود. این دستور تا حد زیادی به همان شیوه دستور \fIvendor-option-space\fR قابل استفاده است. گزینه‌های محلی سایت در DHCP آن دسته از گزینه‌هایی هستند که کدهای عددی آن‌ها بزرگ‌تر از ۲۲۴ است. این گزینه‌ها برای کاربردهای مختص سایت در نظر گرفته شده‌اند، اما غالباً توسط سازندگان سخت‌افزارهای تعبیه‌شده (embedded) که حاوی کلاینت‌های DHCP هستند مورد استفاده قرار می‌گیرند. از آنجا که گزینه‌های ویژه سایت بر مبنای نیاز مقطعی (ad hoc) تخصیص می‌یابند، کاملاً امکان‌پذیر است که کلاینت DHCP یک سازنده از همان کد گزینه‌ای استفاده کند که کلاینت سازنده دیگری برای مقاصد دیگر استفاده می‌کند. گزینه \fIsite-option-space\fR می‌تواند برای تخصیص مجموعه‌ای متفاوت از گزینه‌های ویژه سایت برای هر یک از این سازندگان با بهره‌گیری از ارزیابی شرطی (برای جزئیات بیشتر به \fBdhcp-eval (5)\fR مراجعه کنید) به کار گرفته شود. .RE .PP دستور .I stash-agent-options .RS 0.25i .PP .B stash-agent-options \fIflag\fB;\fR .PP اگر پارامتر \fIstash-agent-options\fR برای یک کلاینت مفروض true باشد، سرور گزینه‌های اطلاعات عامل رله ارسال‌شده در طول پیام اولیه DHCPREQUEST کلاینت هنگامی که در وضعیت SELECTING بود را ضبط می‌کند و به گونه‌ای رفتار می‌نماید که گویی آن گزینه‌ها در تمامی پیام‌های بعدی DHCPREQUEST ارسال‌شده در وضعیت RENEWING نیز لحاظ شده‌اند. این ویژگی مشکلی در گزینه‌های اطلاعات عامل رله را دور می‌زند؛ این نقص که آن‌ها معمولاً در پیام‌های DHCPREQUEST ارسال‌شده توسط کلاینت در وضعیت RENEWING ظاهر نمی‌شوند، چرا که این پیام‌ها مستقیماً و به صورت unicast به سرور فرستاده می‌شوند و از یک عامل رله عبور نمی‌کنند. .RE .PP دستور .I update-conflict-detection .RS 0.25i .PP .B update-conflict-detection \fIflag\fB;\fR .PP اگر پارامتر \fIupdate-conflict-detection\fR دارای مقدار true باشد، سرور تشخیص تداخل استاندارد DHCID چند کلاینت، تک‌نامی (multiple-client, one-name) را انجام خواهد داد. اگر پارامتر روی false تنظیم شده باشد، سرور این بررسی را نادیده می‌گیرد و در عوض به سادگی هرگونه انتساب (binding) پیشین را لغو کرده و پیوند جدید را بدون پرسش مستقر می‌سازد. مقدار پیش‌فرض true است و این پارامتر تنها می‌تواند در حوزه سراسری (global scope) مشخص شود. .RE .PP دستور .I update-optimization .RS 0.25i .PP .B update-optimization \fIflag\fB;\fR .PP اگر پارامتر \fIupdate-optimization\fR برای یک کلاینت معین false باشد، سرور هر بار که کلاینت اجاره‌اش را تمدید می‌کند برای آن کلاینت تلاش به به‌روزرسانی DNS می‌نماید، نه فقط زمانی که به‌روزرسانی ضروری به نظر برسد. این امر به پایگاه داده DNS اجازه می‌دهد تا با آسانی بیشتری از ناسازگاری‌ها بهبود یابد، اما هزینه‌اش این است که سرور DHCP باید به‌روزرسانی‌های DNS به مراتب بیشتری را انجام دهد. توصیه ما فعال نگه داشتن این گزینه است که حالت پیش‌فرض نیز می‌باشد. اگر این پارامتر تعیین نشده باشد یا true باشد، سرور DHCP تنها زمانی به‌روزرسانی را انجام می‌دهد که اطلاعات کلاینت تغییر کند، کلاینت اجاره دیگری دریافت نماید یا اجاره کلاینت منقضی شود. .RE .PP دستور .I update-static-leases .RS 0.25i .PP .B update-static-leases \fIflag\fB;\fR .PP پرچم \fIupdate-static-leases\fR، در صورت فعال بودن، سبب می‌شود سرور DHCP به‌روزرسانی‌های DNS را برای کلاینت‌ها انجام دهد حتی اگر نشانی IP آن کلاینت‌ها با استفاده از دستور \fIfixed-address\fR یا \fIfixed-address6\fR اختصاص داده شده باشد \- یعنی به کلاینت یک تخصیص ایستا داده شده باشد. استفاده از آن توصیه نمی‌شود چرا که سرور DHCP هیچ راهی برای تشخیص اینکه به‌روزرسانی انجام شده است ندارد و بنابراین هنگام عدم استفاده از رکورد، آن را حذف نخواهد کرد. همچنین سرور باید هر بار که کلاینت اجاره خود را تمدید می‌کند تلاش برای به‌روزرسانی را تکرار کند، که می‌تواند در محیط‌هایی با تقاضای بالا بر سرور DHCP تأثیر چشمگیری بر کارایی بگذارد. این ویژگی برای هر دو پروتکل DHCPv4 و DHCPv6، و حالت‌های به‌روزرسانی standard یا interim پشتیبانی می‌شود. این ویژگی به طور پیش‌فرض غیرفعال است. .RE .PP دستور .I use-eui-64 .RS 0.25i .PP .B use-eui-64 \fIflag\fB;\fR .PP (پشتیبانی از این قابلیت باید در زمان کامپایل فعال شده باشد، به EUI_64 در includes/site.h رجوع کنید) پرچم \fIuse-eui-64\fR، در صورت فعال بودن، به سرور دستور می‌دهد تا به جای ساختن نشانی با استفاده از الگوریتم پویا، نشانی را با استفاده از DUID با فرمت EUI-64 کلاینت (نوع ۳، نوع سخت‌افزار EUI-64) ایجاد کند. این بدان معناست که یک DUID معین همیشه همان نشانی را برای یک استخر معین تولید می‌کند و علاوه بر آن یکتا بودن نشانی برای آن DUID تضمین می‌گردد. نشانی IPv6 بر مبنای نشانی لایه پیوند EUI-64 مطابق با RFC 2373 محاسبه خواهد شد، مگر آنکه یک اعلان host برای client-id وجود داشته باشد. دستور range6 برای EUI-64 باید محدوده‌های کامل ۶۴ بیتی (/64) را تعریف کند. محدوده‌های نامعتبر در طول تجزیه پیکربندی به عنوان خطا علامت زده می‌شوند. مثال زیر را ببینید: subnet6 fc00:e4::/64 { use-eui-64 true; range6 fc00:e4::/64; } این دستور می‌تواند تا سطح استخر (pool) نیز تعیین گردد و امکان ترکیبی از استخرهای پویا و مبتنی بر EUI-64 را فراهم آورد. در طول تجزیه فایل اجاره، هر اجاره‌ای که به یک استخر EUI-64 نگاشت شود و دارای DUID غیر EUI-64 باشد یا نشانی اجاره برای آن DUID در آن استخر نشانیِ EUI-64 نباشد، نادیده گرفته شده و دور انداخته می‌شود. اگر اعلان میزبانی (host) برای DUID وجود داشته باشد، سرور بدون توجه به نوع DUID کلاینت (حتی برای DUIDهای EUI-64) نشانی را طبق اعلان میزبان (fixed-prefix6، fixed-address6) اختصاص می‌دهد. اگر کلاینتی درخواست یک اجاره EUI-64 برای شبکه مشخصی داشته باشد و نشانی به‌دست‌آمده با یک رزرو نشانی ثابت تداخل پیدا کند، سرور پاسخ «no addresses available» (نشانی در دسترسی نیست) را برای کلاینت ارسال می‌نماید. هر کلاینتی با DUID نامنطبق (غیر از نوع ۳ یا دارای نوع سخت‌افزار غیر EUI-64) که به یک اعلان میزبان متصل نباشد و از یک استخر فعال برای EUI-64 درخواست نشانی کند، نادیده گرفته شده و رویداد ثبت خواهد شد. استخرهایی که برای EUI-64 پیکربندی شده‌اند برای تخصیص پویا نادیده گرفته می‌شوند. اگر استخری در شبکه اشتراکی برای تخصیص موجود نباشد، کلاینت وضعیت no addresses available را دریافت خواهد کرد. در یک استخر فعال‌شده با EUI-64، هر کلاینتی با DUID نوع ۳ و سخت‌افزار EUI-64 که درخواست solicit/renew ارسال کند و حاوی IA_NA باشد که با خط‌مشی EUI-64 همخوانی ندارد، برای پیام آن کلاینت به گونه‌ای رفتار خواهد شد که گویی خارج از زیرشبکه است: پیام Solicit - سرور با زیرگزینه ia از نوع EUI-64 اما بدون rapid commit تبلیغ می‌کند پیام Request - سرور وضعیت «an address not on link status» و بدون زیرگزینه ia ارسال می‌کند پیام Renew/Rebind - سرور زیرگزینه ia نشانی درخواستی را با طول عمر صفر به همراه یک ia از نوع EUI-64 ارسال می‌کند اینکه آیا اجاره‌های مبتنی بر EUI-64 در پایگاه داده اجاره ذخیره شوند یا خیر، با استفاده از دستور \fIpersist-eui-64-leases\fR قابل کنترل است. .RE .PP دستور .I use-host-decl-names .RS 0.25i .PP .B use-host-decl-names \fIflag\fB;\fR .PP اگر پارامتر \fIuse-host-decl-names\fR در یک حوزه مشخص true باشد، آن‌گاه برای هر اعلان میزبان (host declaration) درون آن حوزه، نام ارائه‌شده برای اعلان میزبان به عنوان نام میزبان (hostname) در اختیار کلاینت قرار می‌گیرد. بنابراین برای نمونه، .PP .nf 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"; } .fi .PP علاوه بر این، فعال‌سازی use-host-decl-names به سرور دستور می‌دهد در صورتی که هیچ مقدار دیگری در دسترس نباشد، از نام اعلان میزبان در نام DNS مستقیم (forward DNS) استفاده کند. این فرآیند گزینش مقدار با جزئیات بیشتر در بخش به‌روزرسانی‌های DNS مورد بحث قرار گرفته است. .PP دستور \fIoption host-name\fR درون یک اعلان میزبان بر استفاده از نام موجود در اعلان میزبان اولویت داشته و آن را لغو می‌کند. .PP در اینجا باید متذکر شد که اکثر کلاینت‌های DHCP گزینه host-name ارسال‌شده توسط سرور DHCP را کاملاً نادیده می‌گیرند و هیچ راهی برای پیکربندی آن‌ها جهت جلوگیری از این رفتار وجود ندارد. بنابراین شما عموماً باید بین نداشتن نگاشت نام میزبان به نشانی IP کلاینت که برای کلاینت قابل شناسایی باشد، یا انجام به‌روزرسانی‌های DNS یکی را برگزینید. بررسی نحوه اتخاذ این تصمیم فراتر از چارچوب این سند است. .RE .PP دستور .I use-lease-addr-for-default-route .RS 0.25i .PP .B use-lease-addr-for-default-route \fIflag\fR\fB;\fR .PP اگر پارامتر \fIuse-lease-addr-for-default-route\fR در یک حوزه معین true باشد، آن‌گاه به جای ارسال مقدار مشخص‌شده در گزینه routers (یا عدم ارسال هیچ مقداری)، نشانی IP همان اجاره‌ای که در حال تخصیص است به کلاینت فرستاده می‌شود. این رفتار ظاهراً باعث می‌شود سیستم‌های Win95 برای تمامی نشانی‌های IP اقدام به ارسال درخواست ARP کنند، که اگر مسیریاب شما برای proxy ARP پیکربندی شده باشد می‌تواند مفید واقع شود. استفاده از این ویژگی توصیه نمی‌شود چرا که برای بسیاری از کلاینت‌های DHCP کار نخواهد کرد. .RE .PP دستور .I vendor-option-space .RS 0.25i .PP .B vendor-option-space \fIstring\fR\fB;\fR .PP پارامتر \fIvendor-option-space\fR تعیین می‌کند که گزینه‌های سازنده (vendor options) از کدام فضای گزینه‌ای برگرفته شوند. کاربرد این پارامتر پیکربندی در صفحه راهنمای \fBdhcp-options(5)\fR در بخش \fIVENDOR ENCAPSULATED OPTIONS\fR تشریح شده است. .RE .SH "تنظیم مقادیر پارامترها با استفاده از عبارات (SETTING PARAMETER VALUES USING EXPRESSIONS)" گاهی اوقات تنظیم مقدار یک پارامتر سرور DHCP بر مبنای مقداری که توسط کلاینت ارسال شده است مفید می‌باشد. برای این کار می‌توانید از ارزیابی عبارات استفاده کنید. صفحه راهنمای .B dhcp-eval(5) نحوه نوشتن عبارات را توصیف می‌کند. برای انتساب نتیجه یک ارزیابی به یک پارامتر، آن را به شکل زیر تعریف نمایید: .nf .sp 1 \fImy-parameter \fB= \fIexpression \fB;\fR .fi .PP برای نمونه: .nf .sp 1 ddns-hostname = binary-to-ascii (16, 8, "-", substring (hardware, 1, 6)); .fi .RE .SH "اجاره‌های رزروشده (RESERVED LEASES)" اغلب سودمند است که یک نشانی منفرد را به صورت تقریباً همیشگی به یک کلاینت اختصاص داد. دستورات host همراه با بندهای \fBfixed-address\fR تا حدودی به همین منظور وجود دارند، اما از آنجا که هدف از دستورات host نزدیک شدن به یک «پیکربندی ایستا» است، از این نقص رنج می‌برند که در سلسله‌ای از دیگر سرویس‌های سرور، نظیر DNS پویا، failover، «رویدادهای on» و غیره مورد ارجاع واقع نمی‌شوند. .PP اگر یک اجاره پویای استاندارد، مانند آنچه از هر دستور range حاصل می‌شود، با برچسب «reserved» (رزروشده) علامت‌گذاری شود، سرور این اجاره را تنها به کلاینتی که با آن مشخص شده است (خواه با شناسه کلاینت یا نشانی سخت‌افزاری) تخصیص خواهد داد. .PP در عمل، این بدان معناست که اجاره از ماشین وضعیت عادی پیروی می‌کند، زمانی که کلاینت به آن متصل می‌شود وارد وضعیت ACTIVE می‌گردد، منقضی می‌شود یا آزاد می‌گردد، و هر رویداد یا سرویسی که به طور معمول در طول این رویدادها ارائه می‌شود مانند سایر اجاره‌های پویا به طور عادی پردازش می‌گردد. تنها تفاوت این است که سرورهای failover با اجاره‌های رزروشده هنگام ورود به وضعیت‌های FREE یا BACKUP رفتار خاصی دارند \- هر سرور اجاره را در وضعیتی اعمال می‌کند که مجاز به تخصیص از آن باشد \- و این اجاره‌ها در صف تخصیص به سایر کلاینت‌ها قرار نمی‌گیرند. در عوض آن‌ها تنها از طریق هویت کلاینت قابل «یافتن» هستند. در نتیجه، اجاره منحصراً به کلاینت بازگشتی پیشنهاد داده می‌شود. .PP احتمالاً باید مراقبت شود تا اطمینان حاصل گردد که کلاینت در یک زیرشبکه مشخص تنها دارای یک اجاره است که با آن شناسایی می‌شود. .PP اجاره‌ها می‌توانند از طریق OMAPI یا از طریق گزینه پیکربندی «infinite-is-reserved» (در صورتی که با محیط و ترکیب کلاینت‌های شما تناسب داشته باشد) به صورت «reserved» تنظیم گردند. .PP همچنین باید متذکر شد که با اجاره‌های دارای برچسب «reserved» عملاً مشابه اجاره‌های دارای علامت «bootp» رفتار می‌شود. .RE .SH "مرجع: دستورات OPTION (REFERENCE: OPTION STATEMENTS)" دستورات گزینه DHCP در صفحه راهنمای .B dhcp-options(5) مستند شده‌اند. .SH "مرجع: عبارات (REFERENCE: EXPRESSIONS)" عبارات مورد استفاده در دستورات گزینه DHCP و سایر نقاط در صفحه راهنمای .B dhcp-eval(5) مستند شده‌اند. .SH "همچنین ببینید (SEE ALSO)" dhcpd(8), dhcpd.leases(5), dhcp-options(5), dhcp-eval(5), RFC2132, RFC2131. .SH "نویسندگان (AUTHORS)" .B dhcpd.conf(5) توسط ISC نگهداری می‌شود. اطلاعات درباره Internet Systems Consortium را می‌توانید در .B https://www.isc.org بیابید.