от Beco(4-04-2006)

рейтинг (20)   [ добре ]  [ зле ]

Printer Friendly Вариант за отпечатване

Управление на зони в динамичен режим чрез nsupdate

(за потребители на UNIX и UNIX-подобни операционни системи)

Copyright ©2006 Веселин Колев, Софийски Университет "Св. Климент Охридски"

Лиценз на документа: CC Attribution-ShareAlike

Съдържание на лиценза: http://creativecommons.org/licenses/by-sa/2.5/

  1. Инструментът nsupdate.
  2. Генериране на ключ.
  3. Принцип на работа на nsupdate.
  4. Извикване на nsupdate от команден ред и указване на ключ.
  5. Указване на първичен сървър за имена за зоната на управлявания домейн.
  6. Заявка за прибавяне на ресурсен запис.
  7. Заявка за премахване на ресурсен запис.
  8. Задаване на параметри "по подразбиране" в командния интерпретатор на nsupdate.
  9. Задаване на условия за наличие или отсъствие на ресурсни записи.

1. Инструментът nsupdate.

Инструментът nsupdate е част от пакета bind. Той служи за дистанционно управление на съдържание на зонални файлове, разположение (в общия случай) върху отделечени сървъри за имена. За да може да бъде извършено това управление, описанието на зоната в конфигурационния файл на отдалечения сървър named.conf, трябва да е такова, че да позволява динамичното й управление.

Предимството на nsupdate е, че не се налага собственика на зоната да има права за достъп до отдалечената система (напрмер потребителско име и/или достъп до локалната файлова система и т.н). Още повече, не се налага той да има достъп до ръчна редакция на файла на зоната на домейна чрез някакви локални за отдалечената система инструменти като скриптове и др.

Ако изходният код на пакета бъде компилиран по стандартно указания в документацията начин, то след компилацията ще бъде наличен изпълнимия файл nsupdate (заедно с още клиентски инструменти). Ако се използва пакетна система е възможно пакетът bind да е разделен на подпакети (например един за сървърски цели и друг за клиенски). Трябва да се провери в кой от подпакетите се намира изпълнимия файл nsupdate и да се инсталира чрез пакетния мениджър. Например, в Linux дистрибуциите Fedora Core и Red Hat Enterprise Linux (и дериватите), изпълнимият файл nsupdate се намира в пакета bind-utils.

2. Генериране на ключ.

Системата за динамично управление на зони често се базира на удостоверяване на заявките за промяна на записите чрез ключ. Това е най-сигурният до момента начин за извършваето им. Понастоящем се използва симетричен ключ за подписване на заявките за промяна на записите чрез алгоритъма HMAC-MD5. При него всяка заявка се подписва електронно с ключа. Удостоверяването на заявките следва TSIG алгоритъма, описан в RFC2845.

Клиентът и администратора на отдалечения сървър за имена, трябва да обменят по сигурен и неподслушваем канал ключа за подписването на заявките. Обикновено генерирането на ключ се извършва от администратора на отдалечения сървър за имена, но е възможен и обратния вариант, при който генерирането се извършва от страна на клиента. Всичко зависи от договорката между тях, но и в двата случая споменатите две страни трябва да притежават копие от ключа.

За генерирането на ключ се използва инструментът dnssec-keygen. Едноименният му изпълним файл, може да бъде компилиран от изходния код на пакета bind, ако се следват приложените към пакета инструкции. Ако се използва пакетна система и пакета bind е разделен на подпакети, трябва да се провери в кой подпакет се намира изпълнимия файл dnssec-keygen (обикновено се включва в сървърския пакет). Например в Linux дистрибуциите Fedora Core и Red Hat Enterprise Linux (и дериватите), изпълнимият файл dnssec-keygen се намира в пакета bind (за разлика от nsupdate, който се намира в пакета bind-utils).

Генериране на ключ с име domain.com по алгоритъм hmac-md5 с дължина 512 бита става чрез следния команден ред:

$ umask 0177 && dnssec-keygen -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==

Ако файловете се съхраняват на външен носител, то те трябва да бъдат задължително криптирани. От тях трябва да се запази и резервно копие. При съмнение за разкриването на ключовете, трябва веднага да се уведомят администраторите на сървърите за имена, с който ключовете са споделени, за да могат последните да предотвратят нежелани записи в зоналните файлове.

3. Принцип на работа на 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
$

Освен от командния интерпретатор, заявките могат да бъдат четени от указан файл. Горния пример би могъл да се помести във файл с име nsupd.asc със следното съдържание:

update add www.domain.com 80 IN A 192.168.100.1
send
quit

и след това този файл да се подаде на nsupdate в рамките на следния команден ред:

$ nsupdate nsupd.asc

Дали ще се използва командния интерпретатор или командите ще се четат от файл е въпрос на избор и/или конкретна ситуация. По-надолу, нещата са преставени в контекста на командния интерпретатор с цел по-лесно онагледяване.

Инструментът nsupdate може да приема различни опции при стартирането си като изпълним файл:

  • -k : указване на файл съдържащ ключа за електронно подписване на заявките (за повече подробности виж параграф 4);
  • -y : указване на име и стойност на ключ, разделени със сепаратор ":" (за повече подробности виж параграф 4);
  • -t : задава максималното време за изчакване (след изпращане на заявката) на отговор на подадена към сървъра заявка, след което, ако тя не бъде потвърдена, се обявява за неизпълнена (по подразбиране това време е 300 секунди);
  • -u : указва времето, през което UDP заявките се повтарят, ако изпратените преди това заявки не са получи потвърждение от страна на сървъра за имена (по подразбиране е 3 секунди, а при задаване на стоиност 0, се прави преизчисляване на основата на параметъра подаден след "-t" и броят на указаните с "-r" UDP опита за заявки);
  • -r : указва броят на опитите за изпращане на UDP заявка, след което се преминава в TCP режим на изпращане за заявката (по подразбиране броят опити е три, а ако се укаже 0 се прави само един опит за UDP заявка);
  • -v : изпращане на заявки само в TCP режим (изпращане на заявки до сървъра за имена по TCP).

4. Извикване на 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" се указва името на ключа и след това неговата стойност.

5. Указване на първичен сървър за имена за зоната на управлявания домейн.

Указването на първичен за зоната на управлявания домейн сървър за имена става чрез командата "server" в командния интерпретатор на nsupdate. Всички заявки, направени след това, се насочват към указания сървър и не се следва указания в SOA записа сървър за имена (виж параграф 2).

В примера по-долу, всички направени заявки (в рамките на една сесия на nsupdate), ще се изпращат към сървъра за имена ns.domain.tld:

$ nsupdate -y domain.com:csVJh6jyqyDRjFHz4rfUwz0rIEp5ZMi6qrFwgCkpWE9hG4MHL+/zoYk1RJe683hRME4lUBL1XUrT4B1tRvkrlA==
> server ns.domain.com
>

За повече подробности виж "Указване на първичен сървър за имена, към когото да се изпращат заявките" в параграф 8.

6. Заявка за прибавяне на ресурсен запис.

Заявката за прибавяне на ресурсен запис се подава след командата "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".

7. Заявка за премахване на ресурсен запис.

Заявката за премахване на ресурсен запис се подава след командата "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, класа, типа или стойността на записа.

8. Задаване на параметри "по подразбиране" в командния интерпретатор на 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.

9. Задаване на условия за наличие или отсъствие на ресурсни записи.

Условията за наличие или отсъствие на ресурсен запис в зоната са мощен инструментариум за съставяне на условия, при чието изпълнение или неизпълненние може или не може да се извърши запис в зоналния файл. Те предпазват от фатални изтривания или записи в процеса на управление на зоналния файл.

  • условия за наличие на ресурсен запис в управляваната зона

    Извършва се чрез указване от типа:

    > 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

    Възможните изходи от изпълнението са два:

    1. успешен - ако поне един запис с изискваното име съществува

      При такъв изход след изпълнение на send се преминава на нов ред в командния интерепретатор на nslookup (виж примера по-горе):

      > prereq yxdomain mail.domain.com
      > update add mail-1.domain.com 60 A 192.168.10.1
      > send
      >

    2. неуспешен - не е открит никакъв запис с това име

      При такъв изход след изпълнение на 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

    Възможните изходи от изпълнението са два:

    1. успешен - ако запис с изискваното име не съществува

      При такъв изход след изпълнение на send се преминава на нов ред в командния интерепретатор на nsupdate (виж примера по-горе):

      > prereq nxdomain mail.domain.com
      > update delete mail-1.domain.com 60 A 192.168.10.1
      > send
      >

    2. неуспешен - открит е запис с това име

      При такъв изход след изпълнение на 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". Ако и двете условия са удовлетворени, няма да се изведе никакво съобщение.



<< Инсталация на Gentoo за начинаещи | Монтиране на отдалечени файлови системи (втора част) >>