Ip dns сервера: Страница не найдена (ошибка 404)

Содержание

что это, для чего нужен, настройка основного сервера

Виталий Леонидович Черкасов

Системный администратор, инженер компьютерных систем.

Задать вопрос

Каждый сайт в интернете физически расположен на сервере, который по сути является компьютером и имеет свой IP-адрес. Пользователю неудобно запоминать набор цифр, чтобы попасть на нужный сайт. Поэтому придумали доменные имена, например, такие как google.com, которые проще запоминать. Теперь не нужно знать набор цифр, который указывает на тот или иной сайт. Для того, чтобы перевести строку символов, которые пользователь набирает в строке браузера, в IP-адрес, существуют DNS. Рассмотрим, что такое DNS-сервер, принцип его работы и настройку.

Определение

DNS сервер нужен для сопоставления имен интернет-доменов, вводимых пользователем (например, mail.ru или rambler.ru), с их реальными IP-адресами. Это база данных, в которой содержатся IP-адреса и соответствующие им доменные имена, и используется для преобразования доменного имени в IP-адрес.

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

Работа DNS похожа на работу со списком контактов смартфона. Вы находите требуемый контакт по имени, нажимаете на значок «позвонить», телефон набирает нужный номер и соединяет с соответствующим абонентом.

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

Рассмотрим подробнее, как работает dns сервер:

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

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

Где находятся

Самые важные DNS-серверы — корневые, которые содержат информацию о нахождении других серверов, более низкого уровня. Впервые они появились в Северной Америке, но потом их стали разворачивать и в других странах. Сейчас корневых серверов всего 13. Однако для увеличения надёжности работы интернет были созданы их копии, и их общее количество возросло до 123.

Наибольшее из количество расположено в Северной Америке, где их 40, что составляет 32,5% от общей численности. На втором месте по числу серверов находится Европа — 35 серверов (28,5%). 6 (4,9%) серверов имеется в Южной Америке и 3 (2,4%) в Африке. Также есть свои DNS-серверы есть в Австралии, Китае и даже Исландии. Общая закономерность расположения серверов такая: чем интенсивнее используется интернет, тем больше серверов.

В России есть несколько корневых серверов:

  • F.root – расположен в Москве;
  • I.root – находиться в Санкт-Петербурге;
  • J.root – распределённый, расположен в Москве, Санкт-Петербурге;
  • K.root – еще один распределённый, находится в трёх городах: Москва, Санкт-Петербург и Новосибирск;
  • L.root – присутствует сразу в трёх городах: Москва, Ростов-на-Дону и Екатеринбург.

Преимущества публичных DNS

Иногда лучше использовать не те ДНС серверы, которые по умолчанию предоставляет провайдер, а воспользоваться публичными. Для этого существуют следующие причины:

  • использование быстрых публичных DNS увеличит скорость работы интернета;
  • иногда используемые по умолчанию серверы работают нестабильно, в этом случае использование публичных серверов повысит надёжность;
  • некоторые публичные DNS включают дополнительные функции по фильтрации данных, которые увеличивают безопасность компьютера;
  • публичные DNS помогут обойти ограничения по расположению, например, можно будет смотреть видео в ютубе, на котором раньше было написано: «Это видео недоступно в вашей стране».

Топ 10 публичных DNS

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

Google

Публичный DNS от компании Google является одним из самых быстрых и безопасных. Чтобы его настроить, нужно ввести IP-адрес «8.8.8.8» в качестве первичного DNS, а «8.8.4.4» в качестве дополнительного.

OpenDNS

OpenDNS предлагает один из лучших облачных серверов, который защитит ваш компьютер. Он имеет два бесплатных решения: OpenDNS Home и OpenDNS Family Shield.

OpenDNS Home идёт вместе с защитой от фишинга. Для его настройки нужно ввести два адреса DNS: предпочитаемый 208.67.222.222 и альтернативный 208.67.222.220.

В решении OpenDNS Shield имеется блокировка контента только для взрослых. Чтобы воспользоваться, введите следующие DNS адреса: основной 208.67.222.123, дополнительный 208.67.220.123.

Norton ConnectSafe

Компания Norton разрабатывает не только антивирусные программы, но и предлагает воспользоваться их сервером доменных имен. Данный облачный сервис защищает ПК от фишинговых сайтов. Он поставляется в трёх версиях, с разными предварительно настроенными фильтрами:

  1. безопасность;
  2. безопасность и порнография;
  3. безопасность, порнография и другое.

Comodo Secure DNS

Благодаря тому, что Comodo Secure DNS рассылает ваш запрос на большое количество глобальных серверов, она способна обеспечить высокую скорость работы в интернете. Чтобы воспользоваться этим сервисом, введите основной адрес «8.26.56.26» и дополнительный «8.20.247.20».

Level3

Level3 – это ещё один бесплатный качественный сервис. Он работает на следующих IP-адресах: предпочитаемый 209.244.0.3, альтернативный 208.244.0.4.

DNS Advantage

DNS Advantage – это очень быстрый сервер, который поможет работать в интернете быстрее и безопаснее. Его основной адрес: «156.154.70.1», а дополнительный «156.154.71.1».

Dyn

Бесплатный сервис Dyn в основном предназначен для защиты вашего ПК от фишинговых атак. Для того, чтобы начать работать с этим сервисом, настройте следующие параметры: адрес основного DNS-сервера «216.146.53.35», альтернативного «216.146.36.36».

SafeDNS

Служба SafeDNS основана на облачной технологии, что помогает защитит ПК. Для работы с ней нужно задать следующие адреса: предпочитаемый «195.46.39.39», дополнительный «195.46.39.40».

DNS.Watch

DNS.Watch – это бесплатный, быстрый и незаметно работающий сервис DNS. Для его настройки введите на своём компьютере следующие IP-адреса: предпочитаемый DNS-сервер «84.200.69.80», альтернативный «84.200.70.40».

Настройка в Windows

Чтобы настроить DNS-сервер в операционной системе Windows любой из версий, начиная с ХР и заканчивая 10, нужно:

Статья помогла6Не помогла2

Настройка DNS сервера на Windows Server 2012 и старше

DNS (Domain Name System, Система Доменных имен) – система, позволяющая преобразовать доменное имя в IP-адрес сервера и наоборот.

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

Настройка сетевого адаптера для DNS-сервера

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

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

Наведя курсор на значок сети в системном трее, можно вызвать всплывающую подсказку с краткими сведениями о сетях. Из примера выше видно, что присоединённая сеть это Network 3.

Далее предстоит проделать цепочку действий:

  • Нажать правой клавишей мыши Пуск, в выпадающем меню выбрать пункт Сетевые подключения;
  • Правой кнопкой мыши нажать на необходимый сетевой адаптер, в меню выбрать Свойства;
  • В окне свойств выбрать IPv4 и нажать на кнопку Свойства;
  • Заполнить соответствующие поля необходимыми данными:

Здесь в качестве предпочитаемого DNS-сервера машина назначена сама себе, альтернативным назначен dns.google [8.8.8.8].

Установка роли DNS-сервера

Для установки дополнительных ролей на сервер используется Мастер Добавления Ролей и Компонентов, который можно найти в Диспетчере Сервера.

На верхней навигационной панели Диспетчера сервера справа откройте меню Управление, выберите опцию Добавить Роли и Компоненты:

Откроется окно Мастера, в котором рекомендуют убедиться что:

1. Учётная запись администратора защищена надёжным паролем.

2. Настроены сетевые параметры, такие как статические IP-адреса.

3. Установлены новейшие обновления безопасности из центра обновления Windows.

Убедившись, что все условия выполнены, нажимайте Далее;

Выберите Установку ролей и компонентов и нажмите Далее:

Выберите необходимы сервер из пула серверов и нажмите Далее:

Отметьте чек-боксом роль DNS-сервер и перейдите Далее:

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

Оставьте список компонентов без изменений, нажмите Далее:

Прочитайте информацию и нажмите Далее:

В последний раз проверьте конфигурацию установки и подтвердите решение нажатием кнопки Установить:

Финальное окно Мастера сообщит, что установка прошла успешно, Мастер установки можно закрыть:

Создание зон прямого и обратного просмотра

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

Зоны прямого просмотра предназначены для сопоставления доменного имени с IP-адресом.

Зоны обратного просмотра работают в противоположную сторону и сопоставляют IP-адрес с доменным именем.

Создание зон и управление ими осуществляется при помощи Диспетчера DNS.

Перейти к нему можно в правой части верхней навигационной панели, выбрав меню Средства и в выпадающем списке пункт DNS:

Создание зоны прямого просмотра
  • Выделите каталог Зоны Прямого Просмотра, запустите Мастер Создания Новой Зоны с помощью кнопки Новая зона на панели инструментов сверху:
  • Откроется окно Мастера с приветствием, нажмите Далее:
  • Из предложенных вариантов выберите Основная зона и перейдите Далее:
  • Укажите имя зоны и нажмите Далее:
  • При необходимости поменяйте название будущего файла зоны и перейдите Далее:
  • Выберите, разрешить динамические обновления или нет. Разрешать не рекомендуется в силу значимой уязвимости. Перейдите Далее:
  • Проверьте правильность выбранной конфигурации и завершите настройку, нажав кнопку Готово:
Создание зоны обратного просмотра
  • Выделите в Диспетчере DNS каталог Зоны Обратного Просмотра и нажатием кнопки Новая зона на панели инструментов сверху запустите Мастер Создания Новой Зоны:
  • Выберите тип Основная Зона, перейдите Далее:
  • Выберите назначение для адресов IPv4, нажмите Далее:
  • Укажите идентификатор сети (первые три октета сетевого адреса) и следуйте Далее:
  • При необходимости поменяйте название будущего файла зоны и перейдите Далее:
  • Выберите, разрешить динамические обновления или нет. Разрешать не рекомендуется в силу значимой уязвимости. Перейдите Далее:
  • Проверьте правильность выбранной конфигурации и завершите настройку, нажав кнопку Готово:
Создание A-записи

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

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

Запись A — запись, позволяющая по доменному имени узнать IP-адрес.

Запись PTR — запись, обратная A записи.

  • В Диспетчере DNS выберите каталог созданной ранее зоны внутри каталога Зон Прямого Просмотра. В правой части Диспетчера, где отображается содержимое каталогов, правой кнопки мыши вызовите выпадающее меню и запустите команду «Создать узел (A или AAAA)…»:
  • Откроется окно создания Нового Узла, где понадобится вписать в соответствующие поля имя узла (без доменной части, в качестве доменной части используется название настраиваемой зоны) и IP-адрес. Здесь же имеется чек-бокс Создать соответствующую PTR-запись — чтобы проверить работу обеих зон (прямой и обратной), чек-бокс должен быть активирован:

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

  • Также можно добавить записи для других серверов:
  • Добавив все необходимые узлы, нажмите Готово.
Проверка
  • Проверьте изменения в каталогах обеих зон (на примере ниже в обеих зонах появилось по 2 новых записи):
  • Откройте командную строку (cmd) или PowerShell и запустите команду nslookup:

Из вывода команды видно, что по умолчанию используется DNS-сервер example-2012.com с адресом 10.0.1.6.

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

  • Запрос по домену;
  • Запрос по IP-адресу:

В примере получены подходящие ответы по обоим запросам.

  • Можно попробовать отправить запрос на какой-нибудь внешний ресурс:

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

Для сравнения все те же запросы выполнены на сервере, где не были настроены прямая и обратная зоны:

Здесь машина сама себе назначена предпочитаемым DNS-сервером. Доменное имя DNS-сервера отображается как неопознанное, поскольку нигде нет ресурсных записей для IP-адреса (10.0.1.7). По этой же причине запрос 2 возвращает ошибку (Non-existent domain).

Средняя оценка: 5.0 Оценили: 2

A05F8E9 г. Алматы ул. Наурызбай Батыра, д. 122

+7 (727) 350-53-42 106 28 ТОО «LINCORE – облачные технологии»

A05F8E9 г. Алматы ул. Наурызбай Батыра, д. 122

+7 (727) 350-53-42 106 28 ТОО «LINCORE – облачные технологии» 106 28

Появление DNS и принцип её работы — Джино • Журнал

29 декабря 2021 г.

Время чтения: 3 минуты

К началу 80-х годов XX века ARPANET — прообраз современной Internet — достигла таких размеров, что игнорировать вопрос об адресации сообщений внутри сети стало невозможно. Чтобы отправить сообщение с одного компьютера на другой, пользователь должен был не только скачать файл со списком всех подключённых к сети компьютеров, но и самостоятельно прописать путь движения сообщения от одного узла к другому.

Этот путь имел примерно такой вид: utzoo!decvax!harpo!eagle!mhtsa!ihnss!ihuxp!grg

Файл HOSTS.TXT с именами и адресами всех подключённых к сети компьютеров хранился на сервере Стэнфордского университета в единственном экземпляре. Новые компьютеры добавлялись в этот список вручную: новый пользователь должен был позвонить в рабочее время в Сетевой Информационный Центр и попросить присвоить его компьютеру имя, адрес и добавить их в файл.

Появление системы доменных имён

Решение проблемы предложили одни из создателей сети ARPANET — Пол Мокапетрис и Джон Постел в 1983 году. Они разработали теоретическую концепцию и указания по практической реализации системы доменных имён (Domain Name System).

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

В 1984 году группа студентов из университета Беркли предложила один из первых вариантов программного обеспечения для DNS-сервера — Berkeley Internet Name Domain (BIND). Он до сих пор остаётся одним из самых популярных ПО для работы DNS-серверов и используется в том числе на корневых DNS-серверах, поддерживающих работу всей структуры DNS.

По словам владельца компании Internet Systems Consortium (некоммерческая организация, поддерживающая работу инфраструктуры Internet), до 2000 года BIND так или иначе опирался на изначальный код, написанный теми самыми студентами в 1984 году.

Как устроена DNS

DNS (Domain Name System — система доменных имён) — это иерархически организованная система серверов, хранящих информацию о доменных именах и привязанных к ним IP-адресах.

Каждый сервер в системе отвечает за определённый уровень или ветку доменных имён.

В памяти DNS-сервера хранится следующая информация:

  • какие домены привязаны к IP-адресам в его зоне ответственности;

  • NS-записи со ссылками на другие DNS-сервера;

  • другая служебная информация.

Также в кэш-памяти каждого DNS-сервера хранится информация о доменных именах и их IP-адресах, которые не принадлежат к зоне ответственности этого сервера, но к которым недавно обращались из его зоны.

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

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

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

Корневые серверы не хранят записи об IP-адресах и привязанных к ним доменах, но они хранят NS-записи — ссылки на DNS-серверы с необходимой информацией. Так запрос движется дальше по цепочке из NS-записей к серверу с нужной информацией.

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

Проблемы в работе DNS

Проблемы могут возникнуть при переносе доменов по следующим причинам:

  1. NS-записи на серверах обновляются не моментально. Это значит, что после переноса домена некоторое время корневые DNS-серверы ведут запросы пользователей к старому серверу, на котором сайта больше нет.

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

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

Запомнить

DNS — это система, которая облегчает адресацию в интернете.

Система была разработана в 1983 году.

В памяти DNS хранится информация о доменных именах и привязанных к ним IP-адресах.

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

DNS Failover: основные понятия и ограничения

Что такое отказоустойчивость DNS?

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

Связанные концепции DNS

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

DNS-запрос

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

Авторитетный сервер имен

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

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

DNS-запись A

Запись A — это тип записи DNS, хранящийся в файле зоны на сервере имен DNS. Файл зоны — это текстовый файл, который содержит всю информацию DNS для домена или поддомена. Запись A просто записывает IP-адрес, сопоставленный с именем хоста, например:

.
 www А 192.126.100.1 

Балансировка нагрузки DNS с циклическим перебором

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

 www А 192.126.100.1
www А 192.126.100.2
www А 192.126.100.3 

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

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

Кэш DNS

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

Например, после того, как DNS Resolver один раз запрашивает IP-адрес «www.example.com» и выполняет рекурсивный запрос для получения правильного IP-адреса, он сохранит его в кеше. В следующий раз, когда клиент запросит то же имя хоста, преобразователь предоставит тот же IP-адрес из кэша.

Чтобы предотвратить устаревание кэша, записи DNS содержат параметр Time to Live (TTL). Предполагается, что различные компоненты в процессе DNS сохранят кэшированные записи DNS только в течение указанного периода TTL.

Как работает традиционный отказоустойчивый DNS

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

Циклическое аварийное переключение DNS на стороне клиента

Браузер или сетевое устройство обычно распознают, что для одного и того же имени хоста указано несколько IP-адресов. Если первый IP-адрес не отвечает, он будет ждать 30 секунд и попытается использовать последующие IP-адреса в списке.Это обеспечивает аварийное переключение, потому что, если сервер не работает, клиент в конечном итоге перенаправится на другой IP-адрес и достигнет резервного сервера.

ПРЕДУПРЕЖДЕНИЕ. Отработка отказа на стороне клиента — это , а не , как рекомендуемый вариант. Переключение на стороне клиента может привести к DNS-атакам, таким как повторная привязка DNS и закрепление DNS. Кроме того, он совместим не со всеми браузерами и операционными системами и может привести к непредсказуемому поведению заголовков управления кешем.

Автоматическое аварийное переключение DNS на стороне сервера с резервированием

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

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

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

3 Ограничения традиционного аварийного переключения DNS

№ 1: обновляется только один раз в каждом цикле TTL

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

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

При TTL = 30 с, что дает еще 10 секунд для мониторинга, чтобы обнаружить сбой, 50% преобразователей DNS обновятся с новой записью DNS в течение 25 секунд после сбоя.Почти 100% пользователей будут перенаправлены в течение минуты.

№2: Обнаружение отказа не обнаружено

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

№ 3: Неизвестно о нагрузке, географическом положении или сервисных возможностях

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

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

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

Быстрое и эффективное аварийное переключение DNS с помощью DNS-служб следующего поколения

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

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

NS1 может решить две из трех проблем, связанных с традиционным аварийным переключением DNS:

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

DNS-кэширование и TTL по-прежнему являются проблемой, но установка значения TTL, равного 30 секундам, позволит перенаправить 50% пользователей в течение 25 секунд после сбоя, а 100% пользователей — в течение минуты.

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


Создайте свой собственный DNS-сервер в Linux

В предыдущей статье этой серии, состоящей из двух частей, «Введение в DNS (систему доменных имен)» я описал структуру базы данных DNS и настройку служб имен на клиенте. . Я также перечислил и описал некоторые из наиболее распространенных записей DNS, с которыми вы, вероятно, столкнетесь при создании сервера имен или просто пытаетесь интерпретировать результаты команды dig .

В этой статье я покажу вам, как создать собственный сервер имен, используя BIND (домен имен в Интернете Беркли). Это не так сложно, как вы думаете, особенно потому, что вы можете сделать это в два этапа.

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

Настройка DNS-сервера с помощью BIND

Настроить сервер имен с помощью BIND довольно просто, поэтому я покажу вам, как это сделать на любом компьютере, который у вас есть для экспериментов.Этот небольшой лабораторный проект покажет вам, как установить и настроить BIND на вашем компьютере в качестве кэширующего сервера имен, протестировать его, а затем настроить в качестве основного сервера имен с файлом зоны, который вы можете использовать в качестве преобразователя имен для вашей сети или просто для тестирования.

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

Моя установка

Вам нужен только один компьютер для выполнения всех задач, кроме одной, в этом лабораторном проекте. Я использую эту настройку на своем гораздо более мощном ThinkPad, потому что серверы имен, предоставляемые DHCP (протокол динамической конфигурации хоста), когда я подключаюсь к не домашним сетям с использованием проводных или беспроводных подключений, иногда могут быть ненадежными. Чтобы показать, что почти любой хост может хорошо работать в качестве сервера имен, я протестировал этот проект на старом нетбуке ASUS EeePC 900.

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

Файл hosts

Во-первых, давайте посмотрим на файл /etc/hosts . В состоянии по умолчанию в файле hosts должно быть только две строки, первые две строки показаны в листинге 1 ниже.

  127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4 
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

# Хосты лаборатории
192.168.25.1        server
192.168.25.21      host1
192.168.25.22      host2
192.168.25.23      host3
192.168.25.24      host4

Хотя вы можете добавлять имена хостов и их соответствующие IP-адреса, как показано в листинге 1, это не оптимальное решение для служб имен, особенно во время путешествий. Если в вашем файле hosts есть другие записи, вам может потребоваться закомментировать их на время этого проекта, если они мешают именованию или IP-адресам.У большинства из вас не будет никаких записей, кроме двух строк по умолчанию.

Подготовка

Кэширующий сервер имен не может заменить использование вами /etc/hosts для разрешения имен хостов во внутренней сети; однако по сравнению с использованием ISP или другого общедоступного сервера имен кэширующий сервер имен может повысить производительность при разрешении часто используемых внешних имен, таких как www.cnn.com. Самое приятное то, что настроить кэширующий сервер имен довольно просто.

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

Сначала сделайте резервные копии файлов /etc/hosts , /etc/named.conf , resolv.conf и /etc/sysconfig/iptables .

Если они еще не установлены, используйте диспетчер пакетов вашего дистрибутива для установки следующих RPM-пакетов BIND: bind , bind-chroot и bind-utils . Чтобы ваш лабораторный хост мог использовать кэширующий сервер имен, вы должны добавить строку сервера имен, указывающую на ваш собственный хост, в /etc/resolv.конф . Например, если IP-адрес вашего тестового хоста — 192.168.0.203, как и мой epc , добавьте следующую строку в начало списка серверов имен в /etc/resolv.conf :

   сервер имен         192.168.0.203   

Обязательно используйте IP-адрес хоста, на котором вы выполняете этот проект.

Вы можете использовать IP-адрес вашего локального хоста, 127.0.0.1, вместо внешнего IP-адреса. Вы также должны закомментировать все строки, указывающие на другие хосты в качестве серверов имен.Обязательно сохраните измененный файл resolv.conf .

Эти изменения вступят в силу немедленно и не требуют перезагрузки или перезапуска службы. Теперь попробуйте пропинговать общий общедоступный хост, который не блокирует пакеты ICMP (Internet Control Message Protocol); не стесняйтесь использовать мой брандмауэр, который является Raspberry Pi.

  .конф файл. Теперь используйте команду  dig , чтобы проверить, работают ли службы имен. 

   dig wally2.both.com   

Вы должны получить сообщение об ошибке "Время ожидания подключения истекло; нет доступа к серверам".

Настройка кэширующего сервера имен

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

Примечание. В файле named.conf особое внимание уделяется синтаксису и особенно пунктуации. Точки с запятой используются для обозначения конца записи и конца строфы, а также конца строки. Обязательно добавьте их правильно, как показано в примерах.

Для первоначальной настройки кэширующего сервера имен необходимо внести пару изменений в файл /etc/named.conf по умолчанию , поэтому отредактируйте этот файл в своем любимом редакторе. Сначала добавьте IP-адрес вашего локального тестового хоста в строку «прослушивание порта 53», как показано в листинге 2 ниже.Это позволяет с именем прослушивать внешний IP-адрес вашего хоста, чтобы другие компьютеры также могли использовать его в качестве сервера имен.

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

Добавьте строку «форвардеры», как показано ниже.Это сообщает вашему кэширующему DNS-серверу, где получить IP-адреса, если они еще не кэшированы локально. IP-адреса в приведенном ниже списке предназначены для общедоступных DNS-серверов Google. Вы можете использовать своего локального интернет-провайдера, OpenDNS или какой-либо другой общедоступный сервер имен в качестве переадресации. Нет необходимости определять какие-либо серверы пересылки, и в этом случае BIND будет использовать корневые серверы Интернета, как определено в файле /var/named/named.ca , для поиска авторитетных серверов имен для доменов, если серверы пересылки не определены.Но для этого упражнения определите серверы пересылки, как показано в листинге 2.

Закомментируйте строку IPV6, поскольку мы не используем IPV6 в лабораторной среде. Обратите внимание, что две косые черты "//" обозначают комментарии в файле named.conf .

  // 
// именованный.conf
// Предоставляется пакетом привязки Red Hat для настройки ISC BIND named(8) DNS
// сервер как кэширующий сервер имен (только как локальный DNS-преобразователь).
// См. /usr/share/doc/bind*/sample/ примеры именованных файлов конфигурации.
//
//

options {
        порт прослушивания 53 { 127.0.0.1; 192.168.0.203; };
//      прослушивание порта v6 53 { ::1; };
        экспедиторы { 8.8.8.8; 8.8.4.4; };
        каталог       "/var/named";
        файл-дампа       "/var/named/data/cache_dump.db";
        файл статистики "/var/named/data/named_stats.txt";
        memstatistics-file "/var/named/data/named_mem_stats.txt";
        allow-query     { localhost; 192.168.0.0/24; };
        рекурсия да;

        dnssec-enable да;
        проверка dnssec да;
        dnssec-lookaside auto;

        /* Путь к ключу ISC DLV */
        bindkeys-file "/etc/named.iscdlv.key ";

Managed-Keys-directory"/var/name/dynamic ";
};
Журнал {
канал Default_debug {
Файл" Data/name.run ";
Dynamic;
}; ;
zone "." IN {
        подсказка типа;
        файл "named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";

Листинг 2. Файл /etc/named.conf содержит простую конфигурацию, необходимую для настройки кэширующего сервера имен.Строки, которые необходимо добавить или изменить, выделены жирным шрифтом.

Добавьте локальный сетевой адрес 192.168.0.0/24 в строку allow-query . В этой строке указываются сети, из которых DNS-запросы будут приниматься этим DNS-сервером.

Запустить службу имен

Теперь запустите названную службу и настройте ее так, чтобы она запускалась при каждой загрузке. Я использую команду systemctl на моем хосте Fedora, но команда может отличаться на вашем хосте, в зависимости от используемого вами дистрибутива.Обратите внимание, что имя службы распознавателя BIND носит имя.

  

systemctl enable named
systemctl start named

Первый тест, который вы можете выполнить, чтобы убедиться, что ваш кэширующий сервер имен работает, это использовать dig для поиска информации базы данных DNS для wally2.both.org. Для дальнейшего тестирования кэширующего сервера имен используйте команду dig , чтобы получить IP-адрес(а) некоторых распространенных интернет-сайтов, таких как www.opensource.com, CNN, Wired и любых других, которые вам нравятся.Теперь результаты должны показывать ваш хост в качестве отвечающего сервера.

На этом этапе ваш кеширующий сервер имен будет правильно разрешать хосты в Интернете, потому что эти DNS-запросы для общедоступных хостов перенаправляются на общедоступные серверы имен Google — см. строку «forwarders» в named.conf . Однако вы по-прежнему зависите от файла /etc/hosts для внутренних служб имен. Создание первичного сервера имен может решить эту проблему.

Создание первичного сервера имен

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

Вам нужно снова изменить named.conf и создать пару новых файлов. Вы создадите домен с именем Example.com, который является доменным именем, зарезервированным для примера в документах, подобных этому. У домена Example.com есть IP-адрес в Интернете и очень редкий веб-сайт, но вы можете использовать это имя в остальной части своего лабораторного проекта, не создавая проблем ни для кого. Вы будете использовать Пример.com в качестве внутреннего доменного имени для оставшейся части этого упражнения.

Два новых файла, которые вы создадите, — это файлы прямой и обратной зон, которые вы поместите в каталог /var/named . Это расположение задается директивой «каталог» в файле конфигурации named.conf .

Создать файл зоны переадресации

Файл прямой зоны содержит записи «A», которые связывают имена хостов в зоне, также называемой доменом, с их соответствующими IP-адресами.Он также может содержать записи CNAME, которые являются псевдонимами реальных имен хостов в записях A, и записи MX для почтовых серверов.

Создайте базовый файл зоны переадресации /var/named/example.com.zone и добавьте в него следующие строки. Когда вы закончите, ваш файл зоны должен выглядеть как пример файла зоны в листинге 3 ниже.

  ; Официальные данные для зоны example.com 
;
$TTL 1D
@   IN SOA  epc.example.com   root.epc.example.com. (
2017031301      ; серийный номер
1D              ; обновить
1H              ; повторите попытку
1W              ; истекает
3H )            ; минимум

$ORIGIN         пример.ком.
Например.com. В      NS      epc.example.com.
EPC на сервере 127.0.0.1
в 192.168.25.1
www в Cname Server
в Cname Server
Test1 в 192.168.25.21
T1 в тестировании CNAME Test1
.168.25.23
test4                 IN      A       192.168.25.24

; MX-запись почтового сервера
example.com. IN      MX      10      mail.example.com.

Листинг 3: Файл зоны пересылки для домена Example.com содержит имена хостов и их IP-адреса для этого домена.

Первая строка без комментариев в листинге 3 — это спецификатор Time to Live, который в данном случае равен одному дню для всех записей, для которых не указано иное.Д означает День. Спецификаторы в строке SOA (Start of Authority) столь же очевидны. Детали параметров в записи SOA подробно описаны здесь.

Запись NS должна иметь полное доменное имя (полное доменное имя) хоста, на котором вы выполняете этот лабораторный проект. Также в файле должна быть запись A с действительным IP-адресом хоста. В этом случае вы должны использовать IP-адрес локального хоста 127.0.0.1.

Записи, показанные выше, дадут вам несколько имен хостов, с которыми можно поэкспериментировать.

Обязательно используйте сегодняшнюю дату и добавьте счетчик, начинающийся с 01, для серийного номера. Приведенный выше серийный номер является первым изменением от 4 марта 2017 г. Серийный номер увеличивается при каждом изменении файла зоны. Если бы существовали вторичные серверы имен, которые использовали этот сервер в качестве основного, они бы не обновлялись, пока серийный номер не будет увеличен.

Добавьте файлы зоны переадресации в named.conf

Однако прежде чем ваш DNS-сервер заработает, вам необходимо создать запись в /etc/named.conf , который будет указывать на ваш новый файл зоны. Добавьте следующие строки под записью для зоны подсказок верхнего уровня, но перед строками «включить».

  

зона "example.com" IN {
        введите master;
        файл "example.com.zone";
};

Листинг 4. Добавьте эти строки в файл named.conf, чтобы добавить файл зоны Example.com в конфигурацию преобразователя.

Теперь перезапустите с именем , чтобы эти изменения вступили в силу.Протестируйте свой сервер имен, используя команды dig и nslookup , чтобы получить IP-адреса для хостов, которые вы настроили в файле зоны переадресации. Обратите внимание, что хост не обязательно должен существовать в сети, чтобы команды dig и nslookup возвращали IP-адрес.

  

копать test1.example.com
копать t1.example.com
копать mx example.com
копать mail.example.com
nslookup test3.example.com
копать www.amazon.com

Имейте в виду, что использование полного доменного имени для этих команд необходимо, за исключением команды nslookup , если домен и записи поиска Example.com указаны в файле /etc/resolv.conf . В данном случае это, вероятно, не так, поэтому просто используйте полные доменные имена для всех тестов в этом проекте.

Использование корневых серверов имен

Обратите внимание, что корневые серверы имен указаны как полномочные серверы для поиска Amazon.com. Но помните, что вы используете общедоступные серверы имен Google в качестве серверов пересылки.Теперь закомментируйте строку forwarders в named.conf и перезапустите named . Запустите приведенные выше команды еще раз, чтобы сравнить возвращаемые результаты. Результаты должны выглядеть примерно так, как показано в листинге 5.

  # dig www.amazon.com     

; <<>> DiG 9.10.4-P6-RedHat-9.10.4-4.P6.fc25 <<>> www.amazon.com
;; глобальные параметры: +cmd
;; Получил ответ:
;; ->>HEADER<<- код операции: QUERY, статус: NOERROR, id: 65004
;; флаги: qr rd ra; ЗАПРОС: 1, ОТВЕТ: 6, ПОЛНОМОЧИЯ: 4, ДОПОЛНИТЕЛЬНО: 1

;; ДОПОЛНИТЕЛЬНЫЙ ПСЕВДОРАЗДЕЛ:
; ЭДНС: версия: 0, флаги:; UDP: 4096
;; РАЗДЕЛ ВОПРОСОВ:
;www.амазон.com. В      А

;; РАЗДЕЛ ОТВЕТОВ:
www.amazon.com. 1800    IN      CNAME   www.cdn.amazon.com.
www.cdn.amazon.com. 300     IN      CNAME   d3ag4hukkh62yn.cloudfront.net.
d3ag4hukkh62yn.cloudfront.net. 60 IN    A       52.85.147.120
d3ag4hukkh62yn.cloudfront.net. 60 IN    A       52.85.147.50
d3ag4hukkh62yn.cloudfront.net. 60 IN    A       52.85.147.92
d3ag4hukkh62yn.cloudfront.net. 60 В    А       52.85.147.109

;; ОРГАНИЗАЦИОННЫЙ РАЗДЕЛ:
d3ag4hukkh62yn.cloudfront.net. 1831 В NS     ns-1144.awsdns-15.org.
d3ag4hukkh62yn.cloudfront.net. 1831 В NS      ns-130.awsdns-16.com.
d3ag4hukkh62yn.cloudfront.net. 1831 В NS      ns-2021.awsdns-60.co.uk.
d3ag4hukkh62yn.cloudfront.net. 1831 В NS      ns-824.awsdns-39.net.

;; Время запроса: 3857 мс
;; СЕРВЕР: 192.168.0.203#53(192.168.0.203)
;; КОГДА: Пн, 13 марта, 09:18:30 EDT 2017
;; MSG SIZE rcvd: 306

Листинг 5. Результаты поиска на сайте www.На amazon.com есть интересная информация, включая время жизни для различных типов записей.

Когда я это сделал, первый вызов для разрешения внешнего адреса для Amazon занял 3857 мс, пока данные были найдены и возвращены. Последующие результаты выполнения того же запроса составили 1 мс, что показывает преимущество локального кэширования результатов преобразователя. Обратите внимание на числа 1800, 300 и 60 в строках раздела ответов и 1831 в строках раздела полномочий — это TTL (время жизни) в секундах.Если вы выполните поиск несколько раз, эти числа изменятся, показывая количество времени, которое осталось для записи в локальном кэше.

Создание файла обратной зоны

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

Создайте файл обратной зоны, /var/named/example.com.rev и добавьте следующее содержимое. Обязательно используйте соответствующий серийный номер.

  ; Достоверные данные для example.com  обратная зона 
;
$TTL 1D
@   IN SOA  test1.example.com   root.test1.example.com. (
2017031501      ; серийный номер
1D              ; обновить
1H              ; повторите попытку
1W              ; истекает
3H )            ; минимум

@       IN      NS      epc.пример.com.
Например.com. В      NS      epc.example.com.
1               IN      PTR     mail.example.com.
1               IN      PTR     server.example.com.
21              IN      PTR     test1.example.com.
22              IN      PTR     test2.example.com.
23              IN      PTR     test3.example.com.
24              IN      PTR     test4.example.com.

Листинг 6: Используйте этот файл обратной зоны, example.com.rev, для вашего сервера имен.

Вы также можете назвать файл обратной зоны /var/named/25.168.192.in-addr.arpa , что соответствует старым соглашениям. На самом деле вы можете назвать его как угодно, потому что вы явно укажете на него в файле named.conf , но использование одного из двух соглашений облегчит другим следить за вашей работой.

Добавить обратную зону в named.conf :

  

зона    "25.168.192.in-addr.arpa" IN {
       type master;
       file "example.com.rev";
};

Листинг 7. Добавление этого раздела в файл named.conf позволяет выполнять обратный поиск.

Добавьте раздел из листинга 7 в файл /etc/named.conf , чтобы указать на новую обратную зону. Теперь перезагрузите с именем и протестируйте обратную зону, используя команды из листинга 8. Ваши результаты должны выглядеть примерно так, как показано ниже.

  systemctl reload с именем 

# dig -x 192.168.25.23

; <<>> DiG 9.10.4-P6-RedHat-9.10.4-4.P6.fc25 <<>> -x 192.168.25.23
;; глобальные параметры: +cmd
;; Получил ответ:
;; ->>HEADER<<- код операции: QUERY, статус: NOERROR, id: 48607
;; флаги: qr aa rd ra; ЗАПРОС: 1, ОТВЕТ: 1, ПОЛНОМОЧИЯ: 1, ДОПОЛНИТЕЛЬНО: 1

;; ДОПОЛНИТЕЛЬНЫЙ ПСЕВДОРАЗДЕЛ:
; ЭДНС: версия: 0, флаги:; UDP: 4096
;; РАЗДЕЛ ВОПРОСОВ:
;23.25.168.192.in-addr.arpa. В      ПТР

;; РАЗДЕЛ ОТВЕТОВ:
23.25.168.192.in-addr.arpa. 86400 IN    PTR     test3.example.com.

;; ОРГАНИЗАЦИОННЫЙ ОТДЕЛ:
25.168.192.in-addr.arpa. 86400  IN      NS      epc.example.com.

;; Время запроса: 21 мс
;; СЕРВЕР: 192.168.0.203#53(192.168.0.203)
;; КОГДА: ср, 15 марта, 16:18:59 по восточному поясному времени 2017
;; MSG SIZE  rcvd: 112

Листинг 8. После перезапуска named вы должны увидеть результаты, подобные этим, когда вы выполняете обратный поиск IP-адреса в обратной зоне.

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

  

dig -x 192.168.25.23
dig -x 192.168.25.1

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

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

Настройка IPTables для DNS

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

Брандмауэр на тестовом хосте, вероятно, блокирует доступ к вашему хосту для служб имен. IPTables должен быть настроен для разрешения входящих пакетов UDP (протокол пользовательских дейтаграмм) на ваш сервер имен, чтобы другие хосты могли использовать его для разрешения имен.Используйте следующие команды, чтобы добавить необходимые записи и сохранить их.

Добавьте в брандмауэр правило с помощью firewalld или IPTables, которое разрешает входящие пакеты через порт 53 (домен) для UDP, и сохраните новый набор правил. Не забудьте вставить новое правило после строки -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT , поэтому для этого вам придется подсчитать количество строк INPUT в таблице фильтров. Число 7 в следующей команде означает, что это правило будет вставлено в позицию номер 7 в существующих правилах INPUT.

   iptables -t filter -I INPUT 7 -p udp -m conntrack --ctstate NEW -m udp --dport 53 -j ACCEPT   

Вы можете сохранить новые правила брандмауэра, если хотите, и вы бы сделали это, если это должна была быть постоянная установка, а не лабораторный проект. Затем проверьте это на одном из других ваших хостов, используя команду из листинга 9 ниже. Аргумент @epc указывает команде dig использовать указанный сервер имен с именем хоста epc . Вы должны заменить либо IP-адрес только что созданного DNS-сервера, либо разрешимое имя хоста в вашей сети, указывающее на ваш новый сервер имен.Конечно, вы всегда можете добавить это имя хоста с его IP-адресом в файл /etc/hosts хоста, который вы используете для удаленного тестирования.

  # dig @epc test1.example.com 

; <<>> DiG 9.10.4-P6-RedHat-9.10.4-4.P6.fc25 <<>> @epc test1.example.com
; (найден 1 сервер)
;; глобальные параметры: +cmd
;; Получил ответ:
;; ->>HEADER<<- код операции: QUERY, статус: NOERROR, id: 27957
;; флаги: qr aa rd ra; ЗАПРОС: 1, ОТВЕТ: 1, ПОЛНОМОЧИЯ: 1, ДОПОЛНИТЕЛЬНО: 1

;; ДОПОЛНИТЕЛЬНЫЙ ПСЕВДОРАЗДЕЛ:
; ЭДНС: версия: 0, флаги:; UDP: 4096
;; РАЗДЕЛ ВОПРОСОВ:
;test1.пример.com. В      А

;; РАЗДЕЛ ОТВЕТОВ:
test1.example.com. 86400   IN      A       192.168.25.21

;; ОРГАНИЗАЦИОННЫЙ РАЗДЕЛ:
example.com. 86400   IN      NS      epc.both.org.

;; Время запроса: 0 мс
;; СЕРВЕР: 192.168.0.203#53(192.168.0.203)
;; КОГДА: Пн, 13 марта, 08:45:34 EDT 2017
;; MSG SIZE  rcvd: 92

Листинг 9. Тестирование преобразователя имен, созданного вами на другом хосте в той же сети.

Очистка

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

  1. Восстановите исходный файл /etc/hosts .
  2. Имя остановки на узле распознавателя, используемом для этого лабораторного проекта.
  3. Отключить указанную службу.
  4. Удалить файлы зоны.
  5. Восстановить исходное имя .файл конф .
  6. Восстановите исходный файл resolv.conf .

Заключительные мысли

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

Обратите внимание, что хотя мой маленький EeePC работает со 100% загрузкой ЦП для [email protected], он очень быстро отвечает на запросы преобразователя.Вы должны иметь возможность попробовать этот проект на любом доступном хосте Linux с незначительным эффектом. Я надеюсь, что многие из вас попытаются настроить свой собственный сервер имен и поэкспериментировать с ним. Особенности установки вашего сервера имен будут зависеть от деталей вашего хоста и сети.

Ресурсы

Служба

— Служба доменных имен (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 своим полным доменным именем (Fully Qualified Domain Name).

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

Чтобы добавить зону 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.ком
;
$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 в конец файла зоны. Дополнительные сведения см. в разделе Общие типы записей.

Примечание

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

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

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

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

Теперь, когда зона настроена и преобразует имена в 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 нс.пример.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.service
  

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

  зона "example.com" {
    тип вторичный;
    файл "db.example.ком";
    мастера { 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.ком'
зона 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-клиентов.В конце концов, ваша строка nameserver в /etc/resolv.conf должна указывать на 127.0.0.53 , и у вас должен быть параметр search для вашего домена. Что-то вроде этого:

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

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

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

Примечание

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

копать

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

  • После установки 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:

  пример пинга.ком
  

Проверяет, может ли сервер имен преобразовать имя 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 , установленную с пакетом 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; };
};
  

Примечание

Параметр отладки может иметь значение от 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 ИН А 192.168.1.12
      
  • Запись CNAME : используется для создания псевдонима существующей записи A.Вы не можете создать запись CNAME , указывающую на другую запись CNAME .

      веб-сайт IN CNAME www
      
  • Запись MX : используется для определения адреса электронной почты. Должен указывать на запись A , а не на 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
      

Дополнительная информация

Конфигурация DNS-сервера в виртуальном частном облаке Amazon Web Services — сообщество SecurID

Для разрешения имен хостов устройству Amazon Web Services (AWS) требуется настроить DNS-сервер в виртуальном частном облаке (VPC).

Необходимо создать набор параметров DHCP, связать его с VPC, а затем изменить свойства VPC. В смешанном локальном развертывании и развертывании AWS любые локальные первичные экземпляры и реплики RSA Authentication Manager должны использовать DNS-сервер, настроенный в VPC.

DNS-сервер по умолчанию для AWS использует IP-адрес 169.254.169.253. Если вы используете DNS-сервер по умолчанию, любая подсеть в VPC может использовать 169.254.169.253 в качестве основного DNS-сервера для Authentication Manager.

Для получения дополнительной информации о DNS-серверах см. Руководство пользователя Amazon Virtual Private Cloud по адресу https://docs.aws.amazon.com/vpc/.

Примечание. AWS также включает сервер протокола сетевого времени (NTP) по умолчанию с IP-адресом 169.254.169.123, который можно указать во время быстрой настройки.

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

Процедура

  1. Откройте консоль Amazon VPC по адресу https://console.aws.amazon.com/vpc/.

  2. В области навигации выберите Наборы параметров DHCP , а затем выберите Создать набор параметров DHCP .

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

    Примечание. Это должен быть тот же DNS-сервер, который используется для настройки RSA Authentication Manager во время быстрой настройки.

  4. Выбрать Да, создать .

    Новый набор параметров DHCP появится в вашем списке параметров DHCP.

  5. Запишите идентификатор для нового набора параметров DHCP (dopt-xxxxxxxx). Идентификатор необходим, чтобы связать новый набор параметров с вашим VPC.

Вы можете изменить параметры DHCP, связанные с VPC.

Процедура

    1. Откройте консоль Amazon VPC по адресу https://console.aws.amazon.com/vpc/.
    2. На панели навигации выберите Your VPCs .

    3. Выберите VPC и выберите Изменить набор параметров DHCP из списка Действия .

    4. В списке DHCP Options Set выберите набор параметров.

    5. Щелкните Сохранить .

      Все существующие экземпляры AWS и все новые экземпляры AWS, которые вы запускаете в этом облаке VPC, будут использовать параметры.

      Вам не нужно перезапускать или перезапускать экземпляры AWS. Экземпляры автоматически принимают изменения в течение нескольких часов, в зависимости от того, как часто экземпляр продлевает аренду DHCP. Вы можете явно продлить аренду в AWS. Инструкции см. в документации AWS.

  • Вы можете изменить свойства VPC.Любые локальные первичные экземпляры и реплики RSA Authentication Manager должны использовать DNS-сервер, настроенный в VPC.

    1. Откройте консоль Amazon VPC по адресу https://console.aws.amazon.com/vpc/.
    2. На панели навигации выберите Your VPCs .

    3. Выберите VPC и выберите Изменить разрешение DNS . Выберите Да .

    4. Выберите VPC и выберите Изменить имена хостов DNS .Выберите .

    После окончания

    Perle Console Server — автоматическое обновление DNS

    Технические примечания Perle Systems

    В больших сетях иногда проще связывать оборудование со значимыми именами по сравнению с конкретными IP-адреса. Серверы доменных имен ( DNS ) являются стандартом механизм, используемый Интернетом и крупными предприятиями связывать имена с IP-адресами.IOLAN имеют возможность для работы с DNS-серверами, чтобы связать свое имя с назначенным ему IP-адресом. Например, ИОЛАН. при включении питания может информировать локальный DHCP-сервер о своем сконфигурированное имя и запрос, чтобы DHCP-сервер информировал DNS-сервер с этой информацией. Это позволяет администратору, чтобы легко найти только что установленный IOLAN и доступ к нему напрямую по имени.

    В большинстве случаев IP-адреса, выделенные в Интернете носят динамический характер.Пользователь мог получить другой IP-адрес при следующем подключении к Интернет. Чаще всего такие соединения работать, поскольку люди, использующие браузеры, устанавливают исходящие подключения к веб-сайтам, почтовым серверам и т. д. Однако, если удаленный пользователь хочет подключиться напрямую к другому пользователю или устройству, это может быть сложно, так как IP-адрес другого узла мог измениться по сравнению с последним время или его адрес замаскирован или переведен за локальный роутер.Поставщики услуг доменных имен, такие как DYNDNS предложить услугу, в которой пользователи идентифицируют себя и имеют поставщик услуг связывает свое имя с IP-адресом которые они сейчас используют. Это позволяет удаленным пользователям получить доступ к объекту, не зная его IP-адреса.

    Идеально подходит для удаленных серверов устройств. подключены к последовательным портам. Пользователи в Интернете могут получить доступ к серверу устройств по имени, не зная его IP-адрес.Серверы устройств IOLAN теперь имеют функцию где он может подключиться к DYNDNS с предопределенной учетной записью и его настроенное имя и разрешить удаленным пользователям доступ это по имени.

    Разница между сервером имен и DNS

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

    Что такое DNS?

    DNS, сокращение от Domain Name System, представляет собой иерархию распределенной базы данных для компьютеров или других ресурсов, подключенных к Интернету. Это как телефонный справочник Интернета, предоставляющий доступ к информации через доменные имена. DNS является основой работы практически всех сетевых приложений Интернет-протокола (IP), от просмотра веб-страниц до электронной почты, мультимедийных приложений и многого другого. DNS преобразует доменные имена в IP-адреса, чтобы веб-браузеры могли загружать интернет-ресурсы.Каждый раз, когда вы вводите веб-адрес, отправляете письмо или получаете доступ к любому IP-приложению, вы используете DNS. Он преобразует логическое имя машины в IP-адрес, а затем в доменное имя. Он преобразует удобочитаемые доменные имена, такие как Google.com, Facebook.com, в соответствующие им IP-адреса, такие как 173, 194, 37, 78. DNS — это стандартный набор протоколов, позволяющих компьютерам обмениваться данными через Интернет.

    Что такое сервер имен?

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

    Разница между сервером имен и DNS

    Определение 

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

    Назначение

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

    Операция

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

    Сервер имен

    и DNS: сравнительная таблица

    Сводка серверов имен и серверов именDNS

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

    Сагар Хиллар — плодовитый автор контента/статей/блогов, работающий старшим разработчиком контента/писателем в известной фирме по обслуживанию клиентов, базирующейся в Индии. У него есть стремление исследовать разносторонние темы и разрабатывать высококачественный контент, чтобы сделать его лучше всего читаемым. Благодаря своей страсти к писательству, он имеет более 7 лет профессионального опыта в написании и редактировании на самых разных печатных и электронных платформах.

    Вне своей профессиональной деятельности Сагар любит общаться с людьми из разных культур и происхождения.Можно сказать, что он любопытен по натуре. Он считает, что каждый — это опыт обучения, и это приносит определенное волнение, своего рода любопытство, чтобы продолжать идти. Поначалу это может показаться глупым, но через какое-то время это расслабит вас и вам будет легче начать разговор с совершенно незнакомыми людьми — вот что он сказал». : Если вам понравилась эта статья или наш сайт.

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

    Ваш адрес email не будет опубликован.