GDNSD.CONFIG(5) gdnsd GDNSD.CONFIG(5)

gdnsd.config - فایل پیکربندی اصلی سرور نام دامنه gdnsd

options => {
  tcp_timeout => 15 ; zonefile-style comment
  listen => [ 127.0.0.1, 192.0.2.1 ]
}
# shell-style comment
service_types => {
  foosvc => { plugin => http_status, vhost => www.example.com, url_path => "/checkme" }
  barsvc => $include{bar-svc.cfg}
  $include{other-services.cfg}
}
plugins => {
  null => {}
}

این صفحه راهنما نحو نگارش فایل پیکربندی اصلی gdnsd را شرح می‌دهد. فایل پیکربندی اصلی همیشه فایلی به نام config در دایرکتوری پیکربندی است. دایرکتوری پیش‌فرض پیکربندی /etc/gdnsd است، اما این مسیر را می‌توان با گزینه خط فرمان "-c" بازنویسی کرد.

نحو سطح پایین و ساختار زبان پیکربندی با جزئیات کامل در پایان این سند شرح داده شده است، اما با توجه به مثال بالا باید تا حد زیادی شهودی باشد. این زبان عملاً یک زبان ساختار داده عمومی است که امکان استفاده از جدول‌های درهم‌سازی مرتب (ordered hashes)، آرایه‌های مرتب و مقادیر اسکالر را با هر عمق تودرتویی فراهم می‌کند. علامت گیومه دوتایی (Double-quote) برای نقل‌قول کردن مقادیر اسکالر حاوی فاصله خالی یا نویسه‌های فرار مبهم به کار می‌رود.

هش ضمنی بالاترین سطح در یک فایل پیکربندی gdnsd تنها اجازه ۳ کلید مجاز را می‌دهد: options، service_types، و plugins.

هر کدام از این کلیدها در صورت وجود، باید مقداری از نوع هش (Hash) داشته باشند.

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

این گزینه‌ها رفتار کلی gdnsd(8) را کنترل می‌کنند.

عدد صحیح بر حسب ثانیه، پیش‌فرض 86400. این مقدار پیش‌فرض سراسری طول عمر (time-to-live یا TTL) برای هر رکورد در هر فایل منطقه (zonefile) است. می‌توان این مقدار را با یک پیش‌فرض خاص‌تر در داخل خود فایل‌های منطقه از طریق دستورالعمل $TTL بازنویسی کرد (به gdnsd.zonefile(5) مراجعه کنید).
عدد صحیح بر حسب ثانیه، پیش‌فرض 3600000 (حدود ۴۲ روز)، در محدوده 3600 تا 268435455 (2^28-1، حدود ۸٫۵ سال). این مقدار حداکثر سراسری TTL است. هر TTL یافت‌شده در یک منطقه که از این مقدار فراتر رود، با یک هشدار به این مقدار محدود (clamped) می‌شود. توجه داشته باشید که مقدار بیشینه پیش‌فرض مقداری است که کارگزارهای نام ریشه اینترنت در حال حاضر برای TTL رکوردهای A استفاده می‌کنند، و مسلماً این رکوردها پایدارترین رکوردها در کل سامانه هستند. تصور دلایل موجه برای افزایش این مقدار در عمل دشوار است.
عدد صحیح بر حسب ثانیه، پیش‌فرض 5، در محدوده 0 تا 86400 (۱ روز). این مقدار حداقل سراسری TTL است. هر TTL یافت‌شده در یک منطقه که کمتر از این مقدار باشد، با یک هشدار به این مقدار محدود می‌شود، از جمله حداقل TTLهای رکوردهای DYN[AC] و TTLهای حافظه پنهان منفی (ncache) در SOA. این مقدار باید کمتر یا مساوی max_ttl باشد.
عدد صحیح بر حسب ثانیه، پیش‌فرض 10800، در محدوده 10 تا 86400. این مقدار حداکثر سراسری برای فیلد TTL حافظه پنهان منفی رکورد SOA است. مقادیر بالاتر از این با یک هشدار به این مقدار محدود می‌شوند. این مقدار باید بزرگتر یا مساوی min_ttl باشد.
عدد صحیح شماره درگاه، ۱ تا ۶۵۵۳۵، پیش‌فرض ۵۳. این شماره درگاه پیش‌فرض سراسری برای نشانی‌های شنودگر DNS است که خودشان شماره درگاه را مشخص نمی‌کنند.
گزینه listen نشانی‌های سوکت را که سرور برای درخواست‌های DNS روی آن‌ها شنود می‌کند، مشخص می‌نماید.

مشخصات یک نشانی شنود به صورت یک نشانی IP (نسخه ۴ یا ۶) به عنوان یک رشته عددی با قالب‌بندی استاندارد است (هر فرمت عددی که getaddrinfo() روی پلتفرم شما پشتیبانی می‌کند)، که به صورت اختیاری با یک دو نقطه و یک شماره درگاه همراه می‌شود. اگر هیچ شماره درگاهی مشخص نشود، مقدار آن به صورت پیش‌فرض از "dns_port" گرفته می‌شود که پیش‌فرض آن 53 است.

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

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

options => { listen = 192.0.2.1 }

همچنین می‌تواند شکل آرایه‌ای از چنین نشانی‌هایی را بگیرد، مانند:

options => {
  listen = [
    192.0.2.1,
    192.0.2.2,
    2001:DB8::1,
    "[2001:DB8::1234]:53035",
  ]
}

همچنین می‌تواند یک هش باشد که کلیدهای آن نشانی‌های شنود، و مقادیر آن گزینه‌های مختص به هر نشانی هستند، مانند:

options => {
  listen => {
    192.0.2.1 => {
      tcp_timeout = 15
    },
    192.0.2.2:53035 => {
      udp_threads = 5
    },
  }
}

گزینه‌های مربوط به هر نشانی (که با گزینه سراسری هم‌نام خود یکسان بوده و به صورت محلی آن را بازنویسی می‌کنند) عبارتند از "tcp_threads"، "tcp_timeout"، "tcp_clients_per_thread"، "tcp_fastopen"، "udp_threads"، "udp_rcvbuf"، و "udp_sndbuf".

سرانجام، می‌تواند روی مقدار رشته‌ای ویژه "any" نیز تنظیم شود، مانند:

options => { listen => any }

در این حالت، دیمن روی درگاه "dns_port" (پیش‌فرض ۵۳) روی نشانی‌های "ANY" در IPv4 و IPv6 شامل 0.0.0.0 و "::" شنود خواهد کرد. سوکت‌های نشانی "ANY" در gdnsd باید ارسال دیتاگرام‌های خروجی را از طریق همان رابطی که دریافت شده‌اند و با نشانی مبدأ مطابق با نشانی مقصد درخواست به درستی مدیریت کنند.

پیکربندی‌های محیط عملیاتی همیشه باید گزینه "listen" خود را به صراحت تعریف کنند، زیرا مقدار پیش‌فرض ممکن است در ارتقاهای نسخه اصلی دستخوش تغییرات ناسازگار شود. پیش‌فرض فعلی همان رفتار "any" در بالا است.

عدد صحیح، پیش‌فرض ۲، حداقل ۱، حداکثر ۱۰۲۴. این تعداد سوکت‌های شنود TCP جداگانه و ریسمان‌های شنودگر متناظر است که برای هر نشانی شنودگر DNS ایجاد خواهد شد. در یک میزبان چند‌هسته‌ای، افزایش این پارامتر (حداکثر تا مضرب بسیار کوچکی از تعداد هسته‌های CPU) ممکن است عملکرد کلی را افزایش دهد.
دقیقاً مانند "tcp_threads"، اما برای سوکت‌های UDP به ازای هر نشانی شنود DNS.
عدد صحیح، پیش‌فرض ۲۵۶، حداقل ۱۶، حداکثر ۶۵۵۳۵. این حداکثر تعداد اتصالات موازی tcp DNS است که gdnsd به ازای هر ریسمان شنود tcp مجاز می‌داند. هنگامی که با ورود یک اتصال جدید به این حد برسد، اتصالی از میان اتصالات موجود که طولانی‌ترین زمان بیکاری را داشته است، بلافاصله به نفع اتصال جدید بسته می‌شود.

می‌توانید آماره "tcp.close_s_kill" را زیر نظر بگیرید تا ببینید آیا چنین بسته‌شدن‌هایی به دلیل رسیدن به حد نصاب رخ می‌دهد یا خیر، که در صورت امکان باید از آن اجتناب شود. کد طوری طراحی شده است که حتی در مواجهه با اضافه‌بارهای اتصال نادرست (مانند خواندن/نوشتن کند) در لینوکس، و در سیستم‌های BSD با "SO_ACCEPTFILTER" و بارگیری ماژول‌های هسته مناسب ("accf_dataready" و/یا "accf_dns")، تاب‌آور باشد (حداقل به یک درخواست معتبر در هر اتصال معتبر پاسخ دهد).

توجه داشته باشید که نشانی‌های سوکت نگاشت ۱ به چند با ریسمان‌ها دارند (یعنی هر ریسمان یک نمونه‌سازی جداگانه "SO_REUSEPORT" از یک سوکت منطقی دریافت می‌کند)، و بنابراین حد کل کارخواه‌ها برای اتصال به یک نشانی سوکت داده‌شده برابر با "tcp_clients_per_thread * tcp_threads" خواهد بود، اما متعادل‌سازی اتصالات بر عهده سیستم‌عامل است و ممکن است از درهم‌سازی تاپل اتصال ساده یا نوبت‌گردشی ساده استفاده کند که هیچ‌کدام توزیع بسیار یکنواختی را تضمین نمی‌کنند.

عدد صحیح بر حسب ثانیه، پیش‌فرض ۳۷، حداقل ۵، حداکثر ۱۸۰۰.

این گزینه زمان انتظار بیکاری سمت کارخواه را برای اتصالات TCP تعیین می‌کند، که توسط سرور به کارخواه‌های منطبقی که از مکانیزم‌های سیگنال‌دهی مانند RFC 7828 EDNS TCP Keepalive یا RFC 8490 DNS Stateful Operations (DSO) پشتیبانی می‌کنند، ارسال می‌شود.

یک زمان انتظار متناظر در سمت سرور نیز وجود دارد که تعیین می‌کند gdnsd چه زمانی از کارخواهی که به نظر متخلف می‌رسد (کارخواهی که اتصال را بیش از حد طولانی بدون رعایت زمان انتظار بیکاری سمت کارخواه باز نگه می‌دارد) قطع امید کند. زمان انتظار سمت سرور دو برابر زمان انتظار کارخواه است (که معادل پیش‌فرض ۷۴، حداقل ۱۰، حداکثر ۳۶۰۰ است).

توجه داشته باشید که در حالت رایج اتصالات و کارخواه‌های با رفتار استاندارد، در سرور لینوکس (که از TCP_DEFER_ACCEPT استفاده می‌کنیم) یا سرور BSD که فیلترهای پذیرش dnsready یا dataready را پشتیبانی می‌کند، با رسیدن اتصال جدید، بلافاصله اولین درخواست دریافت شده و بدون هیچ فرصتی برای تأخیرهای مربوط به زمان بیکاری و بدون ورود مجدد به حلقه رویداد اصلی، پاسخ ارسال می‌شود.

بیکاری یک کارخواه تنها پس از اتمام هر تراکنش کامل بازنشانی می‌شود (ارسال یک درخواست کامل به ما، و ورود پاسخ کامل ما به حداقل بافر نوشتن محلی). ناتوانی در نوشتن فوری پاسخ کامل در بافرهای محلی TCP سرور (معمولاً به دلیل پنجره دریافت بسیار کوچک کارخواه و/یا تایید نکردن پاسخ‌های قبلی) باعث قطع فوری اتصال می‌شود. اتصالات کارخواه‌های خوش‌رفتار که در میانه تراکنش متوقف نمی‌شوند، تنها در طول دوره‌های بیکاری بین تراکنش‌ها پس از اولین تراکنش خود به اتصالات بیکار تبدیل می‌شوند، و برای کارخواه‌های بدرفتار، تایمر بیکاری به مهار تأثیر الگوهای شبیه به حملات کندخوانی/کندنویسی کمک می‌کند.

سرور اطلاعات edns TCP keepalive را در تمام پاسخ‌هایی که از نظر فنی مجاز است به کارخواه‌ها ارسال می‌کند (درخواست از EDNS روی TCP استفاده کرده و هنوز DSO برقرار نشده است). مقدار زمان انتظار با مقدار ثابتی که در اینجا پیکربندی شده ارسال خواهد شد تا زمانی که خاموش شدن سرور آغاز شود، که در آن نقطه مقدار صفر ارسال می‌شود تا کارخواه‌ها اتصالات را تمیز ببندند.

کارخواه‌هایی که DSO را از طریق Keepalive TLV برقرار می‌کنند، همان زمان انتظار سمت کارخواه را به عنوان زمان انتظار عدم فعالیت DSO دریافت خواهند کرد، در حالی که بازه KeepAlive در DSO روی نامحدود (Infinite) تنظیم شده است. کارخواه‌های DSO همچنین در هنگام خاموش شدن سرور یا جایگزینی آن، اطلاعات بهتر و به‌موقع‌تری دریافت خواهند کرد.

بولی، پیش‌فرض false. این گزینه پشتیبانی از عملیات‌های حالت‌دار DNS در RFC 8490 (DSO) را برای ریسمان‌های TCP غیرفعال می‌کند.

احتمالاً تنها دلیل موجه برای غیرفعال کردن آن، یافتن مشکلات سازگاری متقابل یا رفتارهای نادرست در این کد جدید و/یا استاندارد خواهد بود، زیرا در غیر این صورت مکانیزم برتری را برای مدیریت اتصالات حالت‌دار کارخواه نسبت به بهترین راهکار پیشین (RFC 7828 EDNS TCP Keepalive) ارائه می‌دهد.

عدد صحیح، حداقل ۰، پیش‌فرض ۰، حداکثر ۶۵۵۳۵. این گزینه آرگومان "backlog" در فراخوانی listen() را برای سوکت‌های شنود TCP تنظیم می‌کند. اثرات دقیق آن بسته به پیاده‌سازی سیستم‌عامل متفاوت است و همچنین می‌تواند با ویژگی‌هایی مانند "TCP_DEFER_ACCEPT" و "SO_ACCEPTFILTER" تعامل داشته باشد. اگر روی مقدار پیش‌فرض صفر رها شود، مقدار ثابت زمان کامپایل "SOMAXCONN" سیستم‌عامل استفاده خواهد شد که برای بیشتر کاربردها معقول است.
عدد صحیح، پیش‌فرض ۲۵۶، حداقل ۰، حداکثر ۱۰۴۸۵۷۶. در صورت تنظیم روی یک مقدار غیر صفر، اندازه صف TCP Fastopen را اعلام کرده و این ویژگی را فعال می‌کند. قابلیت TCP Fastopen به کارخواه‌هایی که حداقل یک بار قبلاً به سرور متصل شده‌اند اجازه می‌دهد تا داده‌های اولیه (در این مورد، اولین درخواست DNS خود) را همزمان با بسته اولیه SYN ارسال کنند، و بدین ترتیب تأخیرهای رفت و برگشت دست‌تکانی را در هنگام اتصال مجدد حذف نمایند. این گزینه توصیه می‌شود، اما ممکن است نیازمند پشتیبانی در سطح سیستم‌عامل و/یا تنظیم پیکربندی باشد، و در صورت وجود چندین سرور پشت یک متعادل‌کننده بار یا استخر anycast، ممکن است به هماهنگی مدیریتی کلید محرمانه TFO سمت سرور نیز نیاز داشته باشد.
بولی، پیش‌فرض false. این گزینه TCP فقط در داخل گزینه‌های به ازای هر نشانی یک نشانی شنود خاص در شکل هَش گزینه "listen" پشتیبانی می‌شود، نه به عنوان یک گزینه سراسری.

نشانی‌هایی که این گزینه برای آن‌ها فعال است فقط درخواست‌های PROXY را می‌پذیرند، نمی‌توانند از شماره درگاه ۵۳ استفاده کنند، شنودگرهای UDP متناظر ایجاد نمی‌کنند، و گزینه‌های مربوط به UDP را نمی‌پذیرند. ما از هر دو نسخه ۱ و ۲ پروتکل PROXY همان‌طور که در https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt تعریف شده پشتیبانی می‌کنیم، و فقط TCPv4، TCPv6 و حالت LOCAL در PROXYv2 را می‌پذیریم.

نشانی IP مبدأ که از طریق پروتکل PROXY به gdnsd منتقل می‌شود، به عنوان نشانی مبدأ اتصال برای تمام اهداف منطقی، از جمله برای نگاشت‌های GeoIP در صورت نبود edns-client-subnet استفاده خواهد شد. هنگامی که هدر اولیه PROXY با موفقیت تجزیه شود، با این اتصال برای بقیه عمر آن دقیقاً مانند هر اتصال TCP دیگری رفتار می‌شود.

قرار دادن شنودگرهای PROXY در معرض ترافیک عمومی توصیه نمی‌شود؛ آن‌ها باید محدود به localhost یا نشانی‌هایی باشند که خارج از زیرساخت شما به دلیل فایروال و غیره قابل دسترسی نیستند. این گزینه در درجه اول برای آزمایش انتقال‌های رمزگذاری‌شده با استفاده از دیمن‌های خارجی که ترافیک را به سمت gdnsd هدایت می‌کنند، در نظر گرفته شده است.

اتصالات PROXY تمامی شمارنده‌های آماری اتصالات معمولی TCP را افزایش می‌دهند، و همچنین دو شمارنده اختصاصی جدید اضافه می‌کنند:

tcp.proxy: count of received connections on PROXY listeners (also
           increments the normal tcp.conns stat).
tcp.proxy_fail: count of received PROXY connections which are
                closed early for failing to send a PROXY header
                the server parses and likes (also increments
                tcp.close_s_err)

نمونه پیکربندی شنود:

options => {
  listen => {
    0.0.0.0 => { ... } # normal UDP+TCP on port 53
    :: => { ... } # normal UDP+TCP on port 53 for IPv6
    127.0.0.1:53035 => { tcp_proxy => true, ... }
  }
}
بولی، پیش‌فرض false برای شنودگرهای عادی TCP، پیش‌فرض true برای شنودگرهای "tcp_proxy" (بالا را ببینید). این گزینه TCP فقط در داخل گزینه‌های اختصاصی هر نشانی در شکل هش گزینه "listen" پشتیبانی می‌شود، نه به عنوان یک گزینه سراسری.

در صورت فعال بودن، پاسخ به هر درخواستی که دارای EDNS OPT RR باشد، با استفاده از گزینه EDNS Padding به مضربی از ۴۶۸ بایت مطابق توصیه RFC 8467 لایه‌گذاری (pad) می‌شود. این گزینه فقط در صورتی باید فعال شود که اتصالات TCP به یک شنودگر توسط یک پروکسی رمزگذاری شده باشند.

عدد صحیح، حداقل ۴۰۹۶، حداکثر ۱۰۴۸۵۷۶، پیش‌فرض ۰. در صورت تنظیم روی مقدار غیر صفر، این مقدار برای تنظیم گزینه سوکت "SO_RCVBUF" روی سوکت‌های شنود UDP استفاده می‌شود، در غیر این صورت پیش‌فرض‌های سیستم‌عامل دست‌نخورده باقی می‌مانند.
عدد صحیح، حداقل ۴۰۹۶، حداکثر ۱۰۴۸۵۷۶، پیش‌فرض ۰. در صورت تنظیم روی مقدار غیر صفر، این مقدار برای تنظیم گزینه سوکت "SO_SNDBUF" روی سوکت‌های شنود UDP استفاده می‌شود، در غیر این صورت پیش‌فرض‌های سیستم‌عامل دست‌نخورده باقی می‌مانند.
خطر - قرار دادن سوکت کنترل روی TCP خطرناک است. کد سرور سوکت کنترل طوری طراحی نشده است که در برابر ترافیک حملات دلخواه مقاوم باشد، و هیچ‌گونه احراز هویت یا رمزنگاری ندارد. نشانی‌های شنود تعریف‌شده در اینجا باید به خوبی محافظت شوند و توسط خط‌مشی‌های فایروال شبکه به کارخواه‌های داخلی و مجاز محدود گردند، و قطعاً نباید در معرض اینترنت عمومی قرار گیرند.

این گزینه یک یا چند نشانی شنود ثانویه TCP را برای اتصالات سوکت کنترل (در کنار سوکت دامنه یونیکس اولیه و الزامی) مشخص می‌کند. شبیه به listen در بالا است و یک نشانی واحد، آرایه‌ای از نشانی‌ها، یا هشی از نشانی‌ها با گزینه‌های اختصاصی را می‌پذیرد. تمام مشخصات نشانی باید شامل یک نشانی صریح و یک شماره درگاه غیر صفر باشند.

تنها دو گزینه اختصاصی نشانی، گزینه‌های بولی "chal_ok" و "ctl_ok" هستند که پیش‌فرض هر دو false است. به طور پیش‌فرض، سوکت کنترل TCP به عملیات‌های فقط‌خواندنی محدود است ("gdnsdctl status"، "gdnsdctl stats"، و "gdnsdctl states"). گزینه "chal_ok" به عملیات‌های ACME Challenge روی سوکت اجازه می‌دهد ("gdnsdctl acme-dns-01" و "gdnsdctl acme-dns-01-flush"). گزینه "ctl_ok" به دستورات کنترلی دیمن روی سوکت اجازه می‌دهد ("gdnsdctl reload-zones" و "gdnsdctl replace"). دستور "gdnsdctl stop" اصلاً روی TCP مجاز نیست.

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

نمونه‌ها:

options => { tcp_control => 127.0.0.1:885 } # read-only ops only
options => { tcp_control => [ 127.0.0.1:885, 127.0.0.2:885 ] } # ditto
options => { tcp_control => {
    127.0.0.1:885 => {} # readonly
    127.0.0.1:886 => { chal_ok => true } # allows challenge stuff
    127.0.0.1:887 => { ctl_ok => true } # allows daemon control
    127.0.0.1:888 => { chal_ok => true, ctl_ok => true } # allows both
}}

کارخواه "gdnsdctl" گزینه‌ای به نام "-s" برای تعیین سوکت TCP دارد تا با سوکت‌های "tcp_control" متصل شود، که در این حالت حتی تلاشی برای تجزیه پیکربندی سرور جهت یافتن مسیر سوکت عادی یونیکس نمی‌کند.

بولی، پیش‌فرض "false".

اگر false باشد (پیش‌فرض)، گزارش بسیاری از خطاهای کمتر جدی در داده‌های منطقه صرفاً به عنوان هشدارهای ثبت‌شده صادر می‌شود، و داده‌های منطقه همچنان بارگیری و ارائه می‌گردند.

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

عدد صحیح، پیش‌فرض ۲، حداقل ۱، حداکثر ۱۰۲۴. هنگامی که فایل‌های منطقه استاندارد RFC1035 بارگیری (یا بارگیری مجدد) می‌شوند، حداکثر این تعداد ریسمان موقت به صورت موازی ایجاد می‌شوند تا به بارگیری و تجزیه سریع‌تر آن‌ها کمک کنند.

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

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

توجه داشته باشید که به طور کلی، بهبود عملکرد I/O در خواندن فایل‌های منطقه از دیسک (مثلاً قرار دادن آن‌ها روی SSD) بیشتر از موازی‌سازی در اینجا کمک می‌کند، هرچند هر دو با هم حتی بهتر است!

بولی، پیش‌فرض false. باعث می‌شود دیمن فراخوانی mlockall(MCL_CURRENT|MCL_FUTURE) را انجام دهد، که عملاً تمام حافظه دیمن را در RAM قفل می‌کند تا قابل مبادله در swap نباشد. برای اطمینان از اینکه عملیات swap بر تأخیر DNS تأثیر نگذارد، در برخی موارد عملیاتی مفید است.

باید اطمینان حاصل کنید که ulimit برای حافظه قفل‌شده به اندازه کافی بزرگ باشد (مانند infinity) تا از خاتمه فرآیند جلوگیری شود.

بولی، پیش‌فرض false. روی شبکه، رکوردهای "TXT" به صورت تکه‌های مجزای حداکثر ۲۵۵ نویسه‌ای به ازای هر تکه کدگذاری می‌شوند. RFCهای مربوطه بیان می‌کنند که چندین تکه باید توسط کارخواه‌ها طوری رفتار شوند که گویی به هم پیوسته‌اند (concatenated). به عبارت دیگر، برای کارخواه نباید فرقی داشته باشد که داده‌های "TXT" به صورت دو تکه ۱۶ بایتی یا یک تکه ۳۲ بایتی ارسال شوند.

سرور gdnsd به طور خودکار رشته‌های بزرگتر را به این تکه‌های استاندارد تجزیه می‌کند. اگر این گزینه را روی true تنظیم کنید، رفتار تقسیم خودکار غیرفعال می‌شود و هر رشته کاراکتری منفرد مشخص‌شده در فایل منطقه به عنوان بخشی از یک رکورد "TXT" که بزرگتر از ۲۵۵ بایت باشد، به عنوان یک خطای نحوی در نظر گرفته خواهد شد.

عدد صحیح، پیش‌فرض ۱۲۳۲، حداقل ۵۱۲، حداکثر ۱۶۳۸۴. این حداکثر اندازه یک پاسخ edns روی UDP به یک کارخواه از طریق IPv4 است که به عنوان سقفی بر اندازه بافر edns اعلام‌شده توسط کارخواه در درخواست آن عمل می‌کند.

توصیه می‌شود این مقدار را برای سروری که رو به اینترنت عمومی است از مقدار پیش‌فرض افزایش ندهید.

تنظیم این مقدار در محدوده ۴ تا ۱۶ کیلوبایت ممکن است در صورتی مطلوب باشد که مجموعه‌های پاسخ RR بزرگی دارید و مایل به تحمل مقداری تکه‌تکه‌شدن (fragmentation) هستید، به‌ویژه در یک شبکه خصوصی که در آن MTU مسیر بزرگتر (مانند حدود ۹ کیلوبایت برای قاب‌های بزرگ اترنت) قابل تضمین باشد.

اگر مجموعه‌های داده پاسخ بزرگ در مناطق خود ندارید، این گزینه تأثیر عملی نخواهد داشت.

عدد صحیح، پیش‌فرض ۱۲۳۲، حداقل ۵۱۲، حداکثر ۱۶۳۸۴.

مانند بالا برای پاسخ‌های edns روی UDP از طریق IPv6. بار دیگر، افزایش این مقدار بالاتر از مقدار پیش‌فرض برای یک سرور رو به اینترنت عمومی توصیه نمی‌شود.

بولی، پیش‌فرض true. پشتیبانی از گزینه edns-client-subnet در RFC 7871 را فعال می‌کند. سرور gdnsd این گزینه EDNS را فقط در پاسخ به پرس‌وجوهایی که حاوی این گزینه بودند می‌گنجاند. در مورد پاسخ‌های عادی از داده‌های ایستای منطقه، ماسک محدوده (scope mask) روی صفر تنظیم خواهد شد. افزونه‌های پاسخ پویا به داده‌های EDNS client-subnet پرس‌وجو دسترسی دارند و کنترل کاملی روی ماسک محدوده پاسخ دارند.

اگر گزینه روی false تنظیم شود، gdnsd این گزینه را در پرس‌وجوها نادیده می‌گیرد، هرگز آن را در پاسخ‌های خود تنظیم نمی‌کند، و افزونه‌ها به هیچ داده ارائه‌شده توسط هیچ گزینه نادیده‌گرفته‌شده edns-client-subnet در پرس‌وجوها دسترسی نخواهند داشت.

از میان افزونه‌های استاندارد موجود، فقط "reflect" و "geoip" از اطلاعات edns-client-subnet استفاده می‌کنند. بقیه افزونه‌ها ماسک محدوده را طبق معمول برای داده‌های ایستای مستقل از موقعیت کارخواه روی صفر رها می‌کنند.

رشته، پیش‌فرض "gdnsd". هنگامی که gdnsd هر پرس‌وجویی با کلاس "CH" ("Chaos")، در مقایسه با کلاس عادی "IN" ("Internet") دریافت کند، یک رکورد پاسخ منفرد از کلاس "CH" و نوع "TXT" برمی‌گرداند که شامل رشته تعریف‌شده در اینجا است. این مورد شبیه به گزارش نسخه BIND است که به پرس‌وجوهای "version.bind" در کلاس "CH" پاسخ می‌دهد.
عدد صحیح بر حسب ثانیه، محدوده ۶۰ تا ۳۶۰۰، پیش‌فرض ۶۰۰. برای داده‌های موقت چالش ACME DNS-01 اضافه شده از طریق "gdnsdctl acme-dns-01 ..."، این مقدار زمان را تا زمانی که رکوردهای TXT به طور خودکار از سرور منقضی شده و ناپدید شوند، تنظیم می‌کند.

برای جزئیات بیشتر به مستندات gdnsdctl(8) درباره "acme-dns-01" مراجعه کنید.

عدد صحیح بر حسب ثانیه، محدوده ۰ تا ۳۶۰۰، پیش‌فرض ۰. برای داده‌های موقت چالش ACME DNS-01 اضافه شده از طریق "gdnsdctl acme-dns-01 ..."، این مقدار TTL دی‌ان‌اس را که در رکوردهای TXT پاسخ استفاده می‌شود، تنظیم می‌کند.

در نسخه‌های قبلی، مقدار DNS TTL بازتاب‌دهنده TTL انقضا از "acme_challenge_ttl" در بالا بود. با این حال، این امر در شرایط خاص منجر به مشکلات گیج‌کننده‌ای در دنیای واقعی با سرورهای ACME شده است.

توجه داشته باشید که رکوردهای ایستای فایل منطقه با پیشوند "_acme-challenge" صرف‌نظر از TTL صریح در فایل منطقه، به این مقدار TTL مجبور می‌شوند تا از ترکیب مقادیر TTL مختلف در خروجی‌های سرور جلوگیری شود.

رشته، بدون پیش‌فرض، طول ۲ تا ۲۵۶ نویسه. تعداد نویسه‌ها باید زوج باشد و همه نویسه‌ها باید ارقام هگزادسیمال ASCII باشند. این گزینه تا ۱۲۸ بایت داده باینری دلخواه را که توسط مدیر سیستم انتخاب شده کدگذاری می‌کند و آن را در داده‌های گزینه EDNS NSID (RFC 5001) در تمام بسته‌های پاسخ ارائه می‌دهد. مقدار NSID به کارخواه‌ها ارسال نمی‌شود مگر اینکه از طریق EDNS آن را درخواست کنند، و اصلاً ارسال نمی‌شود مگر اینکه این گزینه به صراحت مشخص شده باشد. این قابلیت برای کمک به شناسایی سرورهای خاص زمانی که چندین سرور بخشی از یک استخر anycast یا متعادل‌کننده بار هستند، در نظر گرفته شده است.
رشته، بدون پیش‌فرض، ۱ تا ۱۲۸ نویسه از نویسه‌های قابل چاپ ASCII. این یک جایگزین راحت برای "nsid" در بالا است، که اجازه می‌دهد داده‌های باینری NSID با بایت‌های یک رشته ASCII قابل چاپ تا ۱۲۸ بایت طول پیکربندی شوند. تنها یکی از گزینه‌های "nsid" یا "nsid_ascii" را می‌توان مشخص کرد.
بولی، پیش‌فرض true.

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

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

این رفتار به دلایل متعددی مطلوب است:

استاندارد RFC 7871 (edns-client-subnet) در واقع آن را حداقل برای پاسخ‌های متمایز از نظر زیرشبکه توصیه می‌کند، زیرا در غیر این صورت مبهم است که محدوده زیرشبکه به کدام‌یک از رکوردهای متعدد بخش پاسخ اعمال می‌شود، و کَش‌ها ناگزیرند دیدگاهی بدبینانه اتخاذ کرده و مدخل‌های کَش را بی‌دلیل بر اساس زیرشبکه تکه‌تکه کنند.

همچنین این مورد با اصل کلی حداقل پاسخ‌ها (minimal responses) مطابقت دارد، به حداقل رساندن اندازه پاسخ‌ها کمک می‌کند، و در آینده به‌ویژه برای DNSSEC مفید خواهد بود.

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

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

بولی، پیش‌فرض false. پشتیبانی از کوکی‌های EDNS در RFC 7873 را غیرفعال می‌کند. توصیه نمی‌شود، زیرا این کوکی‌ها لایه‌ای از دفاع را در برابر جعل پاسخ و حملات تقویت (amplification attacks) فراهم می‌کنند. یکی از دلایل موجه احتمالی برای غیرفعال کردن کوکی‌ها این است که gdnsd در مجموعه‌ای مختلط از سرورهای احراز هویت anycast یا متعادل‌کننده بار کار کند و برخی از سرورهای دیگر از کوکی‌ها پشتیبانی نکنند یا از الگوریتم‌های متفاوتی نسبت به gdnsd استفاده نمایند. پشتیبانی ما از کوکی‌ها کاملاً کارآمد است؛ دلیل عمده‌ای از نظر عملکرد برای غیرفعال کردن آن وجود ندارد.
عدد صحیح بر حسب بایت، پیش‌فرض صفر (غیرفعال)، محدوده ۱۲۸ تا ۱۰۲۴. اگر این پارامتر روی یک مقدار غیر صفر تنظیم شود، تمام پاسخ‌های UDP به این تعداد بایت محدود می‌شوند مگر اینکه پرس‌وجو یک کوکی معتبر EDNS ارائه دهد که سرور آن را متعلق به خود بشناسد. پاسخ‌هایی که در این بررسی رد شوند کاملاً کوتاه (truncate) می‌شوند و بیت TC تنظیم می‌گردد تا از کارخواه بخواهد از طریق TCP دوباره امتحان کند.

هدف این گزینه محدود کردن توانایی مهاجمان در استفاده از سرور شما به عنوان منبع بازتاب برای حملات تقویت است، زیرا کوکی‌های معتبر تضمین معقولی می‌دهند که نشانی مبدأ بسته پرس‌وجو جعل نشده است. تنظیم این مقدار حداقل روی ۵۱۲ کاملاً ایمن است.

رشته، پیش‌فرض تعریف‌نشده. هنگامی که این گزینه تعریف شود، محتویات فایل به عنوان مقدار کلید اصلی ماندگار برای تولید پاسخ‌های کوکی EDNS خوانده می‌شود.

اگر فایل وجود داشته باشد، باید توسط دیمن قابل خواندن باشد و باید شامل ۳۲ بایت داده باینری باشد. عدم موفقیت در خواندن درست فایل کلید تعریف‌شده در زمان راه‌اندازی مهلک است. دسترسی‌ها باید با دقت تنظیم شوند تا سایر کاربران بدون مجوز سیستم نتوانند کلید را بخوانند.

توجه داشته باشید که محتویات به عنوان داده باینری در نظر گرفته شده و مستقیماً به عنوان ورودی کلید محرمانه به الگوریتم‌های رمزنگاری استفاده می‌شوند، بنابراین باید با آنتروپی بالا تولید شده باشند. توصیه می‌شود محتوای فایل با یک RNG تولید شود، مانند: "dd if=/dev/urandom of=cookie.key bs=32 count=1".

محتوای فایل کلید برای حفظ امنیت نیازی به تغییر مکرر ندارد. دیمن باید جایگزین یا مجدداً راه‌اندازی شود تا کلید جدید اعمال گردد، و این کار کوکی‌های جاری در اختیار کارخواه‌ها را بی‌اعتبار می‌کند.

دلیل اصلی برای تعریف "cookie_key_file" داشتن کلیدهای کوکی همگام‌شده در مجموعه‌ای از سرورهای anycast یا متعادل‌کننده بار است.

اگر این فایل تعریف نشود، دیمن مقدار کلید اصلی کوکی را به صورت خودکار مدیریت می‌کند. تحت مدیریت خودکار کلید، در زمان راه‌اندازی تلاش می‌کند کلیدی را از //run/gdnsd/cookie.autokey بخواند. اگر این کار نکرد، کلید تصادفی جدیدی در حافظه تولید کرده و تلاش می‌کند آن را در همان مسیر بنویسد.

توجه داشته باشید که در نصب‌های رایج Linux/systemd، دایرکتوری run با راه‌اندازی مجدد سیستم‌عامل پاک می‌شود و در راه‌اندازی بعدی دیمن، یک کلید تازه تولید خواهد شد.

رشته، پیش‌فرض //run/gdnsd. این دایرکتوری‌ای است که دیمن به عنوان دایرکتوری اجرای خود مالک آن است.

دیمن در هنگام راه‌اندازی این دایرکتوری را ایجاد می‌کند یا دسترسی‌های دایرکتوری موجود را تغییر می‌دهد. اگر وجود نداشته باشد و ایجاد نشود، یا دسترسی‌ها روی مقادیر قابل قبول تنظیم نشوند، دیمن شروع به کار نخواهد کرد.

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

رشته، پیش‌فرض //lib/gdnsd. این دایرکتوری‌ای است که دیمن به عنوان دایرکتوری وضعیت خود مالک آن است.

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

فایل admin_state در اینجا قرار دارد.

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

هش service_types شامل تعاریف عمومی برای نحوه نظارت بر انواع معینی از سرویس‌ها است، مستقل از هر نشانی یا نام میزبان خاص برای آن سرویس.

دو نوع سرویس ناچیز به صورت داخلی با نام‌های "up" و "down" تعریف شده‌اند که هیچ نظارت واقعی انجام نمی‌دهند و به سادگی وضعیت نظارت‌شده را به طور دائم "UP" یا "DOWN" تنظیم می‌کنند. "up" نوع سرویس پیش‌فرض در صورت عدم تعیین نوع سرویس است.

در داخل تعریف یک service_type، چندین پارامتر عمومی مربوط به زمان‌بندی و ضد نوسان (anti-flap)، و همچنین پارامترهای خاص هر افزونه وجود دارد که برای هر افزونه متفاوت است.

یک نوع سرویس، با این حال، نام یا نشانی خاصی را برای نمونه مشخصی از سرویس تعیین نمی‌کند. این موارد بر مبنای هر نشانی در پیکربندی افزونه تحلیل‌کننده در بخش "plugins" تعیین می‌شوند، و پیکربندی افزونه سپس به یک نوع سرویس نام‌گذاری‌شده برای نظارت ارجاع می‌دهد.

سرویسی که از طریق این مکانیزم‌ها نظارت می‌شود، از دیدگاه نظارت در زمان اجرا همیشه در وضعیت "UP" یا "DOWN" قرار دارد. وضعیت "UP" در مواجهه با خرابی‌های متناوب یا مقطعی حفظ می‌شود تا زمانی که آستانه‌های ضد نوسان رد شوند و وضعیت به "DOWN" تغییر کند.

هر سرویسی که برای افزونه‌ها نظارت می‌شود، وضعیت آن در کنار گزارش آماری استاندارد gdnsd که توسط سرور HTTP داخلی ارائه می‌شود (درگاه پیش‌فرض 3506)، گزارش می‌گردد.

موارد زیر پارامترهای عمومی برای تمام service_types هستند:

عدد صحیح، پیش‌فرض ۲۰، حداقل ۱، حداکثر ۶۵۵۳۵. تعداد درخواست‌های نظارتی که باید پشت سر هم و بدون هیچ خرابی با موفقیت انجام شوند تا یک منبع معین از وضعیت "DOWN" به وضعیت "UP" منتقل شود.
عدد صحیح، پیش‌فرض ۱۰، حداقل ۱، حداکثر ۶۵۵۳۵. پایین را ببینید.
عدد صحیح، پیش‌فرض ۱۰، حداقل ۱، حداکثر ۶۵۵۳۵. پارامترهای "ok_thresh" و "down_thresh" انتقال از وضعیت "UP" به وضعیت "DOWN" را کنترل می‌کنند در حالی که تلاش می‌نمایند از رفتارهای نوسانی جلوگیری کنند. رفتار آن‌ها به بهترین وجه بر اساس یک شمارنده داخلی خرابی برای منبعی که در حال حاضر در وضعیت "UP" است توصیف می‌شود. شمارنده خرابی با انتقال وضعیت به حالت "UP" از صفر شروع می‌شود.

هر نظرسنجی وضعیتی که منجر به پاسخ ناموفق شود، حتی اگر سایر پاسخ‌های موفق بین آن‌ها قرار گیرند، شمارنده خرابی را افزایش می‌دهد. اگر شمارنده خرابی به "down_thresh" برسد، منبع به وضعیت "DOWN" منتقل می‌شود. با این حال، اگر به تعداد "ok_thresh" موفقیت متوالی و بدون خرابی رخ دهد، شمارنده خرابی به صفر بازنشانی می‌شود.

بنابراین با مقادیر پیش‌فرض، رفتار مورد انتظار این است که اگر یک منبع "UP" تعداد ۱۰ خرابی نظارتی (احتمالاً مقطعی یا متناوب) را در طول هر بازه زمانی تجربه کند بدون اینکه رشته‌ای از ۱۰ موفقیت پیاپی برای بازنشانی شمارنده رخ دهد، به وضعیت "DOWN" تغییر وضعیت می‌دهد. پس از انتقال به "DOWN"، به ۲۰ موفقیت متوالی قبل از بازگشت به وضعیت "UP" نیاز خواهد داشت.

عدد صحیح بر حسب ثانیه، پیش‌فرض ۱۰، حداقل ۱، حداکثر ۲۵۵. تعداد ثانیه‌های بین درخواست‌های نظارتی متوالی برای یک منبع معین.
عدد صحیح بر حسب ثانیه، پیش‌فرض interval/2، حداقل ۱، حداکثر ۲۵۵. حداکثر زمانی که کد نظارت منتظر یک پاسخ موفقیت‌آمیز می‌ماند قبل از اینکه انصراف دهد و درخواست را به عنوان یک شکست در نظر بگیرد. پیش‌فرض نصف "interval" است و باید کمتر از "interval" باشد.
رشته، الزامی. این پارامتر مشخص می‌کند از کدام افزونه برای اجرای درخواست‌های نظارت استفاده شود. هر پارامتری غیر از موارد عمومی ذکرشده در اینجا توسط افزونه استفاده خواهد شد.

شش افزونه نظارتی همراه با gdnsd ارائه شده‌اند که می‌توانند در تعریف service_types استفاده شوند، و هر یک ممکن است گزینه‌های پیکربندی اضافی و اختصاصی افزونه علاوه بر موارد عمومی بالا داشته باشند. هر یک از این موارد در صفحه راهنمای جداگانه خود به تفصیل مستند شده است (مانند "gdnsd-plugin-FOO"):

بررسی اتصال اولیه TCP روی یک درگاه مشخص. فقط از منابع نشانی پشتیبانی می‌کند، نه CNAME.
بررسی اتصال HTTP، همراه با گزینه‌هایی برای درگاه، URL و vhost مورد استفاده در درخواست، و کدهای وضعیت HTTP قابل قبول در پاسخ. فقط از منابع نشانی پشتیبانی می‌کند، نه CNAME.
اجرای دوره‌ای یک برنامه خط فرمان خارجی سفارشی برای نظرسنجی وضعیت یک منبع. از هر دو منبع نشانی و CNAME پشتیبانی می‌کند.
خواندن محتویات یک فایل روی دیسک برای وارد کردن داده‌های نظارت وضعیت از یک منبع دیگر. از هر دو منبع نشانی و CNAME پشتیبانی می‌کند.
پیکربندی یک نتیجه نظارت ایستا، عمدتاً برای تست و کدهای نمونه. از هر دو منبع نشانی و CNAME پشتیبانی می‌کند.
پیکربندی یک نتیجه همیشه خراب (always-down) ایستا، عمدتاً برای تست و کدهای نمونه. از هر دو منبع نشانی و CNAME پشتیبانی می‌کند.

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

افزونه‌های فقط‌نظارتی نیز می‌توانند در صورتی که نویسنده افزونه لازم بداند، در اینجا پیکربندی در سطح سراسری افزونه دریافت کنند.

سرور gdnsd همراه با هشت افزونه نظارتی مختلف ارائه می‌شود که همه آن‌ها مستندات صفحه راهنمای جداگانه خود را دارند (مانند "man gdnsd-plugin-FOO"):

بازتاب دادن IP مبدأ کارخواه DNS و/یا اطلاعات edns-client-subnet به درخواست‌کننده به عنوان داده‌های نشانی برای اشکال‌زدایی.
جایگزینی در صورت خرابی (failover) ساده اولیه/ثانویه برای نشانی‌های نظارت‌شده.
جایگزینی تمام‌فعال (all-active failover) برای گروه‌های نشانی نوبت‌گردشی نظارت‌شده.
پاسخ‌های نوبت‌گردشی وزن‌دار با رفتارهای متنوع، هم برای نشانی‌های نظارت‌شده و هم برای CNAMEها.
متای جایگزینی مرتب ایستا بین «مراکز داده»، که منابعی تعریف‌شده بر اساس افزونه‌های دیگر هستند. از هر دو داده نشانی و CNAME پشتیبانی می‌کند.
ترکیب قابلیت metafo با پایگاه‌های داده MaxMind GeoIP برای انتخاب ترجیحات و ترتیب‌های جایگزینی مختلف برای کارخواه‌های گوناگون بر اساس موقعیت جغرافیایی تقریبی آن‌ها. از هر دو داده نشانی و CNAME پشتیبانی می‌کند.
بازگرداندن نشانی‌های تمام‌صفر یا CNAME نامعتبر "invalid." - عمدتاً برای تست و به عنوان کد نمونه ساده.
پیکربندی نگاشت‌های ایستای نام منابع به نشانی‌های IP یا CNAMEها - عمدتاً برای تست و به عنوان کد نمونه ساده.

یک نمونه پیکربندی که افزونه‌های ساده و همچنین service_types شرح‌داده‌شده قبلی را نشان می‌دهد:

service_types => {
  corpwww_type => {
    plugin => http_status
    vhost => www.corp.example.com
    url_path => /check_me
    down_thresh => 5
    interval => 5
  }
}
plugins => {
  null => {},
  reflect => {},
  static => {
    foo = 192.0.2.2
    bar = 192.0.2.123
    somehost = somehost.example.net.
  },
  multifo => {
    web-lb =>
      service_types => [ corpwww_type, xmpp ],
      lb01 => 192.0.2.200,
      lb02 => 192.0.2.201,
      lb03 => 192.0.2.202,
    }
  }
}

و سپس در فایل منطقه example.com خود، می‌توانید داشته باشید:

zeros 600 DYNA null
reflect 10 DYNA reflect
reflect-both 10 DYNA reflect!both
pointless 42 DYNA static!foo
acname 400 DYNC static!somehost
www 300/45 DYNA multifo!web-lb

در پایین‌ترین سطح، نحو فایل‌های پیکربندی gdnsd تقریباً شبیه به یک ساختار داده ناشناس در پرل (با استفاده از نحو ارجاع) است. سه نوع داده اصلی برای مقادیر وجود دارد: هش‌های مرتب (آرایه‌های متناظر که کلیدها را به مقادیر نگاشت می‌کنند)، آرایه‌های مرتب از مقادیر، و رشته‌های ساده. هش‌ها و آرایه‌ها را می‌توان در هر عمق دلخواهی به صورت تودرتو قرار داد. به طور کلی، فاصله‌های خالی اختیاری هستند. توضیحات تک‌خطی به هر دو سبک شل ("#") و سبک فایل منطقه DNS (";") مجاز هستند. آن‌ها تا انتهای خط فعلی ادامه می‌یابند و توسط تجزیه‌کننده به عنوان فاصله خالی در نظر گرفته می‌شوند.

یک هش با آکولاد محصور می‌شود ("{" و "}"). کلیدها با "=>" یا "=" از مقادیر خود جدا می‌شوند (به صلاحدید سلیقه شما). کلیدهای هش از همان قوانین مقادیر رشته‌ای ساده پیروی می‌کنند. مقادیر هش می‌توانند رشته‌های ساده، آرایه‌ها یا هش‌ها باشند. جفت‌های کلید/مقدار می‌توانند به صورت اختیاری یک کاما در انتها برای وضوح و تفکیک داشته باشند.

یک آرایه با براکت کروشه‌ای محصور می‌شود ("[" و "]"). مقادیر می‌توانند رشته‌های ساده، آرایه‌ها یا هش‌ها باشند. مقادیر می‌توانند به صورت اختیاری یک کاما در انتها برای زیبایی داشته باشند.

رشته‌ها (و در نتیجه کلیدها) را می‌توان هم به صورت نقل‌قول‌شده و هم بدون نقل‌قول نوشت. در شکل نقل‌قول‌شده، رشته با گیومه دوتایی (""") احاطه می‌شود، و می‌تواند شامل هر مقدار بایتی واقعی (حتی داده‌های باینری/utf-8 یا NUL) به جز """ یا "\" باشد. این دو نویسه باید با "\" اسکیپ شوند، یعنی "\"" و "\\".

در شکل بدون نقل‌قول، هیچ گیومه‌ای در اطراف وجود ندارد، و مجموعه نویسه‌های مجازِ بدون اسکیپ محدودتر است. نویسه‌های زیر مجاز نیستند: "][}{;#,"=\" (یعنی کروشه‌ها، آکولادها، نقطه‌ویرگول‌ها، علامت‌های هش، کاماها، گیومه‌های دوتایی، علامت‌های مساوی و بک‌اسلش‌ها). علاوه بر این، اولین نویسه نمی‌تواند علامت دلار ("$") باشد.

هر دو شکل از قوانین اسکیپ یکسانی استفاده می‌کنند که همان قوانین استاندارد RFC مورد استفاده در فایل‌های منطقه است. اسکیپ‌ها همیشه با "\" شروع می‌شوند. نویسه "\" که پس از آن هر تک‌بایتی غیر از رقم (0 تا 9) بیاید، به عنوان همان بایت تفسیر می‌شود. نویسه "\" که پس از آن دقیقاً ۳ رقم بیاید، آن ارقام را به عنوان مقدار صحیح ده‌دهی بدون علامت بایت مورد نظر تفسیر می‌کند (مقدار ۳ رقمی نمی‌تواند از 255 تجاوز کند).

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

example
"example"
ex\097mpl\e
"ex\097mpl\e"
internal\"doublequote
"internal\"doublequote"
white\ space
"white space"
"braces{every[where]oh}my"
braces\{every\[where\]oh\}my
"\\==="
"\092==="
"\092\=\=\="
\\\=\=\=
\092\=\=\=

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

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

وقتی در بخش‌های دیگر بالا به مقداری به عنوان یک «عدد صحیح» (یا نوع اسکالر خاص دیگر) اشاره می‌کنیم، منظورمان محدودیت‌هایی روی محتوای مقدار رشته نویسه‌ای است. تمام مقادیر اسکالر رشته‌های نویسه‌ای هستند. مقادیر «بولی» رشته‌های نویسه‌ای هستند که مقدار "true" یا "false" با هر ترکیبی از حروف بزرگ یا کوچک دارند.

۳ فایل پیکربندی نمونه زیر در معانی تجزیه‌شده خود یکسان هستند و هرگونه ابهام را برطرف می‌کنند:

نمونه ۱ (ساده و مرتب):

options = {
  listen = [ 192.0.2.1, 192.0.2.2 ],
}

نمونه ۲ (فلش‌های بزرگ، بدون کاما، نقل‌قول‌های اختیاری):

"options" => {
  listen => [ 192.0.2.1 192.0.2.2 ]
}

نمونه ۳ (فشرده و تک‌خطی):

options={listen=[192.0.2.1 192.0.2.2]}

قالب vscf اکنون مکانیزمی برای فایل‌های گنجانده‌شده (includefiles) در پیکربندی دارد. نحو آن به صورت زیر است:

$include{dir/file} # single file must exist
$include{dir/*}   # not ok if no matching files
$include{dir}     # ok if no files in dir

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

مسیر معمولاً به صورت گلوب (glob) در نظر گرفته می‌شود، که امکان گنجاندن چندین فایل را فراهم می‌کند. در صورت استفاده به عنوان گلوب، باید حداقل یک تطابق وجود داشته باشد - اگر هیچ فایل منطبقی وجود نداشته باشد، یک خطا خواهد بود. با این حال، اگر مسیر یک گلوب نباشد و به طور صریح نام یک دایرکتوری موجود را بیاورد، با الحاق "/*" طوری رفتار می‌شود که گویی گلوبی از تمام فایل‌های درون آن دایرکتوری است، و اگر هیچ فایلی درون آن دایرکتوری وجود نداشته باشد خطایی رخ نخواهد داد.

به یاد داشته باشید که در بالاترین سطح هر فایل vscf داده‌شده (حتی فایل‌های گنجانده‌شده)، فایل باید از نظر نحوی یا یک هش ضمنی یا یک آرایه صریح محصور در براکت کروشه‌ای باشد.

دستور include می‌تواند در دو زمینه متمایز در ساختار نحوی یک فایل پیکربندی استفاده شود:

زمینه مقدار (Value Context)
دستور include می‌تواند هر مقدار کامل (یعنی سمت راست یک مدخل نگاشت هش یا عضوی از یک آرایه) را با محتویات خود که یک هش یا یک آرایه است جایگزین کند. توجه داشته باشید که هیچ مکانیزمی برای مسطح کردن (flattening) آرایه یک فایل گنجانده‌شده در آرایه والد وجود ندارد (کل آرایه گنجانده‌شده یک آیتم آرایه واحد درون آرایه والد خواهد بود). همچنین، گنجاندن چندین فایل در یک عبارت واحد (نام دایرکتوری یا الگوی گلوب) در زمینه مقدار مجاز نیست. نمونه‌ها: 
main config:
  options => { listen => $include{foo} }
foo:
  [ 127.0.0.1, 127.0.0.2 ]
main config:
  plugins => $include{ "bar" }
bar:
  geoip => { ... }
  extmon => { ... }
زمینه ادغام هش (Hash-Merge Context)
دستور include همچنین می‌تواند در هشی ظاهر شود که در حالت عادی انتظار یک کلید می‌رود. در این حالت، فایل گنجانده‌شده باید در بالاترین سطح به شکل هش (به جای آرایه) باشد، و محتویات آن در هش والد ادغام می‌شوند. ادغام سطحی (shallow) است و کلیدهای متداخل مجاز نیستند. نمونه: 
main config:
  options => { ... },
  plugins => {
      extmon => { ... },
      $include{geoip.cfg},
      $include{plugins.d},
  }
geoip.cfg:
  geoip => { ... }
plugins.d/foo:
  weighted => { ... }
  simplefo => { ... }
plugins.d/bar:
  metafo => { ... }
plugins.d/baz:
  null => { ... }

gdnsd(8), gdnsd.zonefile(5), gdnsd-plugin-simplefo(8), gdnsd-plugin-multifo(8), gdnsd-plugin-weighted(8), gdnsd-plugin-metafo(8), gdnsd-plugin-geoip(8), gdnsd-plugin-extmon(8), gdnsd-plugin-extfile(8)

دفترچه راهنمای gdnsd.

حق نشر (c) 2012 Brandon L Black <blblack@gmail.com>

این فایل بخشی از gdnsd است.

نرم‌افزار gdnsd یک نرم‌افزار آزاد است: شما می‌توانید آن را تحت شرایط مجوز عمومی همگانی گنو (GNU GPL) همان‌طور که توسط بنیاد نرم‌افزار آزاد منتشر شده است، چه نسخه ۳ مجوز یا (به انتخاب خودتان) هر نسخه بعدی، مجدداً توزیع کرده و/یا تغییر دهید.

نرم‌افزار gdnsd به این امید توزیع می‌شود که مفید واقع شود، اما بدون هرگونه ضمانت؛ حتی بدون ضمانت ضمنی قابل فروش بودن یا مناسب بودن برای یک هدف خاص. برای جزئیات بیشتر به مجوز عمومی همگانی گنو مراجعه کنید.

شما باید یک نسخه از مجوز عمومی همگانی گنو را همراه با gdnsd دریافت کرده باشید. در غیر این صورت، نشانی http://www.gnu.org/licenses را ببینید.

2026-04-04 gdnsd 3.8.3