Новые возможности сервера DNS в Windows Server

Новые возможности сервера DNS в Windows Server

С выходом Windows Server Technical Preview 2 многие службы получили обновления. Не обошли обновления стороной и заслуженный сервер имен DNS. Помимо поддержки управления DNS-сервером из PowerShell, появилась новая возможность – DNS policy.

DNS policy – это расширение DNS-сервера для адаптации его работы в зависимости от содержания приходящих запросов. Благодаря первоочередному применению политик на поступивший запрос, можно существенно облегчить работу сервера, отсеяв заведомо ненужные запросы, либо указав серверу, изменить содержание ответа в соответствии с описанными правилами.

Внесение изменений в файл host

Проверка в Windows

Достаточно запустить Блокнот (как администратор — пункт 1 на скриншоте), и открыть C:WindowsSystem32driversetchosts .

Далее в конец файла добавьте список, который мы вам прислали в тикет в Личном кабинете и на почту. Он будет выглядеть примерно так, как показано на скриншоте. Не забудьте удалить добавленные строки, когда закончите проверку.

Проверка в Linux/MacOS

Потребуется терминал — стандартное приложение.

В Linux оно запускается Ctrl+Alt+T . Редактируем файл любимым текстовым редактором (например, Vim, Nano, Gedit ) с опцией sudo :

Добавляем желаемый IP-адрес и домен, либо список, который мы прислали. Закончив проверку, уберите добавленные строки из этого файла.

На MacOS процесс идентичен. Находим через Spotlight (иконка поиска в правом верхнем углу экрана) приложение Терминал, и выполняем аналогичные действия, как в Linux.

Проверка файла host

Когда изменения в файл hosts внесены, нужно проверить применились ли они. Для этого достаточно выполнить ping до домена. На Windows, Linux и MacOS это происходит одинаково, открываем консоль и выполняем команду: ping ВАШ_ДОМЕН.RU

В выводе команды вы должны увидеть IP нового сервера. Также проверить можно через расширения для браузеров, которые будут отображать с какого IP открывается сайт. Например, Website IP для Chrome и Яндекс.Браузера, или Server IP для Firefox и Opera. В углу экрана будет отображаться текущий адрес:

Инструкции по изменению NS для конкретных регистраторов

1. Авторизуйтесь на сайте nic.ua и зайдите в личный кабинет.

2. В личном кабинете перейдите в раздел «Домены» и нажмите на шестерёнку.

3. В разделе «NS-серверы» из выпадающего меню выберите «Собственные серверы имен». Заполните список серверов имен: ns1.1dedic.ru и ns2.1dedic.ru .

Для того, чтобы увидеть изменения в браузере, необходимо подождать какое-то время. Обычно распространение изменений в интернете занимает от 4 до 72 часов.

1. Авторизуйтесь на сайте REG.RU и перейдите в раздел «Домены».

2. Кликните по имени домена, для которого необходимо внести изменения, и в настройках выберите «DNS-серверы».

3. Во вкладке «Управление» кликните по кнопке «Изменить».

4. Во всплывающем меню выберите «Свой список DNS-серверов».

5. Пропишите необходимые DNS-серверы ns1.1dedic.ru и ns2.1dedic.ru . Для сохранения изменений нажмите кнопку «Продолжить».

6. Согласитесь с внесением изменений в сервера имен.

После того как вы изменили DNS-серверы для домена, необходимо время, чтобы информация о них распространилась. Обычно обновление DNS-серверов у Reg.ru происходит в течение суток.

1. Авторизуйтесь в панели управления и выберите пункт меню «Домены». Найдите нужный домен и нажмите на него.

2. На открывшейся странице выберите блок «DNS-серверы».

3. В открывшейся форме в разделе своих DNS-серверов укажите нужные серверы имен.

Через несколько минут DNS-серверы для домена будут изменены, однако полное применение настроек может занять до 72 часов.

1. Для того, чтобы сменить DNS-серверы домена, зайдите в аккаунт, где находится домен, и перейдите на страницу «Личный кабинет».

2. В разделе «Мои домены и услуги» нажмите на нужный домен.

3. В разделе «Управление доменом» напротив раздела DNS-серверы нажмите кнопку «Управлять».

4. Заполните NS1 и NS2 адресами ns1.1dedic.ru и ns2.1dedic.ru и нажмите «Изменить».

1. Авторизуйтесь в личном кабинете R01.

2. Зайдите в раздел «Домены».

3. В строке с вашим доменом отметьте галочкой настраиваемый домен, в выпадающем списке действий с доменами выберите «Сменить DNS-сервера», нажмите «Выполнить».

4. Теперь вы можете добавлять/редактировать/удалять записи в конфигурации вашей зоны, поменяйте серверы на ns1.1dedic.ru и ns2.1dedic.ru .

Внесенные через веб-интерфейс изменения применяются в течение 10 минут, полное распространение настроек может занять около суток.

Настройка клиентских машин и устройств

Отмена перехода на летнее/зимнее время на территории РФ

• Для того, чтобы системы Windows не переходили на летнее/зимнее время необходимо установить заплатку: http://support.microsoft.com/kb/2570791
• В SuSE Linux, возможно, необходимо будет обновить пакет timezone до версии 2011n или выше.

Linux

Как посмотреть стратум удаленного сервера:

Проверка работоспособности конфигурации NTP:

Windows 2003

Вся настрока выполняется из командной строки. Последовательность действий следующая:

В ответ должны получить следующее:

Через некоторое время проверяем журнал событий системы. Если все настроено верно, то в журнале будет информационное сообщение от источника W32Time с кодом (ID) 35 и текстом Служба времени выполняет синхронизацию системного времени с источником времени имя_ntp_сервера

Если возникли какие-то проблемы, то в журнал будет записана ошибка с кодом (ID) 29 от источника W32Time и текстом NTP-клиент поставщика времени настроен на получение времени из одного или нескольких источников, однако ни один из этих источников недоступен. Попытки подключения к источнику не будут выполняться в течение ХХ мин. NTP-клиент не имеет источника правильного времени. В таком случае, убедитесь, что файрвол не блокирует соединения с NTP-сервером по протоколу UDP порт 123. Проверьте, что имя NTP-сервера указано верно. Для этого в командной строке выполните

В ответ будет выведено имя сервера NTP.

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

На экран будет выводиться информация о дельте локального времени и времени на имя_компьютера до прерывания работы при помощи Ctrl+C.

Если Ваша сеть с доменами, то клиенты будут автоматически синхронизировать свои часы с контроллером домена. Если Вы не используете в сети доменов, то настраивать клиентов придётся вручную.

Windows 2008

Ubuntu → Настройка DNS-сервера BIND Master & Slave, с автоматической репликацией данных между серверами

В этот раз, я вам расскажу как настроить собственные DNS сервера, с автоматическим переносом зон на подчиненные сервера.
Идея следующая, т.к. для полноценной работы доменного имени требуется как минимум 2 DNS сервера, то один сервер у нас получается главным (Master), а второй, подчиненным (Slave), то принцип работы будет следующий, изменения внесенные на Master сервере, будут автоматический перенесены на Slave сервера.
Для чего это может понадобиться-например для поддержки работы своего доменного имени, или целой кучи сайтов. В принципе, держать, ради одного домена, собственную инфраструктуру NS серверов, наверное не стоит, но если у вас пара десятков сайтов, то повозиться имеет смысл…
Ну а чтобы не создавать «тепличных условий», мы настроим сразу 3 сервера 1-Master и 2 -Salave, как указанно на схеме ниже.

Думаю что из изображенного на схеме понятно что изменения внесенные на главном сервере, будут автоматически переданы на подчерненные сервера, чтобы, в случае выхода из строя одного из серверов, все продолжало работать как надо.
А теперь практика.

Настраиваем Master сервер

Для начала сделаем основные настройки сервера:
Поднимаем права до root

редактируем параметры options:

Сразу под строкой directory "/var/cache/bind"; добавляем

Находим и закомменитуем строку

Рассмотрим подробнее, то что мы написали:
allow-query < any; >; -параметр отвечающий за то- от кого принимать запросы, мы их принимаем от всех.
version «Super DNS server»; -Уровень болтливости сервера, вместо названия сервера выдаст Super DNS server (можно написать что-то свое).
allow-recursion < none; >; — Отключаем использование рекурсивных запросов т.к. это сильно снижает скорость работы, да и нее имеет смысла опрашивать вышестоящие DNS сервера по поводу зоны которую сами же и обслуживаем. Можете ради эксперимента закомментировать эту функцию, и выполнить запрос, разрешение имени идет почти 4 сек, что не позволительно много…

Создадим нашу первую доменную зону.

И добавляем туда:

Сохраняем изменения и выходим.
Давайте разберемся, что мы туда добавили
zone «example.org» IN — собственно, название DNS зоны, которую мы будем обслуживать, тут вы указываете название своего домена (который нужно купить заранее. )
type master; — Тип данного сервера, не буду играть в К.О. это мастер сервер.
file "/var/lib/bind/example.org.db"; -путь к файлу с настройками данной зоны
allow-transfer <192.168.10.60; 192.168.10.70;>; -разрешаем передачу данной зоны на остальные наши DNS сервера.
allow-update <192.168.10.60; 192.168.10.70;>; — разрешаем обновление.
notify yes; -включаем автоматическое уведомление подчиненных серверов об обновлении файла настроек DNS зоны.

Создаем файл с настройками для созданной нами DNS зоны.
как мы определились ранее, файл с настройкам будет у нас находиться в /var/lib/bind/example.org.db вот его мы и создадим:

Со следующим содержимым:

Рассмотрим подробнее написанное:
$TTL 3600 — Time to live время жизни, по умолчанию ставим 1 час
example.org IN SOA ns01.example.org. root.example.org. сама зона, которая обслуживается данным сервером.
1; Serial -ее серийный номер DNS записи.
600; Refresh-указывает подчиненным DNS серверам как часто им обращаться, для поиска изменений к master серверу.
3600; Retry — говорит о том, сколько Slave сервер должен подождать, прежде чем повторить попытку.
1w; Expire — Максимальный срок жизни записей, после которой они потеряют актуальность (1 неделя)
300; Minimum TTL -минимальный срок жизни записи 5 мин.
NS ns01.example.org.-NS сервер который обслуживает эту зону
NS ns02.example.org.-NS сервер который обслуживает эту зону
NS ns03.example.org.-NS сервер который обслуживает эту зону
A 192.168.10.20 -если требуется попасть по адресу example.org, то клиенту будет выдан этот IP
ns01 A 192.168.10.50 — Записи для поиска наших NS серверов
ns02 A 192.168.10.60
ns03 A 192.168.10.70
www A 192.168.10.20 -Если клиент запросит адрес www.example.org, то ему будет выдан IP 192.168.10.20
test A 192.168.10.12 -Если клиент запрашивает адрес test.example.org, какой будет выдан ему IP?

Если все поднялось нормально, то переходим к настройке Slave сервера, если по каким-то причинам «не взлетело» идем смотреть логи, которые находятся /var/log/syslog и устраняем указанные в них ошибки.

Настраиваем Slave сервер

Я расскажу как настроить 1 подчиненный сервер, второй настраивается аналогично.
Редактируем options

Добавим в него, тоже что и к первому серверу

Находим и закомменитуем строку

Думаю что останавливаться на этом, во второй раз, не имеет смысла, ну а если память «девичья» возвращающемся в начало, повторение оно мать, сами знаете чего…

Создадим доменную зону.
Открываем файл

И добавляем туда запись, только на этот раз она будет немного отличаться:

Рассмотрим подробнее изменения:
type slave;-тип зоны подчиненная
file "/var/lib/bind/slave.example.org.db"; -путь к файлу с настройками, в этот раз в имени файла указано slave.example.org.db чтобы было понятно на каком сервере вы находитесь.
masters < 192.168.10.50; >; — IP адрес Мастер сервера, откуда будет производиться запрос файлов с настройками DNS зон.
allow-transfer <«none»;>; — Отключаем передачу зоны другим серверам, чтобы нельзя было получить все записи в домене
Сохраняем изменения и перезапускаем Bind:

Больше ничего создавать не нужно!
теперь открываем файл с настройками DNS зоны и обнаруживаем что в нем появилось содержимое

Bind кое что туда добавил сам(Смотрим скриншот):

А именно-расставил комментарии о сроках жизни различных параметров.
Третий сервер настраивается аналогично этому, все 1 в 1…
На подчиненных серверах все файлы создаются автоматически

Тестируем работу автоматического обновления DNS записей.
Для лучшего понимания происходящего в системе, очень удобно просматривать логи с отображением изменений в реальном времени, на любом подчиненном сервере открываем syslog т.к. все записи о событиях Bind пишутся в него (правильнее конечно завести отдельный лог для Bind), но это уже сами…

Теперь возвращающемся к нашему мастер серверу, в файле /var/lib/bind/example.org.db добавляем запись вида

и увеличиваем серийный номер DNS зоны на единицу
После этого на мастер сервере перезапускаем Bind

Возвращаемся к нашему подчиненному серверу, на котором мы открыли просмотр отображения изменений в syslog и замечаем что там появились новые записи вида:

Это говорит о том что Master сервер уведомил Slave сервера об изменениях, а Salve сервер их принял и примерил.

Теперь нам нужно уточнить что DNS записи пока НЕ идентичны на всех серверах, т.к. изменения могут еще «не доехать» до подчиненных серверов.
Чтобы в этом убедиться давайте сначала опросим Master сервер, чтобы послать ему запрос, в Windows это делается из командной строки, почти всем, знакомой командой nslookup, нас интересует новая запись test123.example.org

Где:
Nslookup-думаю что все знают что это за команда…
test123.example.org -запрос записи
192.168.10.50 -IP адрес DNS сервера от которого мы хотим получить ответ
В ответ нам выдаст, то что изображено на скриншоте

Таким же способом мы опросим Slave сервер

В ответ мы получим:

Это произошло по тому что изменения до него еще «не доехали» с мастера, таке иногда бывает, нужно просто немного подождать, пока в логах не появляться запись вида

Это говорит о том что данные приехали нормально.
Отлично данные реплицируются, на подчиненные сервера.

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

У нас есть такой параметр как серийный номер зоны, который в данный момент равен единице,

ВНИМАНИЕ.

Каждый раз, когда в настройки вносятся изменения, к серийному номеру прибавляется единица, это делается для того чтобы подчиненные сервера увидели изменения в записях и приняли обновленный файл зоны, если после внесения изменений в файл, серийный номер остался прежним или уменьшился, то подчиненные DNS сервера НЕ станут подтягивать обновления считая что на мастер сервере изменений небыло!
За более подробной информацие обратитесь к RFC1982
Это важный и тонкий момент, внесли изменения +1 к серийному номеру.

Теперь, чтобы делегировать доменное имя в настройках домена вам нужно указать:
ns01.example.org
ns02.example.org
ns03.example.org
После завершения тестирования, домен будет делегирован, с указанным вами списком NS серверов.
И все будет работать как часы.

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

Уф все, с DNS закончили… Спасибо тем кто дочитал до конца.

Возникли вопросы, прошу в комментарии, нашли ошибку, пишите в личку, ну или на мыло, которое указано в нижнем левом углу страницы.

Ready to move faster? We make it easy to tap into 20+ years of experience — our web experts will tackle whatever you need for a successful site.

Professional Web Design

SEO Marketing

Branding and Social Media Marketing

Custom Web Development

«I’ve always appreciated how easy it is — how simple it is. Compared to other sites, it’s ‘buy this, upgrade to this’. With DreamHost it’s been a clean and honest experience. There’s no massive marketing stuff all over the place.»

Peter K | J-Cakes.com

Customer Since 2000

«Our clients and customers count on us to provide feature-rich eCommerce websites, and with DreamHost Dedicated Hosting we have confidence that our sites are secure, fast, and reliable. Dedicated Hosting has been an essential part of our growth and success.»

Laura Peters | Funnychord.com

Customer Since 2015

«I love that DreamHost has one-click WordPress installs, which make setup a breeze! The interface is the most user-friendly platform I’ve ever worked with after 10-plus years of trying out many other competitors. I’m a happy, loyal, lifelong customer.»

Jennifer Emerling | Jennemerlingweddings.com

Customer Since 2008

«I’ve been a DreamHost customer ever since I first started doing web design. Their customer service is outstanding and their hosting is super reliable at an affordable price.»

Jeremiah S | Typewolf.com

Customer Since 2011

Summary

CDS works, and it’s a good method to communicate changes to a parent zone, particularly if both parent and child are under my control: I can then use automatic DS submission like Knot provides, or use dnssec-cds provided by BIND.

I think I understand SWITCH’s motivation for waiting three full days for bootstrapping new zones before accepting the CDS/CDNSKEY records and copying the DS into the parent zone, but it is quite a long time to wait. It’s an ‘are you really really sure you want to do this, or did you sign by mistake?’ kind of period. For all intents and purposes, the zone does not validate during this 72-hour period (note that I’m discussing the DNS method; SWITCH also uses EPP). What also works (I tested it) is that SWITCH resets the three-day counter as soon as one of the zone’s name servers doesn’t respond. The motivation for the three days was to avoid BGP hijacking issues, and this duration was chosen (instead of an even longer one) as a compromise — if my name server IP addresses are hijacked for three days without me noticing, I’m likely having much bigger issues than DNSSEC not being enabled on a zone.

I briefly hoped that RFC 8078 section 3.5 had secretly been implemented. Accept from Inception enables a parent adding a domain that is not yet delegated (at all) to use the child CDS RRset to immediately publish a DS along with the new NS RRset. It’s delegated in a secure state, so to speak. It seems to me as though this would be beneficial for those domains that can actually create keys and publish the CDS/CDNSKEY just before registering the domain, but I’m clueless as to how many that would be, percentage-wise, and whether the effort would be worthwhile.

RFC 8078‘s 3.4 Accept with Challenge might also be a viable method. I’m thinking along the lines of an HTTPS request to a well-known URL that produces a challenge that must be added to the DNS within, say, 15 minutes, before the robot queries whether it’s actually there, before consuming/ processing the CDS.

DNSSEC Bootstrapping has further reading that describes an authenticated in-band method for automatic signalling of a DNS zone’s delegation signer information from the zone’s DNS operator. I understand SWITCH is considering this for a future iteration.

Jan-Piet Mens is an independent Unix/Linux consultant and sysadmin who’s worked with Unix-systems since 1985. JP works extensively with the DNS and authored the book Alternative DNS Servers and a variety of other technical publications.

This post was originally published on jpmens.net.

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.