Dns forwarding что это
В сети Интернет DNS управляется через достаточно сложную систему авторизированных корневых серверов имён, и других менее крупных серверов имён, которые содержат и кэшируют информацию о конкретных доменах.
Протокол DNS стандартизован в RFC1034 и RFC1035.
На данный момент пакет BIND поддерживается Internet Software Consortium (www.isc.org)
Для понимания этого документа нужно понимать значения некоторых терминов, связанных с работой DNS.
. является корневой зоной
org. является зоной ниже корневой зоны
example.org является зоной под зоной org.
foo.example.org. является поддоменом, зоной под зоной example.org.
1.2.3.in-addr.arpa является зоной, в которую включены все IP-адреса, формирующие пространство адресов 3.2.1.*.
Сервера имён обычно используются в двух видах: авторитетный сервер имён и кэширующий сервер имён.
Авторитетный сервер имён нужен, когда:
нужно предоставлять информацию о DNS остальному миру, отвечая на запросы авторизированно.
зарегистрирован домен, такой, как example.org и в этом домене требуется поставить имена машин в соответствие с их адресами IP.
блоку адресов IP требуется обратные записи DNS (IP в имена хостов).
резервный (slave) сервер имён должен отвечать на запросы о домене, когда основной не работает или не доступен.
Кэширующий сервер имён нужен, когда:
локальный сервер DNS может кэшировать информацию и отвечать на запросы быстрее, чем это происходит при прямом опросе внешнего сервера имён.
требуется уменьшение общего сетевого трафика (DNS составляет около 5% всего трафика Интернет, или чуть больше).
| Файл | Описание |
|---|---|
| named | даемон BIND |
| ndc | программа управления даемоном сервера имён |
| /etc/namedb | каталог, в котором располагается вся информация о зонах BIND |
| /etc/namedb/named.conf | конфигурационный файл для даемона |
Файлы зон обычно располагаются в каталоге /etc/namedb и содержат информацию о зоне DNS, за которую отвечает сервер имён.
Так как сервер имён BIND устанавливается по умолчанию, его настройка сравнительно проста.
Чтобы даемон named запускался во время загрузки, сделайте следующие изменения в файле /etc/rc.conf
Для запуска даемона вручную (после его настройки)
Обязательно выполните следующие команды:
# cd /etc/namedb # sh make-localhost
для того, чтобы правильно создать файл /etc/namedb/localhost.rev локальной обратной зоны для loopback-интерфейса.
/* * If there is a firewall between you and name servers you want * to talk to, you might need to uncomment the query-source * directive below. Previous versions of BIND always asked * questions using port 53, but BIND 8.1 uses an unprivileged * port by default. */ // query-source address * port 53; /* * If running in a sandbox, you may have to specify a different * location for the dumpfile. */ // dump-file «s/named_dump.db»; >; // Note: the following will be supported in a future release. /* host < any; >< topology < 127.0.0.0/8; >; >; */ // Setting up secondaries is way easier and the rough picture for this // is explained below. // // If you enable a local name server, don’t forget to enter 127.0.0.1 // into your /etc/resolv.conf so this server will be queried first. // Also, make sure to enable it in /etc/rc.conf. zone «.» < type hint; file "named.root"; >; zone «0.0.127.IN-ADDR.ARPA» < type master; file "localhost.rev"; >; zone «0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.IP6.INT» < type master; file "localhost.rev"; >; // NB: Do not use the IP addresses below, they are faked, and only // serve demonstration/documentation purposes! // // Example secondary config entries. It can be convenient to become // a secondary at least for the zone where your own domain is in. Ask // your network administrator for the IP address of the responsible // primary. // // Never forget to include the reverse lookup (IN-ADDR.ARPA) zone! // (This is the first bytes of the respective IP address, in reverse // order, with «.IN-ADDR.ARPA» appended.) // // Before starting to setup a primary zone, better make sure you fully // understand how DNS and BIND works, however. There are sometimes // unobvious pitfalls. Setting up a secondary is comparably simpler. // // NB: Don’t blindly enable the examples below. 🙂 Use actual names // and addresses instead. // // NOTE. FreeBSD runs bind in a sandbox (see named_flags in rc.conf). // The directory containing the secondary zones must be write accessible // to bind. The following sequence is suggested: // // mkdir /etc/namedb/s // chown bind:bind /etc/namedb/s // chmod 750 /etc/namedb/s
Это примеры описаний прямой и обратной зон из файла named.conf для вторичных серверов.
Для каждого новой зоны, которую будет обслуживать сервер имён, в файл named.conf должна быть добавлена запись
К примеру, самая простая запись для домена example.org может выглядеть вот так:
В случае вторичной зоны информация о ней передается с основного сервера имён для заданной зоны и сохраняется в указанном файле. Если и когда основной сервер имён выходит и строя или недосягаем, то скачанная информация о зоне будет находиться на вторичных серверах и они смогут обслуживать эту зону.
Пример файла зоны example.org для основного сервера (располагающийся в файле /etc/namedb/example.org ) имеет такой вид:
$TTL 3600 example.org. IN SOA ns1.example.org. admin.example.org. ( 5 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 86400 ) ; Minimum TTL ; DNS Servers @ IN NS ns1.example.org. @ IN NS ns2.example.org. ; Machine Names localhost IN A 127.0.0.1 ns1 IN A 3.2.1.2 ns2 IN A 3.2.1.3 mail IN A 3.2.1.10 @ IN A 3.2.1.30 ; Aliases www IN CNAME @ ; MX Record @ IN MX 10 mail.example.org.
Файл зоны имеет следующий формат:
recordname IN recordtype value
Наиболее часто используемые записи DNS:
начало зоны ответственности
авторитативный сервер имен
каноническое имя для алиаса
указатель на доменное имя (используется в обратных зонах DNS)
example.org. IN SOA ns1.example.org. admin.example.org. ( 5 ; Serial 10800 ; Refresh after 3 hours 3600 ; Retry after 1 hour 604800 ; Expire after 1 week 86400 ) ; Minimum TTL of 1 day
имя домена, а также ориджин для этого файла зоны.
основной/авторитативный сервер имён для этой зоны
человек, отвечающий за эту зону, адрес электронной почты с подменённым символом @. ( > становится admin.example.org )
@ IN NS ns1.example.org.
localhost IN A 127.0.0.1 ns1 IN A 3.2.1.2 ns2 IN A 3.2.1.3 mail IN A 3.2.1.10 @ IN A 3.2.1.30
Записи с каноническими именами обычно используются для присвоения машинам псевдонимов. В этом примере www является псевдонимом для машины, соответствующей ориджину, то есть example.org (3.2.1.30). Записи CNAME могут использоваться для присвоения псевдонимов именам хостов или для использования одного имени несколькими машинами по очереди.
@ IN MX 10 mail.example.org.
Можно иметь несколько почтовых серверов с приоритетами 3, 2 и 1. Почтовый сервер, пытающийся доставить почту для example.org, сначала попробует связаться с машиной, имеющий MX-запись с самым большим приоритетом, затем с приоритетом поменьше и так далее, до тех пор, пока почта не будет отправлена.
$TTL 3600 1.2.3.in-addr.arpa. IN SOA ns1.example.org. admin.example.org. ( 5 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 3600 ) ; Minimum @ IN NS ns1.example.org. @ IN NS ns2.example.org. 2 IN PTR ns1.example.org. 3 IN PTR ns2.example.org. 10 IN PTR mail.example.org. 30 IN PTR example.org.
В этом файле дается полное соответствие имён хостов IP-адресам в нашем описанном ранее вымышленном домене.
Создайте все каталоги, которые ожидает увидеть named :
Измените и создайте базовые файлы зоны и настроек:
Постройте статистически скомпонованную копию named-xfer и скопируйте ее в песочницу:
# cd /usr/src/lib/libisc && make clean all # cd /usr/src/lib/libbind && make clean all # cd /usr/src/libexec/named-xfer && make NOSHARED=yes all # cp named-xfer /etc/namedb/bin && chmod 555 /etc/namedb/bin/named-xfer
# cd /usr/src && make cleandir && make cleandir
# cd /etc/namedb/dev && mknod null c 2 2 # chmod 666 null
Создайте символическую ссылку /var/run/ndc на /etc/namedb/var/run/ndc :
Задайте запуск named и выполнение chroot в песочницу, добавив следующее в /etc/rc.conf :
Следующим шагом является редактирование файла /etc/namedb/etc/named.conf так, чтобы named знал, какую зону загружать и где найти их на диске. Далее следует прокомментированный пример (все, что специально не прокомментировано, ничем не отличается от настройки сервера DNS, работающего не в песочнице):
Хотя BIND является самой распространенной реализацией DNS, всегда стоит вопрос об обеспечении безопасности. Время от времени обнаруживаются возможные и реальные бреши в безопасности.
Tip: Если возникают проблемы, то наличие последних исходных текстов и свежеоткомпилированного named не помешает.
Как это работает: Пара слов о 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-запросов на MikroTik
Научиться настройке MikroTik можно на онлайн курсе по оборудованию этого производителя. Автор курса является сертифицированным тренером MikroTik. Подробней Вы можете прочитать в конце статьи.
Вводная информация DNS forwarding
Если используете маршрутизатор MikroTik с настроенным VPN между офисами, вероятно приходилось сталкиваться с проблемой переадресации DNS-запросов на внутренний сервер имён. Существует DNS-сервер, который автоматически разрешает имена сайтов на другом конце туннеля. Однако, если вы запрашиваете DNS-запись для внутреннего домена, например, company.ru, на другом конце, маршрутизатор MikroTik попытается преобразовать запрос через собственный DNS-сервер, который, очевидно, не имеет необходимой информации. Разберемся с проблемой DNS forwarding более детально.
У вас всегда есть возможность создавать записи вручную в файле хостов или добавлять ручные записи на ваш DNS-сервер, однако, если количество сайтов является значительным, это может превратиться в настоящую проблему, не говоря уже о том, что ваши записи не будут обновляться в случае изменения записей DNS на корпоративном сервере.
Как ни странно, у Микротика нет простого решения для условной пересылки DNS или пересылки DNS-запросов для определенного домена на конкретный сервер, однако мы сможем решить данную задачу с помощью командной строки.
Буду считать, что читатель знаком с командной строкой Mikrotik и нет необходимости расписывать используемый функционал, – это выходит за рамки этой публикации. В решении мы будем работать на 7 уровне сетевой модели OSI или прикладном уровне.
Прежде чем начать, вам понадобится следующая информация:
Приступим к решению
1. Откройте текстовый редактор, например, notepad и вставьте следующие команды:
2. В списке команд выше необходимо изменить внутренний IP-адрес вашего маршрутизатора (зеленый цвет), имя внутреннего домена (оранжевый цвет) и адрес внутреннего DNS сервера (синий цвет) в соответствии с вашими настройками в текстовом редакторе.
3. Откройте ssh-сеанс на маршрутизаторе MikroTik и вставьте отредактированное содержимое текстового редактора в командную строку.
4. Перезагрузите маршрутизатор, чтобы изменения вступили в силу
Поиск неисправностей
Нам необходимо проверить, сможем ли попасть на сайты интрасети с другой стороны VPN. Если вы не можете, убедитесь, что туннель vpn запущен и работает, и что сайты действительно доступны через их внутренние IP-адреса, например, проверка по ping-протоколу нашего DNS-сервера 10.100.100.2. Следующим шагом является устранение проблемы с разрешением DNS при помощи таких команд, как nslookup. Сначала убедитесь, что DNS-сервер с другой стороны туннеля отвечает на запросы NS, выдавая команду:
где 10.100.100.2 DNS-сервер Интранета.
После приглашения > введите имя одного из ваших сайтов интрасети, и сервер имен должен сообщить его IP-адрес:
Если проверка проходит, то это означает, что туннель и DNS-сервер работают как нужно. Проверим перенаправление запросов через наш маршрутизатор, для этого выполним команду на клиентском устройстве:
где 172.16.100.1 — внутренний IP-адрес нашего маршрутизатора MikroTik.
Если результат не совпадает с вышеописанным, необходимо вернутся к списку команд в текстовом редакторе и убедитесь, что всё введено правильно. Исправьте ошибки и попробуйте еще раз.
MikroTik: куда нажать, чтобы заработало?
При всех своих достоинствах, есть у продукции компании MikroTik один минус – много разобщенной и далеко не всегда достоверной информации о ее настройке. Рекомендуем проверенный источник на русском языке, где все собрано, логично и структурировано – видеокурс « Настройка оборудования MikroTik ». В курс входит 162 видеоурока, 45 лабораторных работ, вопросы для самопроверки и конспект. Все материалы остаются у вас бессрочно. Начало курса можно посмотреть бесплатно, оставив заявку на странице курса. Автор курса является сертифицированным тренером MikroTik.
MikroTik Split or Forwarding DNS
Форвард зоны на другой сервер, ждали, ждали и дождались
В логах беты версии 6.47 увидел что есть изменения в работе DNS сервера на MikroTik.
Ну что-же интересно, необходимо проверить, работу и посмотреть что к чему.
Решил не использовать GNS, а взял с полки специально для тестов HAP ac2 и естественно обновил на последнюю beta версию.
IP адрес маршрутизатора с бета версией 172.20.17.100
Естественно по наитию пошли смотреть в /ip dns static
И видим нововведения, ну что же надо разобраться и проверить.
Не только A но и другие типы записей.
Раньше нем было доступно только A и AAAA записи для IPv4 и соответственно IPv6, как видим сейчас стало значительно больше.
Ну что-же давайте проверим все эти записи.
CNAME
Тип ссылки, когда мы говорим, что для данной записи ищи значение в другой записи.
Записи MX необходимы для корректной работы, а точнее поиска сервера для получения почты по протоколу SMTP.
Создадим две записи для вымышленного домена, с разными весами.
Когда вам надо сообщить, что за конкретное доменное имя отвечает другой сервер, вы должны использовать запись типа NS.
Вы можете сохранять произвольное значение, частно используется для того чтобы проходить валидация SPF для перечисления записей разрешённых хостов для отправки почты. Также при использовании DKIM подписи.
И ещё мы написали программку knockme которая также может использовать TXT для получения параметров knock-a.
Многие сервисы могут использовать для автоматического получения списка серверов например SIP, XMPP, LDAP и прочее.
Ну что же вроде всё работает.
И самая долгожданная штука это так называемый SPLIT DNS.
MikroTik Split DNS
Для начало, для чего он нужен.
Данный режим ещё называется forward zone
Представим себе ваш MikroTik выступает в роли маршрутизатора удалённого филиала. На нём поднимается VPN до центрального филиала прописываются маршруты и прочее. У вас доменная авторизация все компьютеры в домене, естественно хорошей практикой на компьютерах прописать DNS сервера который обслуживают Active Directory службы. Но в таком случае если туннель по какой-то причине упадёт ваш филиал останется без интернета, а ведь интернета может не быть в центральном филиале. Да перестанут работать различные шары и прочее, конечно для этих целей существует как минимум RODC, но навсегда есть возможность установить подобный сервис в филиале ввиду множества различных проблем.
Представим что наш dns suffix равен mycom.loc
Соответственно, а что если мы на компьютерах припишем DNS сервер адрес MikroTik, а на MikroTik укажем, что если запрос содержит mycom.loc то перенаправлять такие запросы на сервера DNS AD, а все остальные запросы перенаправлять допустим на 8.8.8.8.
Установим на MikroTik сервер DNS 8.8.8.8
и настроим forwarding зоны
Обратите внимания что мы используем регулярное вырожение.
Давайте проверим. Я решил взять реальный прод, поэтому DNS суффикс скрыл, не переживайте всё по подобию.
И так в скриншотах, с замазанным суффиксом.
Настоятельно рекомендую пока данный функционал не использовать в проде, так как это всё ещё бета версия.
