Cname dns не работает

Поиск и устранение неполадок после добавления домена и записей DNS

Если вы не нашли то, что вы ищете, обратитесь к разделу вопросы и ответы по доменам.

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

Вы можете проверить проблемы с доменом, проверив его состояние. Перейдите к > доменам установки и просмотреть уведомления в столбце Состояние. Если вы видите проблему, выберите три точки (больше действий), а затем выберите Проверить здоровье. Открываемая область будет описывать любые проблемы, происходящие с доменом.

Почему?

Не удается проверить свой домен?

Вот несколько причин, по которым может не удаваться проверить домен:

Проверочная запись неправильная. Убедитесь, что вы скопировали и вставили точное значение в проверочную запись TXT на узле DNS. Часто пользователи забывают указать «MS =». Эта часть тоже нужна!

Запись не была сохранена. На некоторых узлах DNS необходимо выполнить дополнительное действие для сохранения файла зоны (в котором хранится запись DNS), чтобы он обновился в Интернете. Убедитесь, что вы сохранили изменения, чтобы Microsoft 365 могли видеть и проверять запись.

Запись не обновилась в Интернете. Обычно новая запись становится доступна через несколько минут, но иногда ее обновление может занять до нескольких часов.

Не работает Outlook?

Если вы настроили свою запись MX и другие записи DNS для домена правильно, но почта не работает, мы поможем устранить неполадки с Outlook.

Все сообщения электронной почты перешли на Microsoft 365 и вы хотели, чтобы ваша электронная почта переключилась?

При добавлении домена в Microsoft 365 обычно запись MX вашего домена обновляется (вами или Microsoft 365), чтобы указать на Microsoft 365, и вся электронная почта, отправленная в этот домен, начнет приходить Microsoft 365. Убедитесь, что вы создали почтовые ящики в Microsoft 365 для всех, у кого есть электронная почта на вашем домене, прежде чем изменить запись MX.

Что делать, если вы не хотите переместить электронную почту для всех в вашем домене, чтобы Microsoft 365? Вы можете предпринять шаги, чтобы Microsoft 365 с несколькими адресами электронной почты вместо.

Не можете подтвердить состояние некоммерческой или школьной учетной записи?

Существует несколько сценариев, когда просто необходимо проверить домен организации и не настроить какие-либо службы. Например, чтобы доказать, что Microsoft 365 организация имеет право на подписку на школу.

Ознакомьтесь с руководством по проверке домена Microsoft 365, чтобы доказать владение, некоммерческое или образовательное состояние или активировать Yammer, чтобы убедиться, что вы выполнили все необходимые действия. Это немного отличается для каждой ситуации.

Службы не работают с вашим доменом?

Мы поможем вам выявить проблемы с настройкой DNS для домена. Устранение неполадок доменов в Microsoft 365 покажет вам все записи, которые необходимо исправить, и точно, какие записи необходимо зафиксировать.

DNS настроена правильно, но почта не работает в Outlook на рабочем столе? Ознакомьтесь с различными сценариями потока почты, которые можно использовать в Microsoft 365, чтобы убедиться, что у вас все правильно настроено для бизнеса. Дополнительную помощь по устранению неполадок с электронной почтой можно найти здесь: Устранение неполадок в Outlook.

Ваш веб-сайт недоступен?

Если вы устранили все неполадки DNS, но у вас по-прежнему возникают проблемы, попробуйте одно из указанных ниже действий.

Люди не могут получить на ваш веб-сайт в contoso.com: Отслеживание проблем веб-сайта

Вы не можете обновить запись или запись CNAME, чтобы указать на веб-сайт: обновление пользовательских записей DNS в Microsoft 365

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

Флаг -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 :

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

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

Сразу видно, что мы получили два ответа. Первый говорит, что 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-серверу вместо своего дефолтного, вот так:

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

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

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

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

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

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

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

CNAME для Heroku или Github

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

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

Wildcards

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

Заключение

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

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

Источник

Проверка работоспособности DNS для поддержки репликации каталогов

Область применения: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

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

Хотя вы можете выполнять этот тест основных функций DNS на любом контроллере домена, обычно этот тест выполняется на контроллерах домена, на которых могут возникать проблемы репликации, например контроллеры домена, которые сообщают о событиях с идентификаторами 1844, 1925, 2087 или 2088 в журнале DNS службы каталогов Просмотр событий.

Выполнение базовой проверки DNS контроллера домена

Основная проверка DNS проверяет следующие аспекты функциональности DNS:

• Подключение: Тест определяет, зарегистрированы ли контроллеры домена в DNS, может ли он связаться с помощью ping команды и иметь подключение к серверу Lightweight Directory или вызов удаленного вызова процедур (LDAP/RPC). Если проверка подключения завершается сбоем на контроллере домена, другие тесты для этого контроллера домена не выполняются. Проверка подключения выполняется автоматически перед запуском любого другого теста DNS.
• Ключевые службы: Тест подтверждает, что следующие службы работают и доступны на проверенном контроллере домена: служба клиента DNS, служба сетевого входа в систему, служба центр распространения ключей (KDC) и служба DNS-сервера (если служба DNS установлена на контроллере домена).
• Конфигурация клиента DNS: Тест подтверждает доступность DNS-серверов на всех сетевых адаптерах клиентского компьютера DNS.
• Регистрация записей ресурсов: Тест подтверждает, что запись ресурса узла (A) каждого контроллера домена зарегистрирована по крайней мере на одном из DNS-серверов, настроенных на клиентском компьютере.
• Зона и начало центра (SOA): Если на контроллере домена работает служба DNS-сервера, тест подтверждает, что Active Directory зона домена и запись ресурса начальной зоны (SOA) для зоны домена Active Directory.
• Корневая зона: Проверяет наличие корневой зоны (.).

членство в Enterprise «администраторы» или «эквивалентное» является минимальным требованием для выполнения этих процедур.

Для проверки основных функций DNS можно использовать следующую процедуру.

Чтобы проверить основные функциональные возможности DNS:

На контроллере домена, который требуется протестировать, или на компьютере, входящем в домен, на котором установлены средства домен Active Directory Services (AD DS), откройте командную строку от имени администратора. Чтобы открыть командную строку от имени администратора, нажмите кнопку Пуск.

В поле Начать поиск введите Командная строка.

Вверху меню Пуск щелкните правой кнопкой мыши элемент Командная строка и выберите пункт Запуск от имени администратора. Если отобразится диалоговое окно Контроль учетных записей пользователей, подтвердите, что отображаемое в нем действие — то, которое требуется, и нажмите кнопку Продолжить.

В командной строке введите следующую команду и нажмите клавишу ВВОД: dcdiag /test:dns /v /s: /DnsBasic /f:dcdiagreport.txt Замените фактическое различающееся имя, имя NetBIOS или DNS-имя контроллера домена для . В качестве альтернативы можно проверить все контроллеры домена в лесу, введя/e: вместо/s:. Параметр/f указывает имя файла, которое в предыдущей команде dcdiagreport.txt. Если требуется поместить файл в расположение, отличное от текущего рабочего каталога, можно указать путь к файлу, например/f:c:reportsdcdiagreport.txt.

откройте файл dcdiagreport.txt в Блокнот или в аналогичном текстовом редакторе. чтобы открыть файл в Блокнот, в командной строке введите блокнот dcdiagreport.txt и нажмите клавишу ввод. Если файл помещен в другой рабочий каталог, укажите путь к файлу. Например, если вы поместили файл в к:Репортс, введите Notepad c:reportsdcdiagreport.txt и нажмите клавишу ВВОД.

Перейдите к сводной таблице в нижней части файла. Обратите внимание на имена всех контроллеров домена, которые сообщают о состоянии «предупреждать» или «ошибка» в сводной таблице. Попробуйте определить, существует ли проблемный контроллер домена, выполнив поиск по строке «DC: DCName», где DCName — фактическое имя контроллера домена.

При появлении очевидных изменений конфигурации внесите необходимые изменения. Например, если вы заметили, что один из контроллеров домена имеет очевидно неверный IP-адрес, его можно исправить. Затем повторно запустите тест.

Чтобы проверить изменения конфигурации, повторно выполните команду Dcdiag/test: DNS/v с параметром/e: или/s:, как нужно. Если на контроллере домена не включена версия IP 6 (IPv6), то следует рассчитывать на сбой проверки узла (AAAA) в тесте, но если IPv6 не используется в сети, эти записи не требуются.

Проверка регистрации записи ресурса

Конечный контроллер домена использует запись ресурса DNS-псевдонима (CNAME) для указания партнера по репликации исходного контроллера домена. хотя контроллеры домена, работающие Windows server (начиная с Windows server 2003 с пакетом обновления 1 (sp1)), могут обнаружить исходные партнеры репликации с помощью полных доменных имен или, если это не удается, ожидается, что NetBIOS-намессе запись ресурса псевдонима (CNAME) будет проверяться на предмет правильной работы DNS.

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

Проверка регистрации записи ресурса

1. Откройте командную строку как администратор. Чтобы открыть командную строку от имени администратора, нажмите кнопку Пуск. В поле Начать поиск введите Командная строка.
2. Вверху меню Пуск щелкните правой кнопкой мыши элемент Командная строка и выберите пункт Запуск от имени администратора. Если отобразится диалоговое окно Контроль учетных записей пользователей, подтвердите, что отображаемое в нем действие — то, которое требуется, и нажмите кнопку Продолжить. С помощью средства Dcdiag можно проверить регистрацию всех записей ресурсов, необходимых для расположения контроллера домена, выполнив dcdiag /test:dns /DnsRecordRegistration команду.

Эта команда проверяет регистрацию следующих записей ресурсов в DNS:

• псевдоним (CNAME): запись ресурса на основе глобального уникального идентификатора (GUID), которая находит партнера репликации.
• узел (A): запись ресурса узла, которая содержит IP-адрес контроллера домена.
• Записи ресурсов LDAP SRV: службы (SRV), которые находят LDAP-серверы.
• GC SRV: записи ресурсов службы (SRV), которые находят серверы глобального каталога
• PDC SRV: записи ресурсов службы (SRV), которые находят хозяева операций эмулятора основного контроллера домена.

Для проверки регистрации записи ресурса псевдонима (CNAME) можно использовать следующую процедуру.

Проверка регистрации записи ресурса псевдонима (CNAME)

1. Откройте оснастку DNS. Чтобы открыть службу DNS, нажмите кнопку Пуск. В окне начать поиск введите днсмгмт. msc и нажмите клавишу ВВОД. Если откроется диалоговое окно Контроль учетных записей пользователей, убедитесь, что оно отображает нужное действие, и нажмите кнопку продолжить.
2. Используйте оснастку DNS, чтобы выбрать любой контроллер домена, на котором работает служба DNS-сервера, где на сервере размещается зона DNS с тем же именем, что и домен Active Directory контроллера домена.
3. В дереве консоли щелкните зону с именем _msdcs. Dns_Domain_Name.
4. В области сведений убедитесь, что имеются следующие записи ресурсов: запись ресурса псевдонима (CNAME) с именем Dsa_Guid. _msdcs. и соответствующую запись ресурса узла (A) для имени DNS-сервера.

Если запись ресурса псевдонима (CNAME) не зарегистрирована, убедитесь, что динамическое обновление работает правильно. Используйте тест в следующем разделе, чтобы проверить динамическое обновление.

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

Если основная проверка DNS показывает, что записи ресурсов не существуют в DNS, используйте динамический тест обновления, чтобы определить, почему служба сетевого входа в систему не зарегистрировала записи ресурсов автоматически. Чтобы убедиться, что Active Directory зона домена настроена на принятие безопасных динамических обновлений и на регистрацию тестовой записи (_dcdiag_test_record), выполните следующую процедуру. Тестовая запись удаляется автоматически после теста.

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

1. Откройте командную строку как администратор. Чтобы открыть командную строку от имени администратора, нажмите кнопку Пуск. В поле Начать поиск введите Командная строка. Вверху меню Пуск щелкните правой кнопкой мыши элемент Командная строка и выберите пункт Запуск от имени администратора. Если отобразится диалоговое окно Контроль учетных записей пользователей, подтвердите, что отображаемое в нем действие — то, которое требуется, и нажмите кнопку Продолжить.
2. В командной строке введите следующую команду и нажмите клавишу ВВОД: dcdiag /test:dns /v /s: /DnsDynamicUpdate Замените различающееся имя, имя NetBIOS или DNS-имя контроллера домена для . В качестве альтернативы можно проверить все контроллеры домена в лесу, введя/e: вместо/s:. Если IPv6 не включен на контроллере домена, следует рассчитывать на сбой записи ресурса узла (AAAA) в тесте, что является нормальным условием, когда IPv6 не включен.

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

Включение безопасных динамических обновлений

1. Откройте оснастку DNS. Чтобы открыть службу DNS, нажмите кнопку Пуск.
2. В окне начать поиск введите днсмгмт. msc и нажмите клавишу ВВОД. Если откроется диалоговое окно Контроль учетных записей пользователей, убедитесь, что оно отображает нужное действие, и нажмите кнопку продолжить.
3. В дереве консоли щелкните правой кнопкой мыши соответствующую зону и выберите пункт Свойства.
4. На вкладке Общие убедитесь, что тип зоны — интегрированная Active Directory.
5. В меню динамические обновления щелкните только безопасные.

Регистрация записей ресурсов DNS

Если записи ресурсов DNS не отображаются в DNS для исходного контроллера домена, вы проверили динамические обновления и хотите зарегистрировать записи ресурсов DNS немедленно, можно принудительно выполнить регистрацию вручную с помощью следующей процедуры. Служба сетевого входа в систему на контроллере домена регистрирует записи ресурсов DNS, необходимые для того, чтобы контроллер домена находился в сети. Служба DNS-клиента регистрирует запись ресурса узла (A), на которую указывает запись псевдонима (CNAME).

Источник