Версия 1.1.1, 12 юни 2008
Веселин Колев, Софийски Университет "Св. Климент Охридски"
Адрес за кореспонденция: vesso AT vesselin.org
Първоизточник: http://www.vesselin.org
Лиценз на документа: CC Attribution-ShareAlike
Съдържание:
Указване на първичен сървър за имена за зоната на управлявания домейн
Задаване на параметри "по подразбиране" в командния интерпретатор на nsupdate
Задаване на условия за наличие или отсъствие на ресурсни записи
nsupdateИнструментът nsupdate е част от пакета bind. Той служи за дистанционно управление на съдържание на зонални файлове, разположени (в общия случай) върху отделечени сървъри за имена. За да може да бъде извършено това управление, описанието на зоната в конфигурационния файл на отдалечения сървър named.conf, трябва да е такова, че да позволява динамичното й управление.
Предимството на nsupdate е, че не се налага собственика на зоната да има права за достъп до отдалечената система (напрмер потребителско име и/или достъп до локалната файлова система и т.н). Още повече, не се налага той да има достъп до ръчна редакция на файла на зоната на домейна чрез някакви локални за отдалечената система инструменти като скриптове и др.
Системата за динамично управление на зони често се базира на удостоверяване на заявките за промяна на записите чрез ключ. Това е най-сигурният до момента начин за извършваето им. Понастоящем се използва симетричен ключ за подписване на заявките за промяна на записите чрез алгоритъма HMAC-MD5. При него всяка заявка се подписва електронно с ключа. Удостоверяването на заявките следва TSIG алгоритъма, описан в RFC2845.
Клиентът и администратора на отдалечения сървър за имена, трябва да обменят по сигурен и неподслушваем канал ключа за подписването на заявките. Обикновено генерирането на ключ се извършва от администратора на отдалечения сървър за имена, но е възможен и обратния вариант, при който генерирането се извършва от страна на клиента. Всичко зависи от договорката между тях, но и в двата случая споменатите две страни трябва да притежават копие от ключа.
За генерирането на ключ се използва инструментът dnssec-keygen от пакета bind.
Генериране на ключ с име domain.com по алгоритъм hmac-md5 с дължина 512 бита става чрез следния команден ред:
$ /usr/sbin/dnssec-keygen -r /dev/urandom -a hmac-md5 -b 512 -n HOST domain.com
Този команден ред произвежда в текущата на изпълнението му директория два файла с имена подобни на:
Kdomain.com.+157+41723.key Kdomain.com.+157+41723.private
Винаги името на файла започва с "K". След него непосредствено следва името на ключа (по горния пример това е domain.com). След това в името на файла има две числа разделени със знак "+". Първото число отразява номера на алгоритъма, който ще използва ключа. В нашия случай това е "hmac-md5" и на него съответства номер 157. Второто число е случайно генерирано и отразява уникалния номер на ключа. За примерът това е 41723.
Структурата на файла с наставка ".key" е следната:
domain.com. IN KEY 512 3 157
csVJh6jyqyDRjFHz4rfUwz0rIEp5ZMi6qrFwgCkpWE9hG4MHL+/zoYk1RJe683hRME4lUBL1XUrT4B1tRvkrlA==
Файлът с наставка private е структуриран така:
Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: csVJh6jyqyDRjFHz4rfUwz0rIEp5ZMi6qrFwgCkpWE9hG4MHL+/zoYk1RJe683hRME4lUBL1XUrT4B1tRvkrlA==
След като бъдат генерирани, тези два файла трябва да бъдат предпазени от публичен достъп. Първата стъпка за това е да им бъдат зададени съответните за това права за достъп спрямо локалната файлова система. Тези права трябва да се зададат така, че да позволяват четене на файловете само от страна на техния собственик. Задаването им може да стане с команден ред от вида:
$ chmod 600 Kdomain.com.+157+41723.*
Ако файловете се съхраняват на външен носител, то те трябва да бъдат задължително криптирани. От тях трябва да се запази и резервно копие. При съмнение за разкриването на ключовете, трябва веднага да се уведомят администраторите на сървърите за имена, с който ключовете са споделени, за да могат последните да предотвратят нежелани записи в зоналните файлове.
nsupdate.Принципът на работа на инструмента nsupdate е следния. Въвежданите в командния му интерпретатор или прочетени от файл заявки за промяна (включване или изтриване на ресурсни записи) на зоната на домейна, се подписват чрез ключа и изпращат до първичния сървър за имена на домейна. Обикновено това е този, който е указан в SOA ресурсния запис на зоната. Сървърът проверява електронния подпис върху заявките чрез локално инсталираното копие на ключа и при установяване на автентичността на заявките те биват изпълнявани. Сървърът подава на клиента флаг за грешка, ако заявката не може да бъде изпълнена по една или друга причина.
Ако указаният с SOA сървър за имена не е първичен (в това няма нищо нередно - там може да се укаже и сървър за имена, който е вторичен и това може да бъде направено по едно или друго съображение, което не е предмет на дискусия тук), то се налага в nsupdate да се укаже към кой именно сървър за имена ще бъдат изпращани подписаните заявки. За подробности виж параграф 5.
Инструментът nsupdate има команден интерпретатор, в който потребителя подава команди с параметри към тях. Влизането в командния интерпретатор става чрез извикване на изпълнимия файл nsupdate, а излизането от него с командата quit без параметри към нея:
$ nsupdate > quit $
Изпращането на заявките направени в командния интерпретатор на nsupdate към сървъра за имена, отговорен за зоната, става с командата send. Ето пример:
$ nsupdate > update add www.domain.com 80 IN A 192.168.100.1 > send > quit $
Освен от командния интерпретатор, заявките могат да бъдат четени от указан файл. Горния пример би могъл да се помести във файл с име nsupdate.asc със следното съдържание:
update add www.domain.com 80 IN A 192.168.100.1 send quit
и след това този файл да се подаде на nsupdate в рамките на следния команден ред:
$ nsupdate nsupdate.asc
Дали ще се използва командния интерпретатор или командите ще се четат от файл е въпрос на избор и/или конкретна ситуация. По-надолу, нещата са преставени в контекста на командния интерпретатор с цел по-лесно онагледяване.
Инструментът nsupdate може да приема различни опции при стартирането си като изпълним файл:
-k: указва името на файла съдържащ ключа за електронно подписване на заявките (за повече подробности виж параграф 4);
-y : указва името и стойността на ключа, разделени със сепаратор ":" (за повече подробности виж параграф 4);
-t : задава максималното време за изчакване (след изпращане на заявката) на отговор на подадена към сървъра заявка, след което, ако тя не бъде потвърдена, се обявява за неизпълнена (по подразбиране това време е 300 секунди);
-u : указва времето, през което UDP заявките се повтарят, ако изпратените преди това заявки не са получи потвърждение от страна на сървъра за имена (по подразбиране е 3 секунди, а при задаване на стоиност 0, се прави преизчисляване на основата на параметъра подаден след "-t" и броят на указаните с "-r" UDP опита за заявки);
-r : указва броят на опитите за изпращане на UDP заявка, след което се преминава в TCP режим на изпращане за заявката (по подразбиране броят опити е три, а ако се укаже 0 се прави само един опит за UDP заявка);
-v : изпращане на заявки само в TCP режим (изпращане на заявки до сървъра за имена по TCP).
nsupdate от команден ред и указване на ключ.За да работи nsupdate е необходимо да са налични файловете с ключа, описани в параграф 2.
Извикването на nsupdate става в команден ред по начин, подобен на следния:
$ nsupdate -k Kdomain.com.+157+41723.private >
Чрез опцията "-k" се указва файл съдържащ ключа за управление на записите (в примера по-горе се предполага, че този файл се намира в текущата за изпълнение на nsupdate директория, но в общия случай може да се укаже и с пълен път). Ако всичко е наред и няма проблеми, трябва да се появи знакът за нов ред ">" в комантния интерпретатора на nsupdate.
Друг начин на стартиране на nsupdate в режим за работа с ключ е директното подаване на името на ключа и самия ключ в командния ред:
$ nsupdate -y
domain.com:csVJh6jyqyDRjFHz4rfUwz0rIEp5ZMi6qrFwgCkpWE9hG4MHL+/zoYk1RJe683hRME4lUBL1XUrT4B1tRvkrlA== >
Тук се използва опцията "-y" като след нея се указва името на ключа, разделено с двуеточие от самата стойност на ключа. Ако всичко е наред и няма проблеми, трябва да се появи знакът за нов ред ">" в комантния интерпретатора на nsupdate.
Ако TSIG ключа за електронно подписване не се зададе в команден ред при извикването на nsupdate (както е показано в параграф 3), това може да бъде направено по-късно в самия команден интерпретатор на инструмента и се извършва по начин подобен на описания в следния пример:
$ nsupdate > key domain.tld
csVJh6jyqyDRjFHz4rfUwz0rIEp5ZMi6qrFwgCkpWE9hG4MHL+/zoYk1RJe683hRME4lUBL1XUrT4B1tRvkrlA== >
Непосредствено след "key" се указва името на ключа и след това неговата стойност.
Указването на първичен за зоната на управлявания домейн сървър за имена става чрез командата "server" в командния интерпретатор на nsupdate. Всички заявки, направени след това, се насочват към указания сървър и не се следва указания в SOA записа сървър за имена (виж параграф 2).
В примера по-долу, всички направени заявки (в рамките на една сесия на nsupdate), ще се изпращат към сървъра за имена ns.domain.tld:
$ nsupdate -y
domain.com:csVJh6jyqyDRjFHz4rfUwz0rIEp5ZMi6qrFwgCkpWE9hG4MHL+/zoYk1RJe683hRME4lUBL1XUrT4B1tRvkrlA== > server ns.domain.com >
За повече подробности виж параграф 8.
Заявката за прибавяне на ресурсен запис се подава след командата "update add" в командния интерпретатор на nsupdate.
Структурата на заявките следва шаблона:
Име на ресурсния запис | TTL на ресурсния запис | Клас на ресурсния запис | Тип на ресурсния запис | Стойност на ресурсния запис
Ето един пример:
> update add www.domain.com 360 IN A 192.168.10.2
В този пример името на ресурсния запис е "www.domain.com". Този запис има TTL равен на 360 секунди, принадлежи към клас "IN", типа на ресурсния запис е "A", а стойността му е 192.168.10.2.
Забележка. Класът на ресурсния запис може да не бъде указван и тогава по подразбиране се приема, че е "IN".
Заявката за премахване на ресурсен запис се подава след командата "update delete" в командния интерпретатор на nsupdate.
Структурата на заявките следва шаблона описан в параграф 6.
Ето един пример:
> update delete www.domain.com 360 IN A 192.168.10.2
В този пример името на ресурсния запис е "www.domain.com". Този запис има TTL равен на 360 секунди, принадлежи към клас "IN", типа на ресурсния запис е "A", а стойността му е 192.168.10.2.
Забележка. Класът на ресурсния запис може да не бъде указван и тогава по подразбиране се приема, че е "IN".
Има една особеност, която трябва да бъде отчетена много внимателно. Ако не се укаже конкретност в шаблона, може да се изтрие цяла група записи, което може да е доста опасно. Ето пример. Записите са били направени така:
$ nsupdate -k Kdomain.com.+157+41723.private > update add list.domain.com 360 IN A 192.168.10.2 > update add list.domain.com 360 IN MX 10 mail.domain.com > send
Следователно за list.domain.com има два ресурсни записа (един A и един MX). Ако сега се изпълни следното:
$ nsupdate -k Kdomain.com.+157+41723.private > update delete list.domain.com > send
След изпълнението ще се изтрият всички записи, чието име е list.domain.com (за нашия пример те са два - един A и един MX), без оглед на това какъв е TTL, класа, типа или стойността на записа.
nsupdate.За да не се повтаря указването на един и същ параметър, той може да бъде зададен в рамките на една и съща сесия на nsupdate. Ето какви параметри за указване допуска командният интерпретатор на nsupdate:
Указване на първичен сървър за имена, към когото да се изпращат заявките
Указването се извършва с командата "server", на която като аргументи се подават IP адреса или името на хоста на сървъра за имена и евентуално порт, до който тези заявки да се изпращат (ако не се укаже порт, по подразбиране се използва порт 53/upd, а ако размера на заявките е по-голям от допустимия за UDP транспорт, се използва порт 53/tcp). Ето пример:
> server 192.168.100.1 53
В този пример всички заявки, въвеждани след това указване, се изпращат след изпълнение на командата "send" към сървъра за имена имащ IP адрес 192.168.100.1 на порт 53/udp (или ако размера на заявките е по-голям от допустимия за UDP транспорт се изпращат на порт 53/tcp). Вместо IP адрес може да се използва име на хост.
Указване на локален адрес и порт за излъчване на заявките
Извършва се с командата local последвана от IP адрес или име на хост и евенатуално порт. Такова указване се прави, ако върху локалната система са налични повече от един IP адреси, чрез които тя може да се представи пред отделечения първичен сървър за имена. Подобно указване може да бъде направено, ако се изисква заявките да излизат от определен порт и особено в случаите на наличие по пътя на преноса на защитни стени, които пропускат излъчване само от определни портове. Отново трябва да се напомни, че по подразбиране преносния протокол за заявките е UDP, но в случай на големи заявки може да се премине автоматично към TCP (защитната стена трябва да е адекватна към тази възможност за смяна на транспортния протокол). Ето пример за указаване на локален адрес и порт:
> local 192.168.3.1 1025
В дадения пример всички заявки се излъчват от порт 1025/upd на адрес 192.168.3.1. Ако заявките са твърде големи за транспорт по UDP се използва автоматично порт 1025/tcp.
Указване на зона на домейн
Извършва се с командата zone след която се указва името на зоната. При това указване всички заявки се отнасят за записи в указаната зона на домейн. По подразбиране nsupdate се опитва да определя зоната, към която да изпрати заявките, на базата на името на записа. Тази възможност се използва рядко.
> zone domain.com
Указване на клас за заявките
Извършва се с командата class следвана от класа на заявките. Възможните стойности са CH и IN. По подразбиране (без да се използва указване с командата class) е IN.
> class IN
Укзване на ключ
Указването е описано в параграф 4.
Условията за наличие или отсъствие на ресурсен запис в зоната са мощен инструментариум за съставяне на условия, при чието изпълнение или неизпълненние може или не може да се извърши запис в зоналния файл. Те предпазват от фатални изтривания или записи в процеса на управление на зоналния файл.
условия за наличие на ресурсен запис в управляваната зона
Извършва се чрез указване от типа:
> prereq yxdomain recond-name [TTL] [class] [record-valie]
Задължително трябва да се обяви поне името на ресурсния запис (record-name). Останалите параметри на записа, като TTL, class и стойност може да не се подават, но всичко зависи каква точност на съвпадение се търси (дали само по име, или по име и TTL, по име и class, по име и стойност и т.н.).
Пример: изисква се да се провери дали в зоната на домейна domain.com съществува ресурсен запис за mail.domain.com, без значение дали типа му е MX, TXT, A, CNAME и др, и ако такъв съществува да се постави ресурсен запис от тип A за mail-1.domain.com, който да е с време на живот 60 секунди и да сочи към IP адрес 192.168.10.1:
> prereq yxdomain mail.domain.com > update add mail-1.domain.com 60 A 192.168.10.1 > send
Възможните изходи от изпълнението са два:
успешен - ако поне един запис с изискваното име съществува
При такъв изход след изпълнение на send се преминава на нов ред в командния интерепретатор на nslookup (виж примера по-горе):
> prereq yxdomain mail.domain.com > update add mail-1.domain.com 60 A 192.168.10.1 > send >
неуспешен - не е открит никакъв запис с това име
При такъв изход след изпълнение на send се издава съобщение за несъстоятелност на условието и се получава резултат NXDOMAIN (Non-eXistent DOMAIN - несъществуващ домейн):
> prereq yxdomain mail.domain.com > update add mail-1.domain.com 60 A 192.168.10.1 > send update failed: NXDOMAIN >
Не е проблем да се задава повече от едно условие за наличие. Тогава успешен изход от операцията има само при изпълнение на всички условия.
условия за отсъствие на ресурсен запис в управляваната зона
Извършва се чрез указване от типа:
> prereq nxdomain recond-name [TTL] [class] [record-valie]
Задължително трябва да се обяви поне името на ресурсния запис (record-name). Останалите параметри на записа, като TTL, class и стойност може да не се подават, но всичко зависи каква точност на съвпадение се търси (дали само по име, или по име и TTL, по име и class, по име и стойност и т.н.).
Пример: изисква се да се провери дали в зоната на домейна domain.com съществува ресурсен запис за mail.domain.com, без значение дали типа му е MX, TXT, A, CNAME и др, и ако такъв не съществува да се премахне ресурсен запис от тип A за mail-1.domain.com, който е с време на живот 60 секунди и сочи към IP адрес 192.168.10.1:
> prereq nxdomain mail.domain.com > update delete mail-1.domain.com 60 A 192.168.10.1 > send
Възможните изходи от изпълнението са два:
успешен - ако запис с изискваното име не съществува
При такъв изход след изпълнение на send се преминава на нов ред в командния интерепретатор на nslookup (виж примера по-горе):
> prereq nxdomain mail.domain.com > update delete mail-1.domain.com 60 A 192.168.10.1 > send >
неуспешен - открит е запис с това име
При такъв изход след изпълнение на send се издава съобщение за несъстоятелност на условието и се получава резултат YXDOMAIN (Yet-eXistent DOMAIN - все още съществуващ домейн, при условие, че не би трябвало да съществува):
> prereq nxdomain mail.domain.com > update delete mail-1.domain.com 60 A 192.168.10.1 > send update failed: YXDOMAIN >
Не е проблем да се задава повече от едно условие за отсъствие. Тогава успешен изход от операцията има само при изпълнение на всички условия.
смесени условия за едновременно наличие и отсъствие на ресурсен запис
Задаването на подобни условия става в смесен режим. Ето пример:
> prereq yxdomain mail1.domain.com > prereq nxdomain mail.domain.com > update delete mail-1.domain.com 60 A 192.168.10.1 > send
В този пример се иска да има наличен запис за mail1.domain.com и да отсъства запис за mail.domain.com и ако тези двете условия се изпълнят, да се направи A ресурсен запис с TTL 60 секунди, който да насочва името на хост mail-1.domain.com към IP адрес 192.168.10.1.
Ако не се удовлетвори условието за наличие на записа, ще бъде изведено съобщение "NXOMDAIN", а ако не се удовлетвори условието за отсъствие, ще се изведе съобщение "YXDOMAIN". Ако и двете условия са удовлетворени, няма да се изведе никакво съобщение.
Версия 1.1: [tar.gz] [електронен подпис върху архива]
Публикувана на: 14 октомври 2007г.
Този документ е с OpenPGP подписано съдържание
[информация] [електронен подпис][TimeStamp]