Вирус меняет настройки DNS на 127.0.0.1

Wednesday, 20 Jun 2012

Напоролся на тут на интересный вирус, который не встречал еще до этого. Собственно познакомился с ним на стадии того, что клиент, вернувшись из командировки, не смог войти с ноута в инет, так что пришлось подъехать посмотреть.

Машинка Windows 7, стоит NOd32, но Comodo я ему ставить не стал, так как оперативки на ноуте маловато. В инет он оказывается входил, ибо скайп подключался, но вот с бродилкой были какие то проблемы. Глянул ipconfig /all , так и есть – DNS почему то стоит 127.0.0.1 . Зашел в настройки сетки- действительно прописан руками.

Человек естественно клялся и божился, что ничего не трогал, но мы то этих клиентов знаем. :) В итоге сменил на автоматическую выдачу DNS, перегрузил- все работает. Ну и забыл.

(more…)

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

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

Friday, 19 Aug 2011

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

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

(more…)

VN:F [1.9.21_1169]
Rating: 8.2/10 (5 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: 7.3/10 (3 votes 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)