LINUX-BG Адрес : http://www.linux-bg.org |
Управление на зони в динамичен режим чрез nsupdate |
От: Beco Публикувана на: 4-04-2006 Адрес на статията: http://www.linux-bg.org/cgi-bin/y/index.pl?page=article&id=advices&key=381272395 |
Управление на зони в динамичен режим чрез nsupdate(за потребители на UNIX и UNIX-подобни операционни системи)Copyright ©2006 Веселин Колев, Софийски Университет "Св. Климент Охридски"Лиценз на документа: CC Attribution-ShareAlike Съдържание на лиценза: http://creativecommons.org/licenses/by-sa/2.5/
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 Винаги името на файла започва с "K". След него непосредствено следва името на ключа (по горния пример това е domain.com). След това в името на файла има две числа разделени със знак "+". Първото число отразява номера на алгоритъма, който ще използва ключа. В нашия случай това е "hmac-md5" и на него съответства номер 157. Второто число е случайно генерирано и отразява уникалния номер на ключа. За примерът това е 41723. Структурата на файла с наставка key е следната: domain.com. IN KEY 512 3 157 csVJh6jyqyDRjFHz4rfUwz0rIEp5ZMi6qrFwgCkpWE9hG4MHL+/zoYk1RJe683hRME4lUBL1XUrT4B1tRvkrlA== Файлът с наставка private е структуриран така:
Private-key-format: v1.2 Ако файловете се съхраняват на външен носител, то те трябва да бъдат задължително криптирани. От тях трябва да се запази и резервно копие. При съмнение за разкриването на ключовете, трябва веднага да се уведомят администраторите на сървърите за имена, с който ключовете са споделени, за да могат последните да предотвратят нежелани записи в зоналните файлове. 3. Принцип на работа на nsupdate.Принципът на работа на инструмента nsupdate е следния. Въвежданите в командния му интерпретатор или прочетени от файл заявки за промяна (включване или изтриване на ресурсни записи) на зоната на домейна, се подписват чрез ключа и изпращат до първичния сървър за имена на домейна. Обикновено това е този, който е указан в SOA ресурсния запис на зоната. Сървърът проверява електронния подпис върху заявките чрез локално инсталираното копие на ключа и при установяване на автентичността на заявките те биват изпълнявани. Сървърът подава на клиента флаг за грешка, ако заявката не може да бъде изпълнена по една или друга причина. Ако указаният с SOA сървър за имена не е първичен (в това няма нищо нередно - там може да се укаже и сървър за имена, който е вторичен и това може да бъде направено по едно или друго съображение, което не е предмет на дискусия тук), то се налага в nsupdate да се укаже към кой именно сървър за имена ще бъдат изпращани подписаните заявки. За подробности виж параграф 5. Инструментът nsupdate има команден интерпретатор, в който потребителя подава команди с параметри към тях. Влизането в командния интерпретатор става чрез извикване на изпълнимия файл nsupdate, а излизането от него с командата quit без параметри към нея:
$ nsupdate
$ nsupdate Освен от командния интерпретатор, заявките могат да бъдат четени от указан файл. Горния пример би могъл да се помести във файл с име nsupd.asc със следното съдържание:
update add www.domain.com 80 IN A 192.168.100.1 $ nsupdate nsupd.asc Дали ще се използва командния интерпретатор или командите ще се четат от файл е въпрос на избор и/или конкретна ситуация. По-надолу, нещата са преставени в контекста на командния интерпретатор с цел по-лесно онагледяване. Инструментът nsupdate може да приема различни опции при стартирането си като изпълним файл:
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" се указва името на ключа и след това неговата стойност. 5. Указване на първичен сървър за имена за зоната на управлявания домейн.Указването на първичен за зоната на управлявания домейн сървър за имена става чрез командата "server" в командния интерпретатор на nsupdate. Всички заявки, направени след това, се насочват към указания сървър и не се следва указания в SOA записа сървър за имена (виж параграф 2). В примера по-долу, всички направени заявки (в рамките на една сесия на nsupdate), ще се изпращат към сървъра за имена ns.domain.tld:
$ nsupdate -y domain.com:csVJh6jyqyDRjFHz4rfUwz0rIEp5ZMi6qrFwgCkpWE9hG4MHL+/zoYk1RJe683hRME4lUBL1XUrT4B1tRvkrlA== За повече подробности виж "Указване на първичен сървър за имена, към когото да се изпращат заявките" в параграф 8. 6. Заявка за прибавяне на ресурсен запис.Заявката за прибавяне на ресурсен запис се подава след командата "update add" в командния интерпретатор на nsupdate. Структурата на заявките следва шаблона:
Ето един пример: > 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 Следователно за list.domain.com има два ресурсни записа (един A и един MX). Ако сега се изпълни следното:
$ nsupdate -k Kdomain.com.+157+41723.private След изпълнението ще се изтрият всички записи, чието име е list.domain.com (за нашия пример те са два - един A и един MX), без оглед на това какъв е TTL, класа, типа или стойността на записа. 8. Задаване на параметри "по подразбиране" в командния интерпретатор на nsupdate.За да не се повтаря указването на един и същ параметър, той може да бъде зададен в рамките на една и съща сесия на nsupdate. Ето какви параметри за указване допуска командният интерпретатор на nsupdate:
9. Задаване на условия за наличие или отсъствие на ресурсни записи.Условията за наличие или отсъствие на ресурсен запис в зоната са мощен инструментариум за съставяне на условия, при чието изпълнение или неизпълненние може или не може да се извърши запис в зоналния файл. Те предпазват от фатални изтривания или записи в процеса на управление на зоналния файл.
<< Инсталация на Gentoo за начинаещи | Монтиране на отдалечени файлови системи (втора част) >> |
Авторите на сайта, както и техните сътрудници запазват авторските права върху собствените си материали публикувани тук,
но те са copyleft т.е. могат свободно да бъдат копирани и разпространявани с изискването изрично да се упоменава името на автора,
както и да се публикува на видно място, че те са взети от оригиналния им URL-адрес на този сървър (http://www.linux-bg.org). Авторските права на преводните материали принадлежат на техните автори. Ако с публикуването тук на някакъв материал неволно са нарушени нечии права - след констатирането на този факт материалът ще бъде свален.
All trademarks, logos and copyrights mentioned on this site are the property of their respective owners.
|