Check ns off что это
Перейти к содержимому

Check ns off что это

  • автор:

Что такое NSLOOKUP и как пользоваться этой утилитой

В этой статье мы расскажем, что такое DNS lookup и какие сведения о сайте можно получить с помощью утилиты NSLOOKUP.

Что такое NSLOOKUP

Процесс поиска IP сайта называется DNS lookup. Самые распространённые способы узнать о ресурсных записях и DNS-серверах домена ― утилита dig и Whois. Об этих способах мы рассказывали в статье. Однако есть ещё один способ узнать данные DNS ― утилита NSLOOKUP.

NSLOOKUP — это утилита, которая находится на локальном компьютере и позволяет узнать содержимое DNS. Утилита работает только через командную строку терминала. Она позволяет определить:

  • IP-адрес,
  • A, NS, SOA, MX-записи для домена.

Как установить NSLOOKUP

В Windows и macOS ничего устанавливать не нужно. Утилита встроена в ОС. Если у вас одна их этих операционных систем, можете переходить в терминал и начинать с ней работу.

В Linux-системе утилита не установлена по умолчанию, поэтому её нужно настроить. Чтобы установить утилиту в CentOS и Ubuntu в терминале введите:

yum install nslookup 

В терминале Debian введите:

apt-get install nslookup 

Готово, можно пользоваться утилитой.

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

Как узнать A-запись домена

А-запись позволяет прикрепить домен к IP-адресу. Поэтому через неё можно найти IP.

nslookup site.com

Где site.com ― доменное имя, А-запись которого вы хотите узнать.

Перед вами появится такой ответ:

NSLOOKUP: указать DNS-сервер

Как узнать MX-запись

Для работы с электронной почтой в ресурсных записях прописывается MX-запись.

Чтобы увидеть MX-запись (DNS MX lookup), введите команду:

nslookup –type=MX site.com

Где site.com ― нужный домен.

Перед вами появится такой ответ:

Как определить NS-записи домена

С помощью NSLOOKUP можно увидеть и NS-записи, которые использует веб-ресурс.

Чтобы узнать NS-записи, введите:

nslookup –type=ns site.com

Где site.com ― нужное доменное имя.

Перед вами появится список NS-записей, прописанных на сайте:

Как определить SOA-запись

SOA-запись (Start of Authority) — начальная запись зоны. Подробнее о ней вы можете прочитать в статье Что такое SOA-запись и как ее проверить.

Чтобы определить SOA-записи, введите команду:

nslookup –type=SOA site.com

Где site.com ― нужный домен.

Как узнать все DNS-записи

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

nslookup –type=any site.com

Где site.com ― нужный домен.

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

У сервера есть установленное по умолчанию время, за которое он должен обработать запрос и дать ответ. Если он не успевает отвечать, пользователь видит ошибку. Если интернет слабый или сайт слишком тяжёлый, серверу может понадобится больше времени, чем установлено в его настройках. Чтобы ответ от сервера успел дойти, нужно увеличить время ожидания. С этим тоже справится NSLOOKUP. Введите команду:

nslookup –timeout=15 site.com
  • 15 ― это количество секунд, за которое должен придти ответ,
  • site.com ― нужное доменное имя.

Как включить интерактивный режим

Во всех командах, о которых мы говорили, в начале мы указывали «nslookup». Когда нужно сделать несколько запросов к утилите, вводить длинную команду неудобно. Слово «nslookup» в команде можно не вписывать, если включить интерактивный режим. Чтобы его включить, введите:

nslookup

Чтобы выйти из интерактивного режима, введите:

exit

Что значит authoritative и non-authoritative

Вы могли заметить, что в ответе на команды всегда есть строчка authoritative или non-authoritative.

Эти данные говорят о том, с какого сервера была получена информация.

Authoritative answer (авторитетный ответ) – это ответ, который получен от основного (официального) сервера.

Non-authoritative answer (неавторитетный ответ) – это ответ от промежуточного сервера. Это могут быть серверы интернет-провайдера или прокси-серверы.

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

В наших примерах встречался только ответ non-authoritative:

Популярные статьи

  • Как указать (изменить) DNS-серверы для домена
  • Я зарегистрировал домен, что дальше
  • Как добавить запись типа A, AAAA, CNAME, MX, TXT, SRV для своего домена
  • Что такое редирект: виды и возможности настройки
  • Как создать почту со своим доменом

Что такое NSLOOKUP и как ей пользоваться

В этой статье мы расскажем, что такое DNS Lookup и как узнать, какие DNS-записи прописаны для домена с помощью утилиты NSLOOKUP.

Что такое NSLOOKUP

DNS ― это центральный элемент интернет-системы. DNS соединяет IP-адрес с доменным именем, которое ему соответствует. Благодаря этой системе, нам не нужно запоминать набор цифр (например 123.123.123.123), чтобы перейти на сайт. Достаточно ввести домен в поисковую строку и браузер автоматически преобразует его в IP-адрес. Чтобы найти сайт, браузер обращается к DNS-системе. Процесс поиска нужного IP называется DNS lookup (DNS-поиск). Браузер делает его при загрузке каждого сайта.

Однако посмотреть DNS может не только браузер. Любой пользователь может получить информацию о записях через сервис Whois или через NSLOOKUP. NSLOOKUP — это утилита, которая позволяет через командную строку узнать содержимое DNS. Утилита поможет:

  • узнать IP-адрес,
  • узнать A, NS, SOA, MX-записи для домена.

Как использовать утилиту NSLOOKUP

В Windows и macOS утилита встроена, поэтому можно сразу переходить в терминал и начинать с ней работать. Для Linux-систем иногда нужна её установка.

Для установки утилиты в CentOS и Ubuntu в терминале введите:

yum install nslookup

Для установки утилиты в Debian введите:

apt-get install nslookup

Теперь можно переходить к работе с утилитой. Если вы хотите сделать несколько запросов NSLOOKUP, можно включить утилиту в интерактивном режиме. Тогда вам не придется каждый раз писать nslookup в командах. Для этого введите:

nslookup

Чтобы выйти из интерактивного режима, введите exit .

Как узнать A-запись домена

С помощью А-записи домен прикрепляется к IP-адресу. Таким образом, А-запись позволяет найти IP.

nslookup site.ru

Где site.ru ― доменное имя, А-запись которого вы хотите узнать.

Вы увидите следующую информацию:

Как использовать NSLOOKUP 1

NSLOOKUP: указать DNS-сервер

Как узнать MX-запись

При создании электронной почты в ресурсных записях прописывают MX-записи .

Для определения MX-записей введите команду:

nslookup –type=MX site.ru

Где site.ru ― нужный домен.

Перед вами появится вывод:

Как использовать NSLOOKUP 2

DNS MX lookup

Как определить NS-записи домена

Утилита NSLOOKUP позволяет определить, какие NS-серверы использует сайт.

Для этого введите команду:

nslookup –type=ns site.ru

Где site.ru ― нужное доменное имя.

Перед вами появится список NS:

Как использовать NSLOOKUP 3

Как определить SOA-запись

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

Для определения SOA-записи введите команду:

nslookup –type=SOA site.ru

Где site.ru ― нужный домен.

Как использовать NSLOOKUP 4

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

Когда интернет слабый, для ответа сервера нужно больше времени, чем обычно. Если ответ не приходит в течение 5 секунд, запрос либо повторяется, либо появляется ошибка. Чтобы ответ от сервера успел дойти, нужно увеличить время ожидания. Для этого введите команду:

nslookup –timeout=10 site.ru
  • 10 ― это количество секунд, за которое должен прийти ответ,
  • site.ru ― нужное доменное имя.

Что значит authoritative и non-authoritative

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

  • authoritative,
  • non-authoritative.

Authoritative answer (авторитетный ответ) – это ответ, который получен от основного (официального) сервера. Non-authoritative answer (неавторитетный ответ) – это ответ от промежуточного сервера. Например, на скриншотах из нашей статьи можно увидеть, что ответ приходил от non-authoritative сервера:

Как использовать NSLOOKUP 5

Обратите внимание

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

Помогла ли вам статья?

Спасибо за оценку. Рады помочь ��

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

Попробуйте наш виртуальный агент . Это поможет вам быстро определить и устранить распространенные проблемы с DNS.

В этой статье описывается устранение неполадок на DNS-серверах.

Проверка конфигурации IP-адресов

  1. Запустите ipconfig /all в командной строке и проверьте IP-адрес, маску подсети и шлюз по умолчанию.
  2. Проверьте, является ли DNS-сервер доверенным для имени, которое ищется. Если да, ознакомьтесь с проверкой проблем с авторитетными данными.
  3. Выполните следующую команду:

nslookup

nslookup app1 10.0.0.1 
dnscmd /clearcache 

Или в окне администрирования PowerShell выполните следующий командлет:

Clear-DnsServerCache 

Проверка проблем с DNS-сервером

Журнал событий

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

  • Приложение
  • Системные
  • DNS-сервер

Тестирование с помощью запроса nslookup

Выполните следующую команду и проверка, доступен ли DNS-сервер с клиентских компьютеров.

nslookup

  • Если сопоставитель возвращает IP-адрес клиента, сервер не имеет проблем.
  • Если сопоставитель возвращает ответ «Сбой сервера» или «Отказ в запросе», зона, вероятно, приостановлена или возможно, сервер перегружен. Вы можете узнать, приостановлена ли зона, проверив вкладку «Общие» свойств зоны в консоли DNS.

Если сопоставитель возвращает ответ «Время ожидания запроса на сервер» или «Нет ответа от сервера», служба DNS, вероятно, не выполняется. Попробуйте перезапустить службу DNS-сервера, введя следующую команду в командной строке на сервере:

net start DNS 

Если проблема возникает при запуске службы, сервер может не прослушивать IP-адрес, используемый в запросе nslookup. На вкладке «Интерфейсы» страницы свойств сервера в консоли DNS администраторы могут ограничить DNS-сервер прослушивать только выбранные адреса. Если DNS-сервер настроен, чтобы ограничить службу определенным списком настроенных IP-адресов, возможно, IP-адрес, используемый для связи с DNS-сервером, отсутствует в списке. Вы можете попробовать другой IP-адрес в списке или добавить IP-адрес в список.

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

Проверка проблем с достоверными данными

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

Если сервер является основным сервером

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

Если сервер размещает вторичную копию зоны

  1. Проверьте зону на основном сервере (сервер, с которого этот сервер извлекает передачу зоны).

Примечание. Вы можете определить, какой сервер является основным сервером, проверив свойства вторичной зоны в консоли DNS.

dnscmd /zonerefresh

Проверка проблем рекурсии

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

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

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

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

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

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

nslookup server set q=NS 
  • Если сопоставитель возвращает IP-адрес корневого сервера, возможно, у вас есть сломанное делегирование между корневым сервером и именем или IP-адресом, который вы пытаетесь разрешить. Выполните проверку процедуры сломанной делегирования, чтобы определить, где у вас неработает делегирование.
  • Если сопоставитель возвращает ответ «Время ожидания запроса на сервер истекло», проверка указывает, указывают ли корневые подсказки на функционирование корневых серверов. Для этого используйте процедуру просмотра текущих корневых подсказок . Если корневые подсказки указывают на функционирование корневых серверов, у вас может возникнуть проблема с сетью, или сервер может использовать расширенную конфигурацию брандмауэра, которая не позволяет сопоставителям запрашивать сервер, как описано в разделе «Проверка проблем DNS-сервера». Также возможно, что рекурсивное время ожидания по умолчанию слишком короткое.

Проверка неработаемого делегирования

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

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

nslookup server set norecursion set querytype=

Примечание. Тип записи ресурсов — это тип записи ресурсов, которую вы запрашивали в исходном запросе, а полное доменное имя — полное доменное имя, для которого вы запрашивали (завершались на период).

  • Если ответ не содержит запись ресурса NS, у вас неработает делегирование.
  • Если ответ содержит записи ресурсов NS, но нет записей ресурсов «A», введите рекурсию и запрос по отдельности для записей ресурсов «A», перечисленных в записях NS. Если у вас нет хотя бы одного допустимого IP-адреса записи ресурса «A» для каждой записи ресурсов NS в зоне, у вас неработает делегирование.

Просмотр текущих корневых подсказок

  1. Запустите консоль DNS.
  2. Добавьте или подключитесь к DNS-серверу, который завершился сбоем рекурсивного запроса.
  3. Щелкните правой кнопкой мыши сервер и выберите пункт «Свойства«.
  4. Щелкните корневые подсказки.

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

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

Проблемы с передачей зоны

Выполните следующие проверка:

  • Проверьте Просмотр событий для основного и дополнительного DNS-сервера.
  • Проверьте первичный сервер, чтобы узнать, отказывается ли он отправлять передачу для обеспечения безопасности.
  • Перейдите на вкладку «Передача зоны» свойств зоны в консоли DNS. Если сервер ограничивает передачу зоны в список серверов, например перечисленных на вкладке «Серверы имен» свойств зоны, убедитесь, что сервер-получатель находится в этом списке. Убедитесь, что сервер настроен для отправки передачи зоны.
  • Проверьте сервер-источник для проблем, выполнив действия, описанные в разделе «Проверка проблем DNS-сервера». Когда вам будет предложено выполнить задачу на клиенте, выполните задачу на сервере-получателе.
  • Проверьте, выполняется ли дополнительный сервер другой реализации DNS-сервера, например BIND. Если это так, проблема может иметь одну из следующих причин:
    • Основной сервер Windows может быть настроен для отправки быстрых передач зоны, но сторонний сервер-получатель может не поддерживать передачу быстрой зоны. Если это так, отключите быструю передачу между зонами на основном сервере в консоли DNS, выбрав поле «Включить привязку вторичных файлов» проверка на вкладке «Дополнительно» свойств сервера.
    • Если зона подстановки вперед на сервере Windows содержит тип записи (например, запись SRV), которую дополнительный сервер не поддерживает, вторичный сервер может столкнуться с проблемами с извлечением зоны.

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

    Если главный или вторичный сервер выполняет другую реализацию DNS-сервера, проверка обоих серверах, чтобы убедиться, что они поддерживают одни и те же функции. Вы можете проверка сервер Windows в консоли DNS на вкладке «Дополнительно» страницы свойств сервера. Помимо поля «Включить привязку» на этой странице содержится раскрывающийся список «Имя проверка». Это позволяет выбрать строгое соответствие RFC для символов в DNS-именах.

    Давайте уже разберемся в DNS

    image

    Внимательный читатель найдет на этой картинке IPv6

    Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.

    Что такое DNS

    DNS расшифровывается как Domain Name System. Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.

    Вот и все. Правда. Вы или ваш браузер запрашивает значение для ключа www.example.com , и получает в ответ 1.2.3.4 .

    Базовые штуки

    Большой плюс DNS в том, что это публичная услуга, и можно потыкать в сервера если хочется разобраться. Давайте попробуем. У меня есть домен petekeen.net , который хостится на машине web01.bugsplat.info . Команды, используемые ниже, можно запустить из командной строки OS X (ой, то есть macOS, — прим. пер.).

    Давайте взглянем на маппинг между именем и адресом:

    $ dig web01.bugsplat.info 

    Команда dig это такой швейцарский армейский нож для DNS-запросов. Крутой, многофункциональный инструмент. Вот первая часть ответа:

    ; > DiG 9.7.6-P1 > web01.bugsplat.info ;; global options: +cmd ;; Got answer: ;; ->>HEADER 

    Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:

    ;; QUESTION SECTION: ;web01.bugsplat.info. IN A 

    dig по-умолчанию запрашивает A -записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4 -адрес. Есть эквивалент для IPv6 -адресов — AAAA . Давайте взглянем на ответ:

    ;; ANSWER SECTION: web01.bugsplat.info. 300 IN A 192.241.250.244 

    Тут говорится, что у хоста web01.bugsplat.info. есть один адрес A : 192.241.250.244 . Число 300 это TTL , или time to live (время жизни). Столько секунд можно держать значение в кэше до повторной проверки. Слово IN означает Internet . Так сложилось исторически, это нужно для разделения типов сетей. Подробнее об этом можно почитать в документе IANA's DNS Parameters.

    Оставшаяся часть ответа описывает сам ответ:

    ;; Query time: 20 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Fri Jul 19 20:01:16 2013 ;; MSG SIZE rcvd: 56 

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

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

    Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info ?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig 'у, если бы информация не был закэширована:

    $ dig +trace web01.bugsplat.info ; > DiG 9.7.6-P1 > +trace web01.bugsplat.info ;; global options: +cmd . 137375 IN NS l.root-servers.net. . 137375 IN NS m.root-servers.net. . 137375 IN NS a.root-servers.net. . 137375 IN NS b.root-servers.net. . 137375 IN NS c.root-servers.net. . 137375 IN NS d.root-servers.net. . 137375 IN NS e.root-servers.net. . 137375 IN NS f.root-servers.net. . 137375 IN NS g.root-servers.net. . 137375 IN NS h.root-servers.net. . 137375 IN NS i.root-servers.net. . 137375 IN NS j.root-servers.net. . 137375 IN NS k.root-servers.net. ;; Received 512 bytes from 192.168.1.1#53(192.168.1.1) in 189 ms info. 172800 IN NS c0.info.afilias-nst.info. info. 172800 IN NS a2.info.afilias-nst.info. info. 172800 IN NS d0.info.afilias-nst.org. info. 172800 IN NS b2.info.afilias-nst.org. info. 172800 IN NS b0.info.afilias-nst.org. info. 172800 IN NS a0.info.afilias-nst.info. ;; Received 443 bytes from 192.5.5.241#53(192.5.5.241) in 1224 ms bugsplat.info. 86400 IN NS ns-1356.awsdns-41.org. bugsplat.info. 86400 IN NS ns-212.awsdns-26.com. bugsplat.info. 86400 IN NS ns-1580.awsdns-05.co.uk. bugsplat.info. 86400 IN NS ns-911.awsdns-49.net. ;; Received 180 bytes from 199.254.48.1#53(199.254.48.1) in 239 ms web01.bugsplat.info. 300 IN A 192.241.250.244 bugsplat.info. 172800 IN NS ns-1356.awsdns-41.org. bugsplat.info. 172800 IN NS ns-1580.awsdns-05.co.uk. bugsplat.info. 172800 IN NS ns-212.awsdns-26.com. bugsplat.info. 172800 IN NS ns-911.awsdns-49.net. ;; Received 196 bytes from 205.251.195.143#53(205.251.195.143) in 15 ms 

    Информация выводится в иерархической последовательности. Помните как dig вставил точку . после хоста, web01.bugsplat.info ? Так вот, точка . это важная деталь, и она означает корень иерархии.

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

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

    В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A -запись для web01.bugsplat.info . Видно только IP-адрес корневого сервера ( 192.5.5.241 ). Так какой именно корневой сервер это был? Давайте узнаем!

    $ dig -x 192.5.5.241 ; > DiG 9.8.3-P1 > -x 192.5.5.241 ;; global options: +cmd ;; Got answer: ;; ->>HEADER

    Флаг -x заставляет dig провести обратный поиск по IP-адресу. DNS отвечает записью PTR , которая соединяет IP и хост, в данном случае — f.root-servers.net .

    Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS -серверов. Он отвечает за домен верхнего уровня info . dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info , и получает в ответ еще один набор NS -серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info. . И, наконец, получает ответ!

    Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер. Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» — прим. от rrrav). Домены верхнего уровня com , net , org , и т.д. тоже обычно сильно закэшированы.

    Другие типы

    Есть еще несколько типов, о которых стоит знать. Первый это MX . Он соединяет доменное имя с одним или несколькими почтовыми серверами. Электронная почта настолько важна, что у нее есть свой тип DNS-записи. Вот значения MX для petekeen.net :

    $ dig petekeen.net mx ; > DiG 9.7.6-P1 > petekeen.net mx ;; global options: +cmd ;; Got answer: ;; ->>HEADER

    Заметьте, что MX -запись указывает на имя, а не на IP-адрес.

    Еще один тип, который вам скорее всего знаком, это CNAME . Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:

    $ dig www.petekeen.net ; > DiG 9.7.6-P1 > www.petekeen.net ;; global options: +cmd ;; Got answer: ;; ->>HEADER

    Сразу видно, что мы получили два ответа. Первый говорит, что www.petekeen.net указывает на web01.bugsplat.info . Второй возвращает запись A для того сервера. Можно считать, что CNAME это псевдоним (или алиас) для другого сервера.

    Что не так с CNAME

    Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.

    Причина в том, что DNS производит замену таким образом, что все записи того места, куда указывает CNAME , также валидны для CNAME . В нашем примере, записи у www.petekeen.net и web01.bugsplat.info будут совпадать.

    Поэтому нельзя делать CNAME на корневом домене вроде petekeen.net , потому что обычно там нужны другие записи, например, MX .

    Запросы к другим серверам

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

    $ dig www.petekeen.net @8.8.8.8

    Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2 .

    Типичные ситуации

    Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.

    Редирект домена на www

    Часто нужно сделать редирект домена iskettlemanstillopen.com на www.iskettlemanstillopen.com . Регистраторы типа Namecheap или DNSimple называют это URL Redirect. Вот пример из админки Namecheap:

    Символ @ означает корневой домен iskettlemanstillopen.com . Давайте посмотрим на запись A у этого домена:

    $ dig iskettlemanstillopen.com ;; QUESTION SECTION: ;iskettlemanstillopen.com. IN A ;; ANSWER SECTION: iskettlemanstillopen.com. 500 IN A 192.64.119.118 

    Этот IP принадлежит Namecheap'у, и там крутится маленький веб-сервер, который просто делает перенаправление на уровне HTTP на адрес http://www.iskettlemanstillopen.com :

    $ curl -I iskettlemanstillopen.com curl -I iskettlemanstillopen.com HTTP/1.1 302 Moved Temporarily Server: nginx Date: Fri, 19 Jul 2013 23:53:21 GMT Content-Type: text/html Connection: keep-alive Content-Length: 154 Location: http://www.iskettlemanstillopen.com/ 

    CNAME для Heroku или Github

    Взгляните на скриншот выше. На второй строке там CNAME . В этом случае www.iskettlemanstillopen.com указывает на приложение, запущенное на Heroku.

    $ heroku domains === warm-journey-3906 Domain Names warm-journey-3906.herokuapp.com www.iskettlemanstillopen.com 

    С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME . См. документацию.

    Wildcards

    Большинство DNS-серверов поддерживают шаблоны (wildcards). Например, есть wildcard CNAME для *.web01.bugsplat.info указывает на web01.bugsplat.info . Тогда любой хост на web01 будет указывать на web01.bugsplat.info и не нужно создавать новые записи:

    $ dig randomapp.web01.bugsplat.info ;; QUESTION SECTION: ;randomapp.web01.bugsplat.info. IN A ;; ANSWER SECTION: randomapp.web01.bugsplat.info. 300 IN CNAME web01.bugsplat.info. web01.bugsplat.info. 15 IN A 192.241.250.244 

    Заключение

    Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:

    • RFC 1034: Domain Names — Concepts and Facilities
    • RFC 1035: Domain Names — Implementation and Specification

    Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.

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

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