Начнём с DNS.
У меня стоит отдельный роутер и разумеется внутри сети используются так называемые серые ip-адреса. Когда компов мало, можно ходить на них по ip, но я админ ленивый, а потому стараюсь всегда упростить себе жизнь. Ещё один минус связи исключительно по ip-адресам - скрипты. Ну, например, укажу я монтирование удалённого диска в скрипте по ip-адресу, а через пару месяцев захочется мне этот ip сменить(мало ли чего, всякое бывает). Придётся в скрипте править. А если таких скриптов много? Возникает проблема. Чтобы такого не было, лучше настроить связь между компами по именам, тогда при смене ip одного из компов, будет достаточно лишь поправить запись в DNS.
Немного скучной истории. Изначально, когда интернет был маленький, а количество компов в сети исчислялось едва ли сотнями, а не как сейчас миллионами, соответсвие имя-адрес просто записывалось в файл /etc/hosts, которым и обменивались все компьютеры. В этом файле должны были содержаться записи для всех имеющихся в сети компов. С разрастанием интернета и увеличением количества участников сети, файл это стал неимоверно разбухать. Да и обмен становился проблематичным - в одном месте кто-то добавил адрес, в другом, кто-то добавил другой, получается в сети ходят уже две версии файла, которые надо объединять. Сначала пытались распространять его централизовано, а потом поняли, что так дальше не пойдёт и была придумана нынешняя система доменных имён.
В славном американском университете Беркли(давшем нам много хорошего, среди прочего ОС FreeBSD) разработали новую систему обмена информацией о именах компьютеров и написали сервер BIND(Berkeley Internet Name Domain). Суть заключается в том, что теперь специальный сервер хранит соответствия имён и адресов в свое базе, следит за обновлениями и по мере надобности отдаёт эту информацию приложениям. Помимо этого, демон named(основная часть сервера BIND) отвечает на запросы удалённо, благодаря чему, нет надобности держать копию базы имён на каждом компе - достаточно одного сервера для работы, например, сети организации. Ну или в моём случае домашней сети.
На данный момент для поддержки DNS(Domain Name System) в мире существует 13 корневых DNS-серверов, несколько зеркал каждого из них и бесчисленное множество кеширующих/авторитетных и других серверов, разбросанных по всему миру.
Помимо BIND существуют другие реализации сервера доменных имён, но BIND считается стандартом де-факто. В замечательной книге "Руководство администратора Linux", например, приводится такая таблица:
Таблица 15.1. Некоторые популярные реализации DNS
| Название | Автор | Источник | Комментарии |
| BIND | ISC | isc.org | Авторитетная и кеширующая |
| NSD | NLnet Labs | www.nlnetlabs.nl | Только авторитетная |
| PowerDNS | PowerDNS BV | www.powerdns.com | Только авторитетная |
| djbdns(tinydns) | Dan Gernstein | tunydns.org | Не согласована с некоторыми документами RFC |
| Microsoft DNS | Microsoft | microsoft.com | Виновата в неисчислимых грехах |
| ANS, CNS | Nominum | www.nominum.com | Авторитетная и кеширующая |
Я решил не уходить далеко от стандартов и воспользоваться BIND.
Итак, что нужно. Установить bind.
У меня сервер на debian, поэтому действуем стандартно:
apt-get install bind9Стандартное расположение конфигов Debian мне в данном случае не очень нравится, поэтому я полностью переписал свой named.conf. Да, понимаю, что не православно, но привычка сильнее меня.
Итак, конфиг:
// This is the primary configuration file for the BIND DNS server named.
//
acl localnet {
10.0.0.0/24;
127.0.0.1/32;
};
options {
directory "/var/cache/bind";
version "root@cppmm.net.ru";
auth-nxdomain no; # conform to RFC1035
// На каких адресах слушать.
listen-on {
10.0.0.11;
127.0.0.1;
109.124.35.175;
};
// allow-query {
// localnet;
// };
};
// Описание настроек для "себя"
view "local" {
// Те, кому отдаются данные из описанного ниже.
match-clients {
localnet;
};
recursion yes;
// Стандартные зоны
zone "." {
type hint;
file "/etc/bind/all_db/db.root";
};
zone "localhost" {
type master;
file "/etc/bind/all_db/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/all_db/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/all_db/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/all_db/db.255";
};
// Моя зона для внутреннего доступа
zone "cppmm.net.ru" IN {
type master;
file "/etc/bind/local/db.cppmm.net.ru";
};
};
// Описание настроек для "мира"
view "inter" {
match-clients {
any;
};
recursion no;
// зона для которой мой мастер является мастером.
zone "cppmm.net.ru" IN {
type master;
file "/etc/bind/inter/db.cppmm.net.ru";
allow-transfer {
// здесь перечислены серверы, которые являются слейвом для моей зоны
22.33.44.55;
33.44.55.66;
};
};
// Зона, для которой мой сервер является слейвом, т.е.
zone "sitename.ru" {
type slave;
file "/etc/bind/inter/db.sitename.ru";
masters {
11.22.33.44;
};
};
// Ещё одна зона, для которой мой сервер является слейвом, но уже в домене .рф
zone "XN--H1AEBJVHAXXD5A.XN--P1AI" {
type slave;
file "/etc/bind/inter/db.XN--H1AEBJVHAXXD5A.XN--P1AI";
masters {
11.22.33.44;
};
};
// Далее идут описаний других зон, для которых мой сервер является слейвом.
};
Ну, стандартные настройки - на каком порту слушать, кому отвечать и прочее - это, я думаю и так понятно. Самое интересное в данной конфигурации - это view - представления для разных клиентов. Проще говоря, в зависимости от того, кто именно спрашивает, я отдаю разные данные. Таким образом, весь мир получает информацию о моём домене с реальным ip-адресом, а мои домашние компьютеры ходят друг к другу по именам в сетке с серыми ip(ниже покажу файл зоны).
Отдельно поясню по поводу мастеров и слейвов. По RFC за каждую доменную зону в интернете должно отвечать минимум два сервера - мастер и слейв. На мастере собственно находятся данные о домене, а слейв просто дублирует их, забирая периодически у мастера базу зоны. Сделано так для отказоустойчивости. Если один сервер по каким-либо причинам выпадет из сети, второй будет отдавать информацию. Причём по RFC серверы должны быть в разных ip-сетях, а лучше далеко друг от друга физически. Поэтому мы с друзьями-админами и помогаем друг-другу - они ставят свои серверы слейвом к моей зоне, а я свой настраиваю для поддержки их зон. Кстати, для примера я оставил запись для новых доменов в .рф. Вот так в действительности выглядит то, что потом трансформируется в кириллицу(запись из конфига не резолвится, потому что я не знаю, хочет ли хозяин домена, чтобы домен распиарили или нет; я исправил там несколько символов на случайные). Костыль знатный.
Теперь о файлах зоны. Как видно, в самом конфиге никаких соответствий имя-адрес нет. Есть только описания зон и ссылки на соответствующие файлы. Итак, зона cppmm.net.ru для мира:
;
; BIND reverse data file for broadcast zone
;
$TTL 20m
$ORIGIN net.ru.
cppmm 3600 SOA ns1.cppmm.net.ru. hostmater.cppmm.net.ru. (
2010111500
7200
1800
604800
7200 )
3600 NS ns1.cppmm.net.ru.
3600 NS ns2.someserver.org.
3600 MX 10 mail.cppmm.net.ru.
3600 A 109.124.35.175
$ORIGIN cppmm.net.ru.
mail A 109.124.35.175
ns1 A 109.124.35.175
redmine A 109.124.35.175
www A 109.124.35.175
Некоторые пояснения. Все строки, начинающиеся с точки с запятой - это комментарии.
$TTL - время жизни данных в кеше для кеширующих DNS-серверов. Стоит 20 минут - примерно стандарт. Больше часа ставить обычно не рекомендуют. А чаще всего эту опцию вообще не используют, так как настройки кеширующих dns-серверов обычно это значение перебивают своим.
$ORIGIN - это "старшая" зона. Например, для linux.org старшая зона - org.
Далее непосредственно описание домена.
ns1.cppmm.net.ru. - это имя мастер-сервера для этой зоны.
hostmater.cppmm.net.ru. - это адрес администратора зоны. Первая точка при запросе заменяется на @, таким образом получается e-mail администратора: hostmaster@cppmm.net.ru
Особо стоит обратить внимание на ключик 2010111500. Это значение последнего изменения файла зоны. Слейв-сервер при запросе в первую очередь смотрит на него. Если оно равно хранящемуся в его базе, то зона повторно не стягивается. Если же значение стало больше, зона обновляется. Создано это для того, чтобы серверы зря не гоняли постоянно файлы зон, нагружая при этом сеть.
Записи NS - это мастер и слейв-dns, обслуживающие зону. Запись MX - это почтовый сервер для этой зоны(цифра 10, перед ним означает приоритет - можно выставить несколько почтовых серверов и назначить им разные приоритеты, тогда, если главный почтовый сервер с наивысшим приоритетом выйдет из строя, почта будет доставлено на запасной).
Ну а в самом низу идёт непосредственно список имён этой зоны и ip-адресов, в которые они резолвятся(так называемые A-записи).
Вот и всё. Но такая настройка хороша для внешнего мира, а для внутренней сети всё несколько иначе. Итак, вот описание этой же зоны cppmm.net.ru, но для локальной сети:
;
; BIND reverse data file for broadcast zone
;
$TTL 20m
$ORIGIN net.ru.
cppmm 3600 SOA ns1.cppmm.net.ru. hostmater.cppmm.net.ru. (
2010110901
7200
1800
604800
7200 )
3600 NS ns1.cppmm.net.ru.
3600 MX 10 mail.cppmm.net.ru.
3600 A 10.0.0.11
$ORIGIN cppmm.net.ru.
damned A 10.0.0.10
mail A 10.0.0.11
moonchild A 10.0.0.11
ns1 A 10.0.0.11
redmine A 10.0.0.11
skynet A 10.0.0.12
vault13 A 10.0.0.1
www A 10.0.0.11
frontier A 10.0.0.13
Всё очень похоже. Только для локлаьной сети мне не нужен слейв. Ну и разумеется, все адреса серые. В итоге сам сервер доступен по адресу 10.0.0.11 и имени moonchild.cppmm.net.ru
Основной комп:
10.0.0.10 - damned.cppmm.net.ru
Ещё один комп:
10.0.0.13 - frontier.cppmm.net.ru
Ноут:
10.0.0.12 - skynet.cppmm.net.ru
Wi-fi-роутер:
10.0.0.1 - vault13.cppmm.net.ru
Плюс к этому, как можно заметить, некоторым ip-адресам присвоено несколько имён(на внешней зоне тоже). Удобно.
Изначально я хотел сделать короткие имена, без домена, но потом отказался от этой идеи, потому как в своей сетке я часто провожу разнообразные опыты и короткие имена мне будут мешать. Как-нибудь объясню, почему. Возможно, в одной из следующих статей цикла.
А по поводу настройки DNS - это всё.
Больше информации можно найти в документации к серверу BIND9 и в книгах:
Руководство администратора Linux
Linux. Руководство администратора сети
DNS и BIND
Подскажите, если почта на домене не нужна, можно ли вообще не указывать MX-запись?
ОтветитьУдалитьЧем-нибудь это будет чревато?
Раз не нужна, можно и не указывать. Никаких проблем быть не должно.
ОтветитьУдалить