Сомнительные достоинства старой доброй утилиты

Nslookup является одной из моих любимых утилит в Windows NT 4.0. Вот уже несколько лет при возникновении проблем с разрешением имен при использовании DNS я обращаюсь только к этой программе. Однако с тех пор, как наша компания перешла на Windows 2000 Professional, за Nslookup водятся некоторые странности: неудачные попытки запроса, обращение к дополнительному серверу DNS, а не к основному, и другие. Прежде чем подробно рассмотреть причуды программы Nslookup в Windows 2000 Professional, вспомним, как просто и надежно работала утилита Nslookup в среде NT 4.0.

DNS как образец качества

Утилита Nslookup позволяет напрямую опрашивать серверы DNS для выяснения соответствия адресов IP и имен хостов, для поиска определенных типов записей в файле зоны DNS и проверки их работоспособности. Эта информация важна для поиска неисправностей в работе сервера DNS и создания нового файла зоны DNS. Для выполнения прямого (имя хоста – адрес IP) или реверсивного (адрес IP – имя хоста) запроса просто наберите в командной строке Nslookup, указав в качестве параметра имя хоста или IP-адрес. Утилита вернет нужное соответствие – либо IP-адрес, либо имя хоста. В рамках домена на серверах DNS в соответствующих файлах содержатся записи типа Address (A), задающие отображение имя хоста – адрес IP . Когда используется команда Nslookup, как раз и анализируются записи типа А. Кроме того, программу Nslookup можно использовать для опроса серверов DNS на предмет анализа записей других типов, таких как Name Server (NS), в которых указывается поддержка определенного имени домена; Canonical Name (CNAME), описывающие псевдонимы для серверов DNS, которые были ранее определены через записи типа А; Mail Exchanger (MX), в которых задаются имена почтовых систем для данного домена. С помощью Nslookup можно опросить как записи всех перечисленных типов, так и записи какого-то определенного типа. Почтовые серверы Internet используют запросы к DNS для получения информации из записи MX, такой как адрес сервера и стоимость маршрута. Когда возникает ошибка в работе почтового сервера Internet, например, возврат небольшого фрагмента переданного сообщения его отправителю по причине сбоя при отправке или же доставка сообщения не на тот почтовый сервер, ручной опрос сервера DNS может оказаться весьма полезным. В результате анализа полученных данных становится ясно, какую информацию из DNS "видят" удаленные серверы, а в этом может быть ключ к решению проблемы. Программа Nslookup также используется для ручного опроса файла зоны DNS. Другая полезная функция Nslookup – отображение всех почтовых серверов данного домена. Для этого установите опрос только одного типа записей – MX и сообщите имя интересующего домена. В приведенном ниже примере используется домен xcedia.com: nslookup Нажмите Enter, после чего наберите: set type=mx xcedia.com На Рисунке 1 показаны результаты работы введенных команд.

Странность номер один: сбой в опросе DNS

Первая странность в работе Nslookup в Windows 2000 Professional была обнаружена при возникновении случайных сбоев в процессе запросов к записям в DNS. На некоторых станциях результаты опроса записей MX были примерно такими же, как и при использовании NT 4.0. Однако с других станций запрос на MX выводил не записи этого типа, а общие данные из файла зоны - имя основного сервера, серийный номер файла зоны, установки Time to Live (TTL) – время жизни. Когда команды из рассмотренного выше примера были выполнены с сетевой станции Windows 2000 Professional, оказалось, что записи типа MX отсутствуют (см. Рисунок 2). После того, как один из читателей Windows 2000 Magazine написал мне о похожей проблеме с утилитой Nslookup в Windows 2000 Professional, я решил выяснить, что Microsoft изменила в новой версии утилиты, и почему с разных машин результаты работы программы Nslookup разные. Для начала один и тот же запрос на наличие записей MX выдавался с различных станций Windows 2000 Professional. В результате на каждой станции запрос на MX завершился неудачно. Но при регистрации на станции NT 4.0 аналогичный запрос прекрасно все показывал. В конце концов мне удалось получить нормальные результаты запросов к записям MX со станций Windows 2000 Professional. Для этого пришлось вручную изменить DNS-сервер, используемый в системе по умолчанию, задав команду server server_name в среде Nslookup (в команде server параметр server_name – это имя хоста DNS или IP-адрес сервера DNS, который запрашивается утилитой Nslookup.) По умолчанию, Nslookup устанавливает в качестве основного сервера DNS самый первый сервер из стека настроек IP клиента. После того как этот сервер был изменен, с различных систем Windows 2000 Professional запросы на тип записей MX стали выдавать нормальные результаты. Я заподозрил, что такое поведение Nslookup связано с ошибкой инициализации утилиты, когда обнаружил, что при изменении настроек сервера DNS случайно поменял тип сервера DNS, к которому подключались клиенты сети. Когда сессии Nslookup на Windows 2000 Professional были проанализированы повторно, обнаружилось, что в каждом случае соединение происходило с сервером DNS на NT 4.0. При изменении настроек сервера DNS мне следовало указать сервер DNS с Windows 2000. Может быть, проблема с Nslookup возникает на стыке клиента Windows 2000 Professional и сервера DNS NT 4.0? Дальнейшие эксперименты подтвердили это предположение. Оказалось, что только серверы DNS на NT 4.0 представляют проблему для Nslookup из Windows 2000 Professional. С другими серверами DNS – на базе Windows 2000 DNS или BIND - клиенты Windows 2000 Professional работают нормально. Есть несколько обходных путей для выхода из этой ситуации. Можно воспользоваться командой server server_name для отказа от сервера DNS на NT 4.0. Или можно настроить IP-протокол на клиентах на сервер DNS, отличный от NT 4.0 DNS. Наконец, можно скопировать версию Nslookup из NT 4.0 на станции Windows 2000 Professional. Я пробовал – это помогает. Установка Windows 2000 Service Pack 2 (SP2) тоже решает проблему.

Странность номер два: выбор сервера

Выбор сервера DNS по умолчанию – другая странность команды Windows 2000 Professional Nslookup. В среде NT 4.0 утилита Nslookup при инициализации иногда выдает такое сообщение об ошибке: DNS request timed out Timeout was x seconds Can"t find server name for address: Timed out Default servers are not available Default Server: UnKnown Address: где xxx.xxx.xxx.xxx – это IP-адрес самого первого сервера DNS, сконфигурированного на станции клиента, с которым работает Nslookup. Похоже, что для NT 4.0 это путанное сообщение никак не отражается на функциональности программы. Не обращайте на него внимания, Nslookup обрабатывает запросы нормально. В статье Microsoft "DNS Request Timed Out" Error Message When You Start Nslookup from a Command Line" (http://support.microsoft.com/support/kb/articles/q242/9/06.asp) объясняется, что это особенность процедуры инициализации Nslookup, когда предпринимаются попытки выполнить реверсивный запрос для IP-адреса самого первого сервера DNS. Если запрос завершается неудачно (поскольку нет записей Pointer - PTR), Nslookup выдает приведенное выше сообщение. Несмотря на эту ошибку, в NT 4.0 утилита продолжает опрашивать первый в списке сервер DNS, даже при неудачном реверсивном запросе. Для Windows 2000 Professional команда Nslookup сообщает об ошибке в процессе инициализации. А потом, когда выдается очередной запрос, Nslookup пропускает первый DNS-сервер в списке настроек клиента и перебирает список до тех пор, пока не сможет нормально обработать реверсивный запрос (в статье Microsoft об этом не упоминается). В моем случае это привело к тому, что вместо основного сервера Windows 2000 DNS стал использоваться вспомогательный сервер NT 4.0 DNS, что послужило причиной сбоев (см. описание странности №1). Я был разочарован, когда разработчики Microsoft сократили возможности такой важной утилиты в процессе перехода на новую версию. Обычно обновление означает улучшение, но в случае с Nslookup это оказалось не так.

Шон Дейли - один из редакторов журнала Windows NT Magazine и президент компании iNTellinet Solutions, занимающейся консалтингом и сетевой интеграцией. Имеет сертификат MCSE. Последней из его книг была «Optimizing Windows NT», выпущенная издательством IDG Books. С ним можно связаться по адресу.

На нашем сайте

DNS - ДОМЕННАЯ СЛУЖБА ИМЕН
Программа nslookup

Программа nslookup (обычно - /usr/sbin/nslookup в Unix)позволяет произвести DNS-преобразования в явном виде. Например:

%nslookup www.ibm.com

Вывод программы означает, что был опрошен сервер maria.vvsu.ru (его IP-адрес 212.16.195.98) и получен ответ IP(www.ibm.com) = 204.146.18.33.

Пример обратного преобразования:

%nslookup 204.146.18.33 Server: maria.vvsu.ru Address: 212.16.195.98 Name: www.ibm.com Address: 204.146.18.33

Программа nslookup работает также в режиме командной строки. Необходимые команды:

server [имя_опрашиваемого_сервера ] lserver [имя_опрашиваемого_сервера ] сменить опрашиваемый DNS сервер, например: server ns.kiae.su . Без аргумента - установить сервер по умолчанию ("свой" сервер). Все запросы (кроме команды lserver - см. след. абзац) отправляются к опрашиваемому серверу, установленному в данный момент. Nslookup позволяет напрямую обращаться с запросами к серверам, непосредственно отвечающим за ту или иную зону. Если же ответ поступил от сервера, не отвечающего за зону, для хоста которой запрашивалась информация (например, данные были извлечены из кэша), такой ответ будет помечен как "non-authoritative answer ".

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

set type=тип_данных установить запрос данных определенного типа. Например:

>set type=NS >ibm.com

означает запрос списка DNS-серверов, отвечающих (authoritative) за домен ibm.com. (Запрос в этом случае должен состоять из имени домена, а не отдельного хоста.)

Возможные типы:

• SOA (Start Of Authority) - заголовок зоны,
• NS (Name Server) - сервер DNS,
• A (Address) - IP-адрес, если указано доменное имя, или доменное имя, если указан IP-адрес (выбрано по умолчанию),
• MX (Mail Exchanger) - обработчик почты,
• CNAME (Canonical Name) - каноническое имя,
• PTR (Pointer) - запрос по обратной зоне,
• ANY - все записи.

Более подробно о типах данных в базе данных DNS см. часть 2 этой темы "Конфигурирование сервера DNS" .

set recurse отправлять рекурсивные запросы (выбрано по умолчанию).

set norecurse отправлять итеративные запросы.

set domain=имя_домена установить имя домена, добавляемое к неполностью определенным доменным именам (по умолчанию берется из /etc/resolv.conf).

set debug подробно показывать содержимое поступающих ответов.

set nodebug отменить set debug (отменено по умолчанию).

set d2 подробно показывать содержимое отправляемых запросов.

set nod2 отменить set d2 (отменено по умолчанию).

set all показать значения всех опций.

ls имя_домена вывести список хостов указанного домена, например ls vvsu.ru. Предварительно следует переключиться на опрос сервера, отвечающего (authoritative) за данный домен. В целях безопасности некоторые серверы не выполняют эту команду (запрещена пересылка баз данных зоны - см. п.

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

КАК РАБОТАЕТ DNS?

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

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

КОМАНДА NSLOOKUP

$ sudo nslookup опции домен сервер

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

• -type - тип информации, которую хотим получить, возможные типы: txt, soa, ptr, ns, mx, mr, minfo, mg, mb, hinfo, gid, cname, a, any;
• -port - другой порт DNS сервера;
• -(no)recurse - использоваться другие DNS серверы, если на этом нет ответа;
• -retry - количество попыток получить нужную информацию;
• -timeout - время между попытками запросов к серверу;
• -fail - пробовать другой сервер имен, если этот вернул ошибку.

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

КАК ПОЛЬЗОВАТЬСЯ NSLOOKUP?

Посмотрим ip адрес для сайт.

@ns:~$ nslookup сайт

В выводе утилиты видно ip адрес 10.3.5.21, это не адрес сервера, а системный DNS сервер. В следующей строке выводится тот же ip адрес и порт, это адрес DNS сервера вместе с портом. По умолчанию порт - 53. И только после этого находится информация про запрашиваемый сайт. Наш ip адрес 87.236.16.171 (от отлично хостинг-провайдера Beget), это означает, что все пакеты, которые вы будете отправлять на сайт будут приходить на этот адрес.

Иногда вы можете получить в ответе утилиты сообщение «Non-authoritative answer» (или на русском: “Не заслуживающий доверия ответ”). Ответ считается авторитетным, только если наш DNS сервер имеет полную информацию о зоне, для рассматриваемой области. Чаще всего, у нашего сервера будет не вся информация, а кэш последнего ответа от авторитетного сервера. Такая информация считается не авторитетной, хотя она была получена из авторитетного источника, но сам DNS сервер таковым не считается.

Первоисточник информации о домене, это его ns сервера. Вы можете их получить, использовав команду с опцией type=ns :

@ns:~$ nslookup -type=ns сайт

Команда выведет список используемых серверов имен, например, у нас это ns1.beget.com. Обычно это от двух до четырех серверов. Если есть авторитетный источник для получения информации, то он указывается в нижней части вывода.

Например, если мы запросим информацию у сервера имен ns1.beget.com, то это уже будет авторитетный (“Заслуживающий доверия”) ответ:

@ns:~$ nslookup сайт ns1.beget.com

Еще можете получить MX запись для домена, для этого нужно установить тип запроса в mx:

@ns:~$ nslookup -type=mx сайт

Здесь будут отображены все настроенные почтовые серверы, у каждого сервера есть свой приоритет, например, 10 или 20. Чем меньше число, тем выше приоритет адреса.

SOA или Start Of Authority предоставляет техническую информацию о домене, для получения этого поля используйте тип запроса soa:

@ns:~$ nslookup -type=soa сайт

Здесь будет выведена такая информация:

• origin - происхождение полученной информации;
• mail addr - адрес электронной почты администратора домена;
• serial - время с момента последнего обнволения домена в формате timestamp;
• refresh - количество секунд, с момента последнего обновления, когда его нужно повторить;
• retry - количество секунд, через которое нужно повторить попытку подключения, если DNS сервер недоступен;
• expire - количество секунд, по истечении которых полученная от первичного DNS информация будет считаться устаревшей;
• minimum - минимальное количество секунд до следующего обновления.

Также возможно использование nslookup для просмотра всех доступных записей DNS:

@ns:~$ nslookup -type=any сайт

Для просмотра более подробной информации про выполнение запроса вы можете использовать опцию -debug:

@ns:~$ nslookup -type=any -debug сайт

Здесь отображается сообщение, отправленное на сервер и полученный от него ответ. Если ip адресов несколько, то система может отобразить ttl для каждого из них. Некоторые крупные сайты размещены на нескольких серверах, это сделано для противостояния DDoS атакам.

Команда nslookup linux может использоваться и в интерактивном режиме, для этого нужно выполнить ее без параметров:

С помощью команды set вы можете задавать различные параметры, например, порт, или тип запроса:

Set port=53 set type=mx

Чтобы завершить работу с утилитой, используйте команду exit.

ВЫВОДЫ

В этой статье рассмотрено пользование nslookup, утилитой для просмотра DNS записей для домена. Она может быть очень полезной для веб-мастеров и системных администраторов, поскольку очень просто предоставляет всю необходимую информацию.
Ну и напоследок – если вы хотите узнать список мировых root серверов-имен, пропишите: ” @ns:~$ nslookup -type=ns . ” И вы увидите актуальный список главных мировых серверов DNS.

Вконтакте

Being able to retrieve DNS TXT records is very useful in multiple scenarios. In this post we will look at checking the TXT domain verification record for Office 365 and also for the Sender protection Framework .

In addition to a MX record, we also have the option to prove domain ownership to Office 365 by using a TXT record. Why do we want to manually check for these Office 365 TXT records? Rather than blindly running the HCW and getting multiple failures, we can check that the correct record is present. This can help prevent the MaxUriReached: Same URI cannot be attached to different AppId on a single day error , which is discussed in KB 3027942 .

When configuring the Sender Protection Framework (SPF), we need to create then add the SPF record into the external DNS zone file for a given domain. This is of type TXT nowadays. This allows external mail servers to consume the SPF record and make an intelligent decision based upon who the sender purports to be.

If we want to ensure that these records are correct, and available in public DNS we can use the nslookup tool. This is very useful if we do not have direct access to the DNS provider, as that may be owned by a different team within the organization.

If we want to talk to the authoritative server directly, we can do so. We just need to know who that is. For redundancy purposes there should be at least two authoritative DNS servers specified in the DNS zone. While we can look for the SOA record, we should query for the Name Server (NS) record.

Note that the query type is now NS, which stands for “Name Server”.

Now we know that for the tailspintoys.ca domain the two authoritative DNS servers are called ns78.domaincontrol.com and ns77.domaincontrol.com, we can query them directly. The IPv4 Addresses for those name servers are:

ns77.domaincontrol.com 216.69.185.49

ns78.domaincontrol.com 208.109.255.49

Note in the below screenshot, when we directly target those specific name servers, there is no mention of non-authoritative.

SPF Reference

For a quick reference, Microsoft has multiple SPF resources. The SPF wizard below helps to construct the content of your SPF record.

Update 17-11-2016 - Looks like the Microsoft SPF wizard has gone the way of the dinosaurs...... Take a look at some of the other tools out there.....

All SPF records contain three parts: the declaration that it is an SPF record, the domains & IP addresses that should be sending email, and an enforcement rule. You need all three in a valid SPF record. Here’s an example of the most common SPF record for Office 365:

TXT Name @ Values: v=spf1 include:spf.protection.outlook.com include:sharepointonline.com -all

Do not simply copy the above SPF record into your DNS zone. You need to plan to correctly implement SPF.

DNS Query Issues

Some issues that you might run into are listed below. It is not an exhaustive list.

Issue #1 – Use IPv4

One of my European colleagues noted they were having issues with NSlookup. They were seeing the below where every lookup was saying DNS request timed out.

This was a weird one. Netmon never lies. But when I sniffed the traffic from my Windows 10 laptop and a Windows Server 2012 R2 VM, no packets were visible on the wire.

To resolve this, get the IPv4 Address of the DNS server and use that specifically in the server command. This is shown below.

Issue #2 - Do Not Anger the Case Sensitivity Gods

In Windows there are very few things that are case sensitive. Because of this we tend to get careless with case sensitivity. Take the below example when trying to set the query type:

Note that the Q in query type is in capitals. This must be in lower case. Yes. Really.

The big yellow arrow (is it big enough??) shows that the working option is in lowercase.

Issue #3 – Beware Caching Devices

Multiple locations have implemented DNS caching devices that may or may not follow RFC standards. It is regrettable and quite common to find that some DNS caching device is quite happily ignoring the TTL on a DNS record and caching it for several days. Yes that does happen. Take the below example. This is written from some airport lounge in Canada that serves Glenfiddich. Though the amount of single malt consumed has nothing to do with any spelling mistak3s in this post!

In the below example we target the authoritative name server for the tailspintoys.ca domain. But note that we only get a non-authoritative answer.

Compare this to running exactly the same commands from a VM in Azure with no DNS shenanigans:

Those are indeed authoritative replies!

Issue #4 – Driving me Dotty

The devil is in the details, and also the dot sometimes. Note that in the below example, when we query for outlook.office365.com the query has the local computer’s DNS search suffix appended to it.

Compare the above queries (underlined in red) to the below screenshot. What is the difference? Note that the query below has a dot at the end of the query. This tells nslookup not to append the domain suffix.

Alternatively, we can tell nslookup not to add the DNS suffix by specifying the nosearch option. This is shown below, note that there is no dot after the search term “outlook.office365.com ”.