Что такое служба dns: Что такое DNS-сервер — объясняем простыми словами

alexxlab

Содержание

DNS | study

Содержание:

  • История
  • Принцип работы
  • Иерархия построения
  • Клиенты и серверы DNS
  • Виды запросов
    • Рекурсивный
    • Нерекурсивный
    • Использование кэша
    • Рекурсивная процедура разрешения имен
  • Типы серверов
  • Проблема распостранения изменений
  • DNS UPDATE
  • DNS зоны
    • Принцип работы
    • Передача зоны
  • Конфигурация DNS сервера
  • Формат DNS пакета
  • Криптосистемы с открытым ключом
  • DNSSEC

Pault Mockapetris_ — автор DNS.

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

В основе иерархической структуры базы данных DNS лежит доменное пространство имен (domain namespace), основной структурной единицей которого является домен, объединяющий сетевые узлы (хосты), а также поддомены.

Процесс поиска в БД службы DNS имени некоего сетевого узла и сопоставления этому имени IP-адреса называется “разрешением имени узла в пространстве имен DNS”.

История

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

  • Файл host и плоские имена поддерживаются и по сей день таблицами соответствия IP-адреса и имени хоста (текстовые файлы с именем hosts).
    • 127.0.0.1 localhost
    • 77/88/21/3 www.google.com

Для установления соответствия символьного имени и MAC-адреса использовались широковещательные запросы. Широковещательный способ разрешения имен реализован в NetBIOS.

  • ​ WINS — служба сопоставления NetBIOS-имен с IP-адресами.

Принцип работы

  1. Когда пользователь запускает веб-браузер и вводит название домена сайта, его ПК отправляет запрос к DNS-серверу интернет-провайдера для получения IP-адреса, на котором находится домен.
  2. Если DNS-серверы провайдера не обнаруживают в своем кэше информации о запрашиваемом сайте, то отправляют запрос на корневые DNS-серверы.
  3. Корневой DNS-сервер ищет в своей базе данных информацию о серверах имен хостинг-провайдера, на которых присутствует этот сайт. Далее, он сообщает их кэширующему DNS-серверу провайдера.
  4. После того, как кэширующий DNS-сервер интернет-провайдера получает информацию о серверах имен хостинг-провайдера он опрашивает любой из них и..
  5. в случае получения положительного результата получения IP-адреса, помещает в кэш. Кэширование используется для того, чтобы снизить как нагрузку на интернет-каналы, так и для ускорения получения результата запроса.
  6. После этого DNS-сервер провайдера передает IP-адрес браузеру пользователя, совершившему запрос сайта.
  7. И уже после этого браузер, получив IP-адрес запрашиваемого сайта..
  8. переходит на сам сайт.

Иерархия построения

Основой DNS является представление об иерархической структуре доменного имени.

Домен — узел в дереве имен, вместе со всеми подчиненными ему узлами(если таковые имеются), то есть именованное поддерево в дереве имен.

Зона — часть дерева доменных имен, размещаемая как единое целое на некотором сервере доменных имен.

Делегирование — операция передачи отвественности за часть дерева доменных имен другому лицу или организации.

Полностью определенное имя домена (Fully Qualified Domain Name)

  • Состоит из непосредственного имени домена и далее имен всех доменов, в которые он входит.
  • Имя заканчивается точкой! (ru.wikipedia.org.)
  • Если в конце имени точка не указана:
    • Точка автоматически добавляется
    • Имя считается относительным (дополнение к имени существующего домена)

Клиенты и серверы DNS

DNS состоит из трех основных частей:

  1. Пространство имен DNS и соответствующие ресурсные записи (RR, resource record) — это сама распределенная база данных DNS;
  2. Серверы имен DNS — компьютеры, хранящие базу данных DNS и отвечающие на запросы DNS-клиентов;
  3. DNS-клиенты (DNS-clients, DNS-resolvers)
    -компьютеры, посылающие запросы серверам DNS для получения ресурсных записей.

Виды запросов

Рекурсивный

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

Посылаемые в этом случае другим DNS-серверам запросы будут итеративными.

Нерекурсивный

Клиент посылает серверу DNS запрос, в котором требует дать наилучший ответ без обращений к другим DNS-серверам

Использование кэша

Рекурсивная процедура разрешения имен

Типы серверов

Authoritative response — возвращают серверы, которые являются ответственными за зону, в которой описана информация, необходимая клиенту DNS.

Non Authoritative response — возвращают серверы, которые не отвечают за зону, содержащую информацию, необходимую клиенту DNS.

Master-сервер — является ответственным за зону; описание зоны master-сервера является публичным.

Slave-сервер — является ответственным за зону; slave-сервер копирует описание зоны с master-сервера.

Кэширующий сервер — временно сохраняет сопоставление доменному имени IP-адреса и еще некоторую полезную информацию.

Скрытый сервер:

  • Для доменов 2-го уровня обязательно иметь два DNS сервера.

Проблема распостранения изменений

-> set type=soa

-> rambler.ru

 __refresh = 10800(3 hours)__
retry = 1800(30 mins)
expire = 864000(10 days)
default TTL = 3600(1 hour)

-> relarn.ru

 __refresh = 86400(1 day)__
 retry = 3600(1 hour)
 expire = 604800(7 days)
 default TTL = 86400(1 day)

DNS UPDATE

Динамический DNS (Dynamic Updates in the DNS) — технология, позволяющая информации на DNS-сервере обновляться в реальном времени и в автоматическом режиме.

DNS зоны

Зона — часть дерева доменных имен (включая ресурсные записи), размещаемая как единое целое на некотором DNS-сервере.

Целью выделения части дерева в отдельную зону является передача ответственности за соответствующий домен другому лицу или организации — это называется делегированием.

Сервер, на котором размещены ресурсные записи какой-то зоны, называется ответственным (authority) за зону. Ответы сервера на запросы о “своих” именах тоже авторитетные. Если есть только часть записей (например, в кеше), то это неавторитетный сервер / ответ.

Принцип работы

За каждую зону DNS отвечает не менее двух серверов. Один из них является первичным, primary, остальные — вторичными, secondary.

Первичный сервер содержит оригинальные базу данных DNS для своей зоны.

Вторичные серверы получают эту базу по сети от первичного, периодически спрашивая, не обновилась ли она (признаком обновления служит увеличение SERIAL в записи SOA). Если данные обновлены, вторичный сервер запрашивает передачу зоны. Передача зоны происходит по TCP/53 (в отличие от запросов — UDP/53).

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

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

Серверы DNS не обязаны находиться в том домене, за который они отвечают.

Примечание. Вторичный сервер необязательно получает данные непосредственно с первичного сервера; источником данных может служить и другой вторичный сервер. В любом случае сервер-источник данных для данного вторичного сервера называется “главным” (“master”).

Передача зоны

Два механизма копирования зоны:

  • Полное копирование (AXFR) это протокол «передачи зон» для копирования данных DNS на нескольких DNS-серверах. В отличие от обычных запросов DNS, которые требуют от пользователя предварительного знания некоторой информации о DNS, AXFR-запросы раскрывают имена поддоменов. Поскольку передача зоны – это один запрос, он может использоваться для получения данных DNS.
  • Инкрементальное копирование зоны (IXFR) —  будет передан список промежуточных изменений данных зоны, упорядоченный по серийным номерам зоны.
    Изменения будут представлены двумя списками: удалённых и добавленных записей. Изменение содержимого записи оформляется как удаление и вставка.

Основы работы со службой DNS / Раздел помощь oblako.kz в Казахстане

В инструкции рассматриваются основные технологии работы DNS, применяющиеся на практике.

Domain Name System в переводе с английского означает «Система доменного имени», то есть это распределенная система, в которой хранится и обрабатывается информация о различных доменных зонах. Применяется DNS, когда нужно соотнести IP-адрес устройства в сети с адаптированным символьным именем, более понятным для людей.

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

DNS можно назвать фундаментальной технологией интернет-пространства, ведь данные касательно IP-адресов остаются главным условием для получения ответного сигнала на запросы. Однако изначально все IP-адреса имеют числовой вид (например, 1.11.11.11), что затрудняет их восприятие для пользователей.

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

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

Базовые особенности Domain Name System:

  • В системе реализовано распределенное управление и хранение данных – сервера хранят информацию исключительно собственных делегированных доменов, а за узлы доменного имени отвечают другие;
  • DNS может кэшировать данные – информация о делегированном домене сохраняется заданное количество времени, чтобы не повышать нагрузку на сервер;
  • Наличие иерархической структуры – ответственные за конкретную доменную зону узлы делегируют другие узлы для DNS-серверов;
  • Система серверов способна к резервированию (хранению и обработки) данных об одинаковых узлах, которые логически и физически изолированы друг от друга – это позволяет сохранить данные, если случится сбой работы какого-либо узла.

Об иерархии и делегировании доменного имени

Домен является именованной веткой, расположенной в дереве имен и включающей определенный узел (например, первый уровень доменов «.org») и подчиняющиеся ему нижестоящие узлы (домены 2-го и 3-го уровней, например, «test.org» и «mail.test.org»). Чтобы обозначить иерархическую принадлежность доменного имени, применяется термин «уровень». Уровнем называют показатели позиции узлов в дереве доменов. С повышением положения уровня понижается иерархический статус домена:

  • Нулевой уровень – «.»;
  • Первый уровень – «.org»;
  • Второй уровень – «test.org»;
  • Третий уровень – «mail.test.org» и т.д.

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

Если доменное имя не включает в себя обозначение нулевого домена, его именуют «относительным». Если имя включает нулевой уровень, его обозначают как «полностью определенный» (в переводе с английского термина Fully Qualified Domain Name).

Доменной зоной называется часть древа иерархии, которая полностью трансформирована под конкретный DNS-сервер или несколько серверов, цель зоны – делегировать другим лицам ответственность за сам домен и его нижестоящие уровни (например, site.com и mail.site.com).

Делегированием считается перепоручение ответственность за ветку доменного древа другим юридическим либо физическим лицам. Делегирование осуществляет основной принцип функционирования системы, а именно распределение задач по сохранению информации и обработке данных. Происходит делегирование путем добавления «склеивающих» NS-записей дочерних зон («site.com») в ресурсную родительскую зону («.com»). NS-записи будут указывать на сервер системы доменного имени, который может принять запрос от сторонних доменов. Яркий пример – DNS-сервер организации. То есть ресурсные записи и запросы от доменов 2-го, 3-го, 4-го и так далее уровней будут храниться на сервере организации, а в родительской зоне «.com» сохранятся NS-записи с указанием на сервер фирмы.

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

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

Какие бывают ресурсные записи

Единицу хранение и передачи данных в системе доменного имени называют ресурсной записью (в переводе с английского «Resource Record»). В ней содержатся такие значения:

  • Class – показывает, может ли Domain Name System взаимодействовать с другим типом сети, не принадлежащих к ТСР/IP;
  • Name – это доменное имя зоны, для которой предназначается информация;
  • TTL (Time To Live) – ограниченный период сохранения записей третьими серверами;
  • Type – характеристика для определения формата записей и их назначений;
  • Rdata – элемент, в котором хранятся разные типы записей, их форматы и содержания;
  • Rdlen – значение длины полей данных.

Какие бывают ресурсные записи, чаще остальных применяемые в работе DNS:

  • A (IPv4 Address Record) – это значение адресной записи, связывающей доменные имена с адресами хоста;
  • AAAA (IPv6) – аналогичный с IPv4 параметр, который взаимодействует с адресами хостов формата IPv6;
  • CNAME (Canonical Name Record) – считается канонической записью имен и применяется в перенаправлении запросов на стороннее имя домена;
  • MX (Mail Exchange) – это сервис почтового обмена для обслуживающего домена;
  • NS (Name Server) – это отдельный именной сервер, ссылающийся на сервер системы, которая отвечает за функционирующий домен;
  • TXT – параметр текстового описания домена, требующийся для решения специальных заданий при подтверждении прав собственности на купленные домены и при попытке связать домен с почтовым сервером;
  • PTR (Point to Reverse) – элемент записи указателя, связывающий домен с IP компьютера, его применяют при проверке электронной корреспонденции на связь с доменом, указанным в настройках сервера почты. Если значения переменных не совпадает, машина проверят e-mail в соответствии с другими характеристиками.

Рекурсивный и нерекурсивный DNS-запрос

Рекурсия – это особый метод сервера Domain Name System обрабатывать запросы, при этом сервер выполняет полные поиски данных (информация о домене, которые ему не делегированы), если встает необходимость обращаться к посторонним серверам.

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

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

В этой статье мы поделились с вами основами работы с DNS. В нашей базе знаний вы найдёте ещё множество статей посвящённых различным аспектам работы с DNS, SSL, Linux и Windows, а среди наших бесплатных услуг есть сервис по работе с DNS. 

Бесплатный DNS →

Служба

— Служба доменных имен (DNS)

Служба доменных имен (DNS) — это интернет-служба, которая сопоставляет IP-адреса и полные доменные имена (FQDN) друг с другом. Таким образом, DNS избавляет от необходимости запоминать IP-адреса. Компьютеры, на которых работает DNS, называются серверами имен . Ubuntu поставляется с BIND (Berkley Internet Naming Daemon), наиболее распространенной программой, используемой для поддержки сервера имен в Linux.

Установка

В командной строке терминала введите следующую команду для установки DNS:

 sudo apt установить bind9

Очень полезным пакетом для тестирования и устранения проблем с DNS является пакет dnsutils . Очень часто эти инструменты уже установлены, но для проверки и/или установки dnsutils введите следующее:

 sudo apt установить dnsutils

Конфигурация

Существует множество способов настройки BIND9. Некоторые из наиболее распространенных конфигураций — это кэширующий сервер имен, первичный сервер и вторичный сервер.

  • При настройке в качестве кэширующего сервера имен BIND9 найдет ответ на запрос имени и запомнит ответ при повторном запросе домена.

  • В качестве основного сервера BIND9 считывает данные для зоны из файла на своем хосте и является полномочным для этой зоны.

  • В качестве вторичного сервера BIND9 получает данные зоны от другого сервера имен, уполномоченного для этой зоны.

Обзор

Файлы конфигурации DNS хранятся в папке /etc/bind каталог. Основной файл конфигурации — /etc/bind/named.conf , который в макете, предоставляемом пакетом, включает только эти файлы.

  • /etc/bind/named.conf.options : глобальные параметры DNS
  • /etc/bind/named.conf.local : для ваших зон
  • /etc/bind/named.conf.default-zones : зоны по умолчанию, такие как localhost, его реверс и корневые подсказки

Раньше корневые серверы имен описывались в файле /etc/bind/db.root . Вместо этого теперь он предоставляется файлом /usr/share/dns/root.hints , поставляемым с пакетом dns-root-data , и упоминается в файле конфигурации named.conf.default-zones выше.

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

Кэширующий сервер имен

Конфигурация по умолчанию действует как сервер кэширования. Просто раскомментируйте и отредактируйте /etc/bind/named.conf.options , чтобы установить IP-адреса DNS-серверов вашего интернет-провайдера:

 экспедиторов {
    1.2.3.4;
    5.6.7.8;
};

Примечание

Замените 1.2.3.4 и 5.6.7.8 на IP-адреса фактических серверов имен.

Чтобы включить новую конфигурацию, перезапустите DNS-сервер. Из командной строки терминала:

 sudo systemctl перезапустить bind9.service

См. dig для получения информации о тестировании кэширующего DNS-сервера.

Основной сервер

В этом разделе BIND9 будет настроен как Основной сервер для домена example. com . Просто замените example.com на свое полное доменное имя (полное доменное имя).

Файл зоны переадресации

Чтобы добавить зону DNS в BIND9, превратив BIND9 в основной сервер, сначала отредактируйте /etc/bind/named.conf.local :

 зона "example.com" {
    тип мастер;
    файл "/etc/bind/db.example.com";
};

Примечание

Если bind будет получать автоматические обновления файла, как с DDNS, используйте /var/lib/bind/db.example.com вместо /etc/bind/db.example.com как здесь, так и в скопировать команду ниже.

Теперь используйте существующий файл зоны в качестве шаблона для создания файла /etc/bind/db.example.com :

 sudo cp /etc/bind/db.local /etc/bind/db.example.com

Отредактируйте файл новой зоны /etc/bind/db.example.com и измените localhost. на полное доменное имя вашего сервера, оставив дополнительный . в конце. Измените 127.0.0.1 на IP-адрес сервера имен и root.localhost на действительный адрес электронной почты, но с . вместо обычного символа @ , снова оставив . в конце. Измените комментарий, чтобы указать домен, для которого предназначен этот файл.

Создайте запись A для базового домена, example.com . Кроме того, создайте запись A для ns.example.com , сервер имен в этом примере:

 ;
; Файл данных BIND для example.com
;
$TTL 604800
@ В SOA example.com. root.example.com. (
                              2; Серийный
                         604800 ; Обновить
                          86400 ; Повторить попытку
                        2419200 ; Срок действия
                         604800 ) ; Отрицательный TTL кэша
@ В NS ns.example.com.
@ В А 192.168.1.10
@ В АААА ::1
нс В А 192.168.1.10

Вы должны увеличивать серийный номер каждый раз, когда вы вносите изменения в файл зоны. Если вы вносите несколько изменений перед перезапуском BIND9, просто увеличьте серийный номер один раз.

Теперь вы можете добавить записи DNS в конец файла зоны. Дополнительные сведения см. в разделе Общие типы записей.

Примечание

Многие администраторы предпочитают использовать дату последнего редактирования в качестве серийного номера зоны, например 9.0003 2020012100 , что соответствует ггггммддсс (где сс — серийный номер)

После внесения изменений в файл зоны необходимо перезапустить BIND9, чтобы изменения вступили в силу:

 sudo systemctl перезапустить bind9.service

Файл обратной зоны

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

Редактировать /etc/bind/named.conf.local и добавьте следующее:

 зона "1. 168.192.in-addr.arpa" {
    тип мастер;
    файл "/etc/bind/db.192";
};

Примечание

Замените 1.168.192 первыми тремя октетами сети, которую вы используете. Также назовите файл зоны /etc/bind/db.192 соответствующим образом. Он должен соответствовать первому октету вашей сети.

Теперь создайте файл /etc/bind/db.192 :

 sudo cp /etc/bind/db.127 /etc/bind/db.192

Следующее редактирование /etc/bind/db.192 изменение тех же параметров, что и /etc/bind/db.example.com :

 ;
; Файл обратных данных BIND для локальной сети 192.168.1.XXX
;
$TTL 604800
@ В SOA ns.example.com. root.example.com. (
                              2; Серийный
                         604800 ; Обновить
                          86400 ; Повторить попытку
                        2419200 ; Срок действия
                         604800 ) ; Отрицательный TTL кэша
;
@ В НС нс. 
10 В PTR ns.example.com.

Серийный номер в обратной зоне также необходимо увеличивать при каждом изменении. Для каждой записи , которую вы настраиваете в /etc/bind/db.example.com , то есть для другого адреса, вам необходимо создать запись PTR в /etc/bind/db.192 .

После создания файла обратной зоны перезапустите BIND9:

 sudo systemctl перезапустить bind9.service

Дополнительный сервер

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

Во-первых, на основном сервере необходимо разрешить передачу зоны. Добавьте параметр allow-transfer в примеры определений зон Forward и Reverse в /etc/bind/named.conf.local :

 зона "example.com" {
    тип мастер;
    файл "/etc/bind/db.example. com";
    разрешить передачу {192.168.1.11; };
};
    
зона "1.168.192.in-addr.arpa" {
    тип мастер;
    файл "/etc/bind/db.192";
    разрешить передачу {192.168.1.11; };
};

Примечание

Замените 192.168.1.11 на IP-адрес вашего вторичного сервера имен.

Перезапустите BIND9 на основном сервере:

 sudo systemctl перезапустить bind9.оказание услуг

Затем на вторичном сервере установите пакет bind9 так же, как и на первичном. Затем отредактируйте /etc/bind/named.conf.local и добавьте следующие объявления для зон Forward и Reverse:

 зона "example.com" {
    тип вторичный;
    файл "db.example.com";
    мастера { 192.168.1.10; };
};
          
зона "1.168.192.in-addr.arpa" {
    тип вторичный;
    файл "db.192";
    мастера { 192.168.1.10; };
};

Примечание

Замените 192.168.1.10 на IP-адрес вашего основного сервера имен.

Перезапустите BIND9 на вторичном сервере:

 sudo systemctl перезапустить bind9.service

В /var/log/syslog вы должны увидеть что-то похожее на следующее (некоторые строки были разделены, чтобы соответствовать формату этого документа):

 клиент 192.168.1.10#39448: получено уведомление для зоны «1.168.192.in-addr.arpa»
зона 1.168.192.in-addr.arpa/IN: Начата передача.
перенос '100.18.172.in-addr.arpa/IN' с 192.168.1.10#53:
 подключен через 192.168.1.11#37531
зона 1.168.192.in-addr.arpa/IN: передан серийный номер 5
передача '100.18.172.in-addr.arpa/IN' с 192.168.1.10#53:
 Перевод завершен: 1 сообщения,
6 записей, 212 байт, 0,002 с (106000 байт/с)
зона 1.168.192.in-addr.arpa/IN: отправка уведомлений (серийный номер 5)
клиент 192.168.1.10#20329: получено уведомление для зоны «example.com»
зона example.com/IN: Передача началась.
передача 'example.com/IN' с 192.168.1.10#53: подключено через 192.168.1.11#38577
зона example.com/IN: передан серийный номер 5
перенос 'example. com/IN' из 192.168.1.10#53: Передача завершена: 1 сообщения,
8 записей, 225 байт, 0,002 с (112500 байт/с)

Примечание

Примечание. Зона передается только в том случае, если серийный номер на основной зоне больше, чем на дополнительной. Если вы хотите, чтобы ваш основной DNS уведомлял другие вторичные DNS-серверы об изменениях зоны, вы можете добавить also-notify { ipaddress; }; до /etc/bind/named.conf.local , как показано в примере ниже:

 зона "example.com" {
    тип мастер;
    файл "/etc/bind/db.example.com";
    разрешить передачу {192.168.1.11; };
    также-уведомить { 192.168.1.11; };
};
зона "1.168.192.in-addr.arpa" {
    тип мастер;
    файл "/etc/bind/db.192";
    разрешить передачу {192.168.1.11; };
    также-уведомить { 192.168.1.11; };
};

Примечание

Каталог по умолчанию для файлов неавторизованных зон — /var/cache/bind/ . Этот каталог также настроен в AppArmor, чтобы позволить демону named писать в него. Дополнительные сведения о AppArmor см. в разделе «Безопасность — AppArmor».

Поиск и устранение неисправностей

В этом разделе рассматривается диагностика проблем с конфигурациями DNS и BIND9.

Тестирование

разрешение.conf

Первым шагом в тестировании BIND9 является добавление IP-адреса сервера имен в преобразователь хостов. Первичный сервер имен должен быть настроен так же, как и другой хост для двойной проверки. Подробную информацию о добавлении адресов серверов имен к сетевым клиентам см. в разделе Конфигурация DNS-клиентов. В конце концов, ваш сервер имен 9Строка 0014 в /etc/resolv.conf должна указывать на 127.0.0.53 , и у вас должен быть параметр search для вашего домена. Что-то вроде этого:

 сервер имен 127.0.0.53
поиск example.com

Чтобы проверить, какой DNS-сервер использует ваш локальный резолвер, запустите:

 systemd-разрешение --статус

Примечание

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

копать

Если вы установили пакет dnsutils, вы можете проверить свои настройки с помощью утилиты поиска DNS:

  • После установки BIND9 используйте dig против интерфейса loopback, чтобы убедиться, что он прослушивает порт 53. Из командной строки терминала:

     копать -x 127.0.0.1

    В выводе команды вы должны увидеть строки, подобные приведенным ниже:

     ;; Время запроса: 1 мс
;; СЕРВЕР: 192.168.1.10#53(192.168.1.10)

  • Если вы настроили BIND9 в качестве сервера имен с кэшированием , «выкопайте» внешний домен, чтобы проверить время запроса:

     копать ubuntu.com

    Обратите внимание на время запроса в конце вывода команды:

     ;; Время запроса: 49 мс

    После второго раскопа должно быть улучшение:

     ;; Время запроса: 1 мс

пинг

Теперь, чтобы продемонстрировать, как приложения используют DNS для разрешения имени хоста, используйте утилиту ping для отправки эхо-запроса ICMP:

 пинг example. com

Проверяет, может ли сервер имен преобразовать имя ns.example.com в IP-адрес. Вывод команды должен выглядеть так:

.
 PING ns.example.com (192.168.1.10) 56 (84) байт данных.
64 байта от 192.168.1.10: icmp_seq=1 ttl=64 время=0,800 мс
64 байта от 192.168.1.10: icmp_seq=2 ttl=64 время=0,813 мс

именованная контрольная зона

Отличный способ проверить файлы зон — использовать утилиту named-checkzone , установленную вместе с 9Пакет 0013 bind9 . Эта утилита позволяет убедиться в правильности конфигурации перед перезапуском BIND9 и внесением изменений.

  • Чтобы проверить наш пример файла зоны пересылки, введите в командной строке следующее:

     name-checkzone example.com /etc/bind/db.example.com

    Если все настроено правильно, вы должны увидеть примерно такой вывод:

     зона example.com/IN: загружен серийный номер 6
ХОРОШО

  • Аналогично, для проверки файла зоны реверса введите следующее:

     именованная контрольная зона 1. 168.192.in-addr.arpa /etc/bind/db.192

    Вывод должен быть похож на:

     зона 1.168.192.in-addr.arpa/IN: загружен серийный номер 3
ХОРОШО

Примечание

Серийный номер вашего файла зоны, вероятно, будет другим.

Быстрая регистрация временных запросов

С помощью инструмента rndc можно быстро включать и выключать ведение журнала запросов без перезапуска службы или изменения файла конфигурации.

Чтобы включить ведение журнала запросов с на , выполните:

 sudo rndc queryвойти

Аналогично, чтобы отключить, введите:

 sudo rndc querylog отключен

Журналы будут отправлены в системный журнал и будут отображаться в /var/log/syslog по умолчанию:

, 20 января, 19:40:50 new-n1 named[816]: получена команда канала управления «querylog on»
20 января 19:40:50 new-n1 named[816]: ведение журнала запросов включено
20 января 19:40:57 new-n1 named[816]: client @0x7f48ec101480 192. 168.1.10#36139 (ubuntu.com): запрос: ubuntu.com IN A +E(0)K (192.168.1.10)

Примечание

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

Ведение журнала

BIND9 имеет множество доступных параметров конфигурации ведения журналов, но два основных из них — это канал и категория , которые настраивают, куда направляются журналы и какая информация регистрируется соответственно.

Если параметры ведения журнала не настроены, конфигурация по умолчанию:

 ведение журнала {
     категория по умолчанию { default_syslog; default_debug; };
     категория не имеет себе равных { ноль; };
};

Вместо этого давайте настроим BIND9 для отправки отладочных сообщений, связанных с DNS-запросами, в отдельный файл.

Нам нужно настроить канал , чтобы указать, в какой файл отправлять сообщения, и категорию . В этом примере категория будет регистрировать все запросы. Отредактируйте /etc/bind/named.conf.local и добавьте следующее:

 ведение журнала {
    канал query.log {
        файл "/var/log/named/query.log";
        отладка серьезности 3;
    };
    запросы категорий { query.log; };
};

Примечание

Параметр debug может иметь значение от 1 до 3. Если уровень не указан, по умолчанию используется уровень 1.

  • Поскольку демон named работает от имени пользователя bind , необходимо создать каталог /var/log/named и изменить владельца:

     sudo mkdir /var/log/named
sudo chown bind:bind /var/log/named

  • Теперь перезапустите BIND9, чтобы изменения вступили в силу:

     sudo systemctl перезапустить bind9.service

Вы должны увидеть файл /var/log/named/query.log , заполненный информацией о запросе. Это простой пример параметров ведения журнала BIND9. Дополнительные сведения о расширенных параметрах см. в разделе Дополнительная информация.

Ссылки

Общие типы записей

В этом разделе рассматриваются некоторые из наиболее распространенных типов записей DNS.

  • Запись : Эта запись сопоставляет IP-адрес с именем хоста.

     www IN A 192.168.1.12

  • Запись CNAME : используется для создания псевдонима существующей записи A. Вы не можете создать запись CNAME , указывающую на другую запись CNAME .

     веб В CNAME www

  • Запись MX : используется для определения адреса электронной почты. Должен указывать на Запись , а не CNAME .

     @ IN MX 1 mail.example.com.
почта ИН А 192.168.1.13

  • Запись NS : Используется для определения того, какие серверы обслуживают копии зоны. Он должен указывать на запись A , а не на CNAME . Здесь определяются первичный и вторичный серверы.

     @ IN NS ns.example.com.
@ В NS ns2.example.com.
нс В А 192.168.1.10
ns2 В А 192.168.1.11

  • Восходящий поток BIND9 Документация

  • DNS and BIND — популярная книга в пятом издании. Теперь также есть книга DNS и BIND на IPv6.

  • Отличное место, где можно попросить помощи у BIND9 и поучаствовать в сообществе Ubuntu Server, — это IRC-канал #ubuntu-server на freenode.

Система доменных имен (DNS) | Oracle

  • Нажмите, чтобы ознакомиться с нашей Политикой доступности
  • Перейти к содержимому

    Сожалеем. Мы не смогли найти совпадение по вашему запросу.

    Мы предлагаем вам попробовать следующее, чтобы найти то, что вы ищете:

    • Проверьте правильность написания вашего ключевого слова.
    • Используйте синонимы для введенного ключевого слова, например, попробуйте «приложение» вместо «программное обеспечение».
    • Начать новый поиск.
    Меню Меню Связаться с отделом продаж Войдите в Oracle Cloud
    1. Облако
    2. Сеть

    Попробуйте Oracle Cloud Free Tier

    Система доменных имен (DNS) — это распределенная интернет-система, которая сопоставляет удобочитаемые имена (например, Oracle.com) с IP-адресами и служит первым звеном в цифровой цепочке поставок клиентов. . Глобально распределенная служба DNS от Oracle предлагает повышенную производительность, отказоустойчивость и масштабируемость DNS, чтобы конечные пользователи могли подключаться к клиентским приложениям как можно быстрее, где бы они ни находились.

    Посмотреть видео (4:38)

    Динамический DNS (DynDNS)

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

    Узнайте больше о DynDNS

    Вход в систему и поддержка клиентов Dyn

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

    Посмотреть все логины и ресурсы поддержки

    Поддержка миграции Dyn/Oracle

    Инженерные группы интегрируют продукты и услуги Dyn в платформу Oracle Cloud Infrastructure.

    Получите помощь по миграции

    Функции DNS

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

    Отзывчивость DNSПоддерживаемые записиАвторитетный DNSВторичный DNSДинамический DNSЗащита от DDoS-атакГлобальная сеть Anycast

    Реакция DNS

    Клиенты используют лучшие в отрасли показатели времени отклика на DNS-запросы. (менее 30 миллисекунд) для оптимизации их применения и производительность цифровых активов. Распространение нового или измененного DNS записывает по всему миру менее чем за минуту.

     

     

    Поддерживаемые записи

    Oracle поддерживает 27 общих ресурсов DNS. типы записей, включая A, AAAA, CNAME, DNSKEY, MX, NS, PTR, SOA и ТЕКСТ.

     

     

     

    Авторитетный DNS

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

    Дополнительный DNS

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

     

     

     

    Динамический DNS

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

    Подробнее

    Защита от DDoS-атак

    Защита от DDoS-атак — это постоянное обнаружение и смягчение последствий платформа для распространенных объемных DDoS-атак. Сервис защищает от распространенных атак уровня 3 и 4, таких как SYN флуд, флуд UDP, флуд ICMP и усиление NTP атаки. Защита от DDoS включена во все продукты Oracle Cloud. Учетные записи инфраструктуры (OCI) и без настройки или необходим мониторинг. Мониторинг осуществляется по всему часы на предмет вредоносной активности и доставляются без дополнительной оплаты.

    Подробнее

    Глобальная сеть Anycast

    Anycast-адресация оптимизирует производительность DNS, позволяя единообразный пользовательский опыт по всему миру. В пределах сеть Anycast, на DNS-запросы отвечает точка присутствие (PoP) ближе всего к пользователю, делающему request — обеспечение максимально возможной производительности DNS.

    Ведущий поставщик телекоммуникационных услуг в скандинавских странах выбирает Oracle для DNS

    «Мы довольно легко установили и начали работать, получили отличный опыт работы с нашей пробной учетной записью и на раннем этапе получили отличное представление о продукте вместо того, чтобы просто читать документацию по продукту».

    Хакон Смепласс, системный менеджер, Telenor

    Подробнее

    Примеры использования и преимущества DNS

    • Интеллектуальная маршрутизация трафика

      Управление DNS-трафиком

      позволяет клиентам разумно направлять пользовательский трафик через Интернет, предлагая управление геолокацией, балансировку нагрузки, ASN и управление IP-префиксом. Это обеспечивает оптимизированное время отклика для веб-приложений, позволяя пользователям обращаться к ним как можно быстрее. Эта служба интегрирована со службами проверки работоспособности Oracle для мониторинга конечных точек.

      Подробнее

    • Высокая доступность

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

      Подробнее

    • Простые в использовании API

      Заказчики оптимизируют интеграцию DNS с веб-приложениями и автоматизируют рутинные задачи настройки DNS с помощью консоли, OCI API, terraform и нескольких SDK.

      Начало работы с DNS

    Стоимость DNS

    AUD – австралийский доллар ($)CAD – канадский доллар ($)EUR – евро (€)GBP – британский фунт стерлингов (£)USD – доллар США ($)──────────────── ────BGN — Болгарский лев (лв.)BRL — Бразильский реал (R$)CHF — Швейцарский франк (CHF)CZK — Чешская крона (Kč)DKK — Датская крона (kr)HKD — Гонконгский доллар (HK$) HUF — Венгерский форинт (Ft)JPY — Японская иена (¥)NOK — Норвежская крона (kr)PLN — Польский злотый (zł)RON — Румынский лей (lei)SEK — Шведская крона (kr)SGD — Сингапурский доллар ($)

    Оценщик затрат

    Ценообразование Oracle Cloud Infrastructure DNS

    Продукт

    Цена за единицу

    Метрическая система

    Службы DNS (1000 поддерживаемых зон, 25 000 записей на зону)

    1 000 000 запросов/расчетный период

    Управление трафиком DNS

    1 000 000 запросов / расчетный период

    25 июня 2019 г.

    Службы DNS, безопасности веб-приложений и доставки электронной почты Oracle Dyn теперь полностью интегрированы с пограничными службами Oracle Cloud Infrastructure

    Ашиш Мохиндроо, вице-президент по маркетингу продуктов, Oracle Инженеры Zenedge и Oracle усердно работали над интеграцией продуктов и услуг Dyn в платформу Oracle Cloud Infrastructure. Теперь предприятия могут использовать службы DNS, безопасности веб-приложений и доставки электронной почты в Oracle Cloud Infrastructure и расширять свои приложения с помощью комплексной платформы для создания, масштабирования и эксплуатации своей облачной инфраструктуры.

    Читать пост полностью

    Ресурсы службы доменных имен

    PricingDocumentation Вход для клиентов Поддержка и услуги Обучение Сопутствующее содержимое

    Тенденции
    • Обзор платформы Oracle Cloud Infrastructure (PDF)
    • Oracle Cloud Infrastructure Cloud Essentials (PDF)
    Центр архитектуры облачной инфраструктуры Oracle
    • Подробнее
    Домашние пользовательские порталы
    • Динамический DNS (DDNS)
    • Стандартный DNS
    Продукты Express/lite
    • Портал продуктов
    • Платежный портал
    Порталы продуктов (DYNID)
    • Управляемый DNS
    • Доставка электронной почты
    Поддержка продукта
    • Мой вход в службу поддержки Oracle
    • Часто задаваемые вопросы по DNS
    • Вопросы и ответы по отказоустойчивости
    • Управляемый DNS
    • Доставка электронной почты
    • Динамический DNS
    • Интернет-разведка
    Связаться со службой поддержки
    • Поддержка учетной записи (электронная почта)
    • Служба поддержки (телефон)
    • Поддержка управляемого DNS
    • Поддержка доставки электронной почты
    Подробнее
    • Часто задаваемые вопросы о DNS
    • Что такое служба доменных имен (DNS)?
    • Что такое облачная сеть?

    Начните работу с Oracle DNS

    Уровень бесплатного пользования Oracle Cloud

    Создавайте, тестируйте и развертывайте приложения в Oracle Cloud — бесплатно.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *