Имя сервера что это
Как это работает: Пара слов о DNS
Являясь провайдером виртуальной инфраструктуры, компания 1cloud интересуется сетевыми технологиями, о которых мы регулярно рассказываем в своем блоге. Сегодня мы подготовили материал, затрагивающий тему доменных имен. В нем мы рассмотрим базовые аспекты функционирования DNS и вопросы безопасности DNS-серверов.
/ фото James Cridland CC
Изначально, до распространения интернета, адреса преобразовывались согласно содержимому файла hosts, рассылаемого на каждую из машин в сети. Однако по мере её роста такой метод перестал оправдывать себя – появилась потребность в новом механизме, которым и стала DNS, разработанная в 1983 году Полом Мокапетрисом (Paul Mockapetris).
Что такое DNS?
Система доменных имен (DNS) является одной из фундаментальных технологий современной интернет-среды и представляет собой распределенную систему хранения и обработки информации о доменных зонах. Она необходима, в первую очередь, для соотнесения IP-адресов устройств в сети и более удобных для человеческого восприятия символьных имен.
DNS состоит из распределенной базы имен, чья структура напоминает логическое дерево, называемое пространством имен домена. Каждый узел в этом пространстве имеет свое уникальное имя. Это логическое дерево «растет» из корневого домена, который является самым верхним уровнем иерархии DNS и обозначается символом – точкой. А уже от корневого элемента ответвляются поддоменые зоны или узлы (компьютеры).
Пространство имен, которое сопоставляет адреса и уникальные имена, может быть организовано двумя путями: плоско и иерархически. В первом случае имя назначается каждому адресу и является последовательностью символов без структуры, закрепленной какими-либо правилами. Главный недостаток плоского пространства имен – оно не может быть использовано в больших системах, таких как интернет, из-за своей хаотичности, поскольку в этом случае достаточно сложно провести проверку неоднозначности и дублирования.
Сопоставление имен
Давайте взглянем, как происходит сопоставление имен и IP-адресов. Предположим, пользователь набирает в строке браузера www.1cloud.ru и нажимает Enter. Браузер посылает запрос DNS-серверу сети, а сервер, в свою очередь, либо отвечает сам (если ответ ему известен), либо пересылает запрос одному из высокоуровневых доменных серверов (или корневому).
Также стоит пару слов сказать про процедуру обратного сопоставления – получение имени по предоставленному IP-адресу. Это происходит, например, при проверках сервера электронной почты. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя.
Кто управляет и поддерживает DNS-сервера?
Когда вы вводите адрес интернет-ресурса в строку браузера, он отправляет запрос на DNS-сервер отвечающий за корневую зону. Таких серверов 13 и они управляются различными операторами и организациями. Например, сервер a.root-servers.net имеет IP-адрес 198.41.0.4 и находится в ведении компании Verisign, а e.root-servers.net (192.203.230.10) обслуживает НАСА.
Каждый из этих операторов предоставляет данную услугу бесплатно, а также обеспечивает бесперебойную работу, поскольку при отказе любого из этих серверов станут недоступны целые зоны интернета. Ранее корневые DNS-серверы, являющиеся основой для обработки всех запросов о доменных именах в интернете, располагались в Северной Америке. Однако с внедрением технологии альтернативной адресации они «распространились» по всему миру, и фактически их число увеличилось с 13 до 123, что позволило повысить надёжность фундамента DNS.
Например, в Северной Америке находятся 40 серверов (32,5%), в Европе – 35 (28,5%), еще 6 серверов располагаются в Южной Америке (4,9%) и 3 – в Африке (2,4%). Если взглянуть на карту, то DNS-серверы расположены согласно интенсивности использования интернет-инфраструктуры.
Защита от атак
Атаки на DNS – далеко не новая стратегия хакеров, однако только недавно борьба с этим видом угроз стала принимать глобальный характер.
«В прошлом уже происходили атаки на DNS-сервера, приводящие к массовым сбоям. Как-то из-за подмены DNS-записи в течение часа для пользователей был недоступен известный всем сервис Twitter, – рассказывает Алексей Шевченко, руководитель направления инфраструктурных решений российского представительства ESET. – Но куда опаснее атаки на корневые DNS-сервера. В частности, широкую огласку получили атаки в октябре 2002 года, когда неизвестные пытались провести DDoS-атаку на 10 из 13 DNS-серверов верхнего уровня».
Протокол DNS использует для работы TCP- или UDP-порт для ответов на запросы. Традиционно они отправляются в виде одной UDP-датаграммы. Однако UDP является протоколом без установления соединения и поэтому обладает уязвимостями, связанными с подделкой адресов – многие из атак, проводимых на DNS-сервера, полагаются на подмену. Чтобы этому препятствовать, используют ряд методик, направленных на повышение безопасности.
Одним из вариантов может служить технология uRPF (Unicast Reverse Path Forwarding), идея которой заключается в определении того, может ли пакет с определенным адресом отправителя быть принят на конкретном сетевом интерфейсе. Если пакет получен с сетевого интерфейса, который используется для передачи данных, адресованных отправителю этого пакета, то пакет считается прошедшим проверку. В противном случае он отбрасывается.
Несмотря на то что, данная функция может помочь обнаружить и отфильтровать некоторую часть поддельного трафика, uRPF не обеспечивает полную защиту от подмены. uRPF предполагает, что прием и передача данных для конкретного адреса производится через один и тот же интерфейс, а это усложняет положение вещей в случае нескольких провайдеров. Более подробную информацию о uRPF можно найти здесь.
Еще один вариант – использование функции IP Source Guard. Она основывается на технологии uRPF и отслеживании DHCP-пакетов для фильтрации поддельного трафика на отдельных портах коммутатора. IP Source Guard проверяет DHCP-трафик в сети и определяет, какие IP-адреса были назначены сетевым устройствам.
После того как эта информация была собрана и сохранена в таблице объединения отслеживания DHCP-пакетов, IP Source Guard может использовать ее для фильтрации IP-пакетов, полученных сетевым устройством. Если пакет получен с IP-адресом источника, который не соответствует таблице объединения отслеживания DHCP-пакетов, то пакет отбрасывается.
Также стоит отметить утилиту dns-validator, которая наблюдает за передачей всех пакетов DNS, сопоставляет каждый запрос с ответом и в случае несовпадения заголовков уведомляет об этом пользователя. Подробная информация доступна в репозитории на GitHub.
Заключение
Система доменных имён разработана в еще 80-х годах прошлого века и продолжает обеспечивать удобство работы с адресным пространством интернета до сих пор. Более того, технологии DNS постоянно развиваются, например, одним из значимых нововведений недавнего времени стало внедрение доменных имен на национальных алфавитах (в том числе кириллический домен первого уровня.рф).
Постоянно ведутся работы по повышению надежности, чтобы сделать систему менее чувствительной к сбоям (стихийные бедствия, отключения электросети и т. д.), и это очень важно, поскольку интернет стал неотъемлемой частью нашей жизни, и «терять» его, даже на пару минут, совершенно не хочется.
Кстати, компания 1cloud предлагает своим пользователям VPS бесплатную услугу «DNS-хостинг» – инструмент, упрощающий администрирование ваших проектов за счет работы с общим интерфейсом для управления хостами и ссылающимися на них доменами.
Что такое name-сервер (NS)
Имя сайта (домен) понятен пользователю, но компьютеру для открытия страниц необходимо знать точный цифровой адрес. Преобразованием «на лету» занимается DNS-сервер (другие наименования – name-сервер, nameserver, NS). Он переводит доменное имя в IP-адрес или наоборот, в зависимости от задачи. В любом случае без этого промежуточного звена открыть веб-ресурс не получится.
Какие функции выполняет name-сервер?
Обычному пользователю и не нужно знать технические детали, NS-серверы работают в прозрачном режиме, их роль незаметна. После ввода имени сайта в адресную строку браузера и нажатия клавиши Enter «сразу» открывается запрошенная страница. Обращение к DNS будет видно только по логу работы приложения.
Часто первое открытие нового веб-ресурса происходит медленно из-за времени, необходимого для ответа DNS-сервера. Последующие запуски происходят быстрее именно благодаря кэшу со списком ранее запрошенных доменов. Технически «промежуточные» узлы делятся по функционалу на три группы:
Сайт не откроется при неправильно указанном адресе DNS-сервера (на хостинге) или при его недоступности, потому что браузер «не будет знать», на каком реальном IP находится сервер, который используется для размещения файлов веб-ресурса. Если владельцу доступна возможность внести правки в настройки хостинга, пользователю остается лишь ждать решения проблемы.
Что такое дочерний NS-сервер?
Практически все хостинг-провайдеры бесплатно предлагают DNS-серверы. И везде работает как минимум один дочерний (резервный) хост. Дочерние серверы формируются при помощи «родительского» домена, например ns1.timeweb.org, ns2.timeweb.org. Такой подход дает возможность размещать их на основном сервере (за счет этого он и предоставляется безвозмездно).
При настройке NS-записей на «родном» хостинге, где покупались домены, достаточно внести имена и сохранить изменения. В большинстве случаев они вводятся автоматически при регистрации сайта (имени). Если же приходится делегировать полномочия другим пользователям, понадобится добавить IP-адреса. Без них работать система идентификации онлайн-ресурсов не будет.
Ресурсные записи для домена
То же относится к настройке электронной почты и других веб-сервисов. Провайдер вносит данные в автоматическом режиме или вручную в панели управления хостингом. Второе чаще востребовано в случае аренды платных DNS-серверов. Например, если у компании одновременно работает сразу несколько сайтов (существуют тарифы до 150 доменов и 12 000 записей).
Базовые типы записей:
От корректности заполнения адресов DNS-сервера зависит работоспособность сайта и его продвижение. Например, MX-записи используются для повышения репутации при рассылках по email (с ними письма реже попадают в категорию «спам»). TXT-записи востребованы для работы системных администраторов и оптимизаторов, пользующихся сторонними сервисами мониторинга и анализа сайтов.
DNS записи и сервер имен (DNS-сервер)
Опубликовано admin в 19 февраля, 2020 19 февраля, 2020
Если вы переносили сайт с одного хоста на другой, вам приходилось обновлять записи DNS. Хотя сам процесс безболезненный, многие могут не задумываться над тем, что это такое и причем тут сервер имен или DNS сервер, кроме того, что техническая поддержка говорит, что им нужно измениться.
В статье представлено краткое руководство для исправления этого пробела в знаниях. Рассказано простыми словами не только, что это за записи, но и какую роль они выполняют на вашем ресурсе.
Что такое DNS
DNS (Domain Name System) — это система доменных имен, которая превращает доменные имена в IP-адреса для загрузки интернет страниц.
Когда люди вводят название сайтов, например «Yandex.ru», в адресную строку браузера, DNS находит надлежащий IP-адрес и указывает куда надо перейти для доступа к данным сайта.
Это позволяет менять хосты без изменения домена, поэтому пользователям не нужно запоминать цифры.
Система содержит информацию о каждом портале в Интернете. Обойти это невозможно, в отличие от некоторых других областей. Хотя вы можете никогда не обновлять свои сведения — они все равно существуют.
Миграция информации является неотъемлемой частью в глобальной сети. Обновление и указание вашего домена при переезде на новый — это все, что требуется хосту для передачи, за вычетом небольшого времени распространения.
Что такое DNS-сервер
DNS-сервер — это компьютер с базой данных, содержащей общедоступные IP, связанные с названиями веб-сайтов.
Это можно представить как своеобразную телефонную книгу для Интернета. В ней находится список с соответствующими уникальными числовыми данными, называемыми IP-адресами, вместо того, чтобы указывать людей с их телефонными номерами. Когда пользователь вводит в своем браузере запрос, происходит поиск цифрового идентификатора в компьютерной сети WAN.
Как только DNS находит запрашиваемый IP-адрес, браузеры берут его и используют для отправки данных на исходные серверы. После этого пользователь получает доступ к информации на странице. DNS запускает процесс, выбирая соответствующий унифицированный указатель ресурса (URL).
«Сервер имен» и «DNS-сервер» часто являются взаимозаменяемыми терминами — они означают одно и то же, поэтому не запутайтесь, если услышите такую терминологию.
DNS, сервер имен и ваш сайт
Соединение этих элементов — вот что позволяет сайту выходить во всемирную паутину. Все начинается с покупки домена у регистратора. Если вы являетесь его владельцем, ваш хост должен хранить свою информацию в DNS, чтобы обрабатывать его при входе в домен.
Это относительно простой процесс. Все, что нужно сделать, это указать, на какой сервер имен ссылается домен. Вы найдете его настройки в панели управления вашего регистратора. Большинство хостов сообщают свои адреса при регистрации, но быстрый звонок в службу поддержки устранит любую путаницу, если вы не сможете ее найти.
Почти всем регистраторам требуется основной и альтернативный DNS в случае, если один из них отключен. Например, «ns1.hosting.com» и «ns2.hosting.com». Каждый хостинг организовывает это немного по-своему. Поэтому обязательно проконсультируйтесь с провайдером.
Основные типы DNS записей
Существует несколько различных типов записей, которые можете изменить у своего регистратора. Как правило, все, что надо совершить — это обновить DNS. Но знание различных типов записей может помочь, если вам нужно что-то изменить в будущем.
A Record
A Record — это то, что указывают доменные имена на IP-адрес. Является самой чистой формой DNS, позволяющая пользователям вводить легко узнаваемое название, в то время как компьютер продолжает работать с числами.
CNAME
CNAME (Canonical Name) перенаправляет один домен на другой. Позволяет обновлять только одну «запись A» каждый раз, когда вы вносите изменения. Например, CNAME позволяет «site.net» получить «www.site.net» с «www» впереди.
MX Entry
MX Entry (почтовый обменник) направляет электронную почту на определенный почтовый сервис. Как и CNAME, записи MX должны указывать на домен. Вы также можете добавить несколько MX с разными приоритетами для избыточности, если у вас настроено значительное количество почтовых ящиков.
TXT Record
Это немного универсальная запись, предназначенная не для направления какого-либо трафика, а для предоставления информации внешним источникам. TXT Record служит ряду различных целей в зависимости от потребностей. Обычно используется для проверки Google.
AAAA Record
Запись AAAA аналогична A Record, но она позволяет указать адрес сайта IPv6 вместо интернет-протокола v4.
Вывод
Не волнуйтесь, если все это кажется немного сложным. Маршрутизация сложна, и эти базовые описания едва ли касаются каждого. В большинстве случаев вам никогда не нужно трогать эти настройки, но, если это сделаете, тех.поддержка любого хостинга всегда окажет помощь.
Автоматизация компьютеров для перенаправления миллионов запросов за доли секунды требует серьезной технической оснащенности и быстрых алгоритмов, и тем более серьезных знаний происходящих процессов. Тем не менее надеюсь, что этот пост хоть немного помог прояснить ситуацию.
Пишите в комментариях ниже, какую информацию добавить или убрать по теме: DNS записи и сервер имен (DNS-сервер). Открыт для предложений по оформлению и наполнению страницы.
HackWare.ru
Этичный хакинг и тестирование на проникновение, информационная безопасность
Введение в DNS терминологию, компоненты и концепции
Оглавление: Компьютерные сети
6. Канальный уровень передачи данных
7. Маршрутизация данных
8. Служебный протокол ICMP
10. Настройка сетевых подключений в командной строке Linux
11. Определение проблем работы сети
12. Туннелизация
Введение
DNS или Domain Name System (система доменных имён), часто является очень сложной частью обучения настройке веб-сайтов и серверов. Понимание того, как работает DNS, поможет вам диагностировать проблемы с настройкой доступа к вашим веб-сайтам и расширит ваше понимание того, что происходит за кулисами.
В данной первой части мы обсудим некоторые фундаментальные концепции DNS, которые помогут понять работу DNS и которые сделают осмысленной и облегчат настройку вашего DNS сервера. После прохождения всех частей вы получите полное представление о работе DNS, о настройке своей собственной DNS и выполнению запросов к DNS серверам.
В других частях будут рассмотрены все основные аспекты DNS: теория данной технологии, инфраструктура DNS, затем мы рассмотрим самостоятельную настройку DNS сервера и рассмотрим прикладные программы для DNS запросов.
Доменная терминология
Нам следует начать с определения терминов. Хотя некоторые из этих тем знакомы из других областей веб технологий и IT, существует много специальных терминов, используемых при разговоре о доменных именах и DNS, которые не слишком часто используются в других областях вычислительной техники.
Система доменных имён (domain name system)
Система доменных имён, более известная как «DNS», является сетевой системой, которая позволяет нам преобразовывать понятные для человека имена в уникальные адреса.
Доменное имя (Domain Name)
URL «google.com» связан с серверами, принадлежащими Google Inc. Система доменных имён позволяет нам обращаться к серверам Google, когда мы вводим «google.com» в наших браузерах.
IP адрес
IP-адрес — это то, что мы называем network addressable location, то есть сетевое расположение, к которому можно обратиться по адресу. Каждый IP-адрес должен быть уникальным в своей сети. Когда мы говорим о веб-сайтах, эта сеть представляет собой весь интернет.
Наиболее популярной формой адресов являются IPv4, которые пишутся как четыре набора чисел, каждый набор может иметь от одной до трёх цифр, наборы разделены точкой. Например «111.222.111.222» может быть правильным IPv4 адресом. С помощью DNS мы сопоставляем имя с этим адресом, чтобы вам не приходилось запоминать сложный набор чисел для каждого места, которое вы хотите посетить в сети.
Домен верхнего уровня (Top-Level Domain)
Домен верхнего уровня, или TLD, является наиболее общей частью домена. Домен верхнего уровня — это самая дальняя часть справа (отделённая точкой). Распространёнными доменами верхнего уровня являются «com», «net», «org», «gov», «edu» и «io».
Домены верхнего уровня находятся на вершине иерархии с точки зрения доменных имён. Некоторым сторонам ICANN (Internet Corporation for Assigned Names and Numbers — Интернет-корпорация по присвоению имён и номеров) предоставляет административный контроль над доменами верхнего уровня. Эти стороны могут затем распространять доменные имена в рамках TLD, обычно через регистратора доменов.
Хосты
Вы можете иметь другие установленные хосты в общем домене. Вы можете получить доступ к API через хост «api» (api.example.com) или получить доступ по ftp, определив хост с именем «ftp» или «files» (ftp.example.com или files.example.com). Имена хостов могут быть произвольными, если они уникальны для домена.
Субдомен (SubDomain)
Субдомены связаны с хостами.
DNS работает в иерархии. У доменов верхнего уровня может быть много доменов. Например, в домене «com» есть и «google.com», и «ubuntu.com». Термин «субдомен» относится к любому домену, который является частью более крупного домена. В этом случае «ubuntu.com» можно назвать поддоменом «com». Обычно это называется доменом, или часть «Ubuntu» называется SLD, что означает домен второго уровня (second level domain).
Аналогично, каждый домен может управлять субдоменами следующих уровней (третьего, четвёртого и т.д.), которые находятся под ним. Именно это мы подразумеваем под поддоменами. Например, у вас может быть поддомен для исторического факультета вашей школы по адресу «www.history.school.edu». Часть «history» является поддоменом.
Разница между именем хоста и поддоменом заключается в том, что хост определяет компьютер или ресурс, в то время как поддомен расширяет родительский домен. Это метод разделения самого домена.
Говоря о поддоменах или хостах, вы можете начать видеть, что самые левые части домена являются наиболее специфичными. Также работает и DNS: если смотреть слева направо, то от наиболее конкретного к наименее конкретному.
Полностью определённое имя домена (Fully Qualified Domain Name)
Это означает, что он указывает каждый родительский домен, включая TLD. Правильное полное доменное имя заканчивается точкой, обозначающей корень иерархии DNS. Примером полного доменного имени является «mail.google.com.». Иногда программное обеспечение, которое запрашивает полное доменное имя, не требует конечной точки, но конечная точка должна соответствовать стандартам ICANN.
Сервер имён (Name Server)
Сервер имён — это компьютер, предназначенный для перевода доменных имён в IP-адреса. Эти серверы выполняют большую часть работы в системе DNS. Поскольку общее количество переводов доменов слишком велико для какого-либо одного сервера, каждый сервер может перенаправить запрос на другие серверы имён или делегировать ответственность за подмножество поддоменов, за которые они отвечают.
Серверы имён могут быть «авторитативными» (authoritative), что означает, что они дают ответы на запросы о доменах, находящихся под их контролем. В противном случае они могут указывать на другие серверы или обслуживать кэшированные копии данных других серверов имён.
Файл зоны (Zone File)
Файл зоны — это простой текстовый файл, который содержит сопоставления между доменными именами и IP-адресами. В конечном счёте именно так система DNS выясняет, какой IP-адрес следует вернуть в ответе, когда пользователь запрашивает определённое доменное имя.
Файлы зон находятся на серверах имён и, как правило, определяют ресурсы, доступные в определённом домене, или место, где можно получить эту информацию.
Записи (Records)
Внутри файла зоны хранятся записи. В своей простейшей форме запись это, по сути, одно сопоставление между ресурсом и именем. Они могут сопоставить доменное имя с IP-адресом, определить серверы имён для домена, определить почтовые серверы для домена и т. д.
Как работает DNS
Теперь, когда вы знакомы с некоторой терминологией, связанной с DNS, пришло время ответить на вопрос: как на самом деле работает DNS система?
Система очень проста в обзоре высокого уровня, но очень сложна, когда вы смотрите на детали. В целом, это очень надёжная инфраструктура, которая была необходима для принятия Интернета, каким мы его знаем сегодня.
Корневые серверы (Root Servers)
Как мы уже говорили выше, DNS по своей сути является иерархической системой. В верхней части этой системы находятся так называемые «корневые серверы». Эти серверы контролируются различными организациями и делегируемыми полномочиями от ICANN (Интернет-корпорация по присвоению имён и номеров).
В настоящее время работают 13 корневых серверов. Тем не менее поскольку существует невероятное количество имён, о которых ежеминутно приходят запросы, каждый из этих серверов фактически имеет зеркала. Интересной особенностью этой настройки является то, что каждое из зеркал для одного корневого сервера имеет один и тот же IP-адрес. Когда запросы сделаны для определённого корневого сервера, запрос будет направлен к ближайшему зеркалу этого корневого сервера.
Что делают эти корневые серверы? Корневые серверы обрабатывают запросы информации о доменах верхнего уровня. Поэтому, если поступает запрос о чём-то, что сервер имён более низкого уровня не может обработать, выполняется запрос к корневому серверу этого домена.
Корневые серверы на самом деле не знают, где находится домен. Тем не менее они смогут направить запрашивающего на серверы имён, которые обрабатывают запрошенный в данном случае домен верхнего уровня.
Таким образом, если запрос к «www.suip.biz» будет отправлен на корневой сервер, корневой сервер не найдёт результат в своих записях. Он проверит файлы своей зоны на наличие списка, который соответствует «www.suip.biz», но не найдёт ни одного.
Вместо этого он найдёт запись для TLD «biz» и даст запрашивающей организации адрес сервера имён, ответственного за адреса «biz».
TLD-серверы
Затем запрашивающая сторона отправляет новый запрос на IP-адрес (предоставленный ему корневым сервером) TLD-сервера, который отвечает за домен верхнего уровня для данного запроса.
Итак, чтобы продолжить наш пример, он отправил бы запрос серверу имён, ответственному за хранение информации о «biz», чтобы узнать, не известно ли ему, где находится «www.suip.biz».
DNS сервер TLD также будет искать «www.suip.biz» в своих файлах зоны, но не найдёт эту запись в своих файлах.
Тем не менее он найдёт запись с указанием IP-адреса сервера имён, ответственного за «suip.biz». В этом момент мы становится намного ближе к ответу, который нам нужен.
Серверы имён на уровне домена
На этом этапе запрашивающая сторона имеет IP-адрес сервера имён, который отвечает за знание фактического IP-адреса ресурса. Он отправляет новый запрос на сервер имён, снова спрашивая, может ли он разрешить (преобразовать в IP) «www.suip.biz».
Сервер имен проверяет свои файлы зон и обнаруживает, что у него есть файл зоны, связанный с «suip.biz». Внутри этого файла есть запись для хоста «www». Эта запись сообщает IP-адрес, где находится этот хост. Сервер имён возвращает окончательный ответ запрашивающей стороне.
Иллюстрация вышеописанной цепочки DNS запросов
Проиллюстрируем вышесказанное реальными запросами к DNS серверам.
Первой командой мы отправляем запрос корневому серверу d.root-servers.net об A записи доменного имени suip.biz
Сервер ничего не прислал о самом доменном имени www.suip.biz, но в разделе AUTHORITY SECTION перечислены DNS сервера, которые должны знать о доменной зоне biz (доменах верхнего уровня biz):
В дополнительном разделе присланы A записи о перечисленных выше DNS серверах:
Вновь мы не получили A запись для домена suip.biz, но раздел AUTHORITY SECTION содержит имена сервером имён ns1.marosnet.ru и ns2.marosnet.ru, которые указаны как сервера имён для домена suip.biz, то есть они должны уже знать IP этого сайта:
Обращаемся с DNS запросом к любому из присланных нам серверов имён:
И только теперь мы действительно получили A запись с IP интересующего сайта:
Что такое разрешающий сервер имён (Resolving Name Server)?
В приведённом выше сценарии мы употребили слово «запрашивающий/запросчик». Что является «запросчиком» в этой ситуации?
Почти во всех случаях запросчиком будет то, что мы называем «разрешающим сервером имён». Разрешающим сервером имён является тот, который настроен для того, чтобы задавать вопросы другим серверам. Это в основном посредник для пользователя, который кэширует результаты предыдущих запросов для повышения скорости и знает адреса корневых серверов, чтобы иметь возможность «разрешать» (резолвить) запросы, сделанные для имён, о которых он ещё не знает.
Как правило, у пользователя обычно есть несколько разрешающих серверов имён, настроенных в его компьютерной системе. Разрешающие серверы имён обычно предоставляются Интернет-провайдером или другими организациями. Например, Google предоставляет разрешающие DNS-серверы, к которым вы можете отправлять DNS запросы. Они могут быть настроены на вашем компьютере автоматически или вручную.
Когда вы вводите URL-адрес в адресной строке вашего браузера, ваш компьютер сначала проверяет, может ли он определить локально, где находится ресурс. Он проверяет файл «hosts» на компьютере и в нескольких других местах. Затем он отправляет запрос на разрешающий сервер имён и ожидает получения IP-адреса ресурса.
Затем разрешающий сервер имён проверяет свой кеш для ответа. Если он не находит его, он проходит шаги, описанные выше.
Разрешающие серверы имён в основном сжимают запрашивающий процесс для конечного пользователя. Клиенту просто достаточно обратиться с запросом к разрешающим серверам имён: где находится ресурс? И клиент может быть уверен, что они сделают необходимые запросы и изучат нужный маршрут, а затем вернут окончательный ответ.
Зональные файлы (Zone Files)
В упомянутом выше процессе мы упомянули идею «файлов зон» (zone files) и «записей» (records).
Если он сконфигурирован для обработки рекурсивных запросов, как разрешающий сервер имён, он найдёт ответ и вернёт его. В противном случае он сообщит запрашивающей стороне, где искать дальше.
Чем больше файлов зон будет у сервера имён, тем на большее число запросов он сможет авторитативно ответить.
Файл зоны описывает DNS «зону», которая в основном является подмножеством всей системы именования DNS. Обычно он используется для настройки только одного домена. Он может содержать ряд записей, которые определяют, где находятся ресурсы для рассматриваемого домена.
$ORIGIN зоны — это параметр, равный максимальному уровню полномочий (authority) зоны по умолчанию, который выражается как домен определённого уровня. То есть если для настройки домена «example.com» используется файл зоны, то $ORIGIN будет установлен на example.com..
Это либо настраивается в верхней части файла зоны, либо его можно задать в файле конфигурации DNS-сервера, который ссылается на файл зоны. В любом случае, этот параметр описывает, для какого уровня зона будет авторитативной.
Аналогично, $TTL настраивает «время жизни» предоставляемой информации. В принципе это таймер. Сервер имён кэширования может использовать ранее запрошенные результаты для ответа на вопросы, пока не истечёт значение TTL.
Типы DNS записей
В файле зоны у нас может быть много разных типов записей. Мы рассмотрим здесь некоторые из наиболее распространённых (или обязательных типов).
Запись SOA
Запись Start of Authority (начало полномочий) или SOA, является обязательной записью во всех файлах зоны. Это должна быть первая реальная запись в файле (хотя спецификации $ORIGIN или $TTL могут отображаться выше). Она является также одной из самых сложных для понимания.
Начало SOA записи выглядит примерно так:
Давайте объясним, для чего каждая часть:
A и AAAA записи
Обе эти записи связывают хост и IP-адрес. Запись «A» используется для сопоставления хоста с IP-адресом IPv4, а записи «AAAA» используются для сопоставления хоста с адресом IPv6.
Общий формат этих записей таков:
Так как наша SOA-запись вызывает основной главный сервер по адресу «ns1.domain.com», нам нужно также сопоставить его с IP-адресом, поскольку «ns1.domain.com» находится в зоне «domain.com», которая этот файл определяет.
Запись может выглядеть примерно так:
Обратите внимание, что нам не нужно давать полное имя. Мы можем просто указать хост без полного доменного имени, а DNS-сервер заполнит остальное значением $ORIGIN. Тем не менее мы могли бы так же легко использовать полное доменное имя, если захотим быть семантическими:
В большинстве случаев именно здесь вы определяете свой веб-сервер как «www»:
Мы также должны указать, где разрешается базовый домен. Мы можем сделать это так:
Мы могли бы использовать «@» для ссылки на базовый домен:
Также у нас есть возможность использовать подстановочный символ «*», чтобы резолвить всё, что находится под управлением этого домена и что не задано явно:
Все это работает так же с записями AAAA для адресов IPv6.
Записи MX
Записи MX применяются для определения почтовых обменов, которые используются для этого домена. Это помогает правильно доставлять сообщения электронной почты на ваш почтовый сервер.
В отличие от многих других типов записей, почтовые записи обычно не сопоставляют хост с чем-либо, потому что они применяются ко всей зоне. Таким образом, они обычно выглядят так:
Обратите внимание, что в начале нет имени хоста.
Также обратите внимание, что там есть дополнительный номер. Это номер предпочтения, который помогает компьютерам решить, на какой сервер отправлять почту, если определено несколько почтовых серверов. Меньшие числа имеют более высокий приоритет.
Запись MX, как правило, должна указывать на хост, определённый с помощью записи A или AAAA, а не на хост, определённый в CNAME.
Итак, допустим, у нас есть два почтовых сервера, тогда должны быть записи, которые выглядят примерно так:
В этом примере хост «mail1» является предпочтительным сервером обмена электронной почтой.
Мы могли бы также написать это так:
Записи NS
Этот тип записи определяет серверы имён (name servers, NS), которые используются для этой зоны.
Как и записи MX, это параметры всей зоны, поэтому они также не принимают хосты. В общем, они выглядят так:
Для правильной работы у вас должно быть как минимум два сервера имён, определённых в каждом файле зоны — это нужно на тот случай, если с одним из серверов возникнет проблема. Большинство программного обеспечения DNS-серверов считает файл зоны недействительным, если существует только один сервер имён.
Как всегда, включите сопоставление для хостов записями A или AAAA:
Записи PTR
Вот пример записи PTR для 111.222.33.4:
В этом примере записи PTR для адреса IPv6 показан формат отрывка обратного IPv6 DNS-сервера Google 2001:4860:4860::8888.
Инструмент командной строки dig с флагом -x можно использовать для поиска обратного DNS-имени IP-адреса. Вот пример команды dig. Опция +short добавлена для сокращения вывода, который будет ограничен обратным DNS-именем.
Выходными данными для приведённой выше команды dig будет имя домена в записи PTR для IP-адреса:
Серверы в Интернете используют записи PTR, чтобы размещать доменные имена в логах, принимать обоснованные решения по обработке спама и отображать легко читаемые сведения о других устройствах.
Наиболее часто используемые почтовые серверы будут искать PTR-запись IP-адреса, с которого получена электронная почта. Если с исходным IP-адресом не связана запись PTR, отправляемые электронные письма могут рассматриваться как спам и отклоняться. Не важно, что полное доменное имя в PTR совпадает с именем домена отправляемого электронного письма. Важно то, что существует действительная запись PTR с соответствующей и совпадающей прямой записью A.
Обычно сетевые маршрутизаторы в Интернете получают записи PTR, которые соответствуют их физическому местоположению. Например, вы можете увидеть ссылки на «NYC» или «CHI» для маршрутизатора в Нью-Йорке или Чикаго. Это полезно при запуске traceroute или mtr при анализе пути интернет-трафика.
Большинство провайдеров, предлагающих выделенные серверы или службы VPS, дают клиентам возможность установить запись PTR для своего IP-адреса.
Примечание. Важно, чтобы полное доменное имя в записи PTR имело соответствующую и совпадающую прямую запись A. Пример: 111.222.333.444 имеет PTR server.example.com, а server.example.com является записью A, указывающей на 111.222.333.444.
Существует довольно много других типов записей, которые вы можете использовать, но приведённые выше, вероятно, являются наиболее распространёнными типами, с которыми вы столкнётесь. Рассмотрим ещё несколько типов DNS записей, которые менее распространены, но всё равно являются интересными.
Записи CAA
Записи CAA используются для указания, каким центрам сертификации (CA) разрешено выдавать сертификаты SSL/TLS для вашего домена. По состоянию на 8 сентября 2017 года все центры сертификации должны проверить эти записи перед выдачей сертификата. Если запись отсутствует, любой центр сертификации может выдать сертификат. В противном случае только указанные центры сертификации могут выдавать сертификаты. Записи CAA могут применяться к отдельным хостам или целым доменам.
Ниже приведён пример записи CAA:
Хост, IN и тип записи (CAA) являются общими полями DNS. Приведённая выше специфическая информация о CAA — это часть 0 issue «letsencrypt.org». Она состоит из трёх частей: флаги (0), теги (issue) и значения («letsencrypt.org»).
Вы можете использовать dig для получения записей CAA, используя следующие параметры:
Записи TXT
Запись TXT (сокращение от текстовой записи) — это тип записи ресурса в Системе доменных имен (DNS), используемый для предоставления возможности связать произвольный текст с хостом или другим именем, таким как читаемая человеком информация о сервере, сети, центр обработки данных или другая учётная информация.
Он также часто используется более структурированным образом для записи небольших объёмов машиночитаемых данных в DNS.
Домен может иметь несколько записей TXT, связанных с ним, при условии, что реализация DNS-сервера поддерживает это. Каждая запись, в свою очередь, может иметь одну или несколько строк символов. Традиционно эти текстовые поля использовались для различных нестандартных применений, таких как полное название компании или организации или адрес хоста.
В 1993 RFC 1464 предложил простой подход к хранению атрибутов и их значений в этих текстовых полях. Этот тип записей сейчас широко используется в:
В качестве неструктурированного текста организации могут использовать строку TXT любым способом, который они определяют, например:
RFC 1464 определяет структурированный формат, который можно использовать для определения атрибутов и их значений в одной записи, как в следующих примерах:
На практике сервисы, использующие записи TXT, часто не следуют этому RFC, а вместо этого имеют свой собственный специфический формат.
Пример использования для DMARC:
Использовать для проверки сайта:
Пример Amazon’s Simple Email Service:
Записи SRV
Запись SRV имеет вид:
Пример записи SRV в текстовой форме, которая может быть найдена в файле зоны:
Это указывает на сервер с именем sipserver.example.com, прослушивающий TCP-порт 5060 для служб протокола SIP. Приоритет здесь равен 0, а вес равен 5.
Как и в MX-записях, хост в SRV-записи должен указывать на адрес (A- или AAAA-запись). Hostname-псевдоним (CNAME-запись) не может быть использован как допустимый параметр.
Записи CNAME
Запись канонического имени (Canonical Name, сокращенно CNAME) — это тип записи ресурса в системе доменных имён (DNS), которая отсылает одно доменное имя (псевдоним) на другое (каноническое имя). Записи CNAME определяют псевдоним канонического имени для вашего сервера (определённый с помощью записи A или AAAA).
Например, мы могли бы иметь запись имени A, определяющую хост «server1», а затем использовать «www» в качестве псевдонима для этого хоста:
Имейте в виду, что эти псевдонимы приводят к некоторым потерям производительности, поскольку они требуют дополнительного запроса к серверу. В большинстве случаев тот же результат может быть достигнут при использовании дополнительных записей A или AAAA.
Одним из случаев, когда рекомендуется CNAME, является предоставление псевдонима для ресурса за пределами текущей зоны.
Это может оказаться удобным при запуске нескольких служб (например, FTP-сервер и веб-сервер, каждый из которых работает на разных портах) с одного IP-адреса. Можно, например, указать ftp.example.com и www.example.com на запись DNS для example.com, которая в свою очередь имеет запись A, которая указывает на IP-адрес. Затем, если IP-адрес когда-либо изменится, нужно только записать изменение в одном месте в сети: в записи DNS A для example.com.
Записи CNAME всегда должны указывать на другое доменное имя, а не на IP-адрес.
Записи CNAME обрабатываются специально в системе доменных имён и имеют несколько ограничений на их использование. Когда резолвер (распознаватель) DNS обнаруживает запись CNAME при поиске обычной записи ресурса, он отправляет новый запрос, используя каноническое имя вместо исходного имени. (Если определителю специально предписано искать записи CNAME, вместо перезапуска запроса возвращается каноническое имя (правая сторона).) Каноническое имя, на которое указывает запись CNAME, может находиться в любом месте DNS, независимо от того, является ли оно локальным или на удалённом сервере в другой зоне DNS.
Например, если есть следующая зона DNS:
когда выполняется поиск записи A для bar.example.com, распознаватель увидит запись CNAME и перезапустит проверку на foo.example.com, а затем вернет 192.0.2.23.
Записи DNAME
Запись DNAME или Delegation Name (запись имени делегирования). Запись DNAME создает псевдоним для всего поддерева дерева доменных имён. В отличие от этого, запись CNAME создаёт псевдоним для одного имени, а не его поддоменов. Как и запись CNAME, поиск DNS будет продолжен путём повторной попытки поиска с новым именем. Сервер имён синтезирует запись CNAME, чтобы фактически применить запись DNAME к запрошенному имени — CNAME для каждого узла в поддереве имеют тот же эффект, что и DNAME для всего поддерева.
Например, если есть следующая зона DNS:
Поиск записи A для foo.example.com не вернёт никаких данных, поскольку DNAME не является CNAME и нет записи A непосредственно в foo.
Однако поиск для xyzzy.foo.example.com будет сопоставлен DNAME и вернёт запись A для xyzzy.bar.example.com, то есть 192.0.2.24; если запись DNAME была бы записью CNAME, этот запрос вернул бы имя не найдено.
Наконец, запрос для foobar.foo.example.com будет сопоставлен DNAME и вернёт 192.0.2.25.
Записи DS
Запись, используемая для идентификации ключа подписи DNSSEC делегированной зоны.
RRSIG
Подпись для набора записей, защищённого DNSSEC. Использует тот же формат, что и запись SIG.
Часть DNSSEC — используется для доказательства того, что имя не существует. Использует тот же формат, что и (устаревшая) запись NXT.
Заключение
Теперь вы должны хорошо понимать, как работает DNS. Хотя общую идею относительно легко понять, при настройке DNS сервера всё ещё могут возникнуть трудности, поэтому мы продолжим знакомство в DNS в последующих статьях, которые также рекомендуются для ознакомления.
Продолжение и дополнительный материал
Для продолжения знакомства с DNS рекомендуются следующие статьи:
[СТАТЬИ БЕЗ ССЫЛОК В ПРОЦЕССЕ ПОДГОТОВКИ — ЗАХОДИТЕ ЗА ССЫЛКАМИ ЧУТЬ ПОЗЖЕ]
Источники
Данный раздел написан/переведён преимущественно на основе: