Служба Доменных Имен предназначена для того, чтобы машины, работающие в Internet, могли по доменному имени узнать IP-адрес нужной им машины, а также некоторую другую информацию; а по IP-номеру могли узнать доменное имя машины.
Служба Доменных Имен была разработана для именования машин в глобальной сети. Основной особенностью глобальной сети является распределенное администрирование, когда один администратор физически не может уследить за выделением имен. Поэтому Служба Доменных Имен функционирует на принципе делегирования полномочий. Каждая машина либо знает ответ на вопрос, либо знает кого спросить. При правильном функционировании система замкнута, т.е. если запрошенная информация имеется у кого-либо, то она будет найдена и сообщена клиенту, либо, если вопрос не имеет ответа, клиент получит сообщение о невозможности получения ответа на вопрос.
Каждый клиент знает своего сервера; обычно указывается не один, а несколько серверов - если первый не отвечает, клиент обращается ко второму и так далее до исчерпания списка. В принципе неважно, к какому серверу обращаться - они дают (должны давать при правильном функционировании) одинаковые ответы на любой запрос. Поэтому для ускорения работы обычно указывают ближайший. Следует помнить, что на одной машине могут функционировать одновременно Name-сервер и программы-клиенты; поэтому если на машине запущен Name-сервер, то в качестве Name-сервера на ней должен быть прописан "я сам".
Имеется некий домен верхнего уровня, обозначаемый точкой: ".". Имеется девять серверов (по крайней мере на моем Name-сервере записано столько), которые отвечают за эту зону. Они не знают ни одного доменного имени - они только авторизуют серверы верхних зон. Серверы верхних зон тоже гнушаются хранить информацию о конкретных машинах и передают это право нижележащим серверам. Тут уже появляются первые упоминания о конкретных машинах, равно как и происходит авторизация нижележащих серверов.
Мне неизвестна ни одна машина с доменным именем из одного сегмента; очень редко используются доменные имена из двух сегментов; имена из трех и четырех сегментов составляют подавляющую долю всех имен Internet; имена из пяти сегментов встречаются довольно редко, а из шести и более мне неизвестны.
Допустим, клиент запросил адрес "www.организация.город.страна". Поиск информации по доменному имени происходит следующим образом:
Однако эту стройную картину искажают системы кэширования и вторичных серверов. Дело в том, что получив ответ на свой вопрос, DNS-сервер получает также некоторое число, которое говорит ему о том, по истечении какого времени эта информация должна считаться устаревшей. Таким образом, все серверы, участвовавшие в поиске ответа на вопрос, заданный клиентом, могут (и скорее всего будут) помнить как ответ на заданный вопрос, так и путь, по которому шел поиск. При следующих запросах, имеющих общую правую часть с недавно сделанными запросами, поиск будет упрощен (ускорен).
Кроме того, большинство зон имеет вторичные серверы, которые содержат копии данных с первичных серверов. Сервер вышележащей зоны может направить запрос как первичному серверу, так и любому из вторичных, основываясь на своих соображениях о том, какой из них ближе.
Хочу обратить особое внимание на сходство, различие и взаимодействие систем DNS и IP-маршрутизации. Как и IP-маршрутизация, DNS работает по принципу делегирования полномочий, но выделение доменных имен совершенно не зависит от выделения IP-адресов. Для примера рассмотрим домен freebsd.org. Это - домен организации, занимающейся распространением операционной системы FreeBSD Unix. FTP-сервер, содержащий дистрибутив операционной системы и множества утилит для нее, имеет копии в нескольких десятках стран. Имена серверов выглядят так:
Таким образом, машины, находящиеся в России оказались произвольно (по воле DNS-мастера из университета Bercley) включенными в домен freebsd.org; однако, они также состоят в своих зонах. Система DNS позволяет любому DNS-мастеру включить любой сервер в свою зону, хотя это включение никого ни к чему не обязывает.
Однако, некоторым сервисам этого недостаточно - так E-mail требует, чтобы машина, принимающая письмо, признала своим адрес, указанный в качестве пункта назначения. Протокол HTTP 1.1 (в 1.0 этого не было) требует, чтобы в HTTP-запросе указывался не путь к файлу, отсчитанный от корня сервера (хотя такие запросы тоже признаются), но и имя сервера; при этом сам сервер знает, какие имена - его, а остальные обрезает и обслуживает в соответствии с HTTP 1.0.
Делегирование зоны ...in-addr.arpa дается только от провайдера вместе с IP-адресами. Собственно, это связано с предназначением ReverceDNS - сообщать доменное имя по IP-адресу. Наверняка мастер зоны freebsd.org держит Reverce-зону для IP-номеров, выделенных университету Bercley; но все эти серверы (кроме сервера, расположенного в университете) не входят в эту Reverce-зону, а значит, ему неподконтрольны.
Одна из проблем состит в том, что Reverce-зону можно выделить только на сеть класса A, B или C (на 16777216, 65536 или 256 адресов) и никак иначе. Можно получить правА на несколько зон одного или разных классов, но что делать тем, кому выделили меньше 256 адресов? А ведь в условиях исчерпания адресного пространства не редкость выделения пула уже на 16 адресов!
Как правило, провайдер предоставляет клиенту целый комплекс услуг. В число оказываемых DNS-услуг входят:
Имена зон условно можно разделить на "организационные" и "географические". В высшей зоне зарегестрированы следующие "организационные" зоны:
В данный момент, чтобы разгрузить домен com, собираются создать несколько новых доменов, но у меня нет достоверной информации по ним. В организационных зонах обычно размещаются непосредственно домены организаций.
Каждая страна (государство) имеет свой географический домен из двух букв:
В зонах государств опять же имеются "организационные" и "географические" зоны. "Организационные" в большинстве своем повторяют структуру "организационных" зон верхнего уровня, разве что вместо "com" используется "co". "Географические" выделяются городам, областям и т.п. территориальным образованиям. Непосредственно в тех и других размещаются домены организаций или домены персональных пользователей.
После выбора зоны, в которую будет включен наш домен надо выбрать собственное имя домена. Обычно это имя компании, торговая марка или что-нибудь столь же характерное. Для неанглоязычных стран используется транскрипция имен. Часто возникают конфликты, связанные с тем, что одно и то же имя используется несколькими фирмами (законодательство допускает это для фирм, работающих в разных отраслях); многие люди заранее резервируют имена, могущие стать популярными для последующей продажи их владельцу торговой марки; но это уже касается юридической стороны функционирования Internet и не входит в мою компетенцию.
С левого конца доменного имени находятся имена машин. Имена бывают "собственные" и "функциональные". Имена "собственные" каждый придумавает в меру фантазии: машинам присваиваются имена членов семьи, животных, растений, музыкантов и артистов, литературных персонажей - кто во что горазд.
Имена "функциональные" вытекают из функций, выполняемых машиной:
Я считаю нежелательным присваивать какой-либо машине функциональное имя - в любой момент может потребоваться перенести соответствующую функцию на другую машину. Для этого лучше всего использовать псевдонимы, которые перенаправляют запросы к данному имени на записи, относящиеся к другому имени. Но вот ссылаться на псевдонимы при обьявлении Mail Exchanger'ов и вообще использовать их в правой части записей считается нежелательным, а зачастую является недопустимым.
Спланируем нашу зону так:
named -b /etc/namedb/named.bootВ качестве аргумента ему передается имя файла с описанием рабочей конфигурации.
|<- | Текст файла начинается с этой позиции. |<-Формат файла:
имя аргументыВ качестве разделителя используются пробелы и табуляции.
Пустые строки игнорируются.
Точка с запятой ";" - признак комментария; все от нее до конца строки игнорируется.
Если строка начинается с пробела или с табуляции, она относится к тому же имени, что и предыдущая строка.
directory /etc/namedbЭто - указание на то, в какой директории находятся все упоминаемые дальше файлы.
primary 0.0.127.in-addr.arpa localhost.revКаждый Name-сервер должен обслуживать зону 0.0.127.in-addr.arpa, ибо каждая машина должна знать свой внутренний номер как localhost.
primary фирма.домен фирма.домен.hostsЭто - домен, выделенный нашей организации.
primary 1.168.192.in-addr.arpa 1_168_192.revЭто - обратное преобразование IP-адресов в имена.
secondary филиал.фирма.домен 192.168.1.193 филиал_фирма_домен.hostsДля ускорения обращений к Name-серверу филиала на нашем сервере должна быть копия содержимого его зоны.
@ IN SOA troll.фирма.домен. ответственный_за_зону. ( 19970315 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 3600 ; Minimum IN NS troll.фирма.домен. 1 IN PTR localhost.домен.Пояснения:
Файл фирма_домен.hosts достаточно велик, поэтому я буду перемежать текст файла обьяснениями.
@ IN SOA troll.фирма.домен. ответственный_за_зону. ( 19970315 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 3600 ; Minimum )Да в общем-то нет никаких причин делать эту зону отличной от зоны, содержащейся в localhost.rev, разве что Serial может (и скорее всего будет) различаться.
IN NS troll IN NS ogre IN NS вторичный_сервер_провайдера.Раз у нас есть вторичный сервер, да к тому же провайдер обещал держать у себя на сервере копию нашего сервера, надо авторизовать их тоже.
IN MX 10 troll IN MX 20 почтовый_шлюз_провайдера.Здесь описаны почтовые шлюзы в порядке возрастания "удаленности" от пункта назначения. Почтовые серверы, имеющие почту для наших машин, пытаются послать ее непосредственно по адресу назначения; если это не удается, они пытаются послать ее самому близкому к пункту назначения шлюзу, при неудаче - следующему и так далее до исчерпания списка. Это касается только адреса фирма.домен, но не относится к машинам зоны (см.ниже).
localhost IN A 127.0.0.1Каждая машина, обратившаяся по адресу localhost или localhost.зона, должна получить номер 127.0.0.1.
* IN MX 10 troll IN MX 20 почтовый_шлюз_провайдера.Для всех машин данной зоны установить почтовые шлюзы (те же, что и для самОй зоны).
troll IN A 192.168.1.1 IN HINFO "486DX2-66" "FreeBSD" ns IN CNAME troll mail IN CNAME troll
ogre IN A 192.168.1.2 IN HINFO "Pentium" "Linux" nss IN CNAME troll www IN CNAME ns.misa.ac.ru. ftp IN CNAME ns.misa.ac.ru. goblin IN A 172.16.21.114В общем-то все то же самое, что и для troll.
группа IN MX 5 dwarf.группа IN MX 10 troll IN MX 20 почтовый_шлюз_провайдера. *.группа IN MX 5 dwarf.группа IN MX 10 troll IN MX 20 почтовый_шлюз_провайдера.На всякий случай отдельно зафиксируем почтовые шлюзы как для самой группы, так и для всех ее машин.
localhost.группа IN A 127.0.0.1 elf.группа IN A 192.168.1.11 dwarf.группа IN A 192.168.1.12Обычные записи для машин группы. Можно сделать им HINFO или добавить псевдонимы, но и так сойдет.
отдел IN NS 192.168.1.21. ; и, если есть, вторичные Name-серверыТак как отдел имеет свой Name-сервер, нужно только авторизовать его, причем по номеру; а дальше он сам должен отвечать за записи своей зоны.
И напоследок - красивый фокус:
altavista IN CNAME altavista.digital.com yahoo IN CNAME www.yahoo.comЭто позволяет моим юзерам обращаться к самым известным поисковым машинам, не набирая www. в начале и .com в конце! Однако, когда я пытался обращаться к этим машинам через Proxy-сервер провайдера, тот обратился к своей зоне DNS и сказал: "Не знаю имени yahoo.провайдер! Впрочем, полное имя www.yahoo.com продолжало нормально функционировать. Есть еще одна особенность такой конфигурации: машина yahoo.фирма.домен находится в нашей зоне, поэтому некоторые программы, кэширующие обращения к WWW, могут решить, что ее кэшировать не надо.
@ IN SOA troll.фирма.домен. ответственный_за_зону. ( 19970315 ; Serial 3600 ; Refresh 300 ; Retry 3600000 ; Expire 3600 ; Minimum )Тут даже думать не надо.
1 IN PTR troll.фирма.домен. 2 IN PTR ogre.фирма.домен. 11 IN PTR dwarf.группа.фирма.домен. 12 IN PTR elf.группа.фирма.домен. ; и так далееЭтот файл содержит преобразования IP-адресов в доменные имена. Многие программы вообще отказываются работать с машинами, чей IP-адрес не прописан в обратной (reverce) зоне, видимо, считая, что этот адрес кем-то присвоен самовольно, без санкции ответственного администратора.
Для тестирования правильности построения зоны используется программа nslookup. Она сообщает IP-адрес по доменному имени, а при запуске без параметров она переходит в командный режим, где проявляет все свои незаурядные качества - читай `man nslookup`.