Журнал LinuxFormat - перейти на главную

LXF142:DrBrown3

Материал из Linuxformat
Версия от 10:54, 13 июня 2012; Crazy Rebel (обсуждение | вклад)

(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

На­строй­ка DNS-сер­ве­ра

Там, где за­да­ча на­строй­ки DNS-сер­ве­ра ста­но­вит­ся вы­пол­ни­мой.

В про­шлом но­ме­ре я опи­сал ар­хи­тек­ту­ру DNS, ее ие­рар­хи­че­­ское про­стран­ст­во имен и по­ша­го­вый про­цесс за­про­са. Мы по­го­во­ри­ли о ти­пах за­пи­сей и об­су­ди­ли на­строй­ку кли­ен­та для раз­ре­шения имен. В этой ста­тье я со­сре­до­то­чусь на сер­вер­ной час­ти DNS.

Для на­ча­ла – несколь­ко тер­ми­нов. DNS (Domain Name System – сис­те­ма до­мен­ных имен) пред­став­ля­ет со­бой опи­сание ар­хи­тек­ту­ры. BIND (Berkeley Internet Name Domain – до­мен­ное имя Ин­тернет Берк­ли) – реа­ли­за­ция DNS, ис­поль­зуе­мая в Linux, а де­мон, пред­став­ляю­щий сер­вис, но­сит имя named (про­из­но­си­те «нэйм-ди», не то опо­зо­ри­тесь сре­ди зна­то­ков Linux).

Ти­пы DNS-сер­ве­ров

Ро­лей, в ко­то­рых мо­жет вы­сту­пать DNS-сер­вер, три. Пер­вая – пер­вич­ный сер­вер [master], ко­то­рый со­дер­жит ав­то­ри­та­тив­ные дан­ные для зо­ны. Эти дан­ные хра­нят­ся в фай­ле зо­ны, с ко­то­рым мы оз­на­ко­мим­ся поз­же. У ка­ж­дой зо­ны, т. е. у ка­ж­дой час­ти про­стран­ст­ва имен DNS, есть ров­но один пер­вич­ный сер­вер. Что­бы рас­пре­де­лить на­груз­ку и из­бе­жать по­яв­ления един­ст­вен­ной точ­ки от­ка­за, у до­ме­нов обыч­но есть один или несколь­ко вто­рич­ных сер­ве­ров [slave]. Эти сер­ве­ры по­лу­ча­ют дан­ные для сво­ей ра­бо­ты от пер­вич­но­го сер­ве­ра при пе­ре­да­че зо­ны. На­конец, су­ще­ст­ву­ют толь­ко кэ­ши­рую­щие DNS-сер­ве­ры. На та­ком сер­ве­ре не хра­нят­ся ав­то­ри­та­тив­ные дан­ные для зон, но он пе­ре­на­прав­ля­ет за­про­сы от сво­их кли­ен­тов и кэ­ши­ру­ет ре­зуль­та­ты. Со вре­менем в кэ­ше сер­ве­ра на­ка­п­ли­ва­ют­ся дан­ные, ис­поль­зуе­мые для раз­ре­шения по­сле­дую­щих за­про­сов. Ро­ли не ис­клю­ча­ют друг дру­га. Один и тот же сер­вер мо­жет быть пер­вич­ным для одних до­ме­нов, вто­рич­ным для дру­гих и кэ­ши­рую­щим для осталь­ных.

Давайте рас­смот­рим кон­фи­гу­ра­цию это­го гиб­рид­но­го сер­ве­ра. Файл на­строй­ки named – ско­рее все­го /etc/named.conf или /etc/bind/named.conf, в за­ви­си­мо­сти от ди­ст­ри­бу­ти­ва. В при­ме­ре A по­ка­зан та­кой файл. Как и сле­до­ва­ло ожи­дать, про­ще все­го на­стро­ить кэ­ши­рую­щий сер­вер имен. Для этой ста­тьи я уста­но­вил Bind 9 и немно­го уди­вил­ся то­му, что он ра­бо­та­ет как кэ­ши­рую­щий DNS-сер­вер без вся­ких до­полнитель­ных на­стро­ек! Од­на­ко сто­ит хо­тя бы ска­зать ему, где на­хо­дят­ся его корневые сер­ве­ры имен, с по­мо­щью так на­зы­вае­мо­го фай­ла «корневых под­ска­зок» [root hints] (стро­ки с 9 по 13). Так­же, ес­ли непо­да­ле­куесть еще несколь­ко DNS-сер­ве­ров, при­над­ле­жа­щих, ве­ро­ят­но, ваше­му про­вай­де­ру, ваш сер­вер мо­жет ис­поль­зо­вать их для пе­ре­на­прав­ления (стро­ки с 4 по 6). Эти сер­ве­ры долж­ны стре­мить­ся вы­пол­нять ре­кур­сив­ные за­про­сы. На­при­мер, здесь нель­зя ука­зать корневой сер­вер имен.

На­стро­ить пер­вич­ный сер­вер для зо­ны чуть сложнее, по­то­му что по­на­до­бит­ся соз­дать файл зо­ны. В та­ких фай­лах со­дер­жат­ся «ис­ход­ные дан­ные» DNS: за­пи­си A, за­пи­си NS, за­пи­си MX и т. д., о ко­то­рых мы го­во­ри­ли в про­шлом ме­ся­це. В этом при­ме­ре мой сер­вер яв­ля­ет­ся пер­вич­ным для до­ме­на example.com. В кон­фи­гу­ра­ци­он­ном фай­ле стро­ки с 17 по 20 го­во­рят мо­ему DNS-сер­ве­ру, что он яв­ля­ет­ся пер­вич­ным для до­ме­на example.com, и со­об­ща­ют ему о ме­сто­по­ло­жении фай­ла зо­ны. Сам файл зо­ны при­ве­ден в при­ме­ре B на обо­ро­те, и сей­час мы по нему прой­дем­ся. Уч­ти­те, что фор­мат этих фай­лов за­да­ет­ся стан­дар­том IETF, оп­ре­де­лен­ ным в RFC 1035 – он не спе­ци­фи­чен для Bind.

Прой­дем­ся по фай­лу зо­ны

В пер­вой стро­ке за­да­ет­ся зна­чение по умол­чанию для по­ля «вре­мя жизни» (TTL). Оно за­да­ет­ся в се­кун­дах и рав­но 86400 (86400 се­кунд – один день; так­же мож­но бы­ло ука­зать 24h или 1d). Вре­мя жизни – по­ня­тие, важ­ное для DNS: ка­ж­дый раз, когда у ав­то­ри­та­тив­но­го DNS-сер­ве­ра за­пра­ши­ва­ет­ся запись ре­сур­са, в его от­вет вклю­ча­ет­ся по­ле «вре­мя жизни», ко­то­рое оп­ре­де­ля­ет, как дол­го кэ­ши­рую­щий DNS-сер­вер мо­жет хранить эту запись, пре­ж­де чем вый­ти в мир и по­лу­чить све­жую ко­пию. И здесь при­хо­дит­ся ба­лан­си­ро­вать ме­ж­ду дву­мя аль­тер­на­ти­ва­ми. Боль­шие зна­чения TTL снижа­ют тра­фик DNS (осо­бен­но за­груз­ку сер­ве­ров верхнего уров­ня) и уве­ли­чи­ва­ют про­из­во­ди­тель­ность. Ма­лень­кие зна­чения TTL улуч­ша­ют ре­ак­цию DNS на по­яв­ление, ис­чез­но­вение или из­менение IP-ад­ре­сов сер­ве­ров.

Про­дол­жим на­шу про­гул­ку по фай­лу зо­ны. Запись SOA (start of authority – на­ча­ло пол­но­мо­чий) в стро­ках со 2 по 7 оз­на­ча­ет, что сер­вер яв­ля­ет­ся ав­то­ри­та­тив­ным для зо­ны. Пер­вая стро­ка оп­ре­де­ля­ет пер­вич­ный сер­вер для зо­ны и со­дер­жит ад­рес элек­трон­ной поч­ты от­вет­ст­вен­но­го ли­ца (с точ­кой . вме­сто @). Запись SOA так­же вклю­ча­ет ряд вре­мен­ных па­ра­мет­ров, ко­то­рые оп­ре­де­ля­ют, как час­то вто­рич­ные сер­ве­ры имен долж­ны об­нов­лять ин­фор­ма­цию с пер­вич­но­го и как дол­го они мо­гут про­дол­жать поль­зо­вать­ся дан­ны­ми сво­их ко­пий, ес­ли не мо­гут свя­зать­ся с пер­вич­ным сер­ве­ром. Вда­вать­ся в под­роб­но­сти мы здесь не бу­дем.

За­пи­си NS в стро­ках 9 и 10 го­во­рят, где на­хо­дят­ся сер­ве­ра имен для дан­но­го до­ме­на. @ в пер­вом по­ле стро­ки 9 – услов­ное обо­зна­чение ис­точника: зо­ны, к ко­то­рой от­но­сит­ся файл. В дан­ном слу­чае это example.com. Пустое по­ле в сле­дую­щей стро­ке оз­на­ча­ет «ис­поль­зо­вать то же зна­чение, что в пре­ды­ду­щей стро­ке», и та­кое со­кра­щение час­то ис­поль­зу­ет­ся в фай­лах зон. Вы так­же ви­ди­те, что у до­ме­на есть два сер­ве­ра имен: пер­вич­ный, ns.example.com, ко­то­рый фак­ти­че­­ски на­хо­дит­ся в об­слу­жи­вае­мом зо­ной до­мене, и вто­рич­ный buddysite.somewhere.com, в ка­ком-ли­бо дру­гом мес­те. (Ес­ли кто-то не по­нял, все эти дан­ные вы­мыш­ле­ны!)

Осо­бые точ­ки

Об­ра­ти­те осо­бое внимание на точ­ку . в кон­це имен. Не будь ее, Bind до­ба­вил бы к имени ис­ход­ный до­мен. Ска­жем, ес­ли бы я опустил точ­ку в кон­це стро­ки 10, пред­по­ла­гае­мое имя ста­ло бы buddysite.somewhere.org.example.com, а это не то, че­го я хо­тел. Это ана­ло­гич­но аб­со­лют­ным и от­но­си­тель­ным пу­тям в фай­ло­вой сис­те­ме, с той разницей, что пу­ти за­пи­сы­ва­ют­ся «от стар­ше­го к млад­ше­му» – са­мая важ­ная часть идет в на­ча­ле, а до­мен­ные име­на – «от млад­ше­го к стар­ше­му». Так, путь var/log/messages без на­чаль­но­го слэ­ша бу­дет ин­тер­пре­ти­ро­вать­ся от­но­си­тель­но те­ку­ще­го ка­та­ло­га.

Стро­ки с 12 по 17 со­дер­жат за­пи­си ти­па A, ко­то­рые свя­зы­ва­ют име­на ком­пь­ю­те­ров с IP-ад­ре­са­ми. В этих стро­ках точ­ки в кон­це имени опу­ще­ны умыш­лен­но. Стро­ка 15, на­при­мер – запись ти­па A для venus.example.com. Об­ра­ти­те внимание, что в стро­ке 17 мы оп­ре­де­ля­ем вто­рой IP-ад­рес для earth.example.com, так как пустое пер­вое по­ле на­сле­ду­ет зна­чение с пре­ды­ду­щей стро­ки.

На­конец, в стро­ках 19 и 20 за­да­ют­ся за­пи­си CNAME, вы­сту­паю­щие в ро­ли алиа­сов: они свя­зы­ва­ют име­на ftp.example.com и www.example.com с так на­зы­вае­мым ка­нониче­­ским именем mercury.example.com. За­пи­си CNAME про­ще под­дер­жи­вать: ес­ли IP-ад­рес ком­пь­ю­те­ра из­менил­ся, нуж­но об­но­вить толь­ко за-пись ти­па A для ка­нониче­­ско­­го имени.

По­сле из­менения фай­ла зо­ны или фай­ла named.conf нуж­но пе­ре­за­пустить де­мон. Ко­ман­да за­ви­сит от ди­ст­ри­бу­ти­ва и бу­дет при­мер­но та­кой: 

# service bind9 restart

При­зна­юсь, рань­ше я никак не мог сов­ла­дать с син­так­си­сом фай­лов зо­ны – всегда ка­за­лось, что го­раз­до про­ще все ис­пор­тить, чем сде­лать все пра­виль­но. Ча­ще все­го я за­бы­вал ста­вить точ­ки по­сле имен до­ме­нов и про­пускал за­вер­шаю­щие точ­ки с за­пя­той в named.conf. Вы бы мог­ли ска­зать, что, пол­жизни занима­ясь про­грам­ми­ро­ванием на C, я дол­жен был хо­тя бы не за­бы­вать о точ­ках с за­пя­той! Так или иначе, я завел при­выч­ку за­гля­ды­вать в со­от­вет­ст­вую­щий файл жур­на­ла (ско­рее все­го /var/log/messages или /var/log/syslog) по­сле из­менения на­стро­ек и пе­ре­за­пуска де­мо­на, что­бы убе­дить­ся, что Bind был за­пу­щен кор­рект­но или что­бы уви­деть, где про­изош­ла ошиб­ка.

В на­шей те­ку­щей кон­фи­гу­ра­ции есть ра­бо­таю­щий пер­вич­ный DNS-сер­вер для до­ме­на example.com. Од­на­ко, что­бы быть от­вет­ст­вен­ным жи­те­лем ми­ра DNS, наш сер­вер дол­жен так­же пре­доста­вить за­пи­си PTR для под­держ­ки об­рат­ных за­про­сов DNS – пре­об­ра­зо­ваний IP-ад­ре­са в пол­но­стью оп­ре­де­лен­ное имя до­ме­на (FQDN). Как я рас­ска­зы­вал в пре­ды­ду­щей ста­тье, эти за­пи­си на­хо­дят­ся в про­стран­ст­ве имен, корнем ко­то­ро­го яв­ля­ет­ся in-addr.arpa. В слу­чае с се­тью 192.168.0.0/24 в на­шем при­ме­ре, ис­точник этой зо­ны – 0.168.192.in-addr.arpa. На­строй­ка этой зо­ны и ее кон­фи­гу­ра­ци­он­ный файл во мно­гом по­хо­жи на пря­мую зо­ну, ко­то­рую мы толь­ко что рас­смот­ре­ли, хо­тя име­на вы­гля­дят немно­го за­бав­но.

Стро­ки с 22 по 27 в фай­ле named.conf (при­мер A) го­во­рят мо­ему DNS-сер­ве­ру, что он яв­ля­ет­ся пер­вич­ным для 0.168.192.in-addr.arpa, и за­да­ют файл зо­ны. Сам файл при­ве­ден в при­ме­ре C. Как и в пре­ды­ду­щем фай­ле зо­ны, в этом есть запись SOA и за­пи­си для сер­ве­ров имен. Нам ин­те­рес­ны по­следние че­ты­ре стро­ки, где оп­ре­де­ля­ют­ся за­пи­си PTR (pointer – ука­за­тель). Но­ме­ров строк я не до­бав­лял: здесь про­ну­ме­ро­ва­ны са­ми име­на за­пи­сей. Помните, что ес­ли имя не за­кан­чи­ва­ет­ся на точ­ку ., к нему бу­дет до­бав­ле­но имя ис­ход­но­го до­ме­на. Так, на­при­мер, в са­мой по­следней стро­ке фай­ла оп­ре­де­ле­на запись PTR для 4.0.168.192.in-addr.arpa; ей бу­дет со­от­вет­ст­во­вать ком­пь­ю­тер с IP-ад­ре­сом 192.168.0.4.

Где уз­нать боль­ше

В этой ста­тье я по­ста­рал­ся сжа­то из­ло­жить осно­вы, но есть несколь­ко клю­че­вых тех­но­ло­гий DNS, о ко­то­рых я не упо­мя­нул – в ча­ст­но­сти, ра­бо­та со вто­рич­ны­ми сер­ве­ра­ми и ис­поль­зо­вание ими пе­ре­но­сов зон и ин­кре­мен­таль­ных пе­ре­но­сов зон для син­хрониза­ции с пер­вич­ным сер­ве­ром. Я так­же не рас­ска­зал о ди­на­ми­че­­ских об­нов­лениях DNS, по­зво­ляю­щих до­бав­лять и уда­лять за­пи­си ре­сур­сов на ле­ту – это важ­но для сер­ве­ров, ко­то­рые по­лу­ча­ют свой IP-ад­рес че­рез DHCP. Я не рас­ска­зал под­роб­но и о DNS-SEC, рас­ши­рениях безо­пас­но­сти DNS, ко­то­рые по­зво­ля­ют ад­минист­ра­то­рам зо­ны под­пи­сы­вать дан­ные зо­ны с по­мо­щью шиф­ро­вания с от­кры­тым клю­чом, в до­ка­за­тель­ст­во ис­тин­но­сти этих дан­ных.

Ес­ли вы хо­ти­те уз­нать боль­ше, ис­кренне со­ве­тую вам книгу “DNS and BIND” Ал­бит­ца [Albitz] и Лю [Liu] из­да­тель­ст­ва O’Reilly. Она бы­ла мо­им ис­чер­пы­ваю­щим ру­ко­во­дством по DNS на про­тя­жении мно­гих лет. Так­же взгляните на пре­крас­ную элек­трон­ную книгу Ро­на Эйт­чи­со­на [Ron Aitchison] по ад­ре­су http://zytrax.com/books/dns или ку­пи­те ее бу­маж­ную вер­сию “Pro DNS and Bind”, опуб­ли­ко­ван­ную в из­да­тель­ст­ве Apress.

Со­ве­ты по от­лад­ке

  1. Про­ве­ряй­те кор­рект­ность опе­ра­ций с кли­ен­та с по­мо­щью dig (об этом я рас­ска­зы­вал в про­шлом ме­ся­це).
  2. Со­об­ще­ния об ошиб­ках при за­груз­ке зо­ны мож­но най­ти в фай­лах /var/log/messages и /var/log/syslog.
  3. С по­мо­щью про­грам­мы Rndc (она же Ndc) мож­но ди­на­ми­че­ски из­ме­нять уро­вень вы­во­да от­ла­доч­ной ин­фор­ма­ции. На­при­мер, сле­дую­щей ко­ман­дой за­да­ет­ся уро­вень 3: 
# rndc trace 3

А вот ко­ман­да, вы­во­дя­щая кэш сер­ве­ра в файл named_dump.db: 

# rndc dumpdb -all

Файл поя­вит­ся в ка­та­ло­ге, за­дан­ном в па­ра­мет­ре directory в named.conf.

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF142:DrBrown3&oldid=14121»
Персональные инструменты
купить
подписаться
Яндекс.Метрика