Differences between revisions 2 and 3
Revision 2 as of 2008-08-01 21:35:39
Size: 10805
Editor: eSyr
Comment:
Revision 3 as of 2008-08-10 18:10:26
Size: 16174
Comment:
Deletions are marked like this. Additions are marked like this.
Line 3: Line 3:
Кусок лекции из сетевого адм, который был: DNS --- такая штука, которая пребз. имена в ip и обратно, структура иерархическая, у каждой зны есть доменный сервер, у каждой сети есть собст. служба доменных имён, ктрая преобр. в обр. сторну. Это не очень связные вещи, в локальной сети всё нормально, а вот если ip выдаёт првайде, то могут быть прблемы с орг. обр. dns. Может быть два варианта по поводу орг. доменных имён: первый --- провайдер, заведи мне поддомен, и ты будешь отвечать за мои доменные имена. И всякий раз, когда вздумаете переим. машину, то надо опять идти к адм. Во втрм случае --- дмен у меня, что ты мне предл по поводу орг. обр. dns? Кусок лекции из сетевого администрирования, который был: DNS --- такая штука, которая преобразует доменные имена в ip и
обратно. Эта служба устроенна иерархически, у каждой зоны есть собственная сервер DNS. За каждой сетью должна быть
зарегистрирована служба, занимающаяся преобразованием IP в доменное имя. Если провайдер выдал группу внешних адресов, то
существуют два варианта для организации доменных имен:
 *провайдер заводит в своем домене поддомены , и назначает им указанные вами адреса. При этом всякий раз, когда возникает
 необходимость переименовать машину, то это опять должен сделать провайдер.
 *Вы заводите собственный домен, который и отвечает за ваши машины,на долю провайдера ложится организация обратного DNS
Line 5: Line 11:
как полоучить собст. домен? Идёте к регистратору, выбираете себен незанятое доменное имя, платите за него, появляете в базе whois, вы обязаны какое-то количество должно быть живым. Стит это порядка 20 долларов в год. Второй способ --- получить поддомен --- пойти к владельцу домена и на непонятных правах получить у него поддомен. За это в больш. случаев не над платить, например, в случае, когда это структ. подразделение, как, например, po.cs.msu.su. В первом случае вы становитесь адм. домена, в ругом случае вполне возм., что адм. его будете не вы. В любм случае, вы по-хрошему длжны обесп. два доменных сервера с сущ. разными адресами, кторые бы занимались преобр. из доменных имён в вашем дмене в ip. В случае, если мы имеем дело со школой, с классом, то эт стаётся в плане отл. фантазии, поск. никаких доменных имён для интранета зарег. не надо. Можно завести какой угодно домен, главное, чтобы не присходило интерференции. Получить собственный домен также можно несколькими способами:
 *Оплачиваете незанятое доменное имя у специальной компании- регистратора, после чего вы появляетесь в базе whois. При этом
 вы обязаны держать какое-то количество "живым" адресов в этом домене. Стоит это порядка 20 долларов в год. При этом вы
 становитесь администратором этого домена.
 *Получить поддомен. Идете к владельцу домена и на непонятных правах получаете у него поддомен. В большинстве случаев это
 бесплатно, например когда вы регистрируете поддомен для структурного подразделения компании, владеющей доменом, например,
 po.cs.msu.su. При этом администратором поддомена можете быть и не вы.
В любом случае, вы по хорошему должны обеспечить не меньше двух доменных серверов (в случае с доменом- обязаны обеспечить)
с существенно разными IP-адресами, которые бы занимались преобразованием из доменных имён IP-адреса в вашем домене. В
случае, если мы имеем дело со школой или с классом, поскольку никаких доменных имён для интранета регистрировать не
надо. Можно завести какой угодно домен, главное, чтобы не происходило интерференции.
Line 7: Line 23:
Сейчас никакого сервера доменныъх имён не стоит вообще. То есть когда клиенты ходят к нему по DHCP, он говорит, что есть общий сервер. В случае, когда пднят DNS, т он будут ходит к нему, а он дальше. И в этом случае взможно работа по именам. Сейчас никакого сервера доменных имён не стоит вообще. Поэтому когда клиенты обращаются за настройками по протоколы DHCP,
им передают местонахождение общего сервера. В случае, когда поднят DNS, им передается местонахождение этого DNS сервера, и
они будут обращаться к нему, а он дальше. И в этом случае возможно обращаться к локальным компьютерам по именам.
Line 9: Line 27:
Что такое pdnsd. Это DNS-сервер, предн. для тго, чтобы запускаться на очень плохих каналах, и предн. для принудителььного кэширования запрсов. То есть, даже если в случае, если сказано, что у записи малое время жизни, всё равно при его исп. не надо ходить. Также он актуален малых сетях без иерархии. === pdnsd ===
Это DNS-сервер,изначально предназначенный для того, чтобы запускаться на очень плохих каналах, и предназначенный для
принудител
ьного кэширования всех DNS-запросов.  То есть, даже если в случае, если сказано, что у записи малое время жизни,
всё равно его нужно закешировать. Также он актуален малых сетях без иерархии, и вся задача сводится к тому, чтобы:
 *снабдить все машины DNS-сервером
 *учесть все машины
Line 11: Line 34:
Установим ег и отредактируем pdnsd.conf. Тут мы редактируем ip сервера. ... Установим его
{{{
root@class305 ~]# apt-get install pdnsd
}}}
посмотрим его состав
{{{
[root@class305 ~]# rpmquery -l pdnsd
/etc/pdnsd.conf
/etc/ppp/ip-up.d/0pdnsd
/etc/rc.d/init.d/pdnsd
/usr/sbin/pdnsd
/usr/sbin/pdnsd-ctl
/usr/share/doc/pdnsd-1.2.5
/usr/share/doc/pdnsd-1.2.5/AUTHORS
/usr/share/doc/pdnsd-1.2.5/COPYING.BSD
/usr/share/doc/pdnsd-1.2.5/ChangeLog
/usr/share/doc/pdnsd-1.2.5/ChangeLog.old
/usr/share/doc/pdnsd-1.2.5/NEWS
/usr/share/doc/pdnsd-1.2.5/README
/usr/share/doc/pdnsd-1.2.5/README.ALT
/usr/share/doc/pdnsd-1.2.5/README.par
/usr/share/doc/pdnsd-1.2.5/README.par.old
/usr/share/doc/pdnsd-1.2.5/THANKS
/usr/share/doc/pdnsd-1.2.5/TODO
/usr/share/doc/pdnsd-1.2.5/contrib
/usr/share/doc/pdnsd-1.2.5/contrib/README
/usr/share/doc/pdnsd-1.2.5/contrib/change_pdnsd_server_ip.pl
/usr/share/doc/pdnsd-1.2.5/contrib/dhcp2pdnsd
/usr/share/doc/pdnsd-1.2.5/contrib/pdnsd_dhcp.pl
/usr/share/doc/pdnsd-1.2.5/html
/usr/share/doc/pdnsd-1.2.5/html/dl.html
/usr/share/doc/pdnsd-1.2.5/html/doc.html
/usr/share/doc/pdnsd-1.2.5/html/faq.html
/usr/share/doc/pdnsd-1.2.5/html/index.html
/usr/share/doc/pdnsd-1.2.5/pdnsd.conf
/usr/share/doc/pdnsd-1.2.5/txt
/usr/share/doc/pdnsd-1.2.5/txt/faq.txt
/usr/share/doc/pdnsd-1.2.5/txt/intro.txt
/usr/share/doc/pdnsd-1.2.5/txt/manual.txt
/usr/share/man/man5/pdnsd.conf.5.bz2
/usr/share/man/man8/pdnsd-ctl.8.gz
/usr/share/man/man8/pdnsd.8.gz
/var/cache/pdnsd
/var/cache/pdnsd/pdnsd.cache
/var/run/pdnsd
/var/run/pdnsd/socket
}}}
Отредактировав конфигурационный файл pdnsd.conf, запустим его
{{{
[root@class305 ~]# service pdnsd start
}}}
Line 13: Line 86:
Теперь над поправить dhcp. После этого надо поправить dhcp.
Line 15: Line 88:
После этг проверим работу с клиентов. Для того, чтобы сервер пользовался своим DNS, надо на нем первым nameserver'ом прописать 127.0.0.1 в /etc/resolv.conf
Line 17: Line 90:
Для того, чтобы сервер польхзвалмся своим dns, надо первым неймсервером прписать 127.0.0.1 в /etc/resolv.conf === BIND ===
Line 19: Line 92:
Настройка BIND Пакет называется bind, а соответствующий сервис называется named.Один из самых популярных в мире. BIND делают долго и
упорно люди из Internet Service consorcium, большинство RFC на этот счёт тоже написаны ими. Этот сервис очень большой и
имеет много функций.
Line 21: Line 96:
Пакет bind, а сервис named. BIND делают долго и упорно ребята из Internet Service consorcium, они писали RFC на этт счёт. н большой, имеет много функций. Запускается он из изолированного окружения.
Line 23: Line 98:
Запускается н из чрута. == chroot ==
Line 25: Line 100:
chroot Идея в следующем: у нас есть служба, которую мы не можем запускать не от root, или есть служба, которую мы можем запускать
не от рута, но опасаемся дырок безопасности в ней.В любом случае, мы не хотим вычитывать все исходные коды, но при этом нам
необходимо ею пользоваться. Поэтому такие службы переносятся в изолированное окружение. chroot --- вызов на уровне ядра для
изменения корневого каталога процесса и всех его потомков. После такой операции получить доступ к остальным частям ФАС кроме
как залезания в устройства не удаётся. При этом никакой изоляции от процессов ,от памяти не происходит. В частности,
сервер bind настолько большой, и дырки там встречаются часто. Более того, получение информации об его ошибках
предоставляется за деньги. И эта служба потенциально опасна. Посему в мануалах конфигурационные файлы указанны как
располагающиеся в /etc и /var, но в АльтЛинуксе они лежат ещё в многих другим местах, из которых потом и формируются
изолированные окружения.
Line 27: Line 110:
Идея в следующем: у нас есть служба, кторую мы не можем запускать не от рута, или есть служба, которуюмы можем запускать не т рута, но бимся, что она может получить призв. доступ. В любом случае, мы не хотим вычитывать все исх., боимся её, но хотим пользваться. Поэтому они переносятся в изолирванное окружение. chroot --- вызов на уровне ядра, после вызова которого при обр. к ФС н видит её как ФС с корнем в виде параметра chroot. И кроме как залезания в устрйства получить доступ к ст. части ФС не удаётся. При этом никакой изоляции т процессов не произв., память неизолир., но на файлы это распр. В частности, сервер bind настольк большой, и дырки там часто. И доступ к списку бн. ошибок предст. за еньги. И эта служба потенциально опасна. Посему в мане в настройке в файлах вывидите файлы в etc и var, а в альте они лежат ещё в другом месте. Если посмтрим на inode (ls -ild), то увидим, что д и почле chroot они отл.. В altlinux все необходимые файлы для bind лежат в /var/lib, что не соответствует FHS. Там лежат все необходимые для
полноценной работы файлы. При этом существенно, что если bind запускается из уже изолированного окружения, то в нем же
надо хранить и разделяемый библиотеки, а если bind запускается из обычного окружения, а потом самостоятельно делает chroot
то библиотеки не нужны, поскольку они загрузились при запуске.
Line 29: Line 115:
В altlinux они лежат в /var/lib, чт не сотв. fhs. Там лежат все небх файлы для работы бинда. Обычн тут лежат и разд. библитеки, но bind делает chroot после запуска, и разд. библиотеки он уже подссал, пэтому ему нужны тлько dev, etc, var, zones. В подкаталоге etc лежат настройки. В подкаталоге zone - соответствия между ip-адресами, доменами, почтовыми серверам.
Редактировать следует файл local.conf(Учтите что файл написан з соображение что chroot уже сделан)
Line 31: Line 118:
зоны --- соотв. имён и ip. Для кнфиг. необх. редактирвать local.conf. Обр. внимание, что файл написан из сооб., что чрут уже призшёл. В zones лежат зоны, там лежат ещё и таблицы с другими типами записей. Пример зоны можно посмотреть на файле localdomain.
{{{
[root@class305 bind]# cat zone/localdomain
$TTL 1D
@ IN SOA localhost. root.localhost. (
                                2008070800 ; serial
                                12H ; refresh
                                1H ; retry
                                1W ; expire
                                1H ; ncache
                        )
        IN NS localhost.
        IN A 127.0.0.0
localhost IN CNAME localhost.
}}}
Line 33: Line 134:
Пример зоны можно посм. на файле localdomain. Типичный пример зоны. SOA определяет различные парметры зоны. serial --- такое число, которое надо увел каждый раз, когда изм. содерж. зоны.

Тут достатчно много полей, н их мжно пропускать, если они повт. предыдущие.

Обратные записи эт записи вида .in-addr.arpa, там всё аналогично. Обр. на устр. обр. зоны. бр. пребр. риентированы на сети, и старший байт справа, а младшие слева, поскльку старшие байты --- сеть, а младшие --- хосты.

Обратите внимние, чт если у вас лок. сеть, или какая-то сеть, где вы разв. доменный сервер, то вы обязаны редакт. бе зоны (за искл. ситуации, когда добавляете CNAME). Ещё обр. внимание, чт далек не всегда обесп. бр. зону, поск. если вы заказали адреса у провайдера, то он должен сам оббесп., он ничего хорошего обычно не беспечивает.

Есть некая договорённость, какую должны бесп. провайдеры: ни олжны делать CNAME на спец. сеть, которую отд. вам, и там уже разруливаются PTR.

Для того, чтбы закончить ввдный разговор пр BIND, надо запомнить, что рег. надо не один DNS-сервер, а два. Никто не заст. править конф. на обоих, поэтому один мастер, другой слейв, и влейв качает зны с мастера. Уст. это просто: в конфиге пишете, что он слейв, и указываете, ткуда их скачивать.

Тем самым получаются два сервера, ни абс. идентичны.

Ещё лектр может посов. запр. рек. запросы для всех машин, крме тех, для которых он создан.
запись типа SOA определяет различные параметры зоны, такие как время жизни, время обновления и т.п. serial --- такое число,
которое надо увел каждый раз, когда изменяется содержимое зоны. Обычная практика - записывать туда дату редактирования.
Line 50: Line 138:
Последнее, что стоит упомянуть: если у вас есть интранет, есть внеш. сеть, и если у вс есть мшины, кторые снаружи видны под вн. адресом, т неплох, что в dns был бы такая же фигня. Для этого существует split horizon, а сотв. место в док. по bind надо читать в view. Аналогично для обратного преобразования, только запись типа PTR а не A.
{{{
[root@class305 bind]# cat zone/127.in-addr.arpa
$TTL 1D
@ IN SOA localhost. root.localhost. (
                                2008070800 ; serial
                                12H ; refresh
                                1H ; retry
                                1W ; expire
                                1H ; ncache
                                )
        IN NS localhost.
        0.0.0 IN PTR localdomain.
        1.0.0 IN PTR localhost.
}}}
Устройство обратной зоны ориентированны на сети, и поэтому старший байт справа, а младшие слева, поскольку старшие байты
--- сеть, а младшие --- хосты.

Обратите внимание, что если у вас локальная сеть, или вообще какая-то сеть, где вы разворачиваете доменный сервер, то вы
обязаны редактировать обе зоны (за искл. ситуации, когда добавляете CNAME). Ещё обратите внимание, что далеко не всегда вы
сами обеспечиваете обратную зону, поскольку если вы заказали адреса у провайдера, то он должен сам обеспечивать
корректность и существование обратной зоны. он ничего хорошего обычно не обеспечивает.

Есть некая договорённость о том, как должны поступать провайдеры когда вы хотите сами заниматься обратным преобразованием:
они должны делать CNAME на специальную сеть, которую отдают вам, и там уже вы разруливаются PTR. Т.е. по сути вам даются
два домена - один нормальный и один вида in-addr.arpa

Для удобство редактирования, покольку DNS-серверов обычно более одного, один из них объявляется master, а остальные -
slave. и они будут скачивать с master конфигурацию. Устроенно это просто: в конфигурационном файле пишете, что он slave, и указываете,
адрес master. Тем самым получаются два абсолютно идентичных(с точки зрения внешнего мира) сервера.

Так же имеет смысл запретить рекурсивные запросы для всех машин, кроме тех, для которых он создан.


Последнее, что стоит упомянуть: если у вас есть интранет, есть внешняя сеть, и если у вас есть машины, которые снаружи видны
под внешним адресом, то неплохо бы чтобы при обращении к DNS серверу за адресом внутренней машины из внутренней сети он
выдавал бы её внутренний адрес, а не внешний. Для этого существует технология split horizon, а соответствующее место в
документации называется view.
Line 58: Line 184:
|| 0 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, [[Allena]], MaximByshevskiKonopko || || || || 10 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, [[Allena]], MaximByshevskiKonopko || || ||

Использование chroot

Кусок лекции из сетевого администрирования, который был: DNS --- такая штука, которая преобразует доменные имена в ip и обратно. Эта служба устроенна иерархически, у каждой зоны есть собственная сервер DNS. За каждой сетью должна быть зарегистрирована служба, занимающаяся преобразованием IP в доменное имя. Если провайдер выдал группу внешних адресов, то существуют два варианта для организации доменных имен:

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

Получить собственный домен также можно несколькими способами:

  • Оплачиваете незанятое доменное имя у специальной компании- регистратора, после чего вы появляетесь в базе whois. При этом вы обязаны держать какое-то количество "живым" адресов в этом домене. Стоит это порядка 20 долларов в год. При этом вы становитесь администратором этого домена.
  • Получить поддомен. Идете к владельцу домена и на непонятных правах получаете у него поддомен. В большинстве случаев это бесплатно, например когда вы регистрируете поддомен для структурного подразделения компании, владеющей доменом, например, po.cs.msu.su. При этом администратором поддомена можете быть и не вы.

В любом случае, вы по хорошему должны обеспечить не меньше двух доменных серверов (в случае с доменом- обязаны обеспечить) с существенно разными IP-адресами, которые бы занимались преобразованием из доменных имён IP-адреса в вашем домене. В случае, если мы имеем дело со школой или с классом, поскольку никаких доменных имён для интранета регистрировать не надо. Можно завести какой угодно домен, главное, чтобы не происходило интерференции.

Сейчас никакого сервера доменных имён не стоит вообще. Поэтому когда клиенты обращаются за настройками по протоколы DHCP, им передают местонахождение общего сервера. В случае, когда поднят DNS, им передается местонахождение этого DNS сервера, и они будут обращаться к нему, а он дальше. И в этом случае возможно обращаться к локальным компьютерам по именам.

pdnsd

Это DNS-сервер,изначально предназначенный для того, чтобы запускаться на очень плохих каналах, и предназначенный для принудительного кэширования всех DNS-запросов. То есть, даже если в случае, если сказано, что у записи малое время жизни, всё равно его нужно закешировать. Также он актуален малых сетях без иерархии, и вся задача сводится к тому, чтобы:

  • снабдить все машины DNS-сервером
  • учесть все машины

Установим его

root@class305 ~]# apt-get install pdnsd

посмотрим его состав

[root@class305 ~]# rpmquery -l pdnsd
/etc/pdnsd.conf
/etc/ppp/ip-up.d/0pdnsd
/etc/rc.d/init.d/pdnsd
/usr/sbin/pdnsd
/usr/sbin/pdnsd-ctl
/usr/share/doc/pdnsd-1.2.5
/usr/share/doc/pdnsd-1.2.5/AUTHORS
/usr/share/doc/pdnsd-1.2.5/COPYING.BSD
/usr/share/doc/pdnsd-1.2.5/ChangeLog
/usr/share/doc/pdnsd-1.2.5/ChangeLog.old
/usr/share/doc/pdnsd-1.2.5/NEWS
/usr/share/doc/pdnsd-1.2.5/README
/usr/share/doc/pdnsd-1.2.5/README.ALT
/usr/share/doc/pdnsd-1.2.5/README.par
/usr/share/doc/pdnsd-1.2.5/README.par.old
/usr/share/doc/pdnsd-1.2.5/THANKS
/usr/share/doc/pdnsd-1.2.5/TODO
/usr/share/doc/pdnsd-1.2.5/contrib
/usr/share/doc/pdnsd-1.2.5/contrib/README
/usr/share/doc/pdnsd-1.2.5/contrib/change_pdnsd_server_ip.pl
/usr/share/doc/pdnsd-1.2.5/contrib/dhcp2pdnsd
/usr/share/doc/pdnsd-1.2.5/contrib/pdnsd_dhcp.pl
/usr/share/doc/pdnsd-1.2.5/html
/usr/share/doc/pdnsd-1.2.5/html/dl.html
/usr/share/doc/pdnsd-1.2.5/html/doc.html
/usr/share/doc/pdnsd-1.2.5/html/faq.html
/usr/share/doc/pdnsd-1.2.5/html/index.html
/usr/share/doc/pdnsd-1.2.5/pdnsd.conf
/usr/share/doc/pdnsd-1.2.5/txt
/usr/share/doc/pdnsd-1.2.5/txt/faq.txt
/usr/share/doc/pdnsd-1.2.5/txt/intro.txt
/usr/share/doc/pdnsd-1.2.5/txt/manual.txt
/usr/share/man/man5/pdnsd.conf.5.bz2
/usr/share/man/man8/pdnsd-ctl.8.gz
/usr/share/man/man8/pdnsd.8.gz
/var/cache/pdnsd
/var/cache/pdnsd/pdnsd.cache
/var/run/pdnsd
/var/run/pdnsd/socket

Отредактировав конфигурационный файл pdnsd.conf, запустим его

[root@class305 ~]# service pdnsd start

После этого надо поправить dhcp.

Для того, чтобы сервер пользовался своим DNS, надо на нем первым nameserver'ом прописать 127.0.0.1 в /etc/resolv.conf

BIND

Пакет называется bind, а соответствующий сервис называется named.Один из самых популярных в мире. BIND делают долго и упорно люди из Internet Service consorcium, большинство RFC на этот счёт тоже написаны ими. Этот сервис очень большой и имеет много функций.

Запускается он из изолированного окружения.

chroot

Идея в следующем: у нас есть служба, которую мы не можем запускать не от root, или есть служба, которую мы можем запускать не от рута, но опасаемся дырок безопасности в ней.В любом случае, мы не хотим вычитывать все исходные коды, но при этом нам необходимо ею пользоваться. Поэтому такие службы переносятся в изолированное окружение. chroot --- вызов на уровне ядра для изменения корневого каталога процесса и всех его потомков. После такой операции получить доступ к остальным частям ФАС кроме как залезания в устройства не удаётся. При этом никакой изоляции от процессов ,от памяти не происходит. В частности, сервер bind настолько большой, и дырки там встречаются часто. Более того, получение информации об его ошибках предоставляется за деньги. И эта служба потенциально опасна. Посему в мануалах конфигурационные файлы указанны как располагающиеся в /etc и /var, но в АльтЛинуксе они лежат ещё в многих другим местах, из которых потом и формируются изолированные окружения.

В altlinux все необходимые файлы для bind лежат в /var/lib, что не соответствует FHS. Там лежат все необходимые для полноценной работы файлы. При этом существенно, что если bind запускается из уже изолированного окружения, то в нем же надо хранить и разделяемый библиотеки, а если bind запускается из обычного окружения, а потом самостоятельно делает chroot то библиотеки не нужны, поскольку они загрузились при запуске.

В подкаталоге etc лежат настройки. В подкаталоге zone - соответствия между ip-адресами, доменами, почтовыми серверам. Редактировать следует файл local.conf(Учтите что файл написан з соображение что chroot уже сделан)

Пример зоны можно посмотреть на файле localdomain.

[root@class305 bind]# cat zone/localdomain
$TTL    1D
@       IN      SOA     localhost. root.localhost. (
                                2008070800      ; serial
                                12H             ; refresh
                                1H              ; retry
                                1W              ; expire
                                1H              ; ncache
                        )
        IN      NS      localhost.
        IN      A       127.0.0.0
localhost       IN      CNAME   localhost.

запись типа SOA определяет различные параметры зоны, такие как время жизни, время обновления и т.п. serial --- такое число, которое надо увел каждый раз, когда изменяется содержимое зоны. Обычная практика - записывать туда дату редактирования.

Аналогично для обратного преобразования, только запись типа PTR а не A.

[root@class305 bind]# cat zone/127.in-addr.arpa
$TTL    1D
@       IN      SOA     localhost. root.localhost. (
                                2008070800      ; serial
                                12H             ; refresh
                                1H              ; retry
                                1W              ; expire
                                1H              ; ncache
                                )
        IN      NS      localhost.
        0.0.0   IN      PTR     localdomain.
        1.0.0   IN      PTR     localhost.

Устройство обратной зоны ориентированны на сети, и поэтому старший байт справа, а младшие слева, поскольку старшие байты --- сеть, а младшие --- хосты.

Обратите внимание, что если у вас локальная сеть, или вообще какая-то сеть, где вы разворачиваете доменный сервер, то вы обязаны редактировать обе зоны (за искл. ситуации, когда добавляете CNAME). Ещё обратите внимание, что далеко не всегда вы сами обеспечиваете обратную зону, поскольку если вы заказали адреса у провайдера, то он должен сам обеспечивать корректность и существование обратной зоны. он ничего хорошего обычно не обеспечивает.

Есть некая договорённость о том, как должны поступать провайдеры когда вы хотите сами заниматься обратным преобразованием: они должны делать CNAME на специальную сеть, которую отдают вам, и там уже вы разруливаются PTR. Т.е. по сути вам даются два домена - один нормальный и один вида in-addr.arpa

Для удобство редактирования, покольку DNS-серверов обычно более одного, один из них объявляется master, а остальные - slave. и они будут скачивать с master конфигурацию. Устроенно это просто: в конфигурационном файле пишете, что он slave, и указываете, адрес master. Тем самым получаются два абсолютно идентичных(с точки зрения внешнего мира) сервера.

Так же имеет смысл запретить рекурсивные запросы для всех машин, кроме тех, для которых он создан.

Последнее, что стоит упомянуть: если у вас есть интранет, есть внешняя сеть, и если у вас есть машины, которые снаружи видны под внешним адресом, то неплохо бы чтобы при обращении к DNS серверу за адресом внутренней машины из внутренней сети он выдавал бы её внутренний адрес, а не внешний. Для этого существует технология split horizon, а соответствующее место в документации называется view.


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

10

1

1

1

1

ArtemSerebriyskiy, Allena, MaximByshevskiKonopko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080731/04Chroot (last edited 2008-10-16 12:48:07 by FrBrGeorge)