Пряморукий DNS: делаем правильно
Представляем вашему вниманию очень эмоциональный рассказ Льва Николаева (@maniaque) о том, как надо настраивать DNS и особенно, как делать не надо. Вот прямо после каждого пункта можете мысленно добавлять: «Пожалуйста, не делайте этого!» В своем докладе Лев так и говорит.
Статья будет состоять из трех частей:
Резольвер — это та штука, которую вы прописываете в настройках своей операционной системы, чтобы можно было превращать понятные человеку адреса типа ya.ru в непонятное 87.250.250.242.
Если вы уже доросли до этого, расскажем, как держать зону самостоятельно, как это делать хорошо и отказоустойчиво, и как это делать, если у вас несколько сотен доменов.
О спикере: Три года назад Лев Николаев пришел в компанию Макснет, в которой DNS развивался как раз не совсем правильно. Был bind и текстовые файлы с зонами; руки чесались навести порядок. В основе статьи доклад на Root Conf 2017, в ходе которого Лев делится с сообществом своим ассортиментом граблей.
Делаем резольвер
Резольвер нужен тем организациям, у которых либо нет провайдерского резольвера, либо которым он уже начинает мешать (от вас льется столько запросов, что резольвер не успевает отвечать или же лимитирует вас). От ЦОД или провайдера в принципе ждут наличия своего производительного резольвера.
Интересный вопрос к размышлению состоит в том, почему в стандартной поставке почти любой операционной системы нет резольвера, который умеет самостоятельно выполнять DNS запросы от корневых серверов. Совершенно непонятно, почему всегда моя машина должна идти к кому-то и просить его выполнить DNS запрос. Как ни странно, коллеги по цеху из FreeBSD ответили, что там есть, что у них из коробки ставится unbound, но в остальных ОС этого нет.
Выбор софта для резольвера
По большому счету, здесь всего 2 варианта:
- Вы можете использовать bind;
- Вы можете использовать unbound.
В отношении резольвера я не пытаюсь вас склонить к выбору какого-то конкретного софта, потому что на сегодня резольвер — это в первую очередь некие реализуемые фичи, а не конкретный софт. Вы можете использовать bind или unbound, или что угодно еще, если оно будет отвечать тем вещам, про которые я сейчас расскажу.
Привет убунтоводам!
Если вы любите Ubuntu, как мы, и используете ее в продакшне, вам придется немножко повелосипедить. Как известно, unbound должен стартовать вместе с системой. В 16.04 перешли на systemd, но, естественно, юнит написать забыли. И когда генератор пытается его сгенерировать автоматически из SysV-скрипта, получается полное безобразие. Не вздумайте это выкатывать в продакшн — я это сделал и оставил 30 000 абонентов без DNS на полчаса. Благо, это было ночью.
Пишите юнит! Или возьмите у меня, в конце будет адрес репозитория. Это касается только тех, кто с Ubuntu, но, например, в Debian что-то близкое должно быть.
Что должно быть в резольвере?
5 вещей, которые нужно сделать в своем резольвере.
1. Никаких форвардов к Яндексу или Google
Это довольно очевидно, поэтому, пожалуйста, перестаньте так делать. Перенаправлять запросы к Google плохо по двум причинам. Во-первых, вас рано или поздно ограничат по количеству запросов, о чем они заранее предупреждают. Но самое неприятное в том, что связность неидеальная.
Иногда бывает, что даже заветные 4 восьмерки недоступны, соответственно, у вас тоже будут проблемы. Абсолютно то же самое касается и Яндекса.
Нет, это не проблема Google или Яндекс, их недоступность обычно связана с тем, что у Вас (или Вашего аплинка) упал до них канал.
2. SO_REUSEPORT
Эта опция реально ускоряет жизнь, но требует, чтобы у вас было ядро, как минимум, версии 3.9. Если среди вас есть любители ядер 2.6. (моябабушкаизRedHat), закопайте его, пожалуйста. Опция SO_REUSEPORT позволяет нескольким процессам одновременно биндить один порт (у них должен быть одинаковый UID, чтобы порт не «угнать»), но ее приятственность в другом — нагрузка распределяется на эти потоки равномерно. Для DNS это подходит идеально, и вы на самом деле увидите прирост производительности, просто перейдя на современное ядро.
SO_REUSEPORT есть и в bind, и в unbound. В bind он включен из коробки, в unbound его надо отдельно включать, потому что unbound пытается быть максимально совместимым, иногда в ущерб производительности.
3. Prefetch
Это странная опция. Она действительно помогает в том смысле, что она немножко не уважает TTL. Когда мы идем к авторитетному серверу и спрашиваем у него какую-то запись, у нее есть TTL — это то время, в течение которого к нему можно за обновлением не ходить. Unbound и bind идут за обновленным содержимым этой записи раньше, чем TTL реально истек.
Но есть две особенности. Вы получите прирост в исходящем трафике процентов на 10. Хотя на самом деле в целом резольверы с трудом могут генерировать вообще много трафика, поэтому вряд ли это вас будет волновать. Второй момент — с короткими TTL (например, в минуту) с Prefetch никакой особой пользы не получится, но так как для ru-сегмента короткий TTL пока еще фантастика, в принципе может отлично сработать.
4. Expired
Этой опции в bind я не нашел, но в unbound она есть и позволяет возвращать просроченную запись с нулевым TTL, а в фоне пытается получить свежую у авторитетных серверов. Это хорошо помогает от крупных падений, например, пользователи могли бы даже и не заметить недавнего падения Dyn, если эта опция была бы массово включена. Но ее не все знают, не все любят и не все включают.
5. DNSSEC
DNSSEC есть в 2 разных ипостасях — в простой и в сложной:
- Простой, когда вы просто валидируете запись, если DNSSEC у домена включен.
- Сложной, когда вы сами для своего домена делаете подпись DNSSEC и пр.
Как вы понимаете, если мы отравим кэш резольвера, все его клиенты получат отравленную запись, и можно будет сделать много интересных вещей. Поэтому, пожалуйста, всегда проверяйте DNSSEC, если он есть у домена, в этом нет ничего сложного и это делается автоматически и хорошо.
Зарубежные домены обзавелись DNSSEC уже неплохо, хотя процент там тоже небольшой. При этом многие провайдеры принципиально DNSSEC не проверяют, например, Ростелеком.
За полтора года этой валидации я все ожидал, что кто-нибудь из наших крупных компаний накосячит с DNSSEС, тем самым порвав на британский флаг нашу техподержку, но пока все единичные срабатывания были на зарубежные сайты с небольшим трафиком — все нормально.
Мелочи жизни
1. Перестаньте отвечать на ANY
Если вы делаете резольвер, перестаньте отвечать на запросы ANY потому, что это вид запроса, который на самом деле толком не стандартизован и используется на 99% всякими замечательными вирусами.
Чтобы не опускаться до программного уровня, можно использовать iptables, который работает достаточно быстро: если он видит, что запрос ANY, он его просто дропает.
iptables -A INPUT -p udp —dport 53 -m string —hex-string «|0000ff0001|» —algo bm -j DROP
2. Rate-limit
Используйте ограничение на количество запросов в секунду, если Вы не закрыты извне. Мой резольвер по целому ряду причин пришлось открыть всему миру, поэтому практически первое, что я сделал — это ограничил количество запросов в секунду извне. Если вы не можете закрыть ваш резольвер для клиентов снаружи, то хотя бы лимитируйте их. Лимит поставьте по вкусу, например, у меня 70 запросов в секунду.
[здесь -j ACCEPT для всех тех, от кого закрываться не надо]
iptables -A INPUT -p udp —dport 53 -m state —state NEW -m recent …
—set —name DNSQF —rsource
—update —seconds 1 —hitcount 70 —name DNSQF —rsource -j DROP
3. Для unbound хорошо interface-automatic: yes
Третья приятная мелочь. Обычно, в сети делается не один резольвер, и иногда хочется делать между ними failover, но, естественно, не при помощи самого резольвера. Надо failover делать методами маршрутизации и у unbound есть отличная опция interface-automatic: yes. Она говорит: «Если запрос ко мне попал в принципе, мне плевать, кому он был предназначен, я отвечу на него». С этой опцией очень удобно, если нужно, на unbound заворачивать трафик соседнего резольвера.
Что мониторить?
Это типичная картинка с прода. Мы здесь видим, что количество запросов достигло 300 000 запросов, и это не в минуту и не в секунду, у меня статистика снимается каждые 5 минут, т. е. на самом деле мелочь.
Таким образом, мониторить количество запросов обязательно нужно, т. к. если вы не можете их измерять, вы не можете их контролировать. Еще нужно мониторить виды запросов. В примере ниже хорошо видно: бирюзовая полоска — это PTR-запросы, и надо разбираться, почему их так много и откуда они берутся.
Чаще всего их причиной является криво сконфигурированный софт, либо какой-то роутер считает, что ему нужно срочно сделать PTR-запросик пару тысяч раз.
Это делается достаточно просто — вы по cron дергаете статистику unbound, а потом оттуда (мы в Zabbix юзер-параметром) забираете то, что нужно.
Виды ответов тоже обязательно надо мониторить. На картинке выше типичный пример DNS Water Torture, т. е. ботнет внутри вашей сети запрашивает несуществующие адреса поддомены атакуемого домена. В результате он получает ответ Nodata (красный цвет), в примере доходило до 25 000 таких запросов в пике.
Цель при этом: заколебать до смерти Name-сервер атакуемого домена, чтобы он устал отвечать и на легитимные запросы. А как только вы начинаете мониторить виды ответов, то начинаете видеть, насколько внутри вашей сети активны ботнеты.
Обратите внимание, и количество легитимных запросов подпрыгивает точно также, когда появляется красненькая полоска, т. е. здесь ботнеты увеличивают количество запросов 2 раза.
Другая проблема — что с этим делать потом, но это не сегодняшняя тематика.
Ваш лучший друг — dnstop
Это очень удобная команда, чтобы понять, кто и что запрашивает, если случилась атака и что-то пошло не так. Обычно, её запускают без параметров, но это неправильно.
dnstop -i
Нажимаем на клавиатуре с, а потом цифру 2
Я специально пишу, что нужно указывать наш IP адрес, чтобы не учитывать в статистике запросы самого резольвера, которых будет много. Далее в сочетании это магических кнопок с значит выдать детализацию по IP адресам, 2 — детализация до 2-го уровня доменов.
Так можно легко смотреть, кто и куда ходит, и какая атака идет сейчас.
Грабли (делюсь своими)
Их много. Как только вы поднимете резольвер, вы столкнетесь с криво настроенными роутерами или софтом. Можете получить тонны PTR запросов. Такое бывает достаточно часто, и вы это будете видеть, сможете исправлять, разбираться и делать вашу сеть лучше. Отдельный момент — это прекрасные китайские видеорегистраторы. К ним у меня особая любовь, как и у многих, наверное.
В вашей сети главная проблема в том, что вашим пользователям на ваши проблемы глубоко наплевать чаще всего. То есть то, что от пользователя идет паразитный трафик с DNS Water Torture его волнует мало, пока World of Tanks работают.
Сейчас говорили про простейшую вещь — про резольвер, теперь давайте усложним задачку.
Держим зоны
Итак, мы доросли до того, что у нас есть домены, мы хотим их у себя держать, быть авторитетным за них сервером, отдавать ответы.
Как правило у себя держат зоны либо организации с особыми амбициями: «Мы крутые! Мы зоны лучше держим, чем какой-нибудь Dyn!», либо ЦОДы или провайдеры, от которых этого опять же этого ждут по умолчанию.
Не надо совмещать
Первая задача — не надо совмещать. Пожалуйста, не делайте этого никогда! Хотя мы найдем исключение из этого правила. Совмещать на одной машине резольвер и авторитетный сервер — это плохо . В чем проблема, я думаю, вы понимаете. Если клиент «увел» домен от вас (т. е. сменил ns-сервера у регистратора) или домен протух (т. е. истек его оплаченный период), Вы об этом вообще не узнаете никак. Потому, что вы можете не внести изменения локально.
У нас были клиенты, которые настолько верили в то, что если сайт открывается изнутри нашей сети, то им и домен продлевать не надо. У них дома наш интернет и на работе наш интернет — везде же открывается, все нормально.
Выбор софта
Главный момент: не надо думать, что вы здесь выбираете софт. Это ключевая ошибка в головах многих. DNS — это база данных, не пихайте ее в текстовый файл. Очень и очень плохо, если вы при помощи Ansible или chef генерируете текстовый файл, который потом засовываете в bind. Но я знаю — вы это делаете, а потом рассказываете о том, что оно плохо работает.
Поэтому ответ: PowerDNS
Вы знаете, что к bind есть патч, чтобы работать с MySQL, да? А вы его пробовали? Многие еще не знают про PowerDNS. Большая часть свято считает, что этот патч можно как-то использовать на старых версиях, но оно будет работать ужасно в плане производительности, потому что это просто набор костылей.
Опять привет убунтуводам
Если вы используете Ubuntu, то в стандартных репозиториях 16.04 лежит alpha-версия PowerDNS 4.х. Я не знаю, кому сказать спасибо за это. Она действительно работает, но с проблемками. Уже год, как я открыл к версии 4.х issue #3824. Я спрашиваю у разработчиков PowerDNS:
– Ребят, а ничего, что я MySQL перезапускаю, а у вас PowerDNS не подхватывает его обратно?
– Ух ты, прикольно!
Запомните этот баг, они уже 3 раза закрывали и 3 раза открывали в 4-й ветке. Поэтому — есть 3-я стабильная, у нее этих проблем нет, но на Debian / Ubuntu вам понадобится ее ставить из deb-файла. И на сегодня, на март 2018 года она уже небезопасна. Поэтому выход один — переходить на ppa от разработчиков для Вашей версии Ubuntu.
Вдумчивая архитектура
Здесь начинается сложная часть статьи — давайте подумаем про архитектуру. Как только мы пришли к PowerDNS, раз это база данных, мы хотим удобный редактор в вебе. А редакторов нет, кроме PowerAdmin. Это веб-приложение на PHP, и сразу понятно, что тому, кто его развернет вместе с DNS-сервером, надо руку отрубить — нельзя его на ту же машину ставить. В итоге возникает задача:
- Есть база данных.
- Есть сервер, который ходит в эту базу данных, чтобы получить ответы.
- Этих серверов несколько.
- Надо все синхронизировать.
Далее, у нас несколько DNS-серверов и необходимо доставлять на них базу данных. Получается, что есть машина с PowerAdmin, с актуальной базой данных, и нужно эту базу данных как-то раскатывать еще на кучу машин.
– Давайте возьмем, например, репликацию MySQL. Говорят, она прикольно работает!
– Она вам тоже не поможет. Репликация тут не лучший друг.
Поэтому схема выглядит так.
У вас есть сервер с PowerAdmin и MySQL. С DNS-сервера вы идете туда и делаете mysqldump с опцией skip-extended-insert (мы о ней скоро поговорим) и получаете SQL-файл.
Вы скажете: «Эка невидаль! Что мы, дампов никогда не делали?»
А дальше начинается интересное. Естественно, вы не можете, взяв dump в базе на допустим 700 доменов, загружать его в ту же базу. Поэтому его надо загрузить в соседнюю, а потом сделать RENAME TABLE. Вы спросите — зачем? Это 100% атомарно. RENAME TABLE — это офигительная штука, которая, как и переименование файла в Linux, либо отрабатывает, либо нет, у неё нет промежуточного состояния. Это очень удобно и удобнее, чем транзакция, потому что в разы быстрее. После того, как вы успешно этот dump загрузили, вы этот же файл кладете в git. Поскольку есть опция skip-extended-insert, то файлик получается git-friendly, т. е. у него на каждый insert одна строчка, и вы получаете вменяемый diff.
Главное здесь вот что: я хочу иметь возможность видеть diff от результатов «накатывания» базы.
Что получим
- Это очень простые операции: 225 строк на PHP во имя добра.
- Каждый DNS-сервер это делает каждые 2 минуты. Часы у них синхронизированы, поэтому у вас может быть любое количество серверов — они получат одинаковую базу данных.
- Опция skip-extended-insert позволяет делать не один большой монструозный INSERT, а много маленьких.
А про понятие master/slave забудьте, в данном контексте оно маловажно.
Хьюстон, у нас проблема
Все бы здорово и замечательно, но у нас есть одна проблема. Этот классный подход работает, только если мы для домена, в котором мы это делаем, и master, и slave. Если же это не так, начинаются сложности, которые мы сейчас будем побеждать.
Давайте переосознаем роль master/slave еще раз. Master шлет уведомления, как только у него изменилась зона, slave эти уведомления получает и что-то делает, при этом оба они отвечают на запросы.
Есть 2 стула варианта:
- Клиент хочет, чтобы мы держали у себя slave. То есть у клиента где-то будет держать master, а мы должны забирать у него данные. Это как раз сложный вариант, который потребует телодвижений.
- Клиент хочет, чтобы мы держали у себя master, а он будет slave, т. е. будет забирать у нас копию. Это простой вариант, мы просто разрешаем трансфер зоны клиенту.
Выход — назначить один из серверов (можно 2 — отдельный разговор) ответственным за прием *XFR. Это не может делать сервер с PowerAdmin, т. к. там нет DNS-сервера и некому принимать.
Схема выглядит так:
- Один из наших серверов получает *XFR.
- Вносит изменения в свою базу.
- Вкатывает эти изменения серверу, где стоит PowerAdmin.
У нас может быть 2 роли: просто DNS-сервер, который синхронизируется, а может быть DNS-сервер с ролью slave, который принимает *XFR, записывает себе в базу данных, и отдает изменения PowerAdmin, выполняя еще один скрипт.
Повторю, что эта схема достаточно простая, работает очень хорошо уже достаточно долго и позволяет полностью отказаться от понятий master и slave вообще в принципе. Мы slave в тех случаях, когда нам нужно им быть, и не более того.
Что мониторить?
Power DNS — это все-таки отдельный механизм, который надо мониторить. Ниже картинки из Zabbix. Мы снимаем Latency, т. е. сколько времени занял ответ в микросекундах, и хорошо видны всплески, если машина была занята или база данных тормозила.
Протокол, по которому пришел запрос тоже нужно мониторить. Там не всегда легитимен TCP, за ним тоже надо аккуратно наблюдать. Заодно можно понять, насколько популярен IPv6, здесь это 10% запросов.
Виды запросов тоже нужно снимать, тогда вы будете понимать, что происходит, и видеть, например, что запросы вида АААА, то есть адреса в IPv6 в нашей ситуации уже практически равны запросам IPv4.
Обязательно нужно мониторить отправку SERVFAIL и поломанные пакеты, причем это удобно делать на одном графике. Если эти два числа совпадают — спите спокойно. Не совпадают — вы увидите.
Взболтать, но не смешивать
Увы иногда приходится использовать связку PowerDNS + unbound. К примеру, у вас есть локальный домен с хитрой структурой, которую неудобно настраивать в unbound. Кстати, так работает один из механизмов блокировки сайтов в России. Резольвер вашего провайдера может возвращать для «плохого» домена заглушку, для хорошего — нормальную запись. В корпоративной среде такое применяется, например, для блокировки социальных сетей или защиты от вирусов.
Архитектура
Архитектура здесь до боли проста — это просто смесь 2 компонентов, о которых мы только что говорили. То есть в свет смотрит PowerDNS, принимает запрос, смотрит в базу, к config-файле которой есть опция отправить запрос дальше вот этому серверу (стоящему на той же машине unbound), если чего-то нет в самой базе. Единственная особенность, что в рамках мониторинга мы на эту машину настраиваем template Zabbix 2 раза и картинок становится в 2 раза больше.
Контакты
Ответы и вопросы
— Хотелось бы услышать Ваш совет, каким образом можно фильтровать до сервера запросы определенных типов. Например, я хочу полностью отрезать IPv4 все запросы, чтобы они не доходили до сервера вообще.
— Эти опции есть и в PowerDNS, и в unbound. Еще есть вариант, используя IPtables, вы можете с помощью hex match выдергивать кусочек, смотреть, что там за запросы и просто их дропать полностью. Еще один вариант. Существуют различные DNS-прокси, причем даже авторы PowerDNS тоже выпускают свой резольвер, который поддерживает скрипты на Lua. Вы можете туда подсунуть свой скрипт, который будет делать любую кастомную магию. Есть для этого разные средства. Все зависит от того, что у вас за задача.
— Скажите, Вы у себя на сети внедрили блокировку запрещенных сайтов с помощью DNS? Статистика примерная есть?
Скажу так, и ее тоже. Много ли блокируется? Понятно, что блокировка через DNS — это от домохозяек. Понятно, что никто не мешает абоненту взять и вбить DNS Google. Честно скажу, мы не смотрим на нее, но в принципе, что-то туда падает.
— А по отчетам ревизоров заметны изменения после внедрения блокировки DNS?
Да. Для ревизора это отличный способ. Имейте это в виду.
— Вы своим клиентам, которые пользуются вашим DNS, даете IP адреса? Вы обеспечиваете доступность этих адресов, и каким образом?
Давайте коротенечко расскажу, как это работает. Вы же помните, что мы там вводим 2 адреса. Знаете, как смешно там работает failover. Смотрите, Windows и Linux ведут себя по-разному. Windows при недоступности первого переключается на второй и раз в 15 минут пытается по-прежнему тыркать первый и по возможности переключается на него. Linux этого не делает.
Во-первых, что надо понимать? Что failover средствами операционной системы не униформен и плох. Соответственно, ваша задача, чтобы оба IP, которые вы отдаете, как резольверы, светились всегда и работали. Поскольку мы это делаем с помощью маршрутизации, у каждого из наших серверов дополнительными IP к интерфейсу прописаны адреса его друганов. У нас их используется 3 и пока хватает.
При помощи маршрутизации мы туда направляем трафик. Поскольку в unbound мы используем опцию «отвечать на всех интерфейсах», он отлично отвечает, и ему никаких дополнительных манипуляций не надо.
— У Вас была табличка по передаче MySQL dump от серверов друг к другу. Вы говорили, что у вас получился не master/slave и master/master. То есть, грубо говоря, вы меняете всегда зону на одном из серверов и перекидываете на другой и split-brain не может получиться в этом случае?
Нет, split-brain возможен. Вообще каждый сервер раз в 2 минуты бежит делает dump и закидывает его к себе. Но если у него это не получилось, то мы наблюдаем а-ля split-brain, у него старая версия базы.
Но здесь нам помогает следующее. Если он не смог этого сделать, скорее всего, у него нет связанности. Если нет связанности, то значит, клиенты до него тоже не доберутся, и проблема не возникнет. Как только у него появится связанность он очень быстро получит новую копию.
— Нет, split-brain в том смысле, что вы на одном из серверов изменили запись, а на другом нет.
Смотрите, на самих DNS-серверах ничего не изменяется. Изменяется в одном месте, где PowerAdmin, а оттуда раскатывается на все остальные. Соответственно, такого не может быть, что мы забыли базу поменять где-то в другом месте. Мы как раз это и делали, чтобы так не было никогда.
Это была одна из наших проблем, когда был bind с текстовыми файлами. Было клево поменять зону в одном месте, потом забыть изменить серийник, а она XFR’ом на второй не перетекала. Это была наша боль, которую мы этим тоже устраняли.
— А еще есть какая-нибудь статистика по тому, когда перестать пользоваться XFR…
XFR — это механизм, который был придуман в условиях плохой связанности. Условно говоря, XFR, особенно инкрементальный XFR, придуман, чтобы полосу экономить. Но в современных реалиях полоса DNS сервера 5 Мб/с, больше он не ест. Поэтому, на мой взгляд, сейчас XFR — это механизм так себе. Поэтому я бы, в принципе, не рекомендовал смотреть в его сторону. Ребята из Power DNS в документации так и пишут, что если вы можете бэкенд как-то реплицировать без XFR и прочего, сделайте это. В нашем случае получилось здорово.
— Когда Вы рассказывали про ситуацию настройки авторитетного сервера, сказали, что якобы про репликацию Master/slave надо забыть, и мы отдаем на один сервер одинаковую конфигурацию со всего. В такой ситуации в SOA записи у нас есть какой-то ns сервер. А ns записей сколько получается? То есть, не будет ли такого, поскольку существуют разные чекеры DNS сервисов, правильно он настроен или нет, он будет ругаться типа: «У тебя 1 ns сервер, это очень плохо!» и т.д. Или мы сделаем одну ns запись несколькими IP’шниками?
Несколько записей, если быть правильным. В нашей ситуации, если клиент приходит к нам с доменом, то мы в качестве ns прописываем один, два — хотите, третий дорисую, четвертый, пятый. Ns может быть огромное количество — любое. У вас на все из них будут литься запросы равномерно.
— У меня легкие уточнения по поводу PowerDNS и изменения зоны. В 4-й версии есть PDNSutil edit. Он берет из базы зону, представляет ее в текстовом классическом виде. Говоришь save — он ее загружает обратно.
По поводу исправления issue — я месяц назад разговаривал с разработчиками PowerDNS — они очень мало притрагиваются сейчас к авторитетному серверу. У них все усилия брошены на DNS dist и recursor. Поэтому если хочется запатчить, лучше самому. В ближайший год они, похоже, ничего там делать не будут.
Меня 3-я версия устраивает. 4-ю я видел только потому, что она в 16.4 по дефолту приезжает. Это было из разряда «О, что есть!»
— Последнее. Как раз в сентябре будет меняться DNSSEC ключ на корнях, не забудьте обновить!
— Вы говорили, что нельзя использовать форвардинг, нужно использовать рекурсивный резолвинг. У меня возник такой вопрос, а если все начнут использовать рекурсивные DNS — корневых серверов как бы мало?
Протокол DNS придуман так, что вы к корневым серверам будете ходить очень редко. Корневые сервера условно держат сейчас уже много Top Level Domain, но посмотрите TTL — там он огромный. Вы туда будете ходить очень редко — раз в месяц сходите, и после этого не будете.
— Вы имеете в виду, что наш резольвер отрезольвит ns из зоны.ru и будет уже ходить только к ним?
Конечно. Пока TTL не истечет, он туда ходить не будет. Я же еще раз говорю — вопрос к размышлению. Это же точка отказа. Есть у меня клиент, и у него в настройках сетевого адаптера какие-то DNS сервера. Но они не обязаны никому работать. Можно было софтово включить поддержку этого дела в ОС. Представляете, какой бы пласт проблем это сняло: отравление кэшей, например. Многие вещи просто перестали бы иметь смысл.
То есть злоумышленнику сейчас резольвер — лакомый кусок для атаки потому, что «отравлю ему кэш — отравлю кэш толпе!» Это плохо, неправильно и так не должно быть. Чтобы это решить, надо просто всунуть резольвер в коробку в ОС. Я не понимаю, почему до сих пор никто этого не делает. Это не настолько сложно.
— У Ubuntu, кажется, dnsmasq в коробке есть.
Нет, там плохо все, поверьте. dnsmasq вообще плохо. Но дело даже не в этом. Он есть только в FreeBSD, там есть unbound, он на local-хвосте висит и работает. Но процент пользователей FreeBSD — это отдельный разговор.
Умеете больше, выше, сильнее — программный комитет RootConf в составе РИТ++ ждет ваших заявок до 9 апреля. Также, как и рассказов о собственных граблях и шишках во всем спектре тем, касающихся поддержки и эксплуатации ИТ-проектов.
Что такое DNS: рассказываем простыми словами
Разберемся сразу в понятиях, что такое WWW (Web) и Internet. WWW (Web) или World Wide Web — это распределенная система, предоставляющая возможность доступа к связанным документам на компьютерах, подключенных к общей сети. WWW состоит из миллионов веб-серверов, которые обслуживают гипертекстовые документы — html-страницы и статические файлы. Группа веб-страниц объединенная общей тематикой, дизайном и связанная между собой ссылками называется сайтом. Именно Web, как комплекс технологий, куда входит и DNS дал толчок развитию Интернета. Internet — это глобальная всемирная компьютерная сеть, объединяющая миллионы других сетей и устройств. Internet — это компьютерная сеть, устройства в которой обмениваются информацией с помощью IP-адресов и стека протоколов TCP/IP. Итак, WWW — это система доступа к web-ресурсам, набор технологий, делающих возможным доступ к различной информации хранящейся на компьютерах, объединенных глобальной мировой сетью под названием Internet. DNS — это технология относящаяся к WWW. Концепция и принципы DNS были описаны в Книге Бернерс-Ли Тима «Плетя паутину: истоки и будущее Всемирной паутины» (англ. Weaving the Web: Origins and Future of the World Wide Web). По задумке праотца WWW, DNS как система должна быть распределенной, но что-то пошло не так. Теперь, когда мы точно понимает, что такое WWW и Internet, и куда относится DNS — давайте вплотную им и займемся. Начнём с простого, поймем, что такое DNS и как он работает.
Что такое DNS и как он работает?
В двух словах и без расшифровки аббревиатур и ссылок на Wiki, DNS — это технология, которая позволяет вам писать человекопонятным языком названия сайтов в поисковую строку браузера, а браузеру находить нужный сайт и отображать его. DNS занимается тем, что преобразует названия сайтов — доменные имена, которые вводят в поисковую строку браузера в IP-адреса конкретных серверов. Если бы не было DNS, вам бы пришлось запоминать IP-адреса нужных вам ресурсов и вводить их вручную в браузер. Хорошо, с общим принципом работы разобрались, но возникает вопрос: откуда DNS берёт информацию? Сайтов же миллионы, где эта вся информация хранится? Сведения о доменах и их связи с IP-адресами находятся в распределенной базе данных, которая хранится на DNS-серверах, образующих иерархию. Для работы DNS использует TCP/IP стек, TCP- или UDP-порт 53. DNS-сервер — это комбинированное понятие подразумевающие под собой ПО, которое отвечает за обработку DNS-запроса и сам «железный сервер». О них поговорим позже, сейчас давайте разберёмся с иерархией DNS и механикой запросов браузера к DNS. Когда вы вводите запрос в поисковую строку браузера, например, 1cloud.ru — браузер сначала проверит наличие DNS-записи на вашем локальном компьютере в файле hosts, если там нет нужного адреса, запрос направляется дальше — на локальный DNS-сервер интернет-провайдера пользователя, если и там записи нет, запрос уходит выше на сервера географических зон. Как только нужная DNS-запись найдена, браузер получает IP-адрес, на который посылает запрос. В ответ приходит web-страница. Графически этот процесс можно изобразить так: 
Получается, что DNS-запрос поднимается от локальных хранилищ данных до самого верхнего уровня, это быстрее, чем делать запрос сначала к корневому DNS-серверу и идти вниз. К тому же, есть нюанс — опрашивает DNS-сервера второго, верхнего и корневого уровней не браузер, а локальный DNS-сервер — resolver. Resolver находит сведения о домене, возвращает их браузеру и записывает данные в кеш на 24 часа. Именно отсюда время обновления DNS-записей может занять до 24 часов. Но это очень полезное действие, так как при следующем обращении к этому сайту, resolver просто вернет данные из кеша и сайт загрузится быстрее. Кстати, история hosts-файла довольно занятная. Ранее это было единственным способом не запоминать IP-адреса. Сейчас же hosts-файл — это по большей части исторический рудимент, который используют, пожалуй, только с целью тестирования и разработки. Выглядит это примерно так: вы купили виртуальный сервер, запустили на нём какой-то сервис, а доменное имя ещё не приобрели, а тестировать сервисы нужно. Вы вносите запись следующего вида в hosts-файл: 93.159.221.110 my_test_site.ru, сохраняете и обращаетесь по имени к своему сайту через браузер. Пути расположения hosts-файла:
- Windows XP, 2003, Vista, 7, 8, 10 — c:\windows\system32\drivers\etc\hosts;
- Linux, Ubuntu, Unix, BSD — /etc/hosts;
- macOS — /private/etc/hosts.
С помощью hosts-файла можно делать и другие полезные штуки, например, ограничить доступ к определенным Интернет-ресурсам на локальной машине.
Подробнее, что такое hosts-файл, как его использовать и редактировать, можно узнать из нашей статьи «Как найти и отредактировать файл Hosts».
Кстати, внутри статьи есть краткая видеоинструкция для тех, кто лучше воспринимает информацию визуально.
С тем, как происходит DNS-запрос разобрались, давайте теперь немного поговорим, что такое DNS-серверы и, что они хранят.
Что такое DNS-сервер и DNS-записи?
Как мы упомянули ранее DNS-сервер — это с одной стороны ПО, как правило, это BIND, NSD, PowerDNS или Microsoft DNS Server, а с другой стороны — «железный сервер». DNS-серверы бывают корневыми, они отвечают за самый верхний уровень — «.», отвечающими за геозоны — .ru,.com,.io,.by,.kz и локальные DNS-серверы.
Доменное имя отражает иерархию DNS-серверов, если читать его справа налево. Сначала идёт точка — это обращение к корневому серверу, она не отражается, но автоматически всегда подставляется, затем идёт домен верхнего уровня — .com, .ru, .kz и т.д., далее домен второго уровня — собственно само название сайта, далее может быть указан домен третьего уровня, как правило, это www или какой-то технический поддомен: api, panel, slack и т.д.
Вот как графически выглядит расшифровка доменного имени, хорошо нам всем известного ресурса:
Исторически все корневые DNS-серверы находились в Северной Америке, но с ростом популярности Интернета, они появились и в других странах. Сейчас их около 123, часть из них находится и в России:
- F.root (Москва);
- I.root (Санкт-Петербург);
- J.root (Москва, Санкт-Петербург);
- K.root (Москва, Санкт-Петербург, Новосибирск);
- L.root (Москва, Ростов-на-Дону, Екатеринбург).
Хорошо, DNS-серверы (с точки зрения железа) — это мощные серверы, которые принадлежат крупным организациям и хранят данные о DNS-зонах. Поговорим о них подробнее.
Самая простая ситуация — это когда DNS-запись содержит лишь сведения о соотношении IP-адреса сервера с доменным именем, но данных может быть куда больше. Например, у сайта, поддоменов и почтового сервера могут быть разные IP-адреса и вся эта информация должна хранится в одном месте — специальном файле на DNS-сервере, его содержимое называется DNS-зона.
Файл содержит следующие типы записей:
- А-запись — привязка IP-адреса веб-ресурса к конкретному имени домена. DNS-зона может содержать несколько A-записей;
- AAAA-запись — преобразование имени хоста в IPV6-адрес;
- MX-запись — адрес почтового сервера в текущем домене;
- CNAME-запись — запись для подключения поддомена или перенаправления на основной домен;
- NS-запись — адрес DNS-сервера, обслуживающего данный домен;
- TXT-запись — произвольная текстовая информация о доменном имени;
- SRV-запись — позволяет получить имя хоста и номер порта серверов для определенных служб;
- SPF-запись — содержит список доверенных серверов, с которых может отправляться почта данного домена, и сведения о механизме обработки писем, отправленных с других серверов;
- SOA — начальная запись зоны, которая указывает местоположение эталонной записи о домене;
- SSHFP-запись — хранит слепок ключей SSH в DNS.
С течением времени значение некоторых DNS-записей расширилось. Например, для подключения CDN используется A-запись, а в некоторых случаях ещё и NS-записи. В A-записи указывается IP-адрес CDN-сервера провайдера, а в NS — NS-сервера провайдера. Это делается для перенаправления трафика и использования DNS-серверов провайдера.
Такая схема подключения CDN используется в 1cloud. Это позволяет в среднем на 30% увеличить скорость загрузки сайта за счёт использования быстрых DNS-серверов, а нагрузка на сайт уходит полностью.
TXT-запись чаще всего используется для подтверждения владения доменом. Обычно это нужно при установке yandex и google счётчиков и запуска рекламы на этих же ресурсах.
Итак, мы затронули множество аспектов работы DNS: начиная от исходной идеи до современного применения. Настало время собрать все воедино и подвести итог.
DNS: что в итоге?
Собираем все новые знания о DNS воедино и раскладываем всё по полочкам.
- DNS — это система, которая позволяет пользователям вводить человекопонятные названия сайтов в поисковую строку, а браузеру получать IP-адрес ресурса, к которому нужно обратиться;
- Система хранения DNS-данных (зон) распределённая, а вот серверы, на которых хранятся данные выстроены иерархически. На верхнем уровне находятся корневые DNS-серверы, ниже — DNS серверы географических зон, ещё на уровень ниже — локальные DNS-серверы;
- DNS-запрос браузером посылается сначала на локальные DNS-серверы (resolve), а затем уже они ищут нужную DNS-запись по иерархии выше;
- DNS-данные для каждого домена называются DNS-зонами и хранят DNS-записи различных типов;
- DNS-зонами можно управлять с помощью платных и бесплатных сервисов.
При работе с DNS важно использовать удобные и продуктивные инструменты. В 1cloud есть бесплатный DNS-хостинг с удобной Панелью и API, который позволит автоматизировать многие процессы работы с DNS. Ознакомиться с услугой и попробовать её можно по кнопке ниже.
Как работает DNS?
Допустим, вы ввели в строке своего браузера «test.ru».
Рассмотрим работу DNS пошагово:
- Ваш браузер об IP-адресе test.ru ничего не знает и с запросом IP-адреса через специальную программу — resolver обращается к локальному серверу имен. Локальный DNS-сервер — это сервер имен вашей локальной сети или DNS-сервер вашего интернет-провайдера. «Откуда браузеру известно о существовании этого локального DNS?» — спросите вы. Все предельно просто. При настройках сетевого подключения вы прописываете IP-адреса DNS-серверов (предпочитаемого и/или альтернативного), один из которых будет отвечать на запросы, посылаемые вашим браузером через resolver — это и есть локальный или местный сервер вашей сети. Вы всегда можете посмотреть IP-адрес вашего локального DNS-сервера. Для этого достаточно посмотреть свойства сетевого подключения, используемого на вашем компьютере.
- Запрос на IP-адрес test.ru доходит до местного сервера имен. Этот сервер о данном IP-адресе ничего не знает и посылает запрос одному из корневых серверов «.» (root).
- Корневой сервер отдает локальному серверу IP-адрес сервера, который поддерживает зону .RU.
- Далее по полученному адресу локальный сервер имен обращается к DNS-серверу, который поддерживает .RU.
- Этот DNS-сервер, в свою очередь, по полученному запросу отдает IP-адрес сервера, который поддерживает зону test.ru.
- Местный DNS-сервер с запросом IP-адреса test.ru обращается к DNS-серверу зоны test.ru.
- Локальный сервер имен получает IP-адрес test.ru от DNS-сервера зоны test.ru.
- Получив адрес test.ru, локальный DNS-сервер сообщает его вашему браузеру.
| Смотрите также: | |
| Редактор DNS (бесплатно) | |
| Что такое DNS? | |
Информация для клиентов: +7 (495) 783-3-783; info@r01.ru
Техническая поддержка: +7 (495) 783-3-783; support@r01.ru
Центральный офис: г. Москва, Большой Гнездниковский переулок, дом 1, строение 2 ( м. «Тверская», выход №9, Бизнес-Центр «Вознесенский»).
DNS сервер — что это и как работает?
Хэй! Знаком ли тебе IP — адрес 172.217.7.206? Наверняка нет. И нам нет. А это один из IP — адресов, на который обращается твой браузер, при вводе youtube.ru в адресной строке. И да, нам определенно не нужно знать наизусть эту информацию, ведь у нас есть DNS — Domain Name System. О нем и поговорим.
Видео: про DNS за 4 минуты
Лучший пример из жизни — контакты на твоем смартфоне. Так, например, за контактом «Инна Тиндер НЕ БРАТЬ» скрываются вполне реальные цифры номер телефона, не так ли? Однако, когда мы ищем контакт, в поиск мы вводим не номер телефона, а имя абонента. Примерно это же делает DNS сервер — он упрощает нашу жизнь. В альтернативной реальности где роботы захватили мир он не нужен, у них обычно нет проблем с запоминанием чисел.
Рассмотрим процесс полностью
Набрав адрес нашей IT базы знаний wiki.merionet.ru в браузере и нажав enter, вы не сразу попадаете на ДНС сервер. Сначала ваш девайс проверит кэш браузера или операционной системы. Ведь если вы до этого посещали сайт, то запись о нем останется локально в кэше, чтобы в последующие разы не тратить время на поиск, гоняя туда-сюда пакеты. Если ты частый гость в нашей IT базе знаний, то так оно и работает. А вот если сайт оказался новым, тогда мы шлем запрос так называемому resolver (распознающему) DNS серверу. Обычно этот сервер находится у нашего интернет провайдера, но мы можем поменять его на другой, например, использовать, известные сервера четыре восьмерки (8.8.8.8) и четыре единицы (1.1.1.1). Он также делает сопоставление пришедшего имени сайта и его адреса в своем кэше. Если находит, то отвечает нам, а если не находит, то мы начинаем наш поход в поисках адреса и резолвер шлет запрос к корневому root серверу. 
Это сервер, который находится на самом верху DNS иерархии. Можно сказать, Шао Кан во вселенной DNS. Важно сказать, что рут сервер не один, их множество. Но этот сервер нам IP — адреса не скажет. Он лишь скажет нам к какому серверу обратиться дальше. Как регистратура, в поликлинике Это нужно для разветвления поиска, чтобы не искать IP в общей куче, а уйти в нужную ветку. Находясь в книжном магазине, чтобы найти новый роман стивена кинга, явно нужно искать не в отделе детской литературы или кулинарии, так ведь? А дальше нам нужно обратиться к нужному серверу верхнего уровня или TLD (top level domain) серверу. Домены верхнего уровня — это то что идет после последней точки .com, .org, .ru, .net. Кстати, существуют Generic Top Level Domain (gTLD), которые не привязаны к стране, например, .edu (образование), .com (коммерческие веб сайты), и ai (организации, связанные с искусственным интеллектом), а также есть Country Code Top Level Domain (ccTLD), которые привязаны к стране: .ru (Россия), .us (США) и .uk (Британия) Получается: к root приходит запрос «Что скажешь про wiki.merionet.ru, бро?», на что он отвечает: «Спроси у ccTLD сервера, так как домен верхнего уровня это .ru» 
Подуставший резолвер теперь идет к ccTLD и спрашивает: «Ну что там дальше то?» А дальше его отправляют на уровень ниже — к серверу авторитативных имен (Authoritative nameserver), который уже скажет нам нужный IP — адрес. Успех! Ну или нет. Он так же может ничего не найти и ответить, что — то в формате «извините, ваш сайт поглотила черная дыра.» Теперь резолвер ответит твоему девайсу, что у сайта wiki.merionet.ru такой-то IP — адрес. А еще резолвер запишет адрес в кэш, чтобы снова не проходить по той же цепочке. В терминологии DNS существует три типа запросов:
- Recursive (рекурсивный) — это запрос формата: «Пришли мне IP-адрес сайта wiki.merionet.ru»
- Iterative (итеративный) — это запрос формата: «Пришли мне IP-адрес сайта wiki.merionet.ru либо авторитативный DNS сервер»
- Inverse (обратный) — спрашивает все наоборот: «Какое доменное имя у такого-то IP — адреса?»