Материал из Linuxformat.

Содержание 1 На­строй­ка DNS-сер­ве­ра 1.1 Ти­пы DNS-сер­ве­ров 1.2 Прой­дем­ся по фай­лу зо­ны 1.3 Осо­бые точ­ки 1.4 Где уз­нать боль­ше 1.5 Со­ве­ты по от­лад­ке

На­строй­ка 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.