DNS

CategoriesWindows Сети By Админ

DNS — Domain Name System «система доменных имён» — первичная компьютерная распределённая система для получения информации о доменых именах. (Локальный аналог х:\Windows\System32\drivers\etc\hosts)
Преобразует доменные имена в IP-адреса.
TCP/UDP порт 53 (обычно используется с AD).
TTL — Время жизни кэша — задается авторитативным сервером, который хостит конкретную зону.

  • Доменное имя — полно-различаемое доменное имя ресурса (FQDN — Fully Qualified Domain Name).
    Состоит из HostName, доменных суффиксов и зоны верхнего уровня.
  • HostName — левая часть полно-различаемого доменного имени (FQDN).
    Имя узла, левая часть доменного имени до точки, еще называют имя устройства.
    В Windows до 63 символов, по стандарту 255 (алфавитные символы, цифры, спецсимволы, включая региональные).
  • Доменный суффиксы — это часть доменного имени (FQDN), левее точки разделителя с зоной верхнего уровня, например: microsoft.com, support.microsoft.com и тд.

Необходим для:

  • Разрешение имен узлов в IP-адреса
  • Используется для разрешения IP-адресов в имена узлов — полезно, когда файл журнала содержит только IP-адрес узла.
  • Поиск контроллеров домена и серверов глобального каталога. Используется при входе в доменные службы Active Directory® (AD DS).
  • Используется для поиска почтовых серверов при доставке электронных сообщений. Используется для доставки всей электронной почты Интернета.

Особенности

  • Есть поддержка коротких имен. Если не интегрирован в AD то хранится в файле win-совместимого формата.
  • Для других ОС хранение ресурсных записей возможно только в файле. Windows/System32/DNS/имя_домена.dns.
  • Альтернативный DNS клиентом опрашивается только при недоступности 1-го.
  • Основные настройки производятся в свойствах самого имени DNS и в свойствах зоны.
  • нужно обеспечить отказоустойчивость — 2 DNS минимум. Может быть в удаленной сети
  • Имя зоны и пространство имен обычно одинаковы, но могут быть разными.
  • Без DNS не будет работать AD DS.

Как устроено?

Разрешение имен осуществляется разными способами и обеспечивается разными DNS-серверами. Вверху иерархии находятся Root Hints — корневые DNS-сервера (13 штук), которые авторитарны за корневую зону «.» (точку). Каждый корневой сервер DNS состоит из множества хостов-реплик, размещаемых в различных локациях сети Интернет (обычно региональных) и имеющих один IP-адрес. Маршрутизация запросов к репликам корневых серверов DNS осуществляется с применением технологии anycast. Таким образом достигается быстрое время отклика и стабильная работа системы.
Root Hints содержат записи о авторитарных DNS-сервера верхнего (первого) уровня (TLD). Это зоны: RU, COM, UA, NET, MUSEUM и др.

*Авторитативный DNS-сервер — DNS-сервер официально ответственный за ту или иную доменную зону. На котором находится официальная база данных ресурсных записей (регистратура) определенной зоны DNS. Такая зона делегируется DNS-серверу, что делает его авторитарным.
Утилита nslookup всегда будет писать «ответ не заслуживает доверия», если отвечает не авторитарный сервер и не выдаст предупреждение, если запрос сделан авторитарному DNS-серверу.

Резолвится — отвечает на DNS-запрос.

Процесс разрешения имен

Когда хост делает DNS-запрос — он его делает непосредственно локальному DNS-серверу (роутеру, маршрутизатору и тд), по классике жанра тот должен отправить запрос Root Hints-у (IP-адреса таковых прописаны в ОС и на всех DNS-серверах) с целью узнать адрес DNS-сервера авторитарного за зону первого уровня, затем отправить запрос DNS-серверу первого уровня, чтобы узнать адрес DNS-сервера искомого второго уровня и т.д., пока не будет найден искомый узел.

Но на сегодняшний день это все происходит несколько иначе, за счет кэширования и форвардинга.

Кэширование. После разрешения какого-либо DNS-имени локальным DNS-сервером этот сервер помещает результат в кэш примерно на 24 часа. На последующие запросы разрешения этого DNS-имени предоставляется кэшированная информация.

Перенаправление (форвардинг). DNS-сервер может быть настроен на перенаправление DNS-запросов вышестоящему DNS-серверу, вместо отправки запросов корневым серверам. Например, запросы в отношении всех интернет-имен могут перенаправляться DNS­серверу поставщика интернет-услуг.

По сути форвардинг — это когда сервер не сам узнает IP-адрес узла, а делегирует эту задачу вышестоящему DNS-серверу.

Зоны и ресурсные записи DNS

Настройки имеют древовидное представление, состоящее из зон ответственности, которые содержат ресурсные записи, чаще всего это запись «А».

Зона DNS находится на DNS-сервере, ответственном за передачу ответов на запросы записей в конкретном
домене. Например, DNS-сервер, который отвечает за разрешение имени www.test.com в IP-адрес, будет содержать зону test.com.

Ресурсные записи — это записи в зоне DNS.

Зона прямого просмотра

Преобразование домена в IP-адрес. Запись «А» — самая распространенная.

A — запись узла. Сопоставляет имя узла в IPv4 (IPv4 host address resource record).

MX — записи обмена электронной почтой, используются для поиска почтовых серверов, отвечающих за домен (Mail exchange resource record). В некоторых случаях, когда MX-запись указывает на другой сервер, AAAA-записи с селекторами pop, mail, smtp текущей панели будут игнорироваться

TXT — (text record) — это текстовая запись для связывания произвольного текст с именем хоста.

SPF (Sender Policy Framework)

SPF — указывает какие почтовые сервера считать доверенными, имеющими право легитимно отправлять письма от имени указанного домена. То-есть какие серверы имеют право отправлять письма с обратным адресом в домене (использовать SMTP HELO и MAIL FROM). Письма с остальных серверов будут считаться Спамом, или отбрасываться — зависит от политики DMARC.
• SPF состоит из трех частей:

• Версия

Версия протокола — spf1. Обязательный параметр, всегда spf1, никакие другие версии не работают.

[свернуть]

• Префикс и механизм

Префиксы:
• «+» — принимать письма (по умолчанию, можно не задавать);
• «—» — отклонить сообщение;
• «~» — «мягкое» отклонение (письмо будет принято, но будет помечено как спам);
• «?» — нейтральное отношение, требуется дополнительная проверка.

Основные механизмы:
• «mx» — разрешать отправку всем почтовым серверам, указанным в MX-записях текущего домена;
• «a» — IP-адрес в «A-записи» считать разрешенным IP-адресом отправителя;
• «ip4» / «ip6» — разрешать IP-адрес или подсеть адресов в качестве отправителя. Указываются, и IP4, и IP6, потому как почтовый сервер может работать и по IP4, и по IP6. + IP-адреса web-сервера сайта, если уведомления будет отправлять сайт не по SMTP. Однако, если на сайте настроена отправка писем  по протоколу SMTP на почтовый сервис (Яндекс, Google и тд), то указывать ip4 ip6 web-сервера сайта не требуется. Так-же это зависит от хостера, например, для sprinthost — не обязательно указывать IP web-сервера в записи SPF, так как его панель на это рассчитана и эти адреса будут учтены (заявление поддержки);
• «include» — возьми дополнительный список доверенных отправителей на указанном сервере;
• «all» — все остальные сервера, не перечисленные в SPF-записи;
• «ptr» — проверяет PTR-запись IP-адреса отправителя (разрешено отправлять всем IP-адресам, PTR-запись которых направлена на указанный домен) (не рекомендуется к использованию согласно RFC 7208);
• «exists» — выполняется проверка работоспособности доменного имени.

[свернуть]

• Модификатор

• «redirect» — указывает получателю, что нужно проверять SPF запись указанного домена, вместо текущего домена.
Если письма отправляются только с одного сервера, например Яндекс, то это будет так:
«v=spf1 redirect=_spf.yandex.net»

[свернуть]

Так как запись SPF должна быть всего одна, через include необходимо прописывать все возможные сервера, через которые отправляются письма.

Пример SPF-записи:

domain.com. TXT «v=spf1 a mx ip4:10.10.1.11 ip4:10.20.1.12 ip6:2a0a:: include:_spf.yandex.ru include:_spf.google.com ~all»
— domain.com. — селектор, с точкой на конце, указывает к какому домену применима запись, (у некоторых хостингов вместо этого может подставляться «@» или оставаться пустое поле). Поле Name/Host/Domain в панели DNS записей;
— TXT — тип записи;
— v=spf1 — версия протокола;
— a — доверенный mail-сервер имеет IP-адрес в A-записи DNS*;
— mx — доверять серверу домена из MX-записи DNS*;
— ip4 ip6 — указываем IP-адреса серверов, которым позволено отправлять e-mail от указанного домена;
— include: — указывает получать доверенные сервера по указанным адресам.

[свернуть]

*Для корректной работы SPF-записи для Яндекс-сервисов в SPF-записи не должно быть «a» или «mx» параметров, а перед all обязательно должен стоять значок в виде волны, а не минус (ответ support).
*TTL для SPF не указывается, но если система требует указываем 21600.
* IP-адреса указываются в SPF-записи (как бы дублируя параметры «a» — дублировать IP-адреса не обязательно, но не запрещается) для того, чтоб если основная запись «A» закрыта за проксированием, например, CloudFlare и не видна — был известен уполномоченный mail-сервер, однако если mail-сервер тоже проксируется (тем-же CloudFlare) — IP реального mail-сервер так-же не указываются.
* По возможности, следует максимально сократить SPF-запись и использовать в ней только адреса сетей через ip4/ip6. на разрешение SPF-политики отведен лимит в 10 DNS-запросов. Его превышение приведет к постоянной ошибке политики (permerror). Кроме того, DNS является ненадежной службой, и для каждого запроса есть вероятность сбоя (temperror), которая возрастает с количеством запросов. Каждая дополнительная запись «a» или «include» требует дополнительного DNS-запроса, для «include» также необходимо запросить всё, что указано в include-записи. «mx» требует запроса MX-записей и дополнительного запроса A-записи для каждого MX-сервера. «ptr» требует дополнительного запроса, к тому же, в принципе, является небезопасной. Только адреса сетей, перечисленные через ip4/ip6, не требуют дополнительных DNS-запросов.
* Postmaster Mail.ru проверяет наличие SPF-записи раз в неделю.

Проверяется это все nslookup, можно воспользовавшись одним из сервисов:
• 2whois.ru — вписав domain.com и указав тип записи TXT. Видит изменения сразу.
• mxtoolbox.com — вписав domain.com и нажав «SPF Record Lookup», есть функция поиска проблем.
• www.digwebinterface.com — вариант попроще, так-же можно проверить все DNS записи.
Селектор = домен, или= @. Значения меняются, при смене mail-провайдера, web-сервера прокси-сервера.

Источник https://habr.com/ru/post/343128/
https://help.mail.ru/developers/notes/spf
Мифы о SPF https://habr.com/ru/company/vk/blog/338700/

[свернуть]

DKIM (Domain Keys Identified Mail)

DKIM (Domain Keys Identified Mail) — это цифровая подпись, которая подтверждает подлинность отправителя и гарантирует целостность доставленного письма.

Подпись добавляется в служебные заголовки письма и незаметна для пользователя. DKIM хранит 2 ключа шифрования — открытый и закрытый. С помощью закрытого ключа формируются заголовки для всей исходящей почты на сервере отправителе, а открытый ключ как раз добавляется в виде TXT-записи в DNS.

Проверка DKIM происходит автоматически на стороне получателя. Если доменная часть отправителя письма не авторизована для отправки сообщений, то письмо может быть помечено подозрительным или помещено в спам, в зависимости от политики получателя.

Записей DKIM может быть несколько — например, если использовать одновременно сервис рассылки и при этом отправляете письма через Gmail — будет 2 записи DKIM с разными селекторами (поле, где прописывается хост/домен):

Name/Domain/Host (Селектор) Type Content
sign._domainkey.name_domen.com. TXT "v=DKIM1; k=rsa; p=публичный_ключ"
mail._domainkey.name_domen.com. TXT "v=DKIM1; k=rsa; p=публичный_ключ"

* Селектор обычно указывается без указания домена: «*._domainkey». Или с «доменом и точкой» — лучше уточнить у хостера. Если нужно без домена — он исчезнет, когда поставится точка и сохранится запись.

Синтаксис DKIM

Обязательные элементы:
• «v» — версия DKIM, всегда принимает значение v=DKIM1;
• «k» — тип ключа, всегда k=rsa;
• «p» — публичный ключ, кодированный в base64.

Необязательные элементы:
• «t=y» — режим тестирования. Нужно только для отслеживания результатов;
• «t=s» — означает, что запись будет использована только для домена, к которому относится; не рекомендуется, если используются субдомены;
• «h» — предпочитаемый hash-алгоритм, может принимать значения «h=sha1» и «h=sha256»;
• «s» — тип сервиса, использующего DKIM. Принимает значения «s=email» (электронная почта) и «s=*» (все сервисы). По умолчанию «*»;
• «;» — разделитель.

[свернуть]

* Некоторые хостинги не поддерживают доменные записи длиннее 255, а то и 200 символов. В таком случае нужно разбить строку переводом. Но у некоторых хостингов и это не работает, необходимо обратиться в поддержку хостинга, чтобы узнать это заранее.
* Некоторые хостинги проставляют кавычки для всех записей самостоятельно, об этом тоже можно спросить у поддержки или проставить по аналогии с другими TXT-записями домена, если они присутствуют.

Проверить DKIM можно здесь. В поле «Selector:» — нужно указать ту часть селектора, что прописана перед «._domainkey». В поле «Domain name:» — только домен с зоной.
Или по средствам MXtoolbox, указав домен и выбрав в выпадающем списке «DKIM Lookup».
Селектор и публичный ключ обычно предоставляет mail-провайдер. Публичный ключ меняется, при смене mail-провайдера.

[свернуть]
DMARC (Domain-based Message Authentication, Reporting and Conformance)

DMARC (Domain-based Message Authentication, Reporting and Conformance) — это настраиваемое правило политики антиспама, по средствам которого мы рекомендуем почтовому серверу получателя, что именно делать с письмами, которые не прошли проверку DKIM и SPF. А так-же инструмент e-mail отчетности.

В параметрах DMARC мы задаем, что делать с письмами, у которых нарушена подпись DKIM и/или сервер отправителя не указан в записи SPF доверенным. Пройдет ли письмо проверку DMARC — зависит от заданных параметров, для DKIM — это «adkim», для SPF — «aspf». Поэтому DMARC добавляется в TXT запись только после того, как настроены записи SPF и DKIM.

Синтаксис DMARC

Обязательные тэги:
• «v» — версия, всегда принимает значение «v=DMARC1», в противном случаи запись игнорируется;
• «p» — определяет политику приёма сообщений для домена и/или поддоменов (если отсутствует тег «sp»). Может принимать значения «none», «quarantine» и «reject»,
где «p=none» не делает ничего, кроме подготовки отчетов, рекомендуется только при настройке;
«p=quarantine» письмо не прошедшее проверку DMARC — помечать как спам, или подозрительное;
«p=reject» отклоняет письмо не прошедшее проверку DMARC. Отклонение должно производиться во время SMTP-транзакции.

Необязательные тэги:
• «sp» определяет политику DMARC для субдомена (поддомена) и может принимать такие же значения, как и «p».
• «adkim» — проверка на аутентификацию DKIM-записи. Возможны значения «r» — relaxed (разрешить частичные совпадения, по умолчанию) или «s» — strict (разрешить только полные совпадения).
Частичное совпадение удобно для поддоменов — проверяем домен test.com, а письмо уходит с *@support.test.com. Строгую проверку пройдет только отправитель *@test.com.
• «aspf» — позволяют проверять соответствие SPF-записям, аналогично adkim.
• «pct» — процент сообщений (целое число), к которым применяется политика DMARC, например, «pct=80» будет отклонять 80% писем, не удовлетворяющих заданных параметров DMARC. Если «pct» не указан — все 100% писем будут обработаны. В начале лучше ставить 10% и месяца за полтора активных рассылок выходить на 100%. Необходимо для постепенного развёртывания политики, дабы избежать ошибок.
Если в вашем домене используется BIMI, для параметра DMARC pct должно быть установлено значение 100. BIMI не поддерживает правила DMARC со значением менее 100 для параметра pct.
• «rua» — позволяет отправлять ежедневные отчеты на email, пример: «rua=mailto:postmaster@domen.com», также можно указать несколько email через запятую без пробелов.
• «ruf» — отчеты для писем, не прошедших проверку DMARC. Указание этого тэга подразумевает, что владелец домена требует от серверов получателей отправлять детальные отчеты о каждом сообщении, не прошедшем проверку DMARC. «ruf=mailto:name@domen.com». Gmail не поддерживает «ruf». В Mail не упоминается.
• «fo» — настройки отчетов об ошибках.  По умолчанию принимает значение «0».
«fo=0» — генерировать отчёт об ошибках DMARC, если не пройден ни один этап аутентификации;
«fo=1» — генерировать отчёт об ошибках DMARC, если не пройден хотя бы один этап аутентификации;
«fo=d» — генерировать отчёт об ошибке DKIM, если не пройдена аутентификация DKIM, независимо от аутентификации;
«fo=s» — генерировать отчёт об ошибке DKIM, если не пройдена аутентификация SPF, независимо от аутентификации.
• «rf» — формат для отчётов об ошибках. По умолчанию значение afrf. На текущий момент поддерживается только это значение.
• «ri» — интервал между отправкой агрегированных отчетов (в секундах). Значение по умолчанию: 86400 (1 раз в сутки).

Запись DMARC может быть одна для домена и поддоменов, т.к. в ней можно явно указать действия для тега «sp». Если вам требуется специфическая запись для поддоменов, можно создать отдельную запись с наименованием «_dmarc.поддомен.домен.».

[свернуть]
Name/Domain/Host (Селектор) Type Content
_dmarc.name_domen.com.
или
_dmarc		 TXT "v=DMARC1; p=quarantine; rua=mailto:fbl@name_domain; ruf=mailto:postmaster@name_domain; pct=100; fo=1; ri=86400"

* Селектор обычно указывается без «name_domen.com.«, то-есть: «_dmarc». Или «доменом и точкой» — лучше уточнить у хостера.

* Почтовые провайдеры, такие как Mail.ru, Yahoo, AOL используют строгую политику DMARC p=reject для своих доменов.

* Если необходимо получать отчеты (rua) на домен, который отличается от домена DMARC, необходимо разместить TXT запись для почтового домена специального вида. Например, если домен с DMARC — example.com, а получать отчеты нужно на домен test.ru, необходимо в DNS домена test.ru добавить следующую TXT-запись: example.com._report._dmarc.test.ru со значением «v=DMARC1»

Проверить DMARC можно здесь. или через MXtoolbox, указав домен с зоной, «DMARC Lookup»
хорошо описано в unisender, больше примеров здесь.
Селектор и настройки обычно предоставляет mail-провайдер, или по таблице выше. Значения меняется, при смене e-mail-адреса получения отчетов, или смене политики DMARC.

[свернуть]


SRV — записи службы, используются для поиска контроллеров домена и серверов глобального каталога (Service locator resource record). Находятся в каталоге _tcp.

NS — запись ресурса сервера имен (Name server resource record)

SOA — запись авторитарного сервера, зону которой он хостит (Start-of-authority resource record)

CNAME — записи канонических имен разрешаются в другое имя узла. Алиас, псевдоним, типа ярлыка (для записи А) (Alias resource record)

AAAA — запись ресурса адреса узла IPv6 (IPv6 host address resource record).

Зоны обратного просмотра

Зоны обратного просмотра содержат PTR-записи. Используются реже.

PTR — записи служат для разрешения IP-адресов в имена узлов (домен) (Pointer resource record). Организация обычно может управлять зонами обратного просмотра для своей внутренней сети.
Однако некоторые PTR-записи для внешних IP-адресов, полученных от поставщика интернет-услуг, могут находиться под управлением этого поставщика.

Реверсивно выводится IP — 2.168.192.in-addr.arpa — IP выводится без последнего октета

Записи SRV

Запись ресурса локатора служб (SRV) разрешает запрос для сетевой службы, позволяя клиенту находить узел, предоставляющий определенную службу.

SRV-записи используются в таких сценариях (список не полный):

  • Когда контроллер домена должен выполнить репликацию изменений с партнеров.
  • Когда клиентскому компьютеру требуется пройти проверку подлинности в AD DS.
  • Когда пользователь изменяет свой пароль.
  • Когда сервер Microsoft Exchange выполняет поиск в каталоге.
  • Когда администратор открывает оснастку «Active Directory — пользователи и компьютеры».

Синтаксис SRV-записей:

имя.службы.протокола срок_жизни класс тип приоритет вес порт целевой_узел

Пример SRV-записи:

_ldap._tcp.contoso.com 600 IN SRV 0 100 389 hqdc01.contoso.com

Запись состоит из следующих компонентов:

  • Имя службы протокола, например служба LDAP, предлагаемая контроллером домена.
  • Срок жизни в секундах.
  • Класс (все записи DNS-сервера Windows будут иметь значение «IN» или «INternet»).
  • Тип: SRV.
  • Значения приоритета и веса, которые помогают клиентам определить предпочтительный узел.
  • Порт, в котором служба предлагается сервером. На контроллере домена Windows для LDAP стандартный порт — 389.
  • Целевой объект, или узел службы, которым в данном случае является контроллер домена с именем hqdc01.contoso.com.

Когда клиентский процесс ищет контроллер домена, он может запросить службу LDAP у DNS. Запрос возвращает как SRV-запись, так и А-запись для одного или нескольких серверов, предоставляющих запрошенную службу.

Типы запросов

Рекурсивный запрос — основной запрос, выполняемый для поиска IP по имени — дай полный ответ, или скажи, что не знаешь адрес из запроса (применяется в форвардинге, запросы пользователей к резолверу (провайдер, сет.админ)).

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

Итеративный запрос — когда сервер начинает искать запрошенный IP по авторитарным DNS-серверам (когда резолвер не может вернуть ответ, потому что он не закэширован. Поэтому он выполняет запрос на корневой DNS-сервер).

Настройка. Выбор зоны DNS

Зона DNS содержит ресурсные DNS-записи и обычно имя зоны = namespase (публичному имени). Некоторые клиенты сами могут делать записи (небезопасно), или это делает DHCP.

Основная зона (папа) (Primary) — основная зона, где можно сделать DNS-записи. Если сервера 2 — обычно первичная зона одного домена на одном сервере, а дополн. — на другом;

Дополнительная зона (Secondary) — дополнительная зона на втором сервере, где записи зон доступны только для чтения. Запросит имя зоны и имя мастер DNS-сервера. В настройках зоны на мастер-сервере во вкладке «зоны трансферта» задать разрешение. Обновляется каждые 15 минут — видно в записи зоны same as parents folder SOA. При работе — добавилась запись — сервер передаст только изменения;

Зона-заглушка (Stub) — условная пересылка запросов. В зависимости от зоны можно назначить разные DNS-сервера;

Мультимастерные зоны — похоже с дополнительной, сейчас не используется.

Динамические обновления

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

Динамическое обновление допускает возможность подделки записи ресурса. Например, какой-нибудь компьютер может зарегистрировать запись с именем «www» и перенаправлять трафик с вашего веб-сайта на неправильный адрес.

Чтобы исключить возможность подделки, служба DNS-сервера Windows Server 2008 R2 поддерживает безопасное динамическое обновление. Клиент должен пройти проверку подлинности, прежде чем обновлять записи ресурсов, поэтому DNS-серверу известно, является ли клиент тем компьютером, которому разрешено изменять запись ресурса.

Передачи зон DNS

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

Если зона интегрирована в доменные службы Active Directory, достаточно добавить роль DNS-сервера в другой контроллер домена в том же домене, где находится первый DNS-сервер. Интегрированные зоны Active Directory и репликация зоны DNS с помощью AD DS описаны в следующем уроке.

Если зона не является интегрированной в AD DS, необходимо добавить другой DNS-сервер и настроить его для размещения дополнительной зоны. Разумеется дополнительная зона — доступна только для чтения, копия основной зоны.

Команды

КомандаОписаниеcmd
ipconfig /displaydnsотобразить кеш DNSDNS-cmd
ipconfig /flushdnsочистить кеш DNSDNS-cmd
ipconfig /registerdnsсходи к DNS и пропиши свое имя в связке со своим IPDNS-cmd
nslookup• вернет имя и IP-адрес отвечающего DNS-сервера (ближайшего получается),
• в ответ пишем домен (или имя сервера, если оно указано в ресурсной записи) и получаем его IP-адреса.
• если имя не резолвится - выдаст превышение времени.
• Ответ "не заслуживает доверия" означает, что не этот DNS является авторитарным для запрашиваемого домена.		DNS-cmd
set query=PTRзадать тип запроса PTR - IP вбиваем и получаем имяDNS-cmd
set query-SOAвыдаст основные настройки основного сервера, на которые должны ориентироваться другие DNS, включая TTL (время кеша)DNS-cmd
Resolve-DnsNameузнать имя DNS по IPDNS-psh
Register-DnsClientсходить и прописать себя в зоне прямого просмотра DNSDNS-psh
Clear-DnsClientCacheочистить DNS-кешDNS-psh
Get-DnsClientCache | flпокажи кеши DNS локального клиента - выдаст имя и сопостовимый IP DNS-сервера (в строке Data). fl - вывод с новой строкиDNS-psh
test-connection name_clпроизвести тестовое подключение, подобие pingDNS-psh

Поиск неполадок

Основными средствами для устранения неполадок разрешения имен узлов являются программы IPConfig.exe и Nslookup.exe. При устранении неполадок разрешения имен необходимо понимать, какие методы разрешения имен используются компьютером, и в каком порядке компьютер их применяет. Между попытками разрешения не забывайте очищать кэш разрешения DNS. Если подключиться к удаленному узлу не удается, и вы считаете, что проблема связана с разрешением имен, для ее устранения выполните следующие операции.

1. Открыть командную строку от админа и очистить кэш разрешения DNS:
IPConfig /flushdns

2. Выполните команду ping, указав IP-адрес удаленного узла. Если команда ping для IP-адреса завершится успешно, но выполнить ее с именем узла не удастся, проблема связана с разрешением имен.

3. Выполните команду ping, указав имя удаленного узла. Для чистоты эксперимента используйте полное доменное имя с точкой в конце:
ping name.domain.com.

4. Если команда ping завершится успешно, проблема, вероятнее всего, не связана с разрешением имен. Если команда ping завершается неудачей, измените текстовый файл узла C:\windows\system32\drivers\etc\hosts, добавив соответствующую запись в конец файла. Например:
10.10.1.11 ping name.domain.com

5. После этого еще раз выполните команду ping с именем узла. Теперь разрешение имени должно быть выполнено успешно. Проверьте правильность разрешения имени, проверив кэш разрешения DNS:
IPConfig /displaydns

6. Удалите запись, недавно добавленную в файл Hosts, и еще раз очистите кэш разрешения.

7. В командной строке введите следующую команду и проверьте содержимое файла filename.txt, чтобы определить этап разрешения имен, вызвавший сбой:
Nslookup.exe –d2 name.domain.com. > filename.txt

nslookup — возвращает имя и IP текущего DNS. Если в ответ написать домен — получим его IP-адрес.

Настройка DNS для доменных служб Active Directory

  • Службу DNS можно установить в процессе развертывания контроллера домена. Роль DNS-сервера также может быть добавлена автоматически с помощью мастера установки доменных служб Active Directory (dcpromo.exe). Страница параметров контроллера домена в мастере позволяет добавить роль DNS-сервера;
  • Зону DNS можно интегрировать в доменные службы Active Directory;
  • Для зоны DNS используйте безопасные динамические обновления;
  • Для обеспечения высокого уровня доступности и балансировки нагрузки используйте несколько DNS-серверов;
  • Записи SRV позволяют находить доменные службы Active Directory и другие службы.

Настройка зон DNS

После установки DNS-сервера можно начать добавлять зоны на сервер. Если DNS-сервер является контроллером домена, можно настроить хранение данных о зонах в AD DS. Тогда будет создана интегрированная зона Active Directory. Если этот параметр не выбран, данные о зонах будут храниться в файле, а не в AD DS.

По умолчанию, при активной роли AD DS и DNS на одном сервере — добавление клиентов в зону прямого просмотра производится только состоящих в домене.