|
|
|||||||||||||||||||
|
|
||||||||||||||||||
Введение Для человека, поработавшего даже небольшое время в сети, становится совершенно естественным, что у каждого компьютера, подключенного к интернет, есть свое название, имя, которое легко запомнить. Система, которая позволяет нам использовать эти привычные для человека имена, избегая других неудобных способов "маркировки" компьютеров, называется dns (domain name system, доменная система имен). В интернете существует, вообще говоря, два основных способа адресации компьютеров. Первый - численный (или ip-адрес; например, 193.124.134.101), второй - символьный (noc.radio-msu.net). dns создана для того, чтобы поставить в соответствие один способ другому. Чтобы облегчить упорядочивание наименований, вся структура компьютерных имен устроена таким образом:есть отдельные уровни (домены), которые могут включать в себя как другие поддомены, так и имена компьютеров. Все названия должны состоять только из латинских букв, цифр и, может быть, знака "минус". Отдельные уровни доменов разделяются точкой. Типичное полное доменное имя компьютера может выглядеть так: computer3.otdel-5.firma.msk.ru В этом примере такой адрес мы присвоили компьютеру номер три, который стоит в отделе (номер сообразите сами) фирмы с изысканным английским названием "firma", которая находится в Москве ("msk"), в России ("ru"). Локальным именем компьютера (hostname) здесь является "computer3", а ".ru" обычно называется доменом верхнего уровня. Домен msk.ru, соответственно, является доменом второго уровня; firma.msk.ru - третьего... В пределах домена каждого уровня есть группа людей, которые отвечают за этот домен. Они могут добавлять имена вновь появившихся компьютеров, менять их или удалять. И по сути дела, то, как будет называться та машина, на которой работаете вы в своей фирме, зависит от того, что им подскажет фантазия написать в конфигурационном файле dns. Тот, кто имеет право администрировать домен, может делать изменения только в пределах этого домена. Например, системный администратор отдела n5 может, скажем, изменить имя "computer3" на "computer4" или на что-то более человеческое, например, назвать этот компьютер "julia" (Тогда полный его адрес станет julia.otdel-5.firma.msk.ru). Но для того, чтобы изменить имя домена 4-го уровня "otdel-5", администратору придется просить об этом у сисадмина фирмы (если, конечно, это не одно и тоже лицо). Процедура получения имени, например, в зоне .ru или .com называется регистрацией домена. Конечно, каждая компания, подключающаяся к интернет, стремится зарегистрировать как можно более естественное и легкое для запоминания имя. Так, для "microsoft inc." логично зарезервировать домен microsoft.com Доменов верхнего уровня очень немного - всего около 250.. Большая часть из них - так называемые, географические домены. Например, .de (deutschland, Германия), .ru (russia, Россия), .iq (iraq, Ирак). Оставшиеся негеографические домены верхнего уровня - .com (для коммерческих компаний), .net (для сетевых ресурсов), .edu (образовательные учреждения), .mil (военные организации), .org (некоммерческие организации), .gov (правительственные ведомства), .int (интернациональные корпорации). Если вам бы захотелось зарегистрировать еще один домен верхнего уровня, то потребовалось для этого предоставить такие серьезные обоснования, что гораздо проще было бы организовать свое маленькое государство и для него уже получить географический домен. К началу 1998 года во всем интернете зарегистрировано около 30 миллионов хостов. Распределение по доменам верхнего уровня приведено в таблице: Россия в этом списке находится на 28-м месте. Под доменом .ru зарегистрировано около 100 тысяч компьютеров. А в Антарктике (.aq), как оказывается, нет ни одного компьютера, подключенного к интернет.. dns вашей компании При текущем уровне развития коммуникаций в России, все больше компаний встают перед необходимостью подключения своих локальных сетей к интернет. Если опустить все организационные и коммерческие вопросы подключения, то в техническом отношении этот процесс сведется к следующей последовательности действий: - Подключение к провайдеру. Физическое подключение может быть выполнено очень многими различными способами: от обычного модема до радиосетей и оптоволокна. Способ подключения и, соответственно, оплата оговариваются непосредственно с провайдером. - Получение численных (ip) адресов. Для того, чтобы ваши компьютеры, подключенные к интернет, стали доступны, необходимо выделить для них уникальные численные адреса. Обычно в договоре на подключение к интернет указывается, сколько и каких адресов отдается в пользование вашей компании. Формат ip-адресов такой: четыре числа от 1 до 255, отделенных точками. Например, 193.124.134.101 - ip-адрес какого-то компьютера в сети. - Настройка dns. Допустим, вы получили блок ip-адресов. Теперь следует правильно сконфигурировать систему имен и корректно настроить работу серверов с этими именами. - Процедура регистрации доменного имени. Она сильно различается для различных доменов верхнего уровня, и может быть как бесплатной, так и по оплате. - Дальнейшая установка программного обеспечения на компьютеры, требующего явного указания доменного имени (например, web-сервера). Вообще говоря, большинство интернет-провайдеров предоставляют услуги по регистрации доменов их силами, но вам может быть полезно представлять, каким образом эта процедура происходит и что для этого требуется. Мы будем рассматривать в конкретных примерах системы, работающие под управлением freebsd unix, хотя те же выкладки без труда переносятся и на любую другую систему. Прежде всего, для полноценной работы dns вам необходимо два или больше компьютеров, так называемых, name-серверов, которые независимо друг от друга подключенны к интернет (лучше, если они будут находиться в разных сетях или даже разных странах). Такая структура обеспечит неизменную работу системы преобразования символьного адреса в числовой и обратно, даже если какое-то время некоторые из этих компьютеров будут недоступны по сети. На таких компьютерах запускается специальная программа-демон named, которая обрабатывает запросы на преобразование адресов и отвечает на них. Настроить dns - означает корректно написать конфигурационные файлы named. name-сервера бывают primary и secondary. Иногда их называют первичными и вторичными, а также master и slave. primary name-сервер может быть только один. На нем хранится вся информация о доменах, и если происходят изменения, то конфигурация правится только на нем. secondary name-серверов может быть несколько, но обычная практика - один secondary nameserver. Дополнительные вторичные name-сервера служат для повышения скорости расшифровывания вашего адреса и для повышения устойчивости такого преобразования. Для небольших сетей три и больше вторичных name-сервера - это уже излишество. secondary name-сервера с заданной периодичностью в автоматическом режиме считывают текущую конфигурацию с primary-сервера. Заметим, что один и тот же компьютер может одновременно являться primary-сервером для одних доменов и secondary nameserver'ом для нескольких других. Конкретную реализацию таких dns-серверов мы рассмотрим в следующих разделах. Выбор и регистрация домена Если вы имеете некоторый опыт работы в интернет, то вам, скорее всего, известны примеры доменных имен различных организаций и фирм. В качестве примера приведем случайно взятые адреса серверов: Как настроить dns Сама программа named в большинстве случаев входит в стандартный набор средств операционных систем unix. Если в вашем случае ее не оказалось, попробуйте сделать поиск программы named для вашей системы в поисковых серверах интернета (altavista, lycos и т.д.). Обычно главный файл с настройками named называется named.boot и лежит в директории /etc. Запускать демон named обязательно с привилегиями пользователя root. В данном случае рассматривается freebsd версии 2.2.2 со стандартной named. Сама программа лежит в /usr/sbin/named, а заготовки для конфигурации в директории /etc/namedb. Прежде всего, перед любым изменением конфигурации сохраните предыдущие файлы настроек, чтобы всегда можно было вернуться к исходному состоянию. Скопируем named.boot в нужную директорию: % cp /etc/namedb/named.boot /etc Комментарии в named.boot начинаются с ";" на первом месте в строке. Рассмотрим различные директивы в named.boot: directory /etc/namedb Это та директория, в которой будут храниться конфигурационные файлы для каждого из доменов, которые этот name-сервер будет держать. cache . named.root Эта специальная опция задает имя файла named.root в директории /etc/namedb, в котором содержатся ip-адреса компьютеров, которые "знают все" о доменных именах, то есть, содержат домен "точка". В этих серверах хранится информация обо всех доменах верхнего уровня, и если на dns-запрос ответ не был дан на более раннем этапе, то, добежав до одного из таких top-level серверов, запрос пойдет по необходимой ветке вниз. Вот кусок этого файла: ; formerly ns.internic.net . 3600000 ns b.root-servers.net. Файл named.root впоследствие нужно периодически забирать с ftp.rs.internic.net, так как ip-адреса top-level серверов через несколько месяцев могут и поменяться. Следующая директива в конфигурационном файле говорит о том, что наш name-сервер является primary name-сервером для какой-то зоны, то есть, содержит всю информацию о ней. Синтаксис ее таков: primary [имя.домена] [имя_файла] Пример: primary radio-msu.net db.radio-msu.net Это означает, что мы установили primary nameserver для доменов radio-msu.net (домен второго уровня) и math.msu.su (третьего уровня), но мы проделали только небольшую часть работы. После этого нужно будет описать эти домены в текстовых файлах, называющихся db.radio-msu.net и db.msu.su в директории /etc/namedb. Мы специально выбрали имена файлов похожими на имена соответствующих им доменов из соображений удобства. Имена конфигурационных файлов больше нигде роли не играют, и вы вправе их называть как угодно. Создавать и редактировать их можно при помощи обычного текстового редактора, находясь в директории /etc/namedb. Подробное описание db.* файлов будет дано чуть ниже. Для того, чтобы стать вторичным nameserver'ом для других доменов, в named.boot нужно написать строчку такого плана: secondary npi.msu.su 158.250.2.232 db.npi.msu.su Общий вид директивы таков: secondary [имя.домена] [ip-адрес primary nameserver'а] [имя_файла] Первый параметр здесь - имя домена, для которого мы устанавливаем secondary. Для него обязательно должен существовать первичный name-сервер, с которого демон будет периодически считывать данные об этом домене. Вместо одного ip-адреса primary nameserver'а может идти и список адресов, откуда еще можно узнать информацию о домене. Это используется в том случае, если мы создаем многоуровневую систему nameserver'ов с различными приоритетами, и т.д. В большинстве случаев в это поле заносится только адрес primary. Последний параметр - имя временного файла, выбранное нами произвольным образом, в котором демон named будет хранить информацию о домене, полученную от primary name-сервера. Как и в первом случае, имена файлов лучше назначать созвучными с именем домена. Кстати, для того, чтобы установить вторичный nameserver для домена, нужно только добавить одну такую строчку named.boot, и все. Чтобы правильно настроить primary name-сервер, нам осталось рассмотреть конфигурационные файлы db.* (эти файлы также называются файлами зоны). Общий вид записи в этом файле: [domain] [opt_ttl] [opt_class] [type] [resource_record_data] где domain есть "." для описания домена верхнего уровня, "@" для текущего домена или обычное доменное имя (в частности, просто имя машины (hostname)). opt_ttl - необязательное поле, целое число, которое означает время жизни (time-to-live) этой записи в секундах. По истечении этого срока содержимое записи должно автоматически обновиться. opt_class - тип адреса объекта. Такой тип существует только один, который, собственно, и указывается ("in"). type - тип записи (рассмариваются ниже) resource_record_data - данные этого типа Рассмотрим пример primary nameserver'а и соответствующего ему файлу зоны для домена radio-msu.net. В случае, если вы будете использовать эти примеры как руководство, не забудьте, пожайлуста, поменять все записи соответственно структуре вашей сети. В named.boot мы должны прописать такую строчку: primary radio-msu.net db.radio-msu.net И в директории /etc/namedb создаем файл с названием db.radio-msu.net примерно такого содержания: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Заметим, что все строки, начинающиеся с ";", являются комментариями и используются для улучшения читабельности текста. Теперь рассмотрим типы записей, встречающиеся в нашей конфигурации: Самая первая запись в любом таком файле выглядит следующим образом: @ in soa ns.radio-msu.net. art.radio-msu.net. ( Символ "@" означает, что дальнейшие директивы относятся к текущему домену (то есть, к домену radio-msu.net). Поле "in" можнно считать несущественым, а после него идет описание типа записи: soa - (start of authorizing) - зона ответственности. Дальнейшие параметры определяют, кто отвечает за этот домен, как часто обновлять информацию об этой зоне на secondary-серверах, а также другую служебную информацию. Первое поле параметров этой записи - имя primary name-сервера, содержащего зону. После него следует адрес технического контактного лица, отвечающего за домен. Обратите особое внимание на точки в конце этих адресов! Точка в конце означает, что этот адрес является обычным доменным именем, и его не нужно дополнять справа доменом, которому соответствует наш конфигурационный файл. То есть, если вместо ns.radio-msu.net. написать ns.serv, то будет иметься ввиду компьютер ns.serv.radio-msu.net Точку в конце символьных имен нужно не забывать ставить и в других полях зоны. Это одна из самых распространенных ошибок. Написать "ns.radio-msu.net" - значит, иметь ввиду сервер "ns.radio-msu.net.radio-msu.net", которого просто не существует. Оставшиеся в круглых скобках после контактного лица пять параметров записи soa - целые числа, определяющие временые интервалы обмена информацией об этом домене между primary и secondary. Первое число ("1998022300" у нас) - сериальный номер (serial number) записи. По изменению сериального номера secondary name-сервера определяют, было ли изменено содержимое домена или нет, и соответственно, нужно ли считывать весь домен с primary-сервера. Сериальный номер должен состоять из десяти цифр и обязательно должен быть заменен вручную на какой-либо больший при любом измеении любой записи в файле домена. Для этих целей идеально подходит такой вариант: первые четыре цифры serial'а - год, затем две на месяц и число. Последние две - порядковый номер (начиная с 00) редакции в течение дня. Если мы меняем конфигурацию домена, то заодно мы должны увеличить и сериальный номер. А при таком задании serial'а увеличение происходит автоматом. После сериального номера идет поле refresh, которое указывает время в секундах, по истечении которого secondary name-сервер проверяет не изменилась ли данная зона на primary-сервере, и если изменения были, то происходит передача файла с зоной. Если при этом у него не получилось по каким-либо причинам соединиться с сервером, то следующую попытку secondary сделает по истечении retry секунд (третий параметр). В том случае, если и последующие попытки подключиться к primary и узнать информацию о зоне оканчиваются неудачей, вторичный name-сервер по прошествии expire секунд забудет всю информацию по этой зоне. Последнее поле ('minimum ttl') указывает на минимальное время жизни (time to live) записей в файле зоны, если только в какой-то записи не будет указано другое значение в необязательном поле opt_ttl. Рекомендуемые значения для этих величин таковы: 28800 ; refresh 8 hours Однако вам никто не вправе помешать поставить свои значения. Только не ставьте слишком маленькие величины (меньше часа) - иначе вы просто забьете сеть бесполезной информацией, непрерывно пересылаемой от primary к secondary. Теперь рассмотри записи следующего типа: ns - (name server) - перечисляет name-сервера (и primary, и secondary), которые держат эту зону. Не забывайте про точку в конце имени! in ns ns.radio-msu.net. Здесь мы для зоны .radio-msu.net указали два name-сервера (первый из них - primary, второй - secondary), на которых содержится вся информация о домене. Далее идет одна из наиболее часто встречающихся записей dns: a - (address) - адрес хоста. На первом месте в такой строке будет стоять символьное имя компьютера в текущем домене, после этого "in a", а затем - числовой ip-адрес, соответствующий этой машине. Рекомендуется внести, например, такую строку в файл зоны: localhost in a 127.0.0.1 Это позволит обращаться с любого компьютера в сети к самому себе, используя зарезервированное имя localhost. Для того, чтобы как-нибудь назвать новый компьютер в сети, вам нужно просто добавить такую строчку в файл зоны (не забудьте только после этого подправить сериальный номер в записи soa и после всех изменений перезапустить демон named (сделать ему kill -1)). В рассмотренном примере мы видим такие строки: ns in a 193.124.134.1 Значит, мы назвали компьютеры с соответствующими ip-адресами именами ns,telion и diana. Очень часто используется имя www, которое позволяет обращаться к web-серверу домена. Если бы мы изменили здесь слово 'telion' на 'www', то по адресу http://www.radio-msu.net/ откликнулась машина с ip-адресом 193.124.134.2. В нашем случае, можно поступить более хитрым образом, используя запись типа cname. cname - (canonical name) - в транслитерации с латинского, на компьютерном жаргоне такая запись называется алиас (alias). Вы как бы добавляете компьютеру еще одно имя, которое при разрешении превратится в тот же ip-адрес, что и основное имя. www in cname telion Теперь имя www.radio-msu.net будет аналогично telion.radio-msu.net. Алиасов для одного ip-адреса может быть сколько угодно, но на них накладывается единственное условие: то имя (каноническое), которое стоит после cname, должно также где-либо быть описанным. Допускается использовать в качестве канонического имени и alias, лишь бы такая цепочка алиасов не замыкалась. В качестве cname может выступать любой именной адрес в сети, не обязательно из текущего домена, например: other in cname www.sun.com. И пойдя теперь по адресу other.radio-msu.net, мы попадем на сервер sun microsystems. Заметим еще один момент. Второе имя компьютеру можно дать и так: mail in a 193.124.134.3 При этом у нас будет несколько записей типа 'a', соответствующих одному ip-адресу. Это ничему не противоречит, но так делать - плохой стиль. Следующий важный тип записей - записи типа mx. mx - (mail exchange) - пересылка почтовых сообщений. Они обычно следуют за записями типа 'a' или 'soa'. Используются они обычно так: [domain] in mx [pref_value] [mail_server] где domain - необязательное поле. Если оно есть, то запись онтосится к этому домену, если нет - то к предыдущему с типом 'a'. В том случае, если на месте [domain] стоит символ '@' или это поле отсутствует, но сама запись находится в самом начале файла зоны (сразу же после soa), то такое поле mx будет относиться к домену, которому соответствует текущий db-файл. 'in' также можно указывать, а можно опускать. mail_server - доменное имя почтового сервера, которому достанется вся почта, приходящая на этот домен. На этом сервере должны стоять программы, поддерживающие почтовый протокол smtp. Для повышения надежности пересылки почты, вы можете указать подряд несколько почтовых серверов. В том случае, если один из них перестанет работать, вся почта на домен будет отправляться на эти "запасные" mail-сервера, которые при первой же возможности отправят все накопившиеся у них электронные письма на основной почтовый сервер. Чтобы регулировать такую систему, и вводится параметр pref_value (приоритет соответствующего почтового сервера), который может меняться от 0 (самый большой приоритет) до 32767 (почта на mail-сервер с таким значением pref_value будет приходить в совсем крайнем случае). Если у вас запись mx единственная для какого-то домена, то значение этого поля не играет роли. Но при использовании только одного mail-сервера в те моменты, когда он по каким-либо причинам недоступен, почта будет теряться. Поэтому обыкновенно ставят две-три mx-записи, а приоритеты у них устанавливают круглыми числами от 10 до 100. Пример: mpr in a 193.124.134.3 Итак, почта, идущая на mpr (например, на john@mpr.radio-msu.net), прежде всего попытается лечь на сам mpr, а в том случае, если у нее это не получится, то будет использован второй вариант (50 больше, чем 10) - mskws.desy.de, где почта пролежит до того момента, пока mpr опять не заработает. Зачастую нужно использовать более короткие почтовые адреса, вроде alla@radio-msu.net. Делается это таким образом: @ in mx 20 mpr Ситуация в точности та же. Почта на somebody@radio-msu.net перенаправляется на mpr (или на mskws), а на этих компьютерах уже должны быть корректно настроены почтовые программы, понимающие, на какой домен приходит почта и что с ней надо делать дальше. Для этого вам, к несчастью, придется ознакомиться с соответствующей документацией к почтовому серверу. Следующие типы записей используются реже, тем не менее, приведем их тут: null - пустая запись. Скорее всего, должна использоваться для резервирования доменного имени, но на практике применяется только в том случае, если необходимо убрать на некоторое время из dns'а запись о какой-то машине. Хотя проще такие строчки просто закомментарить. rp - (responsible person) - ответственное за этот домен лицо: xerox in rp ivanov ivan hinfo - (host information) - информация о компьютере (тип процессора, операционная система и т.д.). Используется крайне редко. Нам осталось рассмотреть последний особый тип записи 'ptr' (domain name pointer), эта запись используется в db.* файлах так называемой "обратной зоны" (reverse-dns). Настройка "обратной зоны" В рассматриваемых до этого примерах мы видели, как установить взаимосвязь между символьными именами и числовыми ip-адресами, но только в одну сторону: от символьных имен к числовым. Доменная система имен должна также обеспечивать обратное преобразование: из числового адреса в строковый. Для этих целей, собственно и служат файлы обратной зоны (reverse-dns), структура которых во многом напоминает файлы зон, которые мы рассматривали выше. Для обратных зон также необходимы primary и secondary сервера. В конфигурационном файле named.boot для установки primary name-сервера может быть написана примерно такая строка: primary 134.124.193.in-addr.arpa db.193.124.134 Домен 'in-addr.arpa' - служебный. Он используется для обозначения числовых ip-адресов. Будьте внимательны: при таком способе записи от вашего полного ip адреса из 4-х чисел остаются только первые три, общие для компьютеров внутри вашей локальной сети (или какого-то ее участка). Причем, эти числа меняются местами: так домен 80.67.194.in-addr.arpa будет соответствовать адресам сетки 194.67.80.*. secondary name-сервера обратных зон устанавливаются аналогично прямым зонам - в named.boot пишется строка secondary 100.250.158.in-addr.arpa 158.250.100.1 db.158.250.100 Этой строкой мы установили secondary name-сервер для reverse-зоны ip-адресов сети 158.250.100, а primary name-сервером будет компьютер этой сети с адресом 158.250.100.1. Обязательной строчкой в named.boot является обратная зона сетки 127.0.0, так как в ней находится ip-адрес 127.0.0.1 (localhost,loopback) - это специальный адрес, при обращении на который с любого компьютера, мы попадаем на него же. Итак, в named.boot должна быть строчка: primary 0.0.127.in-addr.arpa db.local Большие и маленькие буквы здесь не различаются. А в директории /etc/namedb создадим файл db.local примерно такого содержания (имена доменов вам, естественно, придется поменять на свои): ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Итак, вы установили reverse-dns для 127.0.0.1. Рассмотрим теперь пример установки обратной зоны для того же домена ('radio-msu.net'). В named.boot primary name-сервера записывается строка: primary 134.124.193.in-addr.arpa db.193.124.134 В директории /etc/namedb создаем файл с именем db.193.124.134 для обратной зоны. Здесь, как и в предыдущих ситуациях, само по себе имя большой роли не играет, поэтому можно выбирать его легким для запоминания. Теперь посмотрим на то, что может содержаться в этом файле: ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Как мы видим, в обратной зоне в основном используются записи типа ptr. Структура записи такова: [ip_address #4] in ptr [имя.домена] где ip_address #4 - последнее из 4-х чисел ip-адреса (его значения могут быть от 0 до 255). Первые три компоненты задаются для данного файла обратной зоны из named.boot. Запись ptr задает соответствие между ip-адресом и именем домена. Важно отметить, что для правильной работы необходимо соответствие числовых и символьных адресов в прямых и обратных зонах, иначе результат будет непредсказуем. В файле обратной зоны первой записью стоит запись типа soa, полностью аналогичная soa прямой зоны. После этого идет перечисление name-серверов (записи типа ns). И особняком стоит строка для адреса 193.124.134.0, который обозначает весь ethernet-участок сети. Прописывать нулевой адрес необязательно, но это считается правилом хорошего тона. Наконец, после всех этих манипуляций ваш сервер готов к работе. Демон named должен запускаться при старте машины. Все изменения в конфигурации должен производить только пользователь root. После каждого изменения не забывайте менять серийные номера в db.* файлах, согласовывать прямые и обратные зоны, перезапускать (kill -1) named. |
|||||||||||||||||||
|
|||||||||||||||||||
Веб-Мастеру
