DNS-записи домена

Поднимаем свой DNS-over-HTTPS сервер

Tutorial

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

До последнего времени, несмотря на очевидность уязвимости DNS трафика, который, до сих пор, по большей части, передаётся в открытом виде, для злонамеренных действий со стороны провайдеров, стремящихся повысить своих доходы за счёт встраивания рекламы в контент, государственных силовых органов и цензуры, а также просто преступников, процесс усиления его защиты, несмотря на наличие различных технологий, таких как DNSSEC/DANE, DNScrypt, DNS-over-TLS и DNS-over-HTTPS, буксовал. И если серверные решения, а некоторые из них существуют уже довольно долгое время, широко известны и доступны, то поддержка их со стороны клиентского программного обеспечения оставляет желать много лучшего.

Домашний хостинг сайтов с динамическим IP

Из песочницы

У меня (как и у многих web-разработчиков) имеется с десяток сайтов которые необходимо где-то размещать (хостить).
Сайты практически не приносят прибыли, поскольку это какие-то старые работы (по разным причинам не пошедшие в продакшн), домашняя страница, сайт заведенный красивой почты и тому подобное. Но в то же время эти сайты жалко бросать, а потому приходится каждый месяц на них тратить вполне реальные деньги чтобы покупать хостинг. Деньги, прямо скажем небольшие, но тем не менее их жалко, поскольку отдачи от сайтов никакой нет.
В то-же время в наличии имеется:

Домашний сервер на Ubuntu
Быстрый ethernet-интернет от МТС

Но не имеется ключевого — статического IP. Если бы он был, то все было-бы намного проще и данную статью я бы точно не писал. А выдавать статический IP мой МТС абсолютно не желает (если только я не подключусь как бизнес-клиент).
Разумеется есть всем известные Dynamic DNS сервисы вроде noip.com, но они успешно решают лишь задачу удаленного доступа к нашему серверу (по SSH или FTP), но для хостинга совершенно нам не подходят, поскольку в настройках домена на DNS-сервере нам нужно обязательно прописать A-запись с реальным IP-адресом (а не ссылку на наш виртуальный домен).

Какие записи влияют на доставку писем?

Есть специальные TXT записи, наличие которых определяет, попадут письма в инбокс или будут заблокированы еще до появления в почтовых ящиках.

Как вы думаете, кто читает ваши письма прежде чем их доставят получателю? ЦРУ, Моссад или МИ-6? Нет, их прочтут спам-фильтры, которые постоянно совершенствуются и увеличивают количество факторов определения спама. Попадание в базу спам ресурсов (блеклисты) серьезно затруднит жизнь, если вы регулярно совершаете рассылки.

Аутентификация DKIM, SPF, DMARC подтвердит подлинность домена и обеспечит доставку писем в почтовый ящик. Они грудью стоят на страже репутации домена и оберегают от фишинга и спама.

DKIM — цифровая подпись отправителя, которая подтверждает, что письмо отправлено с вашего домена. Принимающий почтовый сервис автоматически проверяет эту подпись и удостоверяется, что письмо отправлено вами, а не мошенниками.

SPF — доменная запись, которая содержит информацию о списке серверов отправки и механизмах обработки писем. Эта запись отравляет жизнь спамерам и мошенникам в прохождении антиспам систем. Четко указывает у кого есть право отправлять письма от имени домена, а у кого нет.

Если домен не защищен записью SPF и подписью DKIM, спамерам ничего не помешает рассылать письма от вашего имени. Почтовые сервисы проверяют входящую корреспонденцию на наличие SPF и DKIM записи и отсутствие их расценивается как спам.

Но эти механизмы также имеют недостатки. Чтобы почтовому сервису было проще отличать реальные емейлы от поддельных, помимо SPF и DKIM ввели еще одну степень защиты — DMARC. При работе этих 3 факторов одновременно, вероятность успешной доставки сообщений адресату возрастает во много раз.

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

Если пользуетесь сервисом рассылок Estismail, можете легко сделать эти настройки. Услуга бесплатна и присутствует даже на тарифе FREE, чем редко могут похвастаться рассылочные сервисы. Подробные инструкции по настройкам записей DKIM, SPF, DMARC в Estismail есть в справочнике.

Cloudflare представила собственный VPN-сервис на базе приложения 1.1.1.1 для мобильных устройств

Вчера, полностью серьезно и без каких-либо шуток-прибауток, компания Cloudflare анонсировала свой новый продукт — VPN-сервис на базе DNS-приложения 1.1.1.1 для мобильных устройств с использованием собственной технологии шифрования Warp. Основной фишкой нового продукта Cloudflare является простота — целевой аудиторией нового сервиса являются условные «мамы» и «друзья», которые не способны самостоятельно купить и настроить классический VPN или не согласны устанавливать прожорливые в плане энергопотребления сторонние приложения от неизвестных команд.
Напомним, ровно год и один день назад — 1 апреля 2018 года — компания запустила свой публичный DNS 1.1.1.1, аудитория которого за прошедший период выросла на 700%

Сейчас 1.1.1.1 борется за внимание публики с уже ставшим классическим DNS от Google по адресу 8.8.8.8. Позже, 11 ноября 2018 года, CloudFlare запустили мобильное приложение 1.1.1.1 для iOS и Android и вот теперь, на его базе запускается и «VPN по кнопке».

Что-что случится 1 февраля?

Не то что бы, конечно, это было первое обсуждение вопроса на Хабре. Однако до сего момента в основном обсуждались последствия, в то время как, на наш взгляд, куда интереснее первопричины.Итак, на 1 февраля запланирован DNS Flag Day. Эффекты этого события будут наступать постепенно, однако всё же быстрее, чем некоторые компании сумеют к нему адаптироваться.
Что это такое? Говоря простым языком, это манифест основных мировых разработчиков DNS-серверов: компаний CZ.NIC, ISC, NLnet Labs и PowerDNS.
Производители программного обеспечения DNS уже давно столкнулись с проблемой: развитие системы доменных имён, добавление в неё новых функций, требующихся клиентам, решение вопросов безопасности — все эти процессы радикально замедляются ввиду кооперативной структуры системы DNS и необходимости поддерживать архаичные серверы, реализующие устаревшие версии протоколов (и даже это зачастую делающие с ошибками).

Настройка сервера DNS по стандартам безопасности Северной Кореи

Перевод

Мне страшно представить, с каким стрессом связана работа ИТ-специалистов Ким Чен Ына, так как он, скорее всего, из тех руководителей, которые все время наблюдают за твоей работой из-за плеча, постоянно касаются экрана и с нехорошим выражением лица намекают на «исчезновение» всех твоих родственников в трех поколениях, если при развертывании исправлений будет допущена хоть одна ошибка.
Мы часто слышим об утечке данных из крупных компаний, государственной поддержке хакеров и разработке нестандартных методов шифрования, однако необходимо признать, что причиной большинства возникающих ежедневно проблем безопасности являются банальные ошибки в конфигурации системы.

2018: Впервые в истории интернета обновлены ключи шифрования для защиты DNS

11 октября 2018 года состоялась первая в истории интернета и долгожданная замена криптографических ключей, защищающих систему доменных имен (DNS). Этот процесс, как сообщили в ], прошла без неполадок.

Криптографические ключи появились в 2010 году по инициативе ICANN. Они применялись в расширении DNS Security (DNSSEC). Изначально в DNS-серверах не была предусмотрена проверка подлинности ответов, чем пользовались злоумышленники: они могли перехватить запрос компьютера пользователя, который пытался установить IP-адрес своего «места назначения», и заменить его на неправильный. Таким образом, пользователь, сам того не замечая, мог подключиться к серверу мошенников. Чтобы избежать этого, в 2010 году было выпущено расширение DNSSEC, которое согласились установить многие крупные интернет-провайдеры.

Корпорация по управлению доменными именами и IP-адресами (ICANN) провела обновление ключей шифрования, служащих защитой для системы доменных имен

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

В ICANN предупреждали, что ряд интернет-пользователей, чьи сетевые операторы или интернет-провайдеры не будут готовы к смене ключа, могут столкнуться с проблемами. Они могут возникнуть при преобразовании имени ресурса в числовой IP-адрес, который компьютеры используют для соединения друг с другом.

Никаких сбоев не замечено

Мы уделяли особое внимание ряду участков, где такие сбои могли бы произойти, но никаких проблем не возникло, — заявил представитель ICANN Брэд Уайт (Brad White), добавив, что обновление прошло успешно.. Вице-президент ICANN по исследовательской деятельности Мэтт Ларсон уверен, что такое обновление криптографических ключей станет обычным делом для операторов

Вице-президент ICANN по исследовательской деятельности Мэтт Ларсон уверен, что такое обновление криптографических ключей станет обычным делом для операторов.

Чем живёт домашний интернет и статистика сервера доменных имён

Домашний роутер (в данном случае FritzBox) умеет многое регистрировать: сколько трафика когда ходит, кто с какой скоростью подключён и т.п. Узнать, что скрывается под непонятными адресатами, мне помог сервер доменных имён (DNS) в локальной сети.
В целом, DNS оказал положительное влияние на домашнюю сеть: добавил скорость, устойчивость и управляемость.
Ниже приведена диаграмма, которая вызвала вопросы и необходимость разбираться в происходящем. В результатах уже отфильтрованы известные и рабочие запросы к серверам доменных имён.
По какой причине каждый день опрашиваются 60 непонятных доменов во время, когда все ещё спят?
Каждый день опрашиваются 440 неизвестных доменов в активное время. Кто это такие и что они делают?

Багофича .RU или как получить проблемы там, где их не должно быть уже много лет

UPD. В связи с тем, что многие комментаторы не читают полностью, напишу здесь краткую суть проблемы: для .RU не очищаются Glue Records при изменении делегирования домена. Как минимум, для доменов, управляемых через Ru-Center и Reg.ru. Сама статья — это «история из жизни» о том, какие проблемы может вызвать такая «особенность» зоны .RU, как они были диагностированы и решены.
«Один мой друг» (с) рассказал историю про свои приключения с DNS.

Предыстория

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

Глава 1

Еще раз проверяем DNS зоны, убеждаемся, что нигде нет старых адресов и очень давно. Проверяем из разных регионов запросами на каждый из своих NS. Везде всё отдаётся правильно. Берем tcpdump и смотрим запросы на 53 порт на старыx DNS. Оказывается, что запросов к ним удивительно много. И это при том, что IP адреса этих серверов уже много месяцев нигде не фигурируют!

Несколько различных VPN подключений с локальными DNS серверами

Откуда появилась проблема

Многие из вас пользуются VPN подключением к рабочей локальной сети из дома.
Благодаря этому, подключив VPN вы работаете с рабочей сетью «как будто находясь в ней».
Как выглядит типичная настройка в linux?
В /etc/resolv.conf прописывается (при помощи openresolv или NetworkManager)

Где local.company.name — домен компании, а 10.0.20.186 — ip адрес локального (в рабочей сети) DNS сервера.
Как выглядит работа?

Что произошло?

search добавил к cdash-master суффикс local.company.name
DNS сервер в рабочей сети преобразовал cdash-master.local.company.name в 10.0.20.237

Всё прекрасно работает, пока у вас VPN подключение… одно.
Мне захотелось подключать одновременно два VPN и прописывать два DNS — один для рабочей сети, другой для локальной сети на hetzner, где крутятся мои виртуальные машины.
Казалось бы, что может быть проще? Однако путь к решению был долгим и извилистым.

Оценка доменного портфеля на примере MostWantedDomains

Перевод
Tutorial

На этой неделе вся доменная индустрия шумела по поводу покупки доменного портфеля MostWantedDomains, который приобрёл ведущий регистратор GoDaddy за неизвестную сумму. В пакет вошли около 70,000 имён старого разлива (без взрослой тематики и без новых зон) с жемчужинами класса 373.com, faculty.com, carauctions.com, ibill.com, bikerentals.com, kitchenchef.com и т.п.

Обе стороны договорились не разглашать условия контракта. Возможно, в будущем, кто-то с соколиным глазом сможет вычислить сумму на чеке с финансовых отчётов. Но кому интересно сегодня, по катом представлено руководство по оценке подобных виртуальных активов с возможными аргументами, которые можно использовать при торгах.

Чистим интернет от назойливой рекламы (AD Blocker для MikroTik)

Переадресовывая клиента при запросе «рекламного» домена, например, на loopback (127.0.0.1 — 127.255.255.255), вместо котента рекламы клиент получит благодатное «ничего» (разумеется, при условии, что у нас не работает локальный веб-сервер который слушает локалхост). Механизм фильтрации довольно старый и не лишен недостатков. Например, нельзя указать маски хостов (*.ad-domain.tld) или «вырезать» рекламу, баннеры которой хостятся на запрашиваемых ресурсах. Но зато не привязан к какому-то либо протоколу и довольно прост в эксплуатации. Более того, если его использовать, например, на домашнем или офисном маршрутизаторе, который используется в качестве DNS сервера, реклама успешно порежется на всех гаджетах, где IP нашей железки прописан первым в качестве DNS сервера.
Но что если у нас вместо роутера с кастомной прошивкой используется… MikroTik (RouterOS), функционал которого накладывает некоторые ограничения? Под катом вы узнаете каким образом удалось успешно «сконвертировать» файл хостов в пригодный для него формат, как автоматизировать это дело и что для хабралюдей в качестве бонуса был создан небольшой сервис как раз для автоматизации этого процесса (маленький, абсолютно бесплатный и с открытыми исходниками).

Блокировщик рекламы для дома на коленке

Tutorial

Прожорливый Bind9

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

Все бы ничего, но реклама там крутится на каждый чих. Пришлось изобретать, как же ее «порезать». Первая мысль была — поднять свой DNS сервер и отправлять все неугодные домены ~~в /dev/null~~ на 127.0.0.1. К этому моменту мой домашний серверок вернулся ко мне и занял свое почетное место на шкафу в качестве NAS сервера.

Сказано — сделано. Поднят Bind9, прописаны конфиги для нескольких доменов, все отлично. Летим.

2014: Передача функций контроля за управлением корневой зоной DNS от правительства США

В декабре 2014 года Межотраслевая рабочая группа ICANN подготовила предложения по передаче функций контроля за управлением корневой зоной DNS от правительства США интернет-сообществу. С инициативой передачи этих функций выступила весной нынешнего года Национальная администрация по телекоммуникациям и информации (NTIA), входящая в состав Министерства торговли США. Межотраслевая рабочая группа из 119 членов представила два варианта передачи функций.

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

Другой вариант предполагает создание новой структуры, надзирающей за деятельностью ICANN по управлению доменной системой и управляемой представителями интернет-сообщества. Авторы предложений подчеркивают, что речь идет о некоммерческой структуре с минимальным числом сотрудников. Таким образом, межотраслевая рабочая группа стремится, очевидно, избежать того, чего опасаются многие наблюдатели – создания «еще одной ICANN для надзора над ICANN».

Структура, условно обозначенная в документе как Contract Co, и возьмет на себя функции NTIA по контролю за управлением корневой зоной DNS. Выработка условий контракта с Contract Co и надзор за соблюдением его исполнения будут возложены на комитет Multistakeholder Review Team, сформированный из числа делегатов всех сообществ, чьи интересы представляет ICANN. Механизмы формирования этого комитета пока не определены и, вероятно, станут предметом жарких дискуссий, поскольку к максимальному представительству в нем будут стремиться самые разные группы с зачастую противоположными интересами.

Также будет сформирован новый постоянный комитет Customer Standing Panel, куда войдут представители регистратур общих и национальных доменов верхнего уровня – как главные «потребители услуг» корневой зоны DNS. Он будет транслировать комитету Multistakeholder Review Team пожелания регистратур, обеспечивая тем самым подотчетность ICANN перед ними. Наконец, предполагается и создание независимого апелляционного комитета, куда могут быть поданы жалобы на любые решения, связанные с управлением корневой зоной DNS, включая, очевидно, и решения о делегировании либо снятии с делегирования доменов.

Предложения опубликованы на сайте ICANN, комментарии к ним принимаются до 22 декабря 2014 года. Окончательное предложение правительству США по передаче функций контроля над управлением корневой зоной DNS должно быть сформулировано летом 2015 года.

DNS прокси на Node.JS своими руками

Из песочницы

При разработке сетевого приложения иногда возникает необходимость запустить его локально, но обращаться к нему по реальному доменному имени. Стандартное проверенное решение — прописать домен в файле hosts. Минус подхода в том, что hosts требует чёткого соответствия доменных имён, т.е. не поддерживает звёздочки. Т.е. если есть домены вида:

то в hosts нужно прописать их все. В отдельных случаях, домен третьего уровня не известен заранее. Возникает желание (пишу за себя, кто-то, возможно, скажет, что и так нормально) обойтись строкой вида:

Решением проблемы может стать использование собственного DNS-сервера, который будет обрабатывать запросы в соответствии с заданной логикой. Такие сервера есть, и вполне бесплатные, и с удобным графическим интерфейсом, например CoreDNS. Так же, можно менять DNS-записи на роутере. Наконец, воспользоваться сервисом наподобие xip.io, это не совсем полноценный DNS-сервер, но для некоторых задач отлично подойдёт. Словом, готовые решения существуют, можно использовать и не заморачиваться.

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

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

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

Для проверки записей DNS и диагностики доменов созданы специальные сервисы:

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

Они будут полезны в случае, если замечены неполадки. Например, перестала доходить или отправляться почта и др. Подобный сбой обычно происходит после коррекций записей DNS. Поэтому, после внесенных изменений необходимо проводить проверки.

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

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

Рекурсия

Рассмотрим на примере работу всей системы.

Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org»? Однако, сервер DNS может ничего не знать не только о запрошенном имени, но даже обо всём домене wikipedia.org. В этом случае имеет место рекурсия: сервер обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является авторитетным для зоны org.» Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является авторитетным для зоны wikipedia.org.» Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ — IP-адрес, который и передаётся клиенту — браузеру.

В данном случае при разрешении имени, то есть в процессе поиска IP по имени:

браузер отправил известному ему DNS-серверу т. н. рекурсивный запрос — в ответ на такой тип запроса сервер обязан вернуть «готовый результат», то есть IP-адрес, либо сообщить об ошибке;
DNS-сервер, получив запрос от клиента, последовательно отправлял итеративные запросы, на которые получал от других DNS-серверов ответы, пока не получил авторитетный ответ от сервера, ответственного за запрошенную зону.

В принципе, запрошенный сервер, мог бы передать рекурсивный запрос «вышестоящему» DNS-серверу и дождаться готового ответа.

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

Google Public DNS не ресолвит некоторые домены

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

Как проверить DNS домена: онлайн инструменты

Задача заключается в следующем. Вы переезжаете на другой хостинг. Как следствие, если вы не используете сторонние DNS сервера, вам нужно сменить DNS сервера у вашего регистратора.

Проверить смену DNS серверов вы можете на следующих онлайн сервисах.

Googleapps

Сервисы Google дают такой инструмент. Его адрес: toolbox.googleapps.com/apps/dig/.

Работает всё просто:

Вписываете свой домен;
Выбираете тип необходимой для проверки записи;
Смотрите результат;
Меняя тип записи смотрите другие записи.

2whois.ru

Адрес сервиса: https://2whois.ru/

Всё те же действия никаких сложностей

Обратите внимание, что этими инструментами вы можете смотреть любые типы записей, в полоть до WHOIS домена

Кстати, сервисы WHOIS тоже показывают DNS записи доменов.

Второй способ

Вы можете воспользоваться бесплатной поддержкой DNS, входящей в стандартный пакет услуг «Reg.Dedicated». Для этого вам предоставляется удобный интерфейс для управления зоной на базе ISPmanager и DNSmanager. При пользовании данной услугой у вашего регистратора для домена в качестве DNS-серверов необходимо прописывать: и .

Если вместе с услугой «Аренда сервера» вы заказали панель управления ISPmanager,

1.
Зайдите в вашу панель управления ISPmanager с правами администратора.
2.
Перейдите в раздел Доменные имена.
3.
Нажмите на Вторичные серверы имен.
4.
Нажмите Зарегистрировать новый внешний сервер имен.
5.
В поле «URL панели управления» введите .
6.
В поле «Пользователь» введите ваш логин вида .
7.
В поле «Пароль» введите ваш пароль для доступа к DNS (не следует путать его с паролем пользователя root).
8.
Нажмите ОК.
9.
Повторите операцию добавления вторичного сервера имён для адреса .
10.
Нажмите на Настройки доменов по умолчанию.
11.
В поле «Серверы имён» введите и .
12.
Поставьте галочку «Изменить для всех доменов».
13.
Нажмите ОК.

Теперь при создании домена в панели управления вашим сервером домен будет автоматически создан на вторичных серверах ns5.hosting.reg.ru и ns6.hosting.reg.ru, которые вы сможете прописать как DNS-сервера для данного домена у вашего регистратора.

Выделенный сервер в качестве первичного DNS-сервера

Если вы не заказывали панель управления ISPmanager и хотите, чтобы ваш выделенный сервер выступал в качестве первичного DNS-сервера, для вас предусмотрен интерфейс управления вторичными серверами имён:

1.
Зайдите в панель управления DNSmanager (https://ns5.hosting.reg.ru/manager/dnsmgr), используя логин вида d0000000 и пароль для доступа к DNS (не следует путать его с паролем пользователя root).
2.
Перейдите в раздел «Доменные имена».
3.
Нажмите на Создать новый домен.
4.
В поле «Имя домена» введите имя добавляемого вами домена.
5.
В поле «IP первичного NS» введите IP-адрес вашего выделенного сервера.
6.
Нажмите ОК.
7.
Повторите операцию добавления домена на втором сервере (https://ns6.hosting.reg.ru/manager/dnsmgr).

Интерфейс управления первичным сервером имён

Если вы не хотите, чтобы ваш выделенный сервер выступал в качестве первичного DNS-сервера, для вас предусмотрен интерфейс управления первичным сервером имен:

1.
Зайдите в панель управления DNS Admin, используя логин вида d0000000 и пароль для доступа к DNS (не следует путать его с паролем пользователя root).
2.
Перейдите в раздел «Доменные имена».
3.
Нажмите на Создать новый домен.
4.
В поле «Доменное имя» введите имя добавляемого вами домена.
5.
В поле «IP-адрес» введите IP-адрес вашего выделенного сервера;
6.
Нажмите ОК.

Создать свои собственные DNS-серверы на базе домена:

а) необходимо иметь основной IP вашего выделенного сервера и дополнительный, полученный при подключении услуги «Дополнительный IP адрес на ваш выбор»;

b) необходимо настроить свои DNS-серверы в ISPManager:

1.
Зайдите в вашу панель управления ISPmanager с правами администратора.
2.
Откройте раздел «Настройки DNS»:
3.
В поле «Серверы имён» укажите два DNS-сервера:, :
4.
Сохраните изменения.

В первый раз при делегировании вашего основного домена на выделенный сервер нужно помимо имён серверов указать IP-адреса для каждого ns-сервера. В дальнейшем при делегировании новых доменов на выделенный сервер достаточно будет указывать только , .

c) У своего регистратора прописать для домена yourdomain.ru DNS-сервера: и , а также IP-адреса для каждого ns-сервера.

США отдаёт контроль над корневой зоной DNS

В эту пятницу на сайте неприметного американского ведомства появилось сообщение, что оно планирует отдать управление над корневой зоной DNS. Другими словами, США перестанет контролировать всю систему доменных имён, отдавая управление сообществу.

Техническая часть

В DNS рекурсивное определение имени начинается с точки в конце доменного имени. Чаще всего её пропускают, но, на самом деле вместо следует писать — именно так, с точкой. Когда клиент просит рекурсивный DNS сервер сказать, какой IP адрес у www, процесс начинается с определения авторитетных серверов для зоны ru. И начинается он с запроса в зону «.», сервера которых отвечают, что у зоны RU есть несколько авторитетных серверов, и дальше процесс рекурсивно продолжается, пока мы не узнаем, что A-запись для www указывает на 46.226.110.151, после чего браузер идёт по этому адресу и выясняет, что Роскомнадзор… Впрочем, пост не о цензуре.
За корневую зону отвечают корневые сервера. У них 13 IP-адресов — это максимальное количество, которое можно уложить в один ответ DNS по UDP. Самих серверов больше (используется мультикастинг, балансировка нагрузки посредством DNAT’а и другие технологии), но адресов у них — 13. Адреса корневых серверов намертво «прибиты гвоздями» в конфигах практических любых DNS-серверов. И даже DNS-сервера, которые не поддерживают рекурсию, обычно отвечают списком корневых серверов (если мы не знаем корневых серверов и не знаем с чего начать процесс рекурсивного определения имени, то любой DNS-сервер нам укажет именно на них).
Именно в корневой зоне регистрируются TLD (top level domains), такие как .ru, .com, .jp, .info и т.д.
На этом техническая часть заканчивается и начинается политическая.

Политическая часть

DPI, великий китайский файрвол, малый русский файрвол — это всё ерунда. Кто контролирует корневую зону, контролирует весь интернет. Если из DNS удалить зону .no, то ни один норвежский сайт не будет открываться по имени. Точнее, перестанет открываться через некоторое время, как только протухнут кеши у ресолверов.
Исторически, с момента разрешения использования Интернета для коммерческой деятельности, корневая зона находилась в формальном подчинении NTIA (полное название: U.S. Commerce Department’s National Telecommunications and Information Administration — американский аналог Роскомнадзора, правда, без функций цензуры). В ходе развития Интернета, была создана некоммерческая организация ICANN, которая занималась отношениями с регистраторами национальных доменов, созданием новых TLD и т.д. С нею был заключен договор — и ICANN выступала и в качестве IANA (верхнего распределяющего IP-адреса), она же управляла корневой зоной. Техническая же работа была поручена Verisign. Но формальный контроль оставался у США.

Как работает DNS

Доменное имя содержит, как минимум, две части (обычно называются метками), разделённые точкой. Самая правая метка является доменом верхнего уровня (например, для адреса ru.wikipedia.org домен верхнего уровня — org). Каждая следующая метка справа налево является поддоменом (например, wikipedia.org — поддомен домена org, а ru.wikipedia.org — домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения.
Система DNS содержит иерархию серверов DNS. Каждый домен или поддомен поддерживается как минимум одним авторизированным сервером DNS, на котором расположена информация о домене. Иерархия серверов DNS совпадает с иерархией доменов.

Рассмотрим на примере работу всей системы.
Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер знает только IP-адрес сервера DNS, обычно это один из серверов интернет-провайдера. Он спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org?». Сервер DNS обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 поддерживает доменную зону org.» Браузер направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 поддерживает доменную зону wikipedia.org.» Наконец, браузер отправляет свой запрос к третьему DNS-серверу (который является авторизированным сервером для домена wikipedia.org), и получает ответ — IP-адрес. Этот процесс называется рекурсивным поиском.

Имя хоста и IP-адрес не тождественны — хост с одним IP может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество хостов: это позволяет создавать балансировку нагрузки.
Запрос на определение имени обычно не идёт дальше кэша DNS, который помнит (ограниченное время) ответы на запросы, проходившие через него ранее. Организации или провайдеры могут по своему усмотрению организовывать кэш DNS. Обычно вместе с ответом приходит информация о том, сколько времени следует хранить эту запись в кэше.
Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию. Существует 13 корневых серверов, расположенных по всему миру и привязанных к своему региону, их адреса никогда не меняются, а информация о них есть в любой операционной системе.
Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP датаграммы. TCP используется в случае, если ответ больше 512 байт, или в случае AXFR-запроса.