Сколько dns можно указывать для сетевого интерфейса
Facebook Если у вас не работает этот способ авторизации, сконвертируйте свой аккаунт по ссылке ВКонтакте Google RAMBLER&Co ID
Авторизуясь в LiveJournal с помощью стороннего сервиса вы принимаете условия Пользовательского соглашения LiveJournal
А вот если у Windows есть несколько сетевых соединений, и на каждом из них настроены свои DNSы, то в каком порядке эти DNSы будут использоваться при разрешении имён?
Более узкий вопрос: есть физическое соединение (со своим DNSом) и поверх него VPN (со своим DNSом). Поскольку при поднятии VPN Windows не отключает default route через физическое соединение, а только сильно повышает ему метрику, то пакетам ничто не мешает ходить через это физическое соединение в приделанный к нему DNS-сервер. Будет ли в этом случае использоваться первый сервер, второй сервер, оба по очереди, оба сразу – кто быстрее ответит, или как?
“The DNS Client service queries the DNS servers in the following order:
- The DNS Client service sends the name query to the first DNS server on the preferred adapter’s list of DNS servers and waits one second for a response.
- If the DNS Client service does not receive a response from the first DNS server within one second, it sends the name query to the first DNS servers on all adapters that are still under consideration and waits two seconds for a response.”
Осталось понять, кто есть preferred adapter..
Определение
Как долго происходит изменение DNS?
Сами изменения в DNS вносятся моментально. Но в связи с тем, что провайдеры кэшируют DNS, то процесс изменения DNS по всему миру может занять время от нескольких минут до 72 часов.
Level3
Level3 – это ещё один бесплатный качественный сервис. Он работает на следующих IP-адресах: предпочитаемый 209.244.0.3, альтернативный 208.244.0.4.
Как указать (изменить) DNS-сервера для домена?
- зарегистрироваться у регистратора домменых имен;
- Найти нужный домен и выбрать там "Управление DNS-серверами / Делегирование"
- В открывшейся форме укажите нужные DNS-сервера (IP можно не указывать). или установите галочку "Использовать DNS-сервера регистратора".
- Нажмите на кнопку "Сохранить".
Информация о Ваших изменениях будет доступна за период от нескольких минут до 72 часов. Поэтому в первое время возможно, что DNS-сервера будут старые. Это не зависит не от регистратора не от хостиг-провайдера. Вам остается только ждать.
там полно приколов
Если у контроллера домена два интерфейса, а один смотрит например в другую (внешнюю) сеть, в список адресов домена в днс опубликуются автоматически (и это я не знаю где отключить) оба адреса. И получается классный цирк, клиенты то видят контроллер, потому что им dns возвращает адрес своей сети, то не видят. Если сетевых карт две, то во второй карточке в качестве днс-а предлагается записать собственный внешний адрес.
очень просто решить - снять галку "register this connection in DNS" на внешнем адаптере.
порядок предпочтения физических адаптеров тоже настраивается.
на контроллере домена эта галочка не поможет.
Сейчас не могу проверить - нет таких DC в доступности. Но раньше точно помогало, когда отвязывал от внешней сетевушки все сервисы, кроме TCP, и настраивал порядок интерфейсов.
А вообще - multihomed DC меня раздражали ещё с 2000й, поэтому по возможности избавляюсь от таких конфигураций.
>А вообще - multihomed DC меня раздражали ещё с 2000й
нет иногда другого выхода
Если на контроллере с работающим DNS установлено более одного сетевого интерфейса (внимание! это плохая практика! не стОит делать любой контроллер домена многодомным/multihomed по многим причинам!), то на всех "внутренних" интерфейсах надо прописать DNSы как указано выше, а на всех "внешних" (глядящих "наружу" вашей локальной сети, например, на провайдера) интерфейсах надо указать в качестве "первого DNS" только IP этого же самого интерфейса, т.е. "самого себя" (но ни в коем случае не 127.0.0.1!), а "вторым DNSом" не указывать ничего.
про шутку со 127.0.0.1 я уже почитал, он тогда может и клиентам по DHCP раздавать этот же 127.0.0.1 в качестве DNSа :)
а вот что контроллер домена в результате не стоит делать multihomed - это IMHO очень неправильно с точки зрения надёжности
>а вот что контроллер домена в результате не стоит делать multihomed - это IMHO очень неправильно с точки зрения надёжности
Ну вот пришлось. Причем второй интерфейс смотрит не в интернет, а в сеть мегафона, и фигачит туда смс-ки клиентам банка.
Являясь провайдером виртуальной инфраструктуры, компания 1cloud интересуется сетевыми технологиями, о которых мы регулярно рассказываем в своем блоге. Сегодня мы подготовили материал, затрагивающий тему доменных имен. В нем мы рассмотрим базовые аспекты функционирования DNS и вопросы безопасности DNS-серверов.
/ фото James Cridland CC
Изначально, до распространения интернета, адреса преобразовывались согласно содержимому файла hosts, рассылаемого на каждую из машин в сети. Однако по мере её роста такой метод перестал оправдывать себя – появилась потребность в новом механизме, которым и стала DNS, разработанная в 1983 году Полом Мокапетрисом (Paul Mockapetris).
Публичный DNS от компании Google является одним из самых быстрых и безопасных. Чтобы его настроить, нужно ввести IP-адрес «8.8.8.8» в качестве первичного DNS, а «8.8.4.4» в качестве дополнительного.
Как прикрепить домен к IP адресу?
Для того, чтобы прикрепить домен к IP адресу, Вам необходимо:
- зайти в настроку dns-записей и внести в зону DNS три записи:
- Для первой в качестве поддомена укажите www, выберите тип записи А, в качестве данных укажите IP адрес, к которому нужно прикрепить домен.
- Для второй записи укажите знак @ (собака) в качестве поддомена и так же выберите тип А и укажите тот же IP.
- Для третьей записи в качестве поддомена укажите знак * (звёздочку) и так же выберите тип А и укажите тот же IP.
- Нажмите "Добавить/Сохранить"
Теперь Вам нужно подождать, пока изменения вступят в силу и Ваш сайт будет открываться с этого IP адреса. Это может занять до 72 часов.
Настройка в Windows
Чтобы настроить DNS-сервер в операционной системе Windows любой из версий, начиная с ХР и заканчивая 10, нужно:
- нажать сочетание клавиш Win+R и в окне «Выполнить» набрать команду «ncpa.cpl», после чего нажать кнопку «Ок»;
- в окне «Сетевые подключения» выбрать соединение, через которое вы подключены к провайдеру, кликнуть по нему правой кнопкой мыши и выбрать нижний пункт «Свойства»;
- когда откроется окно «Ethernet: свойства», найдите строку «IP версии 4», станьте на неё и нажмите кнопку «Свойства»;
- в открывшемся окне установите переключатель «Использовать следующие адреса DNS-серверов» и введите в строках «Предпочитаемый DNS-сервер » и «Альтернативный DNS-сервер » нужные IP-адреса.
Интернет - это совокупность локальных сетей компьютеров, расположенных по всему миру, которые связываются между собой по единым правилам, называемым протоколами.
Для того, чтобы Ваш сайт с Вашим доменным именем заработал - необходимо указать DNS-сервера, на которых будет "записано", на каком именно сервере(хостинге) находится Ваш сайт. DNS сервера имеют вид:
- DNS регистратора. В этом случае, Вам нужно будет полностью настроить зону DNS как в третьем варианте.
- DNS хостинг-провайдера. В этом случае всю предварительную настройку DNS, достаточную для нормальной работы Вашего сайта сделает хостинг-провайдер.
- Сторонний DNS. Вы можете указать хостинг DNS вообще на стороннем сервере DNS, например, Яндекс-DNS.
Norton ConnectSafe
Компания Norton разрабатывает не только антивирусные программы, но и предлагает воспользоваться их сервером доменных имен. Данный облачный сервис защищает ПК от фишинговых сайтов. Он поставляется в трёх версиях, с разными предварительно настроенными фильтрами:
- безопасность;
- безопасность и порнография;
- безопасность, порнография и другое.
Comodo Secure DNS
Благодаря тому, что Comodo Secure DNS рассылает ваш запрос на большое количество глобальных серверов, она способна обеспечить высокую скорость работы в интернете. Чтобы воспользоваться этим сервисом, введите основной адрес «8.26.56.26» и дополнительный «8.20.247.20».
Преимущества публичных DNS
Иногда лучше использовать не те ДНС серверы, которые по умолчанию предоставляет провайдер , а воспользоваться публичными. Для этого существуют следующие причины:
- использование быстрых публичных DNS увеличит скорость работы интернета;
- иногда используемые по умолчанию серверы работают нестабильно, в этом случае использование публичных серверов повысит надёжность;
- некоторые публичные DNS включают дополнительные функции по фильтрации данных, которые увеличивают безопасность компьютера;
- публичные DNS помогут обойти ограничения по расположению, например, можно будет смотреть видео в ютубе, на котором раньше было написано: «Это видео недоступно в вашей стране».
DNS Advantage
DNS Advantage – это очень быстрый сервер , который поможет работать в интернете быстрее и безопаснее. Его основной адрес: «156.154.70.1», а дополнительный «156.154.71.1».
Бесплатный сервис Dyn в основном предназначен для защиты вашего ПК от фишинговых атак. Для того, чтобы начать работать с этим сервисом, настройте следующие параметры: адрес основного DNS-сервера «216.146.53.35», альтернативного «216.146.36.36».
Что такое DNS?
Система доменных имен (DNS) является одной из фундаментальных технологий современной интернет-среды и представляет собой распределенную систему хранения и обработки информации о доменных зонах. Она необходима, в первую очередь, для соотнесения IP-адресов устройств в сети и более удобных для человеческого восприятия символьных имен.
DNS состоит из распределенной базы имен, чья структура напоминает логическое дерево, называемое пространством имен домена. Каждый узел в этом пространстве имеет свое уникальное имя. Это логическое дерево «растет» из корневого домена, который является самым верхним уровнем иерархии DNS и обозначается символом – точкой. А уже от корневого элемента ответвляются поддоменые зоны или узлы (компьютеры).
Пространство имен, которое сопоставляет адреса и уникальные имена, может быть организовано двумя путями: плоско и иерархически. В первом случае имя назначается каждому адресу и является последовательностью символов без структуры, закрепленной какими-либо правилами. Главный недостаток плоского пространства имен – оно не может быть использовано в больших системах, таких как интернет, из-за своей хаотичности, поскольку в этом случае достаточно сложно провести проверку неоднозначности и дублирования.
Где находятся
Самые важные 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-записи в течение часа для пользователей был недоступен известный всем сервис Twitter, – рассказывает Алексей Шевченко, руководитель направления инфраструктурных решений российского представительства ESET. – Но куда опаснее атаки на корневые DNS-сервера. В частности, широкую огласку получили атаки в октябре 2002 года, когда неизвестные пытались провести DDoS-атаку на 10 из 13 DNS-серверов верхнего уровня».
Одним из вариантов может служить технология uRPF (Unicast Reverse Path Forwarding), идея которой заключается в определении того, может ли пакет с определенным адресом отправителя быть принят на конкретном сетевом интерфейсе. Если пакет получен с сетевого интерфейса, который используется для передачи данных, адресованных отправителю этого пакета, то пакет считается прошедшим проверку. В противном случае он отбрасывается.
Несмотря на то что, данная функция может помочь обнаружить и отфильтровать некоторую часть поддельного трафика, uRPF не обеспечивает полную защиту от подмены. uRPF предполагает, что прием и передача данных для конкретного адреса производится через один и тот же интерфейс, а это усложняет положение вещей в случае нескольких провайдеров. Более подробную информацию о uRPF можно найти здесь.
Еще один вариант – использование функции IP Source Guard. Она основывается на технологии uRPF и отслеживании DHCP-пакетов для фильтрации поддельного трафика на отдельных портах коммутатора. IP Source Guard проверяет DHCP-трафик в сети и определяет, какие IP-адреса были назначены сетевым устройствам.
После того как эта информация была собрана и сохранена в таблице объединения отслеживания DHCP-пакетов, IP Source Guard может использовать ее для фильтрации IP-пакетов, полученных сетевым устройством. Если пакет получен с IP-адресом источника, который не соответствует таблице объединения отслеживания DHCP-пакетов, то пакет отбрасывается.
Также стоит отметить утилиту dns-validator, которая наблюдает за передачей всех пакетов DNS, сопоставляет каждый запрос с ответом и в случае несовпадения заголовков уведомляет об этом пользователя. Подробная информация доступна в репозитории на GitHub.
Инструкции по смене DNS-серверов
Какие DNS сервера можно использовать для доступа в интернет?
Топ 10 публичных DNS
Теперь вы знаете, чем могут быть полезны публичные DNS-серверы. Рассмотрим список из 10 наиболее популярных.
Сопоставление имен
Также стоит пару слов сказать про процедуру обратного сопоставления – получение имени по предоставленному IP-адресу. Это происходит, например, при проверках сервера электронной почты. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя.
SafeDNS
Служба SafeDNS основана на облачной технологии, что помогает защитит ПК. Для работы с ней нужно задать следующие адреса: предпочитаемый «195.46.39.39», дополнительный «195.46.39.40».
там полно приколов
Если у контроллера домена два интерфейса, а один смотрит например в другую (внешнюю) сеть, в список адресов домена в днс опубликуются автоматически (и это я не знаю где отключить) оба адреса. И получается классный цирк, клиенты то видят контроллер, потому что им dns возвращает адрес своей сети, то не видят. Если сетевых карт две, то во второй карточке в качестве днс-а предлагается записать собственный внешний адрес.
очень просто решить - снять галку "register this connection in DNS" на внешнем адаптере.
порядок предпочтения физических адаптеров тоже настраивается.
на контроллере домена эта галочка не поможет.
Сейчас не могу проверить - нет таких DC в доступности. Но раньше точно помогало, когда отвязывал от внешней сетевушки все сервисы, кроме TCP, и настраивал порядок интерфейсов.
А вообще - multihomed DC меня раздражали ещё с 2000й, поэтому по возможности избавляюсь от таких конфигураций.
>А вообще - multihomed DC меня раздражали ещё с 2000й
нет иногда другого выхода
Если на контроллере с работающим DNS установлено более одного сетевого интерфейса (внимание! это плохая практика! не стОит делать любой контроллер домена многодомным/multihomed по многим причинам!), то на всех "внутренних" интерфейсах надо прописать DNSы как указано выше, а на всех "внешних" (глядящих "наружу" вашей локальной сети, например, на провайдера) интерфейсах надо указать в качестве "первого DNS" только IP этого же самого интерфейса, т.е. "самого себя" (но ни в коем случае не 127.0.0.1!), а "вторым DNSом" не указывать ничего.
про шутку со 127.0.0.1 я уже почитал, он тогда может и клиентам по DHCP раздавать этот же 127.0.0.1 в качестве DNSа :)
а вот что контроллер домена в результате не стоит делать multihomed - это IMHO очень неправильно с точки зрения надёжности
>а вот что контроллер домена в результате не стоит делать multihomed - это IMHO очень неправильно с точки зрения надёжности
Ну вот пришлось. Причем второй интерфейс смотрит не в интернет, а в сеть мегафона, и фигачит туда смс-ки клиентам банка.
Являясь провайдером виртуальной инфраструктуры, компания 1cloud интересуется сетевыми технологиями, о которых мы регулярно рассказываем в своем блоге. Сегодня мы подготовили материал, затрагивающий тему доменных имен. В нем мы рассмотрим базовые аспекты функционирования DNS и вопросы безопасности DNS-серверов.
/ фото James Cridland CC
Изначально, до распространения интернета, адреса преобразовывались согласно содержимому файла hosts, рассылаемого на каждую из машин в сети. Однако по мере её роста такой метод перестал оправдывать себя – появилась потребность в новом механизме, которым и стала DNS, разработанная в 1983 году Полом Мокапетрисом (Paul Mockapetris).
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.
Кто управляет и поддерживает DNS-сервера?
Каждый из этих операторов предоставляет данную услугу бесплатно, а также обеспечивает бесперебойную работу, поскольку при отказе любого из этих серверов станут недоступны целые зоны интернета. Ранее корневые DNS-серверы, являющиеся основой для обработки всех запросов о доменных именах в интернете, располагались в Северной Америке. Однако с внедрением технологии альтернативной адресации они «распространились» по всему миру, и фактически их число увеличилось с 13 до 123, что позволило повысить надёжность фундамента DNS.
Например, в Северной Америке находятся 40 серверов (32,5%), в Европе – 35 (28,5%), еще 6 серверов располагаются в Южной Америке (4,9%) и 3 – в Африке (2,4%). Если взглянуть на карту, то DNS-серверы расположены согласно интенсивности использования интернет-инфраструктуры.
Настройка DNS-записей.
Пример внесения записей в DNS:
Предположим, вы зарегистрировали домен mydomain.ru и IP-адрес web-сервера, на котором будет расположен сайт - 195.128.128.26. В этом случае Вам потребуется создать минимум две записи типа "A" для Вашего домена (чтобы связать mydomain.ru и www.mydomain.ru с адресом 195.128.128.26). Для этого в форме добавления записей "A" в поле "Имя поддомена" укажите "@" для первой записи и "www" для второй записи, а в поле "Данные" укажите 195.128.128.26 (для обоих записей).
Чтобы сделать пересылку всех поддоменов на IP адрес, нужно в качестве "Имени поддомена" указать *
Пример 2: Вы хотите, чтобы адрес mail.mydomain.ru указывал на тот же хост, что и адрес relay.highway.ru. Для этого необходимо в поле 'Имя поддомена' указать "mail", выбрать 'Тип записи' CNAME, а в поле 'Данные' указать "relay.highway.ru.".
Принцип работы и применение
Работа DNS похожа на работу со списком контактов смартфона. Вы находите требуемый контакт по имени, нажимаете на значок «позвонить», телефон набирает нужный номер и соединяет с соответствующим абонентом.
То же самое происходит, когда вы набираете адрес сайта в браузере. Так как компьютер не знает реального IP-адреса, он отсылает запрос на DNS-сервер , на котором храниться база адресов. После получения ответа браузер загружает данные с нужного сайта и показывает их пользователю.
Рассмотрим подробнее, как работает dns сервер :
- Пользователь в адресной строке браузера вводит доменное имя сайта, на который хочет перейти.
- Браузер ищет нужный IP-адрес на локальном компьютере, в файле hosts. Если нужной информации там не находит, то отправляет свой запрос на сервер более высокого уровня. Например, это может быть локальный сервер провайдера.
- Если и на этом сервере нет данных об IP-адресе сайта, то запрос переправляется на сервис более высокого уровня. Такая переадресация будет длиться, пока нужный адрес не будет найден или корневой DNS-сервер не ответит, что сайта с таким именем не существует.
- После этого начнётся обратное движение запроса, от высшего уровня до низшего, пока данные не придут на компьютер пользователя.
С помощью DNS можно не только найти адрес сайта по IP-адресу, но и выполнить обратную операцию: зная адрес, узнать его доменное имя.
DNS.Watch
DNS.Watch – это бесплатный, быстрый и незаметно работающий сервис DNS. Для его настройки введите на своём компьютере следующие IP-адреса: предпочитаемый DNS-сервер «84.200.69.80», альтернативный «84.200.70.40».
Заключение
Постоянно ведутся работы по повышению надежности, чтобы сделать систему менее чувствительной к сбоям (стихийные бедствия, отключения электросети и т. д.), и это очень важно, поскольку интернет стал неотъемлемой частью нашей жизни, и «терять» его, даже на пару минут, совершенно не хочется.
Кстати, компания 1cloud предлагает своим пользователям VPS бесплатную услугу «DNS-хостинг» – инструмент, упрощающий администрирование ваших проектов за счет работы с общим интерфейсом для управления хостами и ссылающимися на них доменами.
Основная цель 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, у которого еще нет полноценного аккаунта на хабре, но который за такие качественный статьи безусловно его заслуживает! На всякий случай ссылка на оригинал.
Читайте также: