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

В файл /etc/rc.conf добавляем строку запускающую наш сервер доменных имен:
named_enable=”YES”
Открываем наш файл, отвечающий за локальных резолв /etc/resolv.conf и меняем его содержимое (вероятнее всего там стоит провайдерские DNS), на следующие строки, содержащие ваши домены:
domain  your-domain.ru
search host.your-domain.ru your-domain.ru
nameserver 127.0.0.1
для того чтобы сделать поиск доменных имен по кешу локального сервера.
Проверяем в файле /etc/nsswitch.conf наличие записи
hosts:      files dns
говорящей о том, что при резолве имен сначала будет использоваться информация содержащаяся в файле /etc/hosts, а затем запрашивать у доменных серверов, в соответствии с описанием в файле /etc/resolv.conf
После этого в файл /etc/host.conf добавляем строку
order hosts,bind
которая разрешает ту же последовательность, что и в файле /etc/nsswitch.conf
После этого переходим к настройке основного файла конфигурации любого доменного сервера, а не только кеширующего: /etc/namedb/named.conf. Для начала добавляем и раскомментируем следующие опции, идущие списком после директивы options {
Каждая строка, а также перечисление например IP адресов, должно закрываться символом точки с запятой “;”
Определяем на каких интерфейсах слушать входящие пакеты:
listen-on       { 127.0.0.1; 192.168.0.1; 172.16.0.1; };
Данную строку следует прописывать, если возникают какие то проблемы с фаерволом:
query-source address * port 53;
Также если охота поиграться с безопасностью, то можно озвучить сети, из которых разрешены запросы (сети определяем перед директивой options), а также отрубить фингерпринт и включить обработчик рекурсивных запросов:
acl “our_lanz” { 192.168.0.0/24; };
options {
directory “/etc/namedb”;
allow-recursion { “our_lanz”; };
allow-query {“our_lanz”; };
version “unknown”;
fake-iquery no;
};
Добавляем директивы запросов к DNS провайдера, для того чтобы дергать запросы из них и тем самым облегчить работу сетки:
forwarders {
NS_IP1; NS_IP2;
};
forward first;
На этом в принципе можно и остановиться, ибо все должно уже начать шуршать, после перезапуска сервера доменных имен, но для того чтобы произвести классические действия- идет в описание доменных зон и добавляем локальные зоны:
zone “.” {
type hint;
file “named.root”;
};
zone “0.0.127.in-addr.arpa” {
type master;
file “master/127.0.0″;
};
Надо отметить, что все эти файлы указываются от корневой директории named.conf, так что создаем упомянутый файл /etc/named/master/127.0.0
@               IN      SOA     host.your-domain.ru. hostmaster.your-domain.ru. (
1       ; Serial
8H      ; Refresh
2H      ; Retry
1W      ; Expire
1D)     ; Minimum TTL
NS      host.your-domain.ru.
1                       PTR     localhost.
и проверяем что файл /etc/named/named.root содержит информацию о корневых доменных серверах, в нем на самом деле много инфы, вроде подобного:
.                        3600000  IN  NS    A.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.      3600000      A     198.41.0.4
A.ROOT-SERVERS.NET.      3600000      AAAA  2001:503:BA3E::2:30
;
Теперь радостно перезапускаем наш сервер доменных имен, и можем спокойно тестить или заниматься другими делами.
Тестится естественно через терзания nslookup’a:
# nslookup
Default server: 127.0.0.1
Address: 127.0.0.1#53
> odminblog.ru
Server:         127.0.0.1
Address:        127.0.0.1#53
Non-authoritative answer:
Name:   odminblog.ru
Address: 174.120.3.60

Как видно из Non-authoritative answer сервер берет эти данные из кеша, о чем нас и предупреждает этой надписью.

Согласуясь с вышесказанным запись в 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-записи для корневого домена, что было довольно неожиданно, ибо вся остальная зона отдавалась замечательно.

Но в версии 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

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

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

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

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

https://secure.domaintools.com

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

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

Немного воды:

Для задачи поддержки обратной зоны существует специальный домен IN-ADDR.ARPA. Сам файл описания зоны домена обратного просмотра состоит преимущественно из записей PTR типа “Pointer”.

[name][ttl] IN PTR [host]

то есть для сервера ns.server.ru c IP= A.B.C.D запись будет следующего вида

$ORIGIN C.B.A.in-addr.arpa.
D PTR ns.server.ru.

или же

123.46.181.62.in-addr.arpa. IN PTR ns.server.ru.

просмотреть информацию об имеющейся реверсивной записи можно командой:

# dig -x A.B.C.D

там же, кстати, можно увидеть и того, кто является ответственным за поддержку пула адресов. Также посмотреть ситуацию по по PTR в том числе можно на сайте http://www.squish.net/dnscheck
Опять же информация по ответственному за пул адресов можно получить командой:
# whois IP

Основной вывод:

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

Например для сети провайдера 172.16.10.0/24, разбитой на подсети 172.16.10.0/25 ; 172.16.10.128/26 ; 172.16.10.192/26 это будет выглядеть так:

############################################
$ORIGIN 10.16.172.in-addr.arpa.
@ IN SOA ns.provider.ru. dnsmaster.provider.ru. (…)
;
; пулл 0-127 /25
;
0/25 IN NS ns.a.ru.
0/25 IN NS ns.a-slave.ru.
;
1 IN CNAME 1.0/25.10.16.172.in-addr.arpa.
2 IN CNAME 2.0/25.10.16.172.in-addr.arpa.
;
; пулл 129-191 /26
;
128/26 IN NS ns.b.ru.
128/26 IN NS ns.b-slave.ru.
;
129 IN CNAME 129.128/26.10.16.172.in-addr.arpa.
130 IN CNAME 130.128/26.10.16.172.in-addr.arpa.
;
; пулл 193-255 /26
;
192/26 IN NS ns.c.ru.
192/26 IN NS ns.c-slave.ru.
;
193 IN CNAME 193.192/26.10.16.172.in-addr.arpa.
194 IN CNAME 194.192/26.10.16.172.in-addr.arpa.
############################################

Сама же организация обязана вести на своем NS сервере запись вида

############################################
$ORIGIN 0/25.10.16.172.in-addr.arpa.
@ IN SOA ns.a.ru dnamaster.a.ru (…)
IN NS ns.a.ru.
IN NS ns.slave.ru.
;
1 IN PTR host1.a.ru.
2 IN PTR host2.a.ru.
3 IN PTR host3.a.ru.
############################################

Для двух других блоков адресов SOA записи будут соответственно:
$ORIGIN 128/26.10.16.172.in-addr.arpa.
@ IN SOA ns.b.ru dnamaster.b.ru (…)

$ORIGIN 192/26.10.16.172.in-addr.arpa.
@ IN SOA ns.c.ru dnamaster.c.ru (…)

*** По мотивам двухчасового разговора по аське с гуру piv_m

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

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

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

Само сообщение дефейса гласило:

Iranian Cyber Army

THIS SITE HAS BEEN HACKED BY IRANIAN CYBER ARMY

iRANiAN.CYBER.ARMY@GMAIL.COM

U.S.A. Think They Controlling And Managing Internet By Their Access, But THey Don’t, We Control And Manage Internet By Our Power, So Do Not Try To Stimulation Iranian Peoples To….

NOW WHICH COUNTRY IN EMBARGO LIST? IRAN? USA?
WE PUSH THEM IN EMBARGO LIST
Take Care.

На картинке внизу, полученной через сервис PassiveDNS видно, что атака представляла из себя форвард на сторонний IP адрес.  Под раздачу также попало несколько других доменов, не имевших отношения к twitter: www.mowjcamp.org /  net  принадлежащие штатовскому реселлеру OVERSEE и домен wpcrowd.com.

Надо отметить что это уже не первая атака которой подвергается Twitter, т.к. ранее он неоднократно становился целью кибер преступников, а буквально пару месяцев назад была предпринята попытка переконфигурировать их веб сайт.
Быть популярным, значит быть на виду. А быть на виду, значит быть на прицеле

DNS TTL это параметр по аналогии с параметром жизни сетевого пакета (Time To Live) отвечающий за существование записи DNS зоны в кеше DNS сервера, без дополнительных изменений.  По достижении установленного времени, кеширующий сервер запрашивает DNS сервер, содержащий доменную зону, информацию о зоне.
В стандартной настройке $TTL равно 86400 секунды, т.ч. если минимальный параметр TTL на вашем доменном сервере DNS и кэширующем сервере удаленного хоста установлен по умолчанию в значение 86400, то обновление произойдет на сервере через день.

Типичная SOA запись выглядит таким образом:
$TTL    3600

@       IN      SOA     ns.domain.com. abuse.ns.domain.com.  (
2009120200      ; Serial
3600                       ; Refresh
900                          ; Retry
3600000              ; Expire
3600 )                    ; Minimum

Перед запланированными процедурами, первую строку SOA записи следует изменить на значение $TTL    600 , или меньше, после чего изменить serial number и перегрузить зоны, т.е. рестартовать DNS сервер и спокойно идти за чаем в ожидании истечения времени указанного для TTL первоначально. После того как эти данные обновятся, что можно проверить с помощью команды dig, можно начинать производить необходимые процедуры по миграции серверов. Изменение IP адресов произойдет в течении указанного времени.

После того как все процедуры по переезду и миграции будут произведены, значение  TTL можно перевести в большее значение с тем, чтобы снизить нагрузку на DNS сервер и избежать слишком большого сетевого трафика при обновлении зон.