Настройка кеширующего DNS сервера на базе BIND

Friday, 19 Aug 2011

Думаю что не надо лишний раз лить воду на жернов копирайта пустословия, относительно того что для жизни сетей и Интернета в частности, сервера доменных имен являются краеугольной тематикой. Ибо без их существования все доменные имена, типо мойкрутойдомен.ком были бы пустыми словами. И для того, чтобы выходить из любой сети в интернет, нам необходимо использовать DNS сервер для разрешения доменных имен в IP адреса.  Но в данном случае нам хватит, так называемого кеширующего сервера имен, то есть отвечающего только за разрешение имен и не содержащего описаний доменных зон.

С помощью стандартного сервера доменных имен BIND, настроить такой сервер, на базе любой *nix системы, можно за считанные минуты, но при этом необходимо выполнить некоторое количество телодвижений, которые я и перечислю ниже.

(more…)

VN:F [1.9.21_1169]
Rating: 10.0/10 (4 votes cast)
VN:F [1.9.21_1169]
Rating: +3 (from 3 votes)

Делегируем управление субдоменом

Monday, 07 Jun 2010

Возникла необходимость делегировать управление доменной зоной третьего уровня (то есть например newdomain.odminblog.ru) серверам доменных имен хостера. Первое что пришло в голову, это создать зону в named.conf где указать что данный сервер является вторичным и первичным обозначить доменный сервер хостинг провайдера.

Согласуясь с вышесказанным запись в named.conf приобретает следующий вид:

############################################
zone “newdomain.odminblog.ru” {
type slave;
file “slave/newdomain.odminblog.ru”;
masters {
DNS-провайдера;
};
############################################

Но данный вариант по мне не корректен, так что пришлось пойти в изысканиях дальше.  Поковырявшись в доках, мануалах и описаниях на сайте RU-CENTER пришел к тому, что управление зоной можно делегировать в файле описания зоны, подобно тому как это делает провайдер при делегировании PTR записи. Для этого необходимо описать DNS сервера отвечающие за данный субдомен, в разделе определения серверов доменных имен, причем их имена должны принадлежать к субдомену.

newdomain    IN    NS    ns1.newdomain.odminblog.ru
newdomain    IN    NS    ns2.newdomain.odminblog.ru

После чего, через канонический тип имени CNAME определяем доменные сервера провайдера

ns1.newdomain  CNAME  ns1.DNC-провайдера.
ns2.newdomain  CNAME  ns2.DNC-провайдера.

В таком варианте все должно нормально работать. При тестировании попробовал описать DNS сервера провайдера сразу в описании NS для субдомена, используя их хостнеймы, но после такого финта, по непонятной причине отвалились MX-записи для корневого домена, что было довольно неожиданно, ибо вся остальная зона отдавалась замечательно.

VN:F [1.9.21_1169]
Rating: 7.5/10 (2 votes cast)
VN:F [1.9.21_1169]
Rating: +1 (from 1 vote)

Ускоряем разрешение доменных имен через resolve.conf

Wednesday, 12 May 2010

Системный файл /etc/resolv.conf является файлом конфигурации процедур сервера доменных имен. В этом файле хранится информация об используемых DNS серверах, и этот файл перечитывается при вызове процедуры разрешения имен. В файл можно поместить информацию о трех DNS серверах, причем алгорит действия будет таким, что запрос всегда уходит на стоящий первым в списке сервер. В случае если он не отвечает в течении некоторого времени (по умолчанию 5 секунд), то запрос отправляется на вторичный сервер DNS, если он не отвечает, то запрос переходит к третичному серверу DNS. То есть по умолчанию система всегда использует первый из списка сервер, и обращается ко второму и третьему только в случае, если первичный сервер не отвечает.

Но в версии BIND 8.2 были добавлено некоторое количество новых опций, с помощью которых мы можем несколько ускорить работу разрешения доменных имен для нашего сервера:

Опиция timeout позволяет задавать время таймаута для присутствия в очереди запросов. По умолчанию этот параметр равен 5 секундам (максимально 30), так что если мы хотим ускорить отработку запроса, то выставляем этот параметр например на 2 секунды:
options timeout:2

Опция rotate позволяет использовать из списка доменных серверов все адреса, а не только первый, который может быть перегружен многочисленными запросами. Причем вторичный и третичный сервера используются только в случае отказа в обслуживании первого сервера. Поэтому с помощью этой опции мы можем разгрузить первичный сервер и отправить часть запросов на остальные сервера, указанные в resolve.conf
options rotate

Единственно что следует помнить о том что мы используем эту опцию, ибо в случае отладки, например почтового демона, мы никогда не будем знать какой из доменных серверов дал нам ответ на наш запрос. Еще один момент заключается в том, что данная опция будет полезна не всем программам, ибо часть из них, например ping, одноразово инициализирует резолвер и после разрешения имени выходит. Тогда как почтовые демоны, отправляющие многочисленные запросы разрешения доменных имен, будут использовать этот функционал.

Опираясь на все вышесказанное, resolve.conf  будет иметь следующий вид:

nameserver 1.1.1.1
nameserver 2.2.2.2
nameserver 3.3.3.3
option rotate
option timeout:2

VN:F [1.9.21_1169]
Rating: 10.0/10 (4 votes cast)
VN:F [1.9.21_1169]
Rating: +2 (from 2 votes)

Обнуление кэша сервера named

Thursday, 25 Feb 2010

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

Само время устаревания кэша зоны задается администратором домена, при составлении SOA-записи, поэтому по умолчанию кэш обновляется по истечению времени устаревания. Но тем не менее существует возможность обнулить кэш DNS сервера полностью, или только для заданного домена. Сделать это возможно с помощью утилиты управления демоном named называемой rndc.

Обнулить полностью кэш DNS сервера
# rndc flush

Обнулить кэш DNS для определенного домена под именем odminblog.ru
# rndc flushname odminblog.ru

VN:F [1.9.21_1169]
Rating: 7.5/10 (2 votes cast)
VN:F [1.9.21_1169]
Rating: 0 (from 0 votes)

Список всех доменов относящихся к IP адресу

Tuesday, 02 Feb 2010

Неоднократно сталкивался в интернете с крайне удобными сервисами, аналогами resolve IP, только идущими гораздо дальше, то есть на заданный IP адрес они выдают не официальную PTR запись, а все доменные имена, привязанные к заданному IP адресу.  Примеры этих сервисов можно взглянуть на нижеприведенных серверах:

http://www.yougetsignal.com/tools/web-sites-on-web-server/

https://secure.domaintools.com

http://www.ip-adress.com/reverse_ip/

Но более интересный вопрос, как эти сервисы работают?
Понимаю, что это какой то скрипт, но ламбадой буду, то что он работает на базе стандартных dig и resolveip, с вкраплениями whois.  Но как их выстроить в правильный конвейер пока ума не приложу.

VN:F [1.9.21_1169]
Rating: 9.0/10 (1 vote cast)
VN:F [1.9.21_1169]
Rating: 0 (from 0 votes)

PTR запись зоны обратного просмотра

Saturday, 26 Dec 2009

Вторую неделю воюю с замечательным провайдером Горком на предмет поддержки ими зоны обратного просмотра, она же реверсивная зона. Точнее внесения в неё моего MX сервера, поскольку при отправке почты на удаленные сервера, многие почтари проверяют наличие у сайта PTR записи как таковой и в случае её отсутствия, расценивают отправителя как спамера.  Хитрованы же из Горкома убеждают меня в том, что это должен делать я сам и вообще письма от меня не доходят вовсе не из-за реверса упоминаемого в коде ошибки, а потому что у меня дескать не правильно настроен ns сервер.

(more…)

VN:F [1.9.21_1169]
Rating: 6.0/10 (8 votes cast)
VN:F [1.9.21_1169]
Rating: 0 (from 0 votes)

Баг прошивки 8.0.42 для Sofaware 500W

Tuesday, 22 Dec 2009

Прекрасную новость я получил буквально пару минут назад от компании Sofaware, куда я обратился со своей “болью”: после того как устройство Sofaware 500W само, без разрешения, грейдилось на последнюю версию прошивки 8.0.42- сразу же начинались траблы с работоспособностью- по дефолтной политике дропались входящие UDP пакеты на 53 порт, даже в случае наличия правила разрешающего это действие; пропадал доступ к веб морде из вне сетки по https; и самое пакостное- после перевода wi-fi и Lan VLAN’ов в режим bridge, для того чтобы пользователи этих двух сетей могли работать друг с другом и внутренними ресурсами (хотя по причине этого косяка, выяснилось что все это реализуется и при обычном режиме firewall просто описанием взаимодействия подсетей)- начинались проблемы с доступам к внутренним ресурсам, транслируемым в интернет, по их внешним IP адресам, причем настолько сильные, что все соединения smtp/pop3/http/https/ssh дропались по таймауту.

Вообщем ответ тех.поддержки был, что shit happend- сие есть баг (баг заключается в том, что дропаются те пакеты у которых исходящий порт такой же как и входящий- 53; если же порт стандартно выше 1024 порта, то они проходят нормально), посему надо откатить устройство на более раннюю версию прошивки, но как оказывается сам я это сделать не могу, а это указывается ручками на стороне сервис центра производителя SMP, где оператор ручками указывает какому MAC адресу на какую прошивку перегрузиться. Но самое веселое, что это уже сделали, попросив меня ручками передернуть устройство. И мало кого волнует, что я в 50 километрах от устройства и самое близкое когда собирался туда заехать – это конец недели.

Все это очень мило, но тогда не понятно зачем там вообще в устройстве кнопка перепрошить устройство на специфическую прошивку. Надеюсь, что 7 прошивка, которую мне сегодня перезальют будет лучше чем 8.0.42, поскольку баг, со слов поддержки, будет исправлен не столь оперативно, как решаются проблемы для тех же Checkpoint Edge, которые являются клонами sofaware с той лишь разницей, что управляться могут централизованно и поддерживаются старшим братом.

*** 23.12.09 *** Баг после отката не исчез, по прежнему дропаются входящие и исходящего 53 порта, но зато разрешилась проблема с доступом по https к консоли. Оказалось, что сервер https, для внешних подключений, переехал со своего стандартного порта на 981, т.к. обращение https://server:981 позволяет достучаться к серверу из вне.

VN:F [1.9.21_1169]
Rating: 10.0/10 (1 vote cast)
VN:F [1.9.21_1169]
Rating: 0 (from 2 votes)