Настройка dns для ftp
Есть много отличных статей, касающихся настройки FTP, DNS, Windows Server 2016, доменных имен и маршрутизаторов. То, что я ищу, это процедура, чтобы связать их все вместе для моей домашней сети.
- Маршрутизатор с IP-адресом от интернет-провайдера, который так же хорош, как и статический, и предоставляет через DHCP-адреса в диапазоне 192.168.1.x для всех подключенных устройств.
- Сервер Windows 2016, который всегда получает адрес 192.168.1.9 от сервера DHCP.
- Доменное имя с DNS-хостингом от провайдера доменных имен.
На роутере у меня перенаправлены порты 21 и 80. На сервере я включил роли IIS и FTP и могу получить доступ к веб-странице по умолчанию с предоставленным провайдером адресом wxyz:80 и ftp с wxyz:21.
На сайте провайдера доменных имен я связал доменное имя с адресом wxyz Ввод MyDomainName в моем браузере, я получаю веб-страницу по умолчанию.
Теперь вот биты, с которыми у меня проблемы:
Когда я настрою DNS-сервер, текущая настройка у провайдера доменных имен автоматически найдет его?
Нужно ли отменять хостинг DNS у провайдера доменных имен?
Настройка DNS-сервера потребует двух серверов имен. Я использую два в настоящее время, используемые поставщиком доменного имени? Если не то, что я использую?
FTP и веб-службы работают на портах 21 и 80 соответственно из
тот же сервер. Может ли DNS-сервер обрабатывать разные порты или мне придется настраивать виртуальные машины, используя разные IP-адреса?
Я ищу ответ, объясняющий, что делать и чего ожидать, а не как это сделать - я могу получить это в другом месте.
Что делать?
Я не буду останавливаться на том, как настроить linux сервер (и тем более как его выбрать), поскольку предполагаю, что он у вас уже есть. Также я не буду подробно расписывать настройки nginx и Apache, поскольку опять-таки предполагаю, что вы с этим справитесь самостоятельно.
Для решения нам нужно настроить DNS-сервер, а именно следующие записи: SOA, NS, MX, A, CNAME. Важно чтобы мы имели возможность настройкой TTL (time to live), поскольку время жизни наших записей должно быть очень небольшим, буквально 60-120 секунд. В противном случае при смене IP-адреса сервера пользователи долго не смогут попасть на наш сервер (из-за кеширования).
Итак, нам нужен DNS сервер, варианты решения:
- Используем сервисы которые предоставляют нам DNS-хостинг
- Используем собственный DNS-сервер в связке с DDNS-доменом
Используем сервисы которые предоставляют нам DNS-хостинг
Остальные сервисы рассматривать не будем, а сосредоточимся на втором варианте.
Используем собственный DNS-сервер в связке с DDNS-доменом
1. Настроить 2 или 3 DDNS-поддомена
Почему 2 или 3? Потому, что ряд регистрантов не разрешит вам использовать домен только с одним NS-сервером. Самое обидно, что не все про это скажут — ваш домен просто не будет работать, но вы не будете понимать почему.
2. Настраиваем собственный DNS-сервер
Создаем зоны (по одной зоне на каждый наш домен):
и собственно файл с настройками зоны:
Примечание: обращаю внимание, что TTL устанавливаем равным 60 секунд. В файле /etc/bind/named.conf.local добавляем подключение нашей зоны:
Все, рестартуем BIND:
3. Настроить наш домен(ы)
Идем в панель управления регистратора и там в настройках нашего домена в качестве NS-серверов указываем созданные DDNS-поддомены:
После этого возможно придется подождать несколько часов (или даже сутки) пока настройки среплицируются между всеми серверами.
4. Настроить периодическое обновление IP-адресов
Мой роутер поддерживает обновление IP-адреса на одном домене, но мне нужно это делать сразу для 3-х доменов. Плюс нам надо обновлять IP-адрес в конфиге BIND'а, поэтому напишем скрипт который будет делать:
Скрипт нужно запускать под рутом (чтобы ему хватило прав обновлять конфиги BIND'а и рестартовать его). Добавляем в crontab рута его запуск каждую минуту:
Поэтому у себя я использовал улучшенный вариант, который заодно не лазит в интернет:
5. Настройка роутера
Итак, что я получил в итоге:
- Мои сайты живут на домашнем сервере, за который я никому не плачу;
- Мои домены резолвятся через мой собственный DNS-сервер, время жизни записей 1 минута, то есть обновление происходит очень быстро;
- В качестве NS-записей указаны не реальные IP-адреса (которые у меня часто меняются), а DDNS-поддомены;
- Актуальность записей в DDNS-поддоменах и в конфиге моего DNS-сервера обеспечивается автоматически, без какого-либо вмешательства со моей стороны.
P.S. Если кому-то понравилась данная заметка, то я могу написать вторую часть, где расскажу как настроить работу с использованием DNS-хостинга Яндекса. Это позволит отказаться от собственного DNS-сервера, отказаться от DDNS-поддоменов, плюс чуть улучшит надежность работы (поскольку DNS-сервер никогда не будет менять свой IP). Именно такую схему я использую в настоящий момент.
В этой статье я покажу вам, как настроить Windows Firewall для сервера, на котором крутятся сайты и FTP, а так же DNS. Ничего сверхъестественного в этой процедуре нет, за исключением того, что нужно будет в менеджере IIS настроить диапазон портов для пассивного режима работы FTP сервера.
Заходим на наш сервер, переходим в менеджер IIS, в нем на главной странице сервера заходим в пункт поддержка Брандмауэра FTP.
И в нем указываем диапазон портов канала данных.
После этого заходим в inbound rules, в расширенной настройке Брандмауэра Windows.
Для того что бы отрыть TCP порты добавляем новое правило, выбираем port, жмем далее.
Выбираем TCP в вводим через запятую порты которые должны быть открыты, возможно, использование диапазонов через тире. Жмем далее.
Выбираем Allow Connection.
На следующем шаге выбираем к каким профилям будет применяться правило, я выбрал Public, т.к. эти правила настраиваю для внешней сети.
На последнем шаге даем название правилу.
Для того что бы открыть UDP порты, нужно делать все то же самое, только на втором шаге выбираем за место TCP – UDP.
Что бы открыть ICMP, нужно создать новое правило и на первом шаге выбрать Custom.
Далее выбираем, что бы правило применялось ко всем программам.
В протоколах выбираем ICMPv4, по желанию можно выбрать какие запросы разрешены (кнопка Customize…).
На следующем шаге можно выбрать с каких сетей разрешены запросы, и последние шаги такие же как при настройке портов. Так же, если у вас на сервере включен IPv6 можно разрешить ICMPv6 запросы, для этого повторяем шаги, но за место протокола ICMPv4 выбираем ICMPv6.
1 ответ 1
То, что вы предлагаете, - это размещение авторитетного Сервера доменных имен (DNS-сервера) вашего домена.
Когда я настрою DNS-сервер, текущая настройка у провайдера доменных имен автоматически найдет его?
Нет. Чтобы сделать DNS-сервер видимым для Интернета, вам необходимо предоставить его статический IP-адрес регистратору вашего домена. Они будут указывать его в качестве авторитетного сервера имен для вашего домена.
Статический IP-адрес не является обязательным. Кроме того, ваш сервер должен оставаться доступным 24x7x365, чтобы разрешать запросы имен для вашего домена, в противном случае имена и службы, которые они поддерживают в вашем домене, будут недоступны.
Нужно ли отменять хостинг DNS у провайдера доменных имен?
Да. Хотя для домена требуется иметь несколько серверов имен, они должны быть настроены на синхронизацию друг с другом, всегда возвращая совпадающие ответы на запросы, которые они получают. Ваш Интернет-провайдер, скорее всего, не согласится настроить свои DNS-серверы, как этот, поэтому вам придется прекратить использовать их полностью.
Настройка DNS-сервера потребует двух серверов имен. Я использую два в настоящее время, используемые поставщиком доменного имени? Если не то, что я использую?
У вас должно быть два уникальных сервера имен для вашего домена. В соответствии с техническими требованиями IANA к авторитетным серверам имен:
В делегировании должно быть не менее двух записей NS, и хосты не должны разрешать один и тот же IP-адрес.
Именно в этот момент я предлагаю вам не размещать свои собственные NS-серверы. Однако, если вы все еще хотите, вам нужно настроить второй DNS-сервер в другом месте, чтобы он имел свой собственный IP-адрес.
FTP и веб-службы работают на портах 21 и 80 соответственно с одного и того же сервера. Может ли DNS-сервер обрабатывать разные порты или мне придется настраивать виртуальные машины, используя разные IP-адреса?
DNS ничего не знает о портах, только имена хостов. Вы правы, что для достижения этой цели исключительно с помощью DNS вам необходимо использовать отдельную публичную (!) IP-адреса.
Расскажу как поднять ftp-сервер на своем ПК с динамическим IP-адресом. Итак, приступим, шаг за шагом.
Чтобы каждый раз не нажимать OK в окне авторизации можно поставить опцию "Always connect to this server". И еще: пароль к админке вашего сервера хранится в ключе "Admin Password" XML-файла "FileZilla Server.xml", который расположен в каталоге с программой. С установкой покончено, приступим к настройке.
Настройка FTP-сервера, в простейшем виде, сводится к созданию аккаунта пользователя и настройке расшаренного ресурса. Создадим аккаунт пользователя. На панели инструментов FileZilla Server выбираем "Users" и получаем вот такое окно.
В группе "Users" ("пользователи") кликаем на "Add" ("добавить") и вводим имя нового пользователя (как видно, у меня это "asus" - планшет, с которого я буду получать доступ к моему ftp). Теперь в группе "Account settings" ("настройки аккаунта") устанавливаем опцию "Enable account" ("включить аккаунт") и опцию "Password" ("пароль") и в поле справа вводим пароль. Пароль придется запомнить или записать, т.к. он нам пригодится в дальнейшем. С настройками нового пользователя закончили, перейдем к настройке ресурсов.
Выберите в окне слева в группе "Page" раздел "Shared folders" ("расшаренные папки"). Убедитесь, что в группе "Users" ("пользователи") выбран нужный аккаунт пользователя. В группе "Shared folders" нажмите "Add" и укажите каталог на диске, который вы хотите расшарить. После того, как выбран каталог необходимо установить права доступа к папкам и файлам в каталоге. Для этого установите необходимые опции в группа "Files" и "Directories".
Это все, что необходимо для простейшей настройки вашего FTP сервера. Остальные настройки можно оставить по умолчанию.
Перейдем к самому интересному, а именно постараемся сделать так, чтобы ваш FTP стал доступен из сети интернет.
3. Делаем из динамического IP статический
Получилось так, что ваш провайдер выдает динамический IP-адрес. т.е. ваш компьютер каждый раз получает новый IP. Напротив, нашему серверу нужен постоянный IP адрес. Для перевода динамического адреса в статический существует масса сервисов.
В своем случае, я использовал бесплатный аккаунт от No-IP. Как и за все бесплатное, рано или поздно приходится платить, точнее через 30 дней : ) Каждый месяц необходимо выполнять подтверждение аккаунта, в противном случае его удалят.
Начнем. Для начала необходимо зарегистрировать на сайте новый аккаунт. Вводим логин, пароль и адрес электронный почты, на которую будет отправлено письмо с подтверждением аккаунта и указываем доменное имя (у меня получилось такое: itkladovka.sytes.net). После подтверждения аккаунта заходим в свой веб-кабинет на сайте и выбираем в меню "Hosts/Redirects".
Здесь можно настроить существующий домен или добавить новый.
Для синхронизации IP-адреса с доменным именем необходимо установить на ПК программу No-IP DUC (Dynamic Update Client). Скачиваем и устанавливаем. При первом запуске необходимо указать логин и пароль от аккаунта no-ip. Обратите внимание, хотя первое поле называется "E-mail Adress" указывать нужно именно логин, а не адрес электронной почты!
После авторизации видим вот такое окно.
Нажимаем "Edit Hosts" (редактировать хосты) и в появившемся окне отмечаем наше доменное имя. Нажимаем "Save" (сохранить).
Уф! С настройкой доменного имени и привязки его к нашему IP адресу покончено. Держитесь, немного осталось : )
Итак, мы установили и настроили ftp-сервер. Зарезервировали доменное имя, для обращения к нашему ftp из сети интернет и привязали домен к нашему изменчивому IP-адресу. Что же еще нужно? Совсем немного - настроить роутер. У меня это dLink DIR-300.
Заходим в админку роутера. В браузере набираем адрес 192.168.0.1 и попадаем на страницу авторизации роутера. Вводим имя пользователя и пароль, по умолчанию логин: admin пароль: admin . Если у вас задан пароль по умолчанию желательно придумать свой, тем более с учетом того, что вы открываете доступ к странице авторизации модема из интернет по доменному адресу. После авторизации необходимо выбрать раздел "Maintenance" (поддержка) и слева выбираем пункт "DDNS Setting".
Сначала устанавливаем опцию "Enable DDNS" (Включить динамический DNS). Поле "Server Address" можно пропустить, а в поле "Host Name" (Имя хоста) прописываем доменное имя, которое указывали на сайте noip.com. В поля Username (имя пользователя) и Password (пароль) записываем логин и пароль от вашего аккаунта на сайте noip.com. Нажимаем "Save Settings" (сохранить настройки). Теперь если введете ваш новый адрес в адресную строку браузера, то попадете на страницу авторизации роутера.
Для того, чтобы ваш ftp-сервер был доступен по адресу ftp://ваше_доменное_имя необходимо выполнить еще одну настройку - пробросить 21 порт на роутере. Переходим на вкладку "Advanced" (расширенные настройки) и слева выбираем пункт "Port Forwarding" (перенаправление портов).
Отмечаем новое правило и в поле "Name" (имя) пишем "ftp". В поле "Public Port" вводим 21. Если не знаете, какой адрес написать в поле "IP Address", выберите из выпадающего списка сетевое имя своего ПК и нажмите кнопку Указываем 21 порт. Сохраняем изменения.
Пунктом выше мы описали правила перенаправления трафика, поступающего на порт 21 на конкретный IP-адрес. Но здесь есть одно но. Роутер выдает адреса в ЛС из определенного диапазона и по порядку. К примеру, если вы сначала включили планшет, то он получит адрес 192.168.0.100, а ноутбук получит адрес следующий по порядку 192.168.0.101. Получилось, что адрес ноутбука, для которого мы производили настройки изменился. Для того, чтобы наш сервер получал всегда один и тот же адрес необходимо определить правила выдачи IP адресов роутером для устройств в локальной сети.
Переходим на закладку "Setup" (установки) и слева выбираем пункт "LAN Setup" (установки локальной сети).
В разделе "DHCP Reservation" устанавливаем для нашего сервера фиксированный IP адрес, отмечаем созданное правило галочкой и сохраняем изменения. Перезагружаем роутер.
Убедитесь, что FTP-сервер запущен. Открываем проводник Windows и вводим адрес ftp-сервера "ftp://ваше_доменное_имя". Если все настроено правильно появится окно авторизации FTP-сервера. Вводим учетные данные, которые мы указывали в п. 2 данной статьи при добавлении пользователя и . радуемся .
Помимо проводника Windows существует бессчетное число FTP клиентов. Ну вот, собственно и все. Вы проделали большую работу и я надеюсь она увенчалась успехом. Спрашивайте, постараюсь ответить.
Основная цель DNS — это отображение доменных имен в IP адреса и наоборот — IP в DNS. В статье я рассмотрю работу DNS сервера BIND (Berkeley Internet Name Domain, ранее: Berkeley Internet Name Daemon), как сАмого (не побоюсь этого слова) распространенного. BIND входит в состав любого дистрибутива UNIX. Основу BIND составляет демон named, который для своей работы использует порт UDP/53 и для некоторых запросов TCP/53.
Основные понятия Domain Name System
Исторически, до появления доменной системы имен роль инструмента разрешения символьных имен в IP выполнял файл /etc/hosts, который и в настоящее время играет далеко не последнюю роль в данном деле. Но с ростом количества хостов в глобальной сети, отслеживать и обслуживать базу имен на всех хостах стало нереально затруднительно. В результате придумали DNS, представляющую собой иерархическую, распределенную систему доменных зон. Давайте рассмотрим структуру Системы Доменных Имён на иллюстрации:
Доменная структура DNS представляет собой древовидную иерархию, состоящую из узлов, зон, доменов, поддоменов и др. элементов, о которых ниже пойдет речь. «Вершиной» доменной структуры является корневая зона. Настройки корневой зоны расположены на множестве серверов/зеркал, размещенных по всему миру и содержат информацию о всех серверах корневой зоны, а так же отвечающих за домены первого уровня (ru, net, org и др). Информация о серверах корневой зоны расположена на данном сайте корневых серверов. Настройки корневой зоны всегда доступны тут. Серверы корневой зоны обрабатывают и отвечают на запросы, выдавая информацию только о доменах первого уровня (то есть отвечают на любые запросы, как на нерекурсивные)! Итак, уже много раз повторилось слово зона. Пора этот термин объяснить.
Домен — это именованная ветвь или поддерево в дереве имен DNS, то есть это определенный узел, включающий в себя все подчиненные узлы. Следующая цитата из книги Linux Network Administrators Guide хорошо проясняет картину относительно разницы между зоной и доменом:
Таким образом, пространство имен раздроблено на зоны ( zones), каждая из которых управляется своим доменом. Обратите внимание на различие между зоной (zone) и доменом (domain): домен groucho.edu затрагивает все машины в университете Groucho Marx, в то время как зона groucho.edu включает только хосты, которые работают в непосредственно компьютерном центре, например в отделе математики. Хост в отделе физики принадлежат другой зоне, а именно physics.groucho.edu.
Каждый узел в иерархии DNS отделен от своего родителя точкой. Если провести аналогию с файловой системой Linux, система доменных имен имеет похожую структуру, за тем исключением, что разделитель в файловой системе — слэш, а в DNS — точка. А так же DNS адрес читается справа налево (от корневого домена к имени хоста) в отличии от пути в файловой системе Linux. Доменное имя начинается с точки (корневого домена) и проходит через домены первого, второго и если нужно третьего и т.д. уровней и завершается именем хоста. Т.о. доменное имя полностью отражает структуру иерархии DNS. Часто (я бы сказал — всегда в повседневной жизни), последняя точка (обозначение корневого домена) в доменном имени опускается (то есть в браузере мы вводим не k-max.name., а k-max.name). Итак, разобрав структуру доменного имени, мы незаметно подошли к понятию FQDN.
FQDN (англ. Fully Qualifed Domain Name, полностью определённое имя домена) — это имя домена, однозначно определяющее доменное имя и включающее в себя имена всех родительских доменов иерархии DNS, в том числе и корневого. Своеобразный аналог абсолютного пути в файловой системе. Давайте разберем вышесказанное на примере имени домена mail.k-max.name:
Различие между FQDN и обычным доменным (неFQDN) именем появляется при именовании доменов второго, третьего (и т. д.) уровня. Для получения FQDN требуется обязательно указать в доменном имени домены более высокого уровня (например, mail является доменным именем, однако FQDN имя выглядит как mail.k-max.name.). Максимальный размер FQDN — 255 байт, с ограничением в 63 байта на каждое имя домена.
Поддомены, коротко говоря, это — подчиненные домены. По большому счету, все домены в интернете являются подчиненными за исключением корневого. Например домен k-max является поддоменом домена name, а name, в свою очередь — поддоменом корневого домена.
Ресурсные записи
Ресурсная запись — это то, собственно ради чего в конечном счете и существует DNS. Ресурсная запись — это единица хранения и передачи информации в DNS. Каждая такая запись несет в себе информацию соответствия какого-то имени и служебной информации в DNS, например соответствие имени домена — IP адреса.
Запись ресурса состоит из следующих полей:
Для бОльшего понимания, приведу пример. Делегирование управления поддоменом k-max.name другому лицу (в моем случае — хостеру) приводит к созданию новой зоны, которая администрируется независимо от остального пространства имен (независимо от вышестоящего name.). Зона k-max.name после делегирования полномочий теперь не зависит от name. и может содержать все (вернее сказать — любые имена, которые я захочу) доменные имена, которые заканчиваются на *.k-max.name. С другой стороны, зона name. содержит только доменные имена, оканчивающиеся на *.name., но не входящие в делегированные этой зоны, такие, например, как k-max.name или a-lab.name или любая другая. k-max.name может быть поделен на поддомены с именами вроде mail.k-max.name, ftp.k-max.name и некоторые из этих поддоменов могут быть выделены в самостоятельные зоны, и ответственность за данные зоны может так же быть делегирована. Если ftp.k-max.name будет являться самостоятельной зоной, то зона k-max.name не будет содержать доменные записи, которые заканчиваются на *.ftp.k-max.name.
Т.о. после делегирования ответственности, информация хранимая делегирующей зоной уже не включает информацию по делегированному поддомену и его ресурсным записям хостов, а хранит информацию о серверах имен, являющихся для делегируемого поддомена авторитативными. Это и есть «склеивающие» записи, о чем я выше уже говорил. В таком случае, если у DNS-сервера родительского домена запрашиваются данные об адресе, принадлежащем делегированному поддомену, в ответ предоставляется список DNS-серверов, которые обладают соответствующей информацией.
Серверы DNS
Выше, при рассмотрении типов ресурсных записей я упоминал о первичном и вторичном сервере. Кроме данных типов, существует еще один тип — кэширующий.
Главный сервер DNS (он же первичный, он же master, он же primary) — это авторитетный сервер (иногда называют — авторитативный, как правильнее называть — не знаю), который хранит главную копию файла данных зоны, сопровождаемую администратором системы.
Вторичный сервер — тоже является авторитетным, но он копирует главный файл зоны с первичного сервера. Отличие главного от вторичного лишь в том, что главный загружает свою информацию из конфигурационных файлов зоны, а вторичный — загружает (получает) настройки зон — с главного сервера. Вторичный DNS может получать свои данные и от другого вторичного сервера. Любой запрос относительно хоста в пределах зоны, за которую отвечает авторитетный сервер, будет в конце концов передан одному из этих серверов (главному или вторичному). Вторичных серверов может быть сколько угодно много. В зависимости от настроек, главный сервер может посылать вторичному сигнал о изменении зоны, при этом вторичный, получив сигнал производит копирование. Данное действие называется трансфер зоны (zone transfer). Существует два механизма копирования зоны: полное копирование (AXFR) и инкрементальное (incremental) копирование зоны (IXFR).
Кэширующие серверы НЕ АВТОРИТЕТНЫ, данные серверы хранят в памяти (кэше), ответы на предыдущие запросы, если данный сервер получил запрос, то он сначала просматривает информацию в кэше, и если в кэше не оказалось необходимого ответа, то отправляет запрос вышестоящему серверу DNS.
Возможно так же настроить DNS в режиме stels (т.н. невидимый), информацию о данном сервере невозможно получить используя прямые запросы. Это может быть полезно для организации primary сервера в защищенной среде и тем самым оградить зону от атак на зону.
Клиенты DNS (resolver)
Как же программы на конечных машинах знают куда и в каком виде посылать запросы DNS? Они этого не знают. Для разрешения имен и IP адресов клиентскими приложениями используется библиотека Resolver. Это не какое-то специальное приложение, это функциональность системы (ядра). Т.о. приложения посылают системные вызовы gethostbyname(2) и gethostbyaddr(2), а ядро уже на основании настроек в файле /etc/nsswitch.conf определяет по какому пути ему далее действовать. Данный файл определяет какие сервисы (будь то файл /etc/hosts или DNS) и в каком порядке использовать. В ранних версиях библиотеки Linux — libc, использовался файл /etc/host.conf. Вот фрагмент файла, который нас интересует:
Две строки данного фрагмента указывают ядру производить преобразование имен хостов в IP (строка hosts: files dns) сначала из файла hosts, затем силами DNS, а так же преобразование имен сетей в IP (строка networks: files) с помощью файла /etc/network.Возможны так же параметры nis или nisplu, определяющие использовать Network Information System (NIS) чтобы найти адрес. Порядок, в котором перечислены сервисы, определяет последовательность их опроса.
Если согласно /etc/nsswitch.conf запрос отправляется DNS, то используются настройки из файла /etc/resolv.conf, который определяет какие серверы DNS использовать. Вот типичный пример файла /etc/resolv.conf:
Директива nameserver определяет адрес сервера доменных имен, который будет выполнять рекурсивные запросы resolver. В данном файле указано использовать север имен сначала 192.168.1.1 затем, если первый не смог обработать запрос, 192.168.1.2. Рекомендуется не использовать более 3х параметров nameserver. Если опция nameserver не задана, то резолвер попытается соединиться с сервером на локальном хосте. Параметр domain определяет заданное по умолчанию имя домена, которое будет подставлено, когда DNS не удастся найти имя хоста. Существует так же опция search, которая задает дополнительные домены, в которых необходимо произвести поиск и разрешение имени хоста. Опции search и domain нельзя использовать совместно.
Кроме кэша на ДНС сервере, существуют кэши интернет-браузеров, кэши резолверов. Довольно прозрачную картину предоставляет Wikipedia:
Запросы DNS
В DNS имеются следующие типы запросов: итеративный (он же прямой), обратный и рекурсивный.
Итеративный (он же прямой, он же нерекурсивный) запрос посылает доменное имя DNS серверу и просит вернуть либо IP адрес этого домена, либо имя DNS сервера, авторитативного для этого домена. При этом, сервер DNS не опрашивает другие серверы для получения ответа. Так работают корневые и TLD серверы.
Рекурсивный запрос посылает DNS серверу доменное имя и просит возвратить IP адрес запрошенного домена. При этом сервер может обращаться к другим DNS серверам.
Обратный запрос посылает IP и просит вернуть доменное имя.
Любой DNS-server должен отвечать на итеративные запросы. Возможно настроить DNS отвечать и на рекурсивные запросы. Если DNS не настроен отвечать на рекурсивные запросы, он обрабатывает их как итеративные.
- Клиент (браузер, почтовая программа, либо любое другое приложение) отправляет запросрезолверу, резолвер на основании указанных конфигов определяет адрес настроенного сервера имен.
- Резолверпосылает запрос указанному серверу имен.
- Сервер имен принимает данный рекурсивный запрос и, т.к. не имеет информации ни о домене, ни, возможно, даже о зоне name., отправляет рекурсивный (или нерекурсивный в зависимости от настроек) запроссерверу, отвечающему за корневую зону.
- Сервер корневой зоны не обрабатывает рекурсивные запросы, в результате обрабатывает данный запрос как итеративный и возвращает имя и адрес сервера, авторитетного за зону name.
- Сервер последовательно продолжает опрашивать авторитативные сервера для последующих зон, в порядке убывания уровня зон в имени
- пока не получает удовлетворительный ответ, данных шагов может быть больше, в зависимости от длины доменного имени
- и «вложенности» доменных имен.
- В итоге, сервер получает необходимый ответ от сервера имен, хранящего необходимую ресурсную запись о хосте.
- Сервер провайдера локальной сети возвращает резолверу клиента запрошенные данные.
Для решения данного вопроса DNS-серверы BIND используют метрику, называемую временем отклика (roundtrip time, или RTT), для выбора среди авторитативных DNS-серверов одной зоны. RTT определяет задержку, с которой приходит ответ на запросы от удаленного сервера. Каждый раз, при передаче запроса удаленному серверу, DNS-сервер BIND запускает внутренний таймер. Таймер останавливается при получении ответа, и метрика фиксируется локальным сервером. Если приходится выбирать один из нескольких авторитативных серверов, выбор падает на сервер с наименьшим показателем RTT.
До того как BIND впервые послал запрос какому-либо серверу и получил от него ответ, удаленному серверу присваивается случайное значение RTT, которое меньше, чем все прочие, полученные на основании замеров. Таким образом, DNS BIND гарантированно опросит все авторитативные серверы для определенной зоны случайным образом, прежде чем начнет выбирать предпочтительный на основании метрики.
Ответы DNS сервера
- Авторитативный ответ (authoritative response) приходит от серверов, являющихся ответственными за зону.
- Неавторитативный ответ (non authoritative response) приходит от серверов, которые не отвечают за зону (от кэширующих).
- Запись заголовка — служебную информацию о запросе.
- Запись запроса — повторяет отправленный запрос.
- Запись ответа — собственно, сам ответ.
- Записи авторитетных серверов — информацию об авторитетных серверах, хранящих информацию по текущему запросу.
- Дополнительную информацию — дополнительные записи, например адреса NS-серверов.
Обратное преобразование имен
DNS используется в первую очередь для преобразования доменных имён в IP-адреса, но он также может выполнять обратный процесс, называемый Обратное преобразование имен или обратным отображением. Т.к. записи в прямой базе DNS структурированы иерархически по доменным именам, DNS не может эффективно выполнять поиск по IP адресу в такой базе. Для обратного преобразования в DNS используется специальный домен in-addr.arpa. Ресурсные записи в данном домене в поле Name содержат IP-адреса, в поле Type — PTR, а в поле Data — FQDN-имя соответствующее данному IP.
На схеме представлена структура домена arpa. Думаю, что тут все довольно наглядно. Домен arpa. имеет 2 поддомена in-addr и ip6, отвечающие за IPv4 и IPv6 адреса соответственно. Домен in-addr.arpa. имеет от *.0.in-addr.arpa. до *.255.in-addr.arpa. поддоменов, каждый из которых так же имеет по 256 поддоменов.
В целях уменьшения объёма нежелательной корреспонденции (спама) многие почтовые серверы могут проверять наличие PTR записи для хоста, с которого происходит отправка. В этом случае PTR запись для IP адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP сессии.
Наглядно приведенную схему можно представить командами:
Имя 50.0.87.194 не заканчивается точкой и поэтому является относительным. Вопрос: относительным относительно чего? Ни в коем случае не относительно "www.ru". Для того чтобы эта запись была FQDN, домен по умолчанию должен называться «IN-ADDR.ARPA.». Этого можно добиться либо поместив записи PTR в отдельный файл, в котором доменное имя зоны по умолчанию — IN-ADDR.ARPA. (заданный в файле начальной загрузки демона named), либо изменив этот домен с помощью директивы $ORIGIN. Если домен по умолчанию определен как 0.87.194.IN-ADDR.ARPA., то запись можно представить так:
В двух словах хотел бы затронуть вопрос регистрации доменных имен.
Регистратор доменных имён — это организация, имеющая полномочия создавать (регистрировать) новые доменные имена и продлевать срок действия уже существующих доменных имён в домене, для которого установлена обязательная регистрация.
В завершение статьи хочу отметить так же о таком маркетинговом нюансе, что иногда домены второго уровня называют именами доменов ПЕРВОГО уровня, тем самым «опуская» значение корневого домена и принимая за корневой домен — домены TLD.
Так же хочу отметить, что доменный адрес и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.
Резюме
Итак, в сегодняшней статье я постарался как можно понятней описать работы доменной системы имен. Надеюсь, это у меня получилось. Мы рассмотрели иерархическую структуру базы данных DNS, а так же рассмотрели процессы взаимодействия клиентов и серверов DNS, а так же разновидности серверов DNS. В следующей статье я рассмотрю практические вопросы установки и настройки DNS сервера BIND на Linux. Буду рад Вашим комментариям.
Что еще почитать:
Разместил с разрешения mcsim85, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.
У меня (как и у многих web-разработчиков) имеется с десяток сайтов которые необходимо где-то размещать (хостить).
Сайты практически не приносят прибыли, поскольку это какие-то старые работы (по разным причинам не пошедшие в продакшн), домашняя страница, сайт заведенный красивой почты и тому подобное. Но в то же время эти сайты жалко бросать, а потому приходится каждый месяц на них тратить вполне реальные деньги чтобы покупать хостинг. Деньги, прямо скажем небольшие, но тем не менее их жалко, поскольку отдачи от сайтов никакой нет.
В то-же время в наличии имеется:
- Домашний сервер на Ubuntu
- Быстрый ethernet-интернет от МТС
Читайте также: