GDNSD.ZONEFILE(5) gdnsd GDNSD.ZONEFILE(5)

gdnsd.zonefile - قالب پرونده‌های منطقه (zone) در gdnsd

example.com:

$TTL 86400
@     SOA ns1 dns-admin (
      1      ; serial
      7200   ; refresh
      30M    ; retry
      3D     ; expire
      900    ; ncache
)
@     NS      ns1.example.com.
@     NS      ns2
@     NS      ns.example.net.
ns1   A       192.0.2.1 ; a comment
ns2.example.com.      A       192.0.2.2
@     7200    MX      10 mail-a
@     7200    MX      100 mail-b
$ttl 86400
; a comment
mail-a        A 192.0.2.3
mail-b        A 192.0.2.4
subz          NS      ns1.subz
subz          NS      ns2.subz
ns1.subz      A       192.0.2.5
ns2.subz      A       192.0.2.6
www   600/10  DYNA    some_plugin!resource_name
alias         CNAME   www
_http._tcp    1800    SRV     5 500 80 www
foo           TXT     "blah blah" "blah"
_spf          TXT     "v=spf1 ..."

این نحوِ اصلی پرونده منطقه (zonefile) برای gdnsd(8) است. نحو طوری طراحی شده است که تا جای ممکن به نحو استاندارد پرونده منطقه از RFC 1035 (که قالب «استاندارد» دیده‌شده در کارگزارهای سنتی BIND است) نزدیک باشد. این سند تنها به چند نکته برجسته مهم و/یا انحرافات از قاعده استاندارد می‌پردازد.

دستورالعمل‌های استاندارد $TTL، $ORIGIN و $INCLUDE با نحو و معناشناسی معمول خود پشتیبانی می‌شوند:

$TTL مقدار پیش‌فرض TTL هر رکوردی را که پس از آن می‌آید تغییر می‌دهد و می‌تواند چندین بار تکرار شود. توجه داشته باشید که در نبود تنظیم $TTL در سطح پرونده منطقه، مقدار پیش‌فرض TTL از گزینه پیکربندی سراسری "zones_default_ttl" گرفته می‌شود که مقدار پیش‌فرض آن 86400 (۱ روز) است.

$ORIGIN آنچه را که از آن نقطه به بعد به نام‌های میزبان فاقد صلاحیت (unqualified hostnames، یعنی آن‌هایی که نقطه پایانی "." ندارند) و همچنین هر مدخل "@" (که نام مستعاری برای مبدا فعلی است) الحاق می‌شود، تغییر می‌دهد. خود $ORIGIN نیز ممکن است یک نام فاقد صلاحیت باشد، که در این حالت مبدا قبلی به انتهای آن اضافه می‌شود. هر $ORIGIN دارای صلاحیت کامل (fully-qualified) باید در محدوده منطقه‌ای باشد که توسط این پرونده منطقه توصیف شده است. مبدا پیش‌فرض، نام خود منطقه است.

$INCLUDE پرونده دیگری را طوری در بر می‌گیرد که گویی محتویات آن در همان نقطه دستورالعمل $INCLUDE قرار دارد. دستورالعمل‌های include می‌توانند یک مبدا اختیاری مشخص کنند که تاثیری مشابه $ORIGIN در بالای پرونده دربرگرفته‌شده دارد. تغییرات مبدا (و TTL پیش‌فرض) در پرونده‌های دربرگرفته‌شده هیچ تاثیری بر پرونده بیرونی ندارد.

افزونه $GENERATE مربوط به BIND در حال حاضر پشتیبانی نمی‌شود، اما هیچ دلیل بنیادینی وجود ندارد که نتواند در آینده اضافه شود.

کاراکتر استاندارد "@"، به‌عنوان یک نام کامل، به‌صورت نام مستعاری برای مبدا فعلی پشتیبانی می‌شود. علاوه بر این، gdnsd دو افزونه ویژه @Z و @F را پیاده‌سازی می‌کند. این‌ها نام منطقه فعلی و مبدا اولیه (پیش از هرگونه اعلان درون‌پرونده‌ای $ORIGIN) پرونده‌ای که در حال پردازش است را نشان می‌دهند. بر خلاف "@"، آن‌ها می‌توانند به عنوان برچسب نهایی یک نام فاقد صلاحیت نیز استفاده شوند. @Z و @F در پرونده منطقه اصلی برای یک منطقه همیشه با یکدیگر معادل خواهند بود، اما هنگام پردازش پرونده‌های دربرگرفته‌شده از «$INCLUDE» ممکن است متفاوت باشند. به‌عنوان مثال:

* zones/example.org has the line "$INCLUDE includes/foo foo"
* zones/includes/foo has these lines:
   $ORIGIN bar
   asdf A 192.0.2.1
   $ORIGIN baz.@F
   asdf A 192.0.2.2
   $ORIGIN quux.@Z
   asdf A 192.0.2.3
* This results in creating all of these:
   asdf.bar.foo.example.org A 192.0.2.1
   asdf.baz.foo.example.org A 192.0.2.2
   asdf.quux.example.org    A 192.0.2.3

توجه داشته باشید که تغییرات مبدا که با @F و @Z انجام می‌شود، به سمت ریشه سلسله‌مراتب نام‌ها به عقب برمی‌گردد، و بنابراین معمولاً بدون استفاده صریح از نام خود منطقه امکان‌پذیر نخواهد بود. مزیت اصلی این دستورالعمل‌ها این است که امکان این نوع رفتار تغییر مبدا را فراهم می‌کنند در حالی که تمام داده‌های منطقه را به جای مطلق، نسبت به نام منطقه حفظ می‌نمایند. وقتی این موضوع با این واقعیت ترکیب شود که پویشگر مناطق پیوندهای نمادین را بارگذاری می‌کند، بدان معناست که پرونده بالا zones/example.org می‌تواند به صورت پیوند نمادین با نام zones/example.com نیز ایجاد شود، و تمام همان پرونده‌ها را بارگذاری کرده و بدون هیچ تداخلی درختی یکسان از داده‌ها را تحت نام منطقه دیگر ارائه دهد.

تمام رکوردهای منبع (RRها) باید از کلاس "IN" باشند، که پیش‌فرض ضمنی است.

gdnsd(8) از انواع RR استاندارد زیر با قالب‌های استاندارد RDATA آنها پشتیبانی می‌کند:

سنتی: SOA، A، AAAA، NS، PTR، CNAME، MX، SRV، TXT، NAPTR
غیرسنتی: CAA
صریحاً پشتیبانی‌نشده: HINFO

همچنین از قالب عمومی برای انواع ناشناخته RR که در RFC 3597 مستند شده است پشتیبانی می‌کند، که نحوی مانند زیر دارد:

foo TYPE31337 \# 10 0123456789 ABCDEF0123

... که نشان‌دهنده یک RR از نوع عددی 31337 شامل ۱۰ بایت RDATA است، که در بخش نهایی RR به‌صورت یک جفت رشته هگزادسیمال ۵ بایتی مشخص شده است. برای جزئیات کامل به خود RFC 3597 مراجعه کنید.

برنامه gdnsd اجازه استفاده از قالب RFC3597 را برای مشخص کردن هیچ‌یک از انواع سنتی و استاندارد RRهای پشتیبانی‌شده نمی‌دهد، اما می‌توان از آن برای کدگذاری داده‌ها برای انواع غیرسنتی استفاده کرد. همچنین استفاده از RFC3597 برای مشخص کردن رکوردهای HINFO مجاز نیست، زیرا این رکوردها اکنون در gdnsd برای استفاده در مدیریت پرس‌وجوهای "ANY"، با استفاده از گزینه RFC 8482 HINFO رزرو شده‌اند.

مقدار TTL حافظه پنهان منفی رکوردهای "SOA" برابر با کمینه فیلد سنتی «minimum» (آخرین فیلد، که از زمان RFC 2308 همیشه به معنای «TTL حافظه پنهان منفی» است) و TTL واقعی خود رکورد SOA تنظیم می‌شود. این TTL به عنوان TTL واقعی رکورد SOA در هر زمان که صادر شود (چه برای پاسخ‌های منفی یا مثبت) استفاده می‌شود.

علاوه بر این، gdnsd از دو نوع رکورد منبع مجازی ویژه و غیراستاندارد DYNA و DYNC پشتیبانی می‌کند:

"DYNA" برای رکوردهای آدرس تعیین‌شده به‌صورت پویا (هر دو A و AAAA) از طریق کد افزونه (پلاگین) است. سمت راست یک RR از نوع "DYNA" شامل یک نام افزونه و یک نام منبع است که با یک علامت تعجب از هم جدا شده‌اند. نام منبع و آدرس IP کلاینت DNS و/یا اطلاعات edns-client-subnet به افزونه نام‌برده تحویل داده می‌شود، و به کد افزونه بستگی دارد که کدام آدرس‌ها از چه انواعی را در پاسخ برگرداند.

جستجوی پویای افزونه برای "DYNA" در هر جایی که رکوردهای معمولی "A" و/یا "AAAA" استفاده می‌شوند به کار خواهد رفت. "DYNA" نمی‌تواند همزمان با رکوردهای ایستای واقعی A یا AAAA با همان نام وجود داشته باشد، اما می‌تواند در کنار هر نوع RR دیگری همزیستی داشته باشد.

رکوردهای "DYNA" و "DYNAAAA" نمی‌توانند برای ارائه آدرس کارگزارهای نام (nameservers) استفاده شوند. به عبارت دیگر، هر نامی که در محدوده منطقه در سمت راست یک رکورد "NS" وجود داشته باشد، نمی‌تواند دارای "DYNA" یا "DYNAAAA" باشد (و در همین رابطه، باید حداقل یکی از "A" یا "AAAA" را داشته باشد).

مثال:

; asks plugin 'geoip' to provide address data from
;  its resource named 'pubwww' for address queries.
foo DYNA geoip!pubwww
foo MX 10 mail

"DYNC" دارای همان نحو "DYNA" در بالا است، اما قوانین داده متفاوتی دارد. نتایج بازگردانده‌شده از افزونه‌ها از طریق "DYNC" می‌توانند آدرس‌ها یا یک رکورد "CNAME" باشند. "DYNC" همانند رکوردهای عادی "CNAME"، نمی‌تواند با هیچ رکورد منبع دیگری تحت همان نام همزیستی داشته باشد. این امر همچنین بدین معناست که "DYNC" نمی‌تواند در ریشه منطقه استفاده شود، زیرا ریشه منطقه نیازمند رکوردهای "NS" و "SOA" است.

مقصدهای CNAME پویای "DYNC" نمی‌توانند برای اشاره به نام‌هایی در همان پرونده منطقه رکورد "DYNC" استفاده شوند؛ آنها باید برای اشاره به مناطق دیگر به کار گرفته شوند.

مثال:

; asks plugin 'geoip' to provide address data or a CNAME
;  (at the plugin's discretion) for its resource named
;  'www'.  No other RRs of any type for name 'foo' are
;  legal alongside this record.
foo DYNC geoip!www

فیلدهای TTL در "DYNA" و "DYNC" دارای یک گسترش نحوی هستند و مفاهیمی اندکی متفاوت از فیلد TTL یک RR سنتی و ثابت دارند. قالب TTLهای DYNA/DYNC به‌صورت "MAX[/MIN]" است که در صورت عدم تعیین صریح، مقدار پیش‌فرض "MIN" برابر با نصف "MAX" خواهد بود.

بر اساس پیکربندی و وضعیت سرویس‌های پایش‌شده زیرین (به «service_types» در gdnsd.config(8) مراجعه کنید)، gdnsd حداقل زمان تا تغییر وضعیت احتمالی بعدی که می‌تواند بر نتیجه یک "DYNA" یا "DYNC" معین تأثیر بگذارد را می‌داند. به‌عنوان مثال، با توجه به پیکربندی و وضعیت، ممکن است مشخص باشد که برای تغییر وضعیت یک آدرس فعلی "DOWN" به وضعیت "UP" (و در نتیجه تغییر پاسخ به یک پرس‌وجوی معین)، به ۷ بررسی پایش موفق متوالی دیگر در فواصل ۸ ثانیه‌ای نیاز است، و بنابراین نمی‌تواند در کمتر از ۵۶ ثانیه رخ دهد. در این حالت، ۵۶ ثانیه TTL محاسبه‌شده به‌صورت داخلی خواهد بود.

در مواردی که چندین منبع پایش‌شده در تصمیم‌گیری و/یا پاسخ یک افزونه دخیل باشند (مانند multifo)، TTL محاسبه‌شده عموماً کمینه همه TTLهای پایش داخلی دخیل خواهد بود. این TTL محاسبه‌شده سپس به محدوده‌های "MAX" و "MIN" پرونده منطقه مقید می‌شود.

مثال‌ها:

; Explicit range of 30 - 300:
www 300/30 DYNC weighted!foo
; Implicit range of 150 - 300:
www 300 DYNA metafo!myservice
; Avoid all TTL-mangling and use a fixed value of 10 minutes:
www 600/600 DYNA geoip!foo-dist

رکوردهای "TXT" در gdnsd از تقسیم خودکار ثابت‌های رشته‌ای طولانی پشتیبانی می‌کنند. به جای شکستن دستی داده‌ها به قطعات ۲۵۵ بایتی طبق الزامات پروتکل، می‌توانید یک قطعه طولانی واحد را مشخص کنید تا کارگزار آن را به‌طور خودکار در مرزهای ۲۵۵ بایتی تقسیم کند (این رفتار را می‌توان از طریق gdnsd.config(5) نیز غیرفعال کرد، که قطعات بزرگتر از حد مجاز را به خطاهای تجزیه پرونده منطقه تبدیل خواهد کرد).

رکوردهای TXT هنگام کدگذاری در قالب rdata برای انتقال روی شبکه (wire transmission)، حداکثر به ۱۶۰۰۰ بایت محدود می‌شوند.

gdnsd(8)، gdnsd.config(5)

راهنمای gdnsd.

حق نشر (c) 2012 متعلق به Brandon L Black <blblack@gmail.com>

این پرونده بخشی از gdnsd است.

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

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

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

2026-04-04 gdnsd 3.8.3