Как это работает: Пара слов о DNS
Являясь провайдером виртуальной инфраструктуры, компания 1cloud интересуется сетевыми технологиями, о которых мы регулярно рассказываем в своем блоге. Сегодня мы подготовили материал, затрагивающий тему доменных имен. В нем мы рассмотрим базовые аспекты функционирования DNS и вопросы безопасности DNS-серверов.
/ фото James Cridland CC
Изначально, до распространения интернета, адреса преобразовывались согласно содержимому файла hosts, рассылаемого на каждую из машин в сети. Однако по мере её роста такой метод перестал оправдывать себя – появилась потребность в новом механизме, которым и стала DNS, разработанная в 1983 году Полом Мокапетрисом (Paul Mockapetris).
Что такое DNS?
Система доменных имен (DNS) является одной из фундаментальных технологий современной интернет-среды и представляет собой распределенную систему хранения и обработки информации о доменных зонах. Она необходима, в первую очередь, для соотнесения IP-адресов устройств в сети и более удобных для человеческого восприятия символьных имен.
DNS состоит из распределенной базы имен, чья структура напоминает логическое дерево, называемое пространством имен домена. Каждый узел в этом пространстве имеет свое уникальное имя. Это логическое дерево «растет» из корневого домена, который является самым верхним уровнем иерархии DNS и обозначается символом – точкой. А уже от корневого элемента ответвляются поддоменые зоны или узлы (компьютеры).
Пространство имен, которое сопоставляет адреса и уникальные имена, может быть организовано двумя путями: плоско и иерархически. В первом случае имя назначается каждому адресу и является последовательностью символов без структуры, закрепленной какими-либо правилами. Главный недостаток плоского пространства имен – оно не может быть использовано в больших системах, таких как интернет, из-за своей хаотичности, поскольку в этом случае достаточно сложно провести проверку неоднозначности и дублирования.
Сопоставление имен
Давайте взглянем, как происходит сопоставление имен и IP-адресов. Предположим, пользователь набирает в строке браузера www.1cloud.ru и нажимает Enter. Браузер посылает запрос DNS-серверу сети, а сервер, в свою очередь, либо отвечает сам (если ответ ему известен), либо пересылает запрос одному из высокоуровневых доменных серверов (или корневому).
Также стоит пару слов сказать про процедуру обратного сопоставления – получение имени по предоставленному IP-адресу. Это происходит, например, при проверках сервера электронной почты. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя.
Кто управляет и поддерживает DNS-сервера?
Когда вы вводите адрес интернет-ресурса в строку браузера, он отправляет запрос на DNS-сервер отвечающий за корневую зону. Таких серверов 13 и они управляются различными операторами и организациями. Например, сервер a.root-servers.net имеет IP-адрес 198.41.0.4 и находится в ведении компании Verisign, а e.root-servers.net (192.203.230.10) обслуживает НАСА.
Каждый из этих операторов предоставляет данную услугу бесплатно, а также обеспечивает бесперебойную работу, поскольку при отказе любого из этих серверов станут недоступны целые зоны интернета. Ранее корневые DNS-серверы, являющиеся основой для обработки всех запросов о доменных именах в интернете, располагались в Северной Америке. Однако с внедрением технологии альтернативной адресации они «распространились» по всему миру, и фактически их число увеличилось с 13 до 123, что позволило повысить надёжность фундамента DNS.
Например, в Северной Америке находятся 40 серверов (32,5%), в Европе – 35 (28,5%), еще 6 серверов располагаются в Южной Америке (4,9%) и 3 – в Африке (2,4%). Если взглянуть на карту, то DNS-серверы расположены согласно интенсивности использования интернет-инфраструктуры.
Защита от атак
Атаки на DNS – далеко не новая стратегия хакеров, однако только недавно борьба с этим видом угроз стала принимать глобальный характер.
«В прошлом уже происходили атаки на DNS-сервера, приводящие к массовым сбоям. Как-то из-за подмены DNS-записи в течение часа для пользователей был недоступен известный всем сервис Twitter, – рассказывает Алексей Шевченко, руководитель направления инфраструктурных решений российского представительства ESET. – Но куда опаснее атаки на корневые DNS-сервера. В частности, широкую огласку получили атаки в октябре 2002 года, когда неизвестные пытались провести DDoS-атаку на 10 из 13 DNS-серверов верхнего уровня».
Протокол DNS использует для работы TCP- или UDP-порт для ответов на запросы. Традиционно они отправляются в виде одной UDP-датаграммы. Однако UDP является протоколом без установления соединения и поэтому обладает уязвимостями, связанными с подделкой адресов – многие из атак, проводимых на DNS-сервера, полагаются на подмену. Чтобы этому препятствовать, используют ряд методик, направленных на повышение безопасности.
Одним из вариантов может служить технология uRPF (Unicast Reverse Path Forwarding), идея которой заключается в определении того, может ли пакет с определенным адресом отправителя быть принят на конкретном сетевом интерфейсе. Если пакет получен с сетевого интерфейса, который используется для передачи данных, адресованных отправителю этого пакета, то пакет считается прошедшим проверку. В противном случае он отбрасывается.
Несмотря на то что, данная функция может помочь обнаружить и отфильтровать некоторую часть поддельного трафика, uRPF не обеспечивает полную защиту от подмены. uRPF предполагает, что прием и передача данных для конкретного адреса производится через один и тот же интерфейс, а это усложняет положение вещей в случае нескольких провайдеров. Более подробную информацию о uRPF можно найти здесь.
Еще один вариант – использование функции IP Source Guard. Она основывается на технологии uRPF и отслеживании DHCP-пакетов для фильтрации поддельного трафика на отдельных портах коммутатора. IP Source Guard проверяет DHCP-трафик в сети и определяет, какие IP-адреса были назначены сетевым устройствам.
После того как эта информация была собрана и сохранена в таблице объединения отслеживания DHCP-пакетов, IP Source Guard может использовать ее для фильтрации IP-пакетов, полученных сетевым устройством. Если пакет получен с IP-адресом источника, который не соответствует таблице объединения отслеживания DHCP-пакетов, то пакет отбрасывается.
Также стоит отметить утилиту dns-validator, которая наблюдает за передачей всех пакетов DNS, сопоставляет каждый запрос с ответом и в случае несовпадения заголовков уведомляет об этом пользователя. Подробная информация доступна в репозитории на GitHub.
Заключение
Система доменных имён разработана в еще 80-х годах прошлого века и продолжает обеспечивать удобство работы с адресным пространством интернета до сих пор. Более того, технологии DNS постоянно развиваются, например, одним из значимых нововведений недавнего времени стало внедрение доменных имен на национальных алфавитах (в том числе кириллический домен первого уровня.рф).
Постоянно ведутся работы по повышению надежности, чтобы сделать систему менее чувствительной к сбоям (стихийные бедствия, отключения электросети и т. д.), и это очень важно, поскольку интернет стал неотъемлемой частью нашей жизни, и «терять» его, даже на пару минут, совершенно не хочется.
Кстати, компания 1cloud предлагает своим пользователям VPS бесплатную услугу «DNS-хостинг» – инструмент, упрощающий администрирование ваших проектов за счет работы с общим интерфейсом для управления хостами и ссылающимися на них доменами.
Настройка разрешения имен на DNS-клиентах
Способ настройки разрешения имен на DNS-клиентов зависит от конфигурации сети. Если в ней применяется DHCP, настройка DNS осуществляется при помощи параметров DHCP-сервера. Если на компьютерах используются статические ІР-адреса или вы хотите особо настроить DNS для отдельного пользователя или системы, придется настроить DNS вручную.
Параметры DNS задаются на вкладке DNS диалогового окна Дополнительные параметры TCP/IP (Advanced TCP/IP Settings). Чтобы открыть это окно, выполните следующие действия:
1. В окне Центр управления сетями и общим доступом (Network And Sharing Center) щелкните ссылку Управление сетевыми подключениями (Manage Network Connections). В окне Сетевые подключения (Network Connections) щелкните правой кнопкой нужное подключение и выберите команду Свойства (Properties).
2. Дважды щелкните протокол, соответствующий типу настраиваемого ІР-адреса — TCP/IPv6 или TCP/IPv4.
3. Если вы используете DHCP и хотите, чтобы адрес DNS-сервера был задан посредством DHCP, установите переключатель Получить адрес DNS-сервера автоматически (Obtain DNS Server Address Automatically). В противном случае установите переключатель Использовать следующие адреса DNS-серверов (Use The Following DNS Server Addresses), а затем введите адреса основного и дополнительного DNS-серверов в соответствующих полях.
4. Щелкните кнопку Дополнительно (Advanced), чтобы открыть диалоговое окно Дополнительные параметры TCP/IP (Advanced TCP/IP Settings). Перейдите на вкладку DNS. Далее описаны параметры вкладки DNS:
• Адреса DNS-серверов, в порядке использования Укажите ІР-адрес каждого DNS-сервера, используемого для разрешения доменных имен. Чтобы добавить ІР-адрес сервера в список, щелкните Добавить (Add). Щелкните Удалить (Remove), чтобы удалить адрес выделенного сервера из списка. Для редактирования выделенной записи щелкните Изменить (Edit). Если вы указываете несколько серверов DNS, их приоритет определяется очередностью в списке. Если первый сервер не может ответить на запрос о разрешении имени хоста, запрос посылается на следующий DNS-сервер и т. д. Чтобы изменить положение сервера в списке, выделите его и воспользуйтесь кнопками со стрелками вверх и вниз.
• Дописывать основной DNS-суффикс и суффикс подключения (Append Primary And Connection Specific DNS Suffixes) Обычно по умолчанию этот переключатель установлен. Он применяется для разрешения неполных имен компьютеров в основном домене. Допустим, вы обращаетесь к компьютеру Pavel в родительском домене logi.cc. Для разрешения имя компьютера будет автоматически дополнено суффиксом DNS — pavel.logi.cc. Если в основном домене компьютера с таким именем нет, запрос не выполняется. Основной домен задается на вкладке Имя компьютера (Computer Name) диалогового окна Свойства системы (System Properties).
• Дописывать родительские суффиксы основного DNS-суффикса (Append Parent Suffixes Of The Primary DNS Suffix) По умолчанию Этот флажок установлен. Он используется для разрешения неполных имен компьютеров в иерархии родительских и дочерних доменов. В случае неудачного запроса в ближайшем родительском домене, для попытки разрешения запроса используется суффикс родительского домена более высокого уровня. Этот процесс продолжается, пока не будет достигнута вершима иерархии доменов DNS. Допустим, в запросе указано имя компьютера Pavel в родительском домене dev.logi.cc. Сначала DNS пытается разрешить имя компьютера pavel.dev.logi.cc, а потом, в случае неудачи, пытается разрешить имя pavel.logi.cc
• Дописывать следующие DNS-суффиксы (по порядку) (Append These DNS Suffixes (In Order)) Установите этот переключатель, чтобы задать использование особых DNS-суффиксов вместо имени родительского домена. Щелкните Добавить (Add), чтобы добавить суффикс домена в список. Щелкните Удалить (Remove), чтобы удалить выделенный суффикс домена из списка. Для редактирования выделенной записи щелкните Изменить (Edit). Вы можете указать несколько суффиксов домена. Если первый суффикс не позволяет разрешить имя, DNS применяет следующий суффикс из списка. В случае неудачи берется следующий суффикс и так далее. Чтобы изменить очередность суффиксов домена, выберите нужный суффикс и измените его положение кнопками со стрелками вверх и вниз.
• DNS-суффикс подключения (DNS Suffix For This Connection) В этом поле задастся DNS-суффикс подключения, перекрывающий DNS-имена, уже настроенные на использование с данным подключением.
• Зарегистрировать адреса этого подключения в DNS (Register This Connection’s Addresses In DNS) Установите этот флажок, если хотите, чтобы все ІР-адреса данного подключения регистрировались в DNS с FQDN-именами компьютеров. Этот флажок по умолчанию установлен.
• Использовать DNS-суффикс подключения при регистрации в DNS (Use This Connection’s DNS Suffix In DNS Registration) Установите этот флажок, если хотите, чтобы все ІР-адреса для данного подключения регистрировались в DNS родительского домена.
Записки IT специалиста
Технический блог специалистов ООО»Интерфейс»
Расширенная настройка DNS и DHCP в роутерах Mikrotik
Со службами DHCP и DNS знакомы, пожалуй все, ведь это базовые службы для сетей любого размера. Но их настройка обычно сводится к установке базовых параметров и затем о них забывают. Действительно, ну что может быть в них интересного, особенно если это неполноценные сервера, а службы роутера. Это так, если говорить о бытовых роутерах, где пользователю стараются не давать в руки лишних инструментов, но RouterOS рассчитана на иную аудиторию и предоставляет широкий спектр возможностей, которыми глупо не воспользоваться.
DNS (Domain Name System)
Как видим, Mikrotik использовал значение TTL из SOA-записей, ни о каких 7 днях речи не идет. Тогда для чего нужна эта настройка? Вы можете обновлять кеш чаще, чем это указано в TTL-домена. Если значение максимального TTL Mikrotik будет меньше, чем указанное в SOA-домена, то будет использоваться именно оно.
Это может быть полезным, если вы внесли какие-либо изменения во внешнюю зону и желаете быстрее обновить кеш. Как показывает практика, публичные сервера, такие как Google, OpenDNS или Яндекс тоже часто игнорируют TTL из SOA и обновляют свой кеш чаще.
Очистить кеш можно кнопкой Flush Cache в окне Cache или командой в терминале:
Поэтому, если у вас нет иных инструментов логирования и статистики, то изучение записей кеша вполне позволит получить картину сетевой активности ваших пользователей.
Проверим, как это работает. Выполним разрешение имени на клиенте:
Но имейте ввиду, работать такое разрешение имен будет только на Windows машинах, на Linux вы получите ошибку:
Но так как большинство сетей имеет преимущественно Windows ПК, то особых проблем плоские имена не доставят, и вы можете смело добавлять их записи на DNS Mikrotik вместо того, чтобы прописывать в hosts на каждой машине.
Так так, скажет внимательный читатель, это же можно использовать для блокировки нежелательных ресурсов и будет прав. Если мы не хотим, чтобы пользователи сидели в соцсетях, то добавим на сервер записи, который будут разрешать такие запросы в 127.0.0.1:
Проверим?
Вроде бы работает, но недостаток такого метода, что мы заблокировали только основной домен и пользователь легко сможет зайти через мобильный поддомен:
Чтобы этого избежать следует использовать регулярные выражения. К сожалению, в большинстве инструкций в интернете приводятся неправильные выражения, с которыми фильтр работать не будет, поэтому мы советуем использовать для создания и проверки регулярных выражений ресурс regex101.com. Это избавит вас от ошибок и вопросов в стиле «я сделал все как написано в статье, но ничего не работает».
Скажем, чтобы заблокировать домен vk.com со всеми поддоменами нам потребуется выражение:
Внесем его в соответствующее поле Mikrotik:
И проверим, теперь любое, даже заведомо не существующее имя в домене vk.com будет разрешаться в 127.0.0.1, что нам и требовалось.
Но это правило заблокирует также любые ресурсы, которые заканчиваются на vk.com, для того, чтобы этого избежать, нам потребуется более сложное выражение:
Потом создаем точно такое же правило для протокола tcp. Эти же самые действия можно быстро выполнить в терминале:
Теперь любые DNS-запросы от пользователей сети будут перенаправляться на наш DNS-сервер на роутере, что сделает любые попытки обойти локальный DNS бессмысленными.
Как видим, DNS-сервер роутера Mikrotik, несмотря на кажущуюся простоту, в общем не так уж и прост и дает в руки администратора достаточно широкие возможности.
DHCP (Dynamic Host Configuration Protocol)
Когда речь заходит о DHCP, то обычно имеют ввиду автоматическое присвоение сетевых параметров, таких как IP-адрес, маска, шлюз и DNS-сервера. Но на самом деле возможности протокола намного шире и позволяют настроить очень многие сетевые параметры. Все возможности протокола описаны в RFC 2132, но мы не будем забираться столь глубоко, а рассмотрим в качестве примера только несколько наиболее популярных опций.
Обратите внимание, что значение value берется в кавычки два раза, в двойные и одинарные.
Наборам желательно давать осмысленные названия, чтобы впоследствии вы легко могли понять для чего он предназначен. Теперь назначим его для применения на всю область DHCP-сервера. Перейдем на закладку DHCP и откроем запись нашего сервера, в поле DHCP Option Set укажем имя созданного нами набора.
Теперь обновим параметры DHCP и сразу увидим полученный DNS-суффикс:
После этого все плоские имена, которые вы добавили на DNS-сервер следует дополнить до FQDN, т.е. вместо HV-CORE-01 написать hv-core-01.interface31.lab (регистр записи значение не имеет).
Проверим:
Как видим, одной проблемой стало меньше, плоские имена нормально дополняются до FQDN и нормально разрешаются на нашем DNS вне зависимости от используемой ОС.
Также довольно часто используются опции: 42 (NTP Servers), 60, 66 (TFTP Server Name), 67 (Bootfile-Name). Имейте ввиду, что ОС Windows не запрашивает у DHCP-сервера опцию 42 и для нее установить таким образом сервер времени не удастся.
Отдельно коснемся того, как указывать IP-адреса. Протокол предусматривает передачу значений в шестнадцатеричном (Hex) формате, но RouterOS позволяет использовать и строковые значение, для этого значение Value должно содержать привычное написание адреса, взятое в одинарные кавычки:
или его шестнадцатеричное значение, которое должно начинаться с префикса 0х:
Если адресов несколько, то указываем каждый, взяв в одинарные кавычки, без пробелов между ними:
В шестнадцатеричном виде мы добавляем второе значение в конец строки, также без пробелов:
В терминале это будет выглядеть так:
Для перевода значений IP-адреса в шестнадцатеричное значение, можно использовать любой онлайн-калькулятор, мы при подготовке данного материала использовали этот.
Еще одна интересная возможность открывается в выдаче отдельным узлам своего набора опций. Следующий сценарий подойдет домашним пользователям, как достаточно простой и эффективный способ обеспечить безопасность ребенка в интернет.
Суть ее состоит в следующем: мы выборочно изменяем DNS-сервера детских сетевых устройств на безопасные DNS, например, Яндекс Семейный, SkyDNS, AdGuard и т.д. Тем, кто захочет реализовать этот сценарий в сети предприятия следует иметь ввиду, что в этом случае таким клиентам будут недоступны возможности собственного DNS-сервера, т.е. все то, о чем мы говорили в первой части статьи.
Итак, сначала создадим новую DHCP опцию с кодом 6 и укажем в значении сервера Яндекс Семейного:
Теперь создадим новый набор опций и добавим туда опцию YandexDNS.
Теперь перейдем на закладку Leases, где находится список выданных в аренду адресов и найдем там детское устройство, после чего откроем запись и выполним резервирование адреса, нажав Make Static:
Закроем и заново откроем эту запись и в поле DHCP Option Set укажем созданный нами набор с безопасными серверами:
Теперь проверим на клиенте, какие DNS-сервера он получил:
Все верно, это семейные сервера Яндекса. Попробуем посетить какой-нибудь сайт «для взрослых»:
Отлично, фильтрация работает, теперь можно гораздо меньше переживать, что ребенок увидит неподобающий контент, в тоже время взрослые члены семьи могут использовать интернет без ограничений.
Также можно быстро добавить нужные правила командой:
Напоследок рассмотрим опции 121 (Classless Static Routes) и 249 (MS Routes), которые предназначены для передачи статических маршрутов. Первая опция предусмотрена RFC 2132, вторая является «художественной самодеятельностью» Microsoft, поэтому следует указывать обе из них с одинаковым содержимым.
Во избежание ошибок мы советуем задавать маршруты в HEX-формате, синтаксис предусмотрен следующий:
Таким образом первый маршрут должен выглядеть так:
Итоговое значение будет (не забываем про 0x вначале):
Добавим опции командами:
или через графический интерфейс:
Обновим параметры DHCP и проверим таблицы маршрутизации на клиентах. Windows-клиент:
Linux-клиент:
В заключение хочется добавить, что данная статья не должна рассматриваться вами как догма, все пункты которой требуется обязательно применить. Данный материал имеет цель показать те скрытые возможности привычных сервисов, которые обычно не затрагиваются в руководствах по базовой настройке. После чего уже сам администратор должен решать, что он будет применять в своей сети и зачем. К сожалению, объем статьи не позволяет нам охватить все возможности DHCP, что-то из них мы отразим в будущих статьях, а что-то вам придется изучать самостоятельно. Но надеемся, что данный материал окажется вам полезен и даст дополнительный стимул к изучению всех возможностей используемых протоколов.
Дополнительные материалы:
Mikrotik
The Dude
Помогла статья? Поддержи автора и новые статьи будут выходить чаще:
Или подпишись на наш Телеграм-канал: 
