Файлове с описание на зони
В тази статия ще анализираме характеристиките на използването на контролни директиви, когато описваме зони в главните файлове. В допълнение към стандартните директиви $ORIGIN и $INCLUDE, $TTL и $GENERATE също ще бъдат взети предвид.
Най-често използваната контролна директива е$ORIGIN. Позволява ви да определите текущото име на домейн. Нека обясним какво представлява. Когато описват именуван конфигурационен файл, първичната, вторичната (конфигурационен файл BIND 4) и директивата за зона (конфигурационен файл BIND 8 или 9) указват името на зоната като първи параметър, например:
# # конфигурационен файл за BIND 4 # директория /etc/namedb primary kyky.ru kuku.ry secondary first.kyky.ru 192.168.0.1 first.kuku.ru
/* конфигурационен файл за BIND 9 */ директория с опции "/etc/namedb"; >; зона "kyky.ru" в главния тип; файл "kyky.ru"; >; зона "first.kyky.ru" в тип slave; файл "first.kyky.ru"; майстори ; >;
И в двата примера зоната на отговорност за главния сървър е kyky.ru, а за подчинения - first.kyky.ru.
Сега, ако отидем до основния файл на зоната kyky.ru, т.е. файл с описание на зона kyky.ru, тогава по подразбиране името kyky.ru ще се приема като текущо име на домейн. За да бъдем абсолютно точни, това име ще се съдържа в променливата @. Ето защо файлът с описание на зоната kyky.ru започва със запис като този:
@ В SOA ns.kyky.ru. adm.kuku.ru. ( 1 2h 30m 2d 30m ) IN NS ns.kyky.ru. ns В А 192.168.0.2
Какво да направите, ако трябва да включите описание на хост от друга зона в описанието на зоната, например от зоната, делегирана от този сървър на друг сървър:
@ В SOA ns.kyky.ru. adm.kuku.ru. ( 1 2h 30m 2d 30m ) IN NS ns.kyky.ru. ns IN A 192.168.0.2 sub IN NS first.kyky.ru. първи В А192.168.0.2 $ORIGIN sub.kyky.ru. ns В А 192.168.0.45
В този пример директивата $ORIGIN предефинира текущото име на домейн от kyky.ru на sub.kyky.ru.
Най-общо казано, основната цел на $ORIGIN е да опрости съдържанието на файла с описание на зоната при дефиниране на поддомейни в същата зона като домейна по-горе:
$ ПРОИЗХОД kyky.ru. ns В A 192.168.0.1 www В A 192.168.0.2 $ORIGIN sub1.kyky.ru. host1 В A 192.168.0.3 host2 В A 192.168.0.4 $ORIGIN sub2.kyky.ru. хост1 В А 192.168.0.5 хост2 В А 192.168.0.6
В примера по-горе създадохме два поддомейна в домейна kyky.ru и именуването на машините в тях е същото, но пълните имена на домейни са различни, което не е изненадващо.
Преди няколко години доста често можеше да се види следната картина във файловете с описание на зони:
@ В SOA ns.kyky.ru. adm.kuku.ru. ( 1 2h 30m 2d 30m ) IN NS ns.kyky.ru. В NS ns.provider.ru. ns В 192.168.0.2 $ORIGIN provider.ru. ns В А 192.168.10.5
какво не е наред тук Формално всичко е точно. За зоната kyky.ru трябва да се дефинират два сървъра за имена на домейни с независима мрежова връзка, тъй като това е корпоративен домейн.
Първият сървър е дефиниран в мрежата на компанията и носи името ns.kyky.ru, а вторият сървър е сървърът на доставчика, който осигурява дублиране, т.е. ns.kyky.ru е главен, а ns.provider.ru е подчинен.
По-новите версии на BIND (4.9 и по-нови) проследяват това, но по-старите версии не. Администраторите на системата за имена на домейни включиха такива „лепкави“ записи, за да спестят трафик (няма нужда да се правят заявки към сървъри за имена на домейни).
В този случай се използва файлът /etc/namedb/my_zone.dsc, защото обикновено директиви за директория (BIND 4)или директория (BIND 8-9) укажете точно тази директория за съхраняване на именувани файлове на база данни.
В този случай е посочен пълният път и той ще се използва при достъп до файла.
Нека сега разгледаме още две контролни директиви, които се появиха сравнително наскоро във файловете с описание на зони: $TTL и $GENERATE.
Директивата$TTLдефинира времето за съхранение на записа с описание на ресурса в кеша на резолвера и ако резолверът е "глупав" (stub), т.е. няма кеш и изпраща само рекурсивни заявки, тогава $TTL ще определи колко дълго RR се съхранява в кеша на локалния сървър за имена на домейни, който изпълнява заявките на "глупавия" резолвер.
Тази директива беше въведена в RFC-2308, за да освободи последния параметър на SOA записа за отрицателното време за кеширане.
Директивата $TTL трябва да се появи точно преди SOA записа във файла с описание на зоната. $TTL е свързан с 32-битова дефиниция на стойност, така че може да приема стойности от 0 до 2147483647 (RFC 2181).
Най-общо казано, администраторът на BIND версия 8 или 9 сървъри има способността да дефинира максималното време на кеша за запис на описание на ресурс. Това се прави в конфигурационния файл named.conf. По подразбиране това време е една седмица.
В материала "Описание на зона. Формат на запис на описание на ресурс (RR)" беше посочено, че при преминаване от стари версии на BIND към нови не е необходимо да променяте файловете с описание на зоната, т.к. RR форматът не е променен. Както вече стана ясно, това не е съвсем вярно. Във всеки случай целта на един от атрибутите на SOA се е променила и в резултат на това е станала необходима директивата за управление $TTL.
Разбира се, разработчиците на BIND разбират, че в мрежата има голям брой сървъри, за които администраторите просто са забравили, и следователно е разумнокеш времена (TTL) по подразбиране.
Директивата $GENERATE има за цел да опрости процеса на създаване на файл с описание на зона. Основната му цел е да намали броя на редовните записи, които се различават един от друг с един или повече знака. Например, ако стандартният набор от записи във файла с описание на зоната изглежда така:
host1 IN A 192.168.0.1 host2 IN A 192.168.0.2 … host10 IN A 192.168.0.10
Тогава запис, използващ $GENERATE, ще изглежда така:
$ГЕНЕРИРАЙТЕ 1-10 $ В 192.168.0.$
Така сменихме 10 записа с един.
Този запис е много полезен, когато трябва да дефинирате обратна зона за мрежа от клас C (първите 24 бита са маскирани в CIDR нотация), която е разделена на подмрежи от доставчика и тези подмрежи се разпространяват към различни клиенти (вижте RFC 2317). Нека оставим самия проблем зад кулисите до момента, в който наистина трябва да делегираме този вид обратни зони, и тук представяме само частта от файла с описание на "обратната" зона, в която се прилага управляващата директива $GENERATE:
$GENERATE 1-63 $.0.168.192.in-addr.arpa В CNAME $.0-63.0.168.192.in-addr.arpa. 0-63.0.168.192.in-addr.arpa. В NS ns.kyky.ru.
$GENERATE 65-127 $.0.168.192.in-addr.arpa В CNAME $.64-128.0.168.192.in-addr.arpa. 64-128.0.168.192.in-addr.arpa. В NS ns.corp.ru.
В този случай $GENERATE се използва за създаване на RR от същия тип.
Имайте предвид, че $GENERATE не е стандартна директива, а разширение на директивите за управление на пакета BIND.