Dns имена не совпадают с ip

Имена

[Конспект админа] Домены, адреса и Windows: смешивать, но не взбалтывать

Для преобразования имени в IP-адрес в операционных системах Windows традиционно используются две технологии – NetBIOS и более известная DNS.

Дедушка NetBIOS

NetBIOS (Network Basic Input/Output System) – технология, пришедшая к нам в 1983 году. Она обеспечивает такие возможности как:

регистрация и проверка сетевых имен;

установление и разрыв соединений;

связь с гарантированной доставкой информации;

связь с негарантированной доставкой информации;

В рамках этого материала нас интересует только первый пункт. При использовании NetBIOS имя ограниченно 16 байтами – 15 символов и спец-символ, обозначающий тип узла. Процедура преобразования имени в адрес реализована широковещательными запросами.

Широковещательным называют такой запрос, который предназначен для получения всеми компьютерами сети. Для этого запрос посылается на специальный IP или MAC-адрес для работы на третьем или втором уровне модели OSI.

Для работы на втором уровне используется MAC-адрес FF:FF:FF:FF:FF:FF, для третьего уровня в IP-сетях адрес, являющимся последним адресом в подсети. Например, в подсети 192.168.0.0/24 этим адресом будет 192.168.0.255

Интересная особенность в том, что можно привязывать имя не к хосту, а к сервису. Например, к имени пользователя для отправки сообщений через net send.

Пример работы кэша для разрешения имени узла «хр».

Что происходило при этом с точки зрения сниффера.

В крупных сетях из-за ограничения на количество записей и срока их жизни кэш уже не спасает. Да и большое количество широковещательных запросов запросто может замедлить быстродействие сети. Для того чтобы этого избежать, используется сервер WINS (Windows Internet Name Service). Адрес сервера администратор может прописать сам либо его назначит DHCP сервер. Компьютеры при включении регистрируют NetBIOS имена на сервере, к нему же обращаются и для разрешения имен.

В сетях с *nix серверами можно использовать пакет программ Samba в качестве замены WINS. Для этого достаточно добавить в конфигурационный файл строку «wins support = yes». Подробнее – в документации.

В отсутствие службы WINS можно использовать файл lmhosts, в который система будет «заглядывать» при невозможности разрешить имя другими способами. В современных системах по умолчанию он отсутствует. Есть только файл-пример-документация по адресу %systemroot%\System32\drivers\etc\lmhost.sam. Если lmhosts понадобится, его можно создать рядом с lmhosts.sam.

Сейчас технология NetBIOS не на слуху, но по умолчанию она включена. Стоит иметь это ввиду при диагностике проблем.

Стандарт наших дней – DNS

DNS (Domain Name System) – распределенная иерархическая система для получения информации о доменах. Пожалуй, самая известная из перечисленных. Механизм работы предельно простой, рассмотрим его на примере определения IP адреса хоста www.google.com:

если в кэше резолвера адреса нет, система запрашивает указанный в сетевых настройках интерфейса сервер DNS;

сервер DNS смотрит запись у себя, и если у него нет информации даже о домене google.com – отправляет запрос на вышестоящие сервера DNS, например, провайдерские. Если вышестоящих серверов нет, запрос отправляется сразу на один из 13 (не считая реплик) корневых серверов, на которых есть информация о тех, кто держит верхнюю зону. В нашем случае – com.

после этого наш сервер спрашивает об имени www.google.com сервер, который держит зону com;

Наглядная схема прохождения запроса DNS.

Разумеется, DNS не ограничивается просто соответствием «имя – адрес»: здесь поддерживаются разные виды записей, описанные стандартами RFC. Оставлю их список соответствующим статьям.

Сам сервис DNS работает на UDP порту 53, в редких случаях используя TCP.

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

Также как и у NetBIOS, у DNS существует кэш, чтобы не обращаться к серверу при каждом запросе, и файл, где можно вручную сопоставить адрес и имя – известный многим %Systemroot%\System32\drivers\etc\hosts.

В отличие от кэша NetBIOS в кэш DNS сразу считывается содержимое файла hosts. Помимо этого, интересное отличие заключается в том, что в кэше DNS хранятся не только соответствия доменов и адресов, но и неудачные попытки разрешения имен. Посмотреть содержимое кэша можно в командной строке с помощью команды ipconfig /displaydns, а очистить – ipconfig /flushdns. За работу кэша отвечает служба dnscache.

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

При попытке разрешения имени обычно используются сервера DNS, настроенные на сетевом адаптере. Но в ряде случаев, например, при подключении к корпоративному VPN, нужно отправлять запросы разрешения определенных имен на другие DNS. Для этого в системах Windows, начиная с 7\2008 R2, появилась таблица политик разрешения имен (Name Resolution Policy Table, NRPT). Настраивается она через реестр, в разделе HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\DnsClient\DnsPolicyConfig или групповыми политиками.

Настройка политики разрешения имен через GPO.

При наличии в одной сети нескольких технологий, где еще и каждая – со своим кэшем, важен порядок их использования.

Порядок разрешения имен

Операционная система Windows пытается разрешить имена в следующем порядке:

проверяет, не совпадает ли имя с локальным именем хоста;

смотрит в кэш DNS распознавателя;

если в кэше соответствие не найдено, идет запрос к серверу DNS;

если имя хоста «плоское», например, «servername», система обращается к кэшу NetBIOS. Имена более 16 символов или составные, например «servername.domainname.ru» – NetBIOS не используется;

если не получилось разрешить имя на этом этапе – происходит запрос на сервер WINS;

если постигла неудача, то система пытается получить имя широковещательным запросом, но не более трех попыток;

Для удобства проиллюстрирую алгоритм блок-схемой:

Алгоритм разрешения имен в Windows.

То есть, при запуске команды ping server.domain.com NetBIOS и его широковещательные запросы использоваться не будут, отработает только DNS, а вот с коротким именем процедура пойдет по длинному пути. В этом легко убедиться, запустив простейший скрипт:

Выполнение второго пинга происходит на несколько секунд дольше, а сниффер покажет широковещательные запросы.

Сниффер показывает запросы DNS для длинного имени и широковещательные запросы NetBIOS для короткого.

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

Active Directory и суффиксы

Active Directory тесно интегрирована с DNS и не функционирует без него. Каждому компьютеру домена создается запись в DNS, и компьютер получает полное имя (FQDN — fully qualified domain name) вида name.subdomain.domain.com.

Читайте также:  Кино во имя мести стивен сигал

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

При попытке запуска команды ping servername система проделает следующее:

если в кэше DNS имя не существует, система спросит у DNS сервера о хосте servername.subdomain.domain.com;

При этом к составным именам типа www.google.com суффиксы по умолчанию не добавляются. Это поведение настраивается групповыми политиками.

Настройка добавления суффиксов DNS через групповые политики.

Настраивать DNS суффиксы можно также групповыми политиками или на вкладке DNS дополнительных свойств TCP\IP сетевого адаптера. Просмотреть текущие настройки удобно командой ipconfig /all.

Суффиксы DNS и их порядок в выводе ipconfig /all.

Однако утилита nslookup работает немного по-другому: она добавляет суффиксы в том числе и к длинным именам. Посмотреть, что именно происходит внутри nslookup можно, включив диагностический режим директивой debug или расширенный диагностический режим директивой dc2. Для примера приведу вывод команды для разрешения имени ya.ru:

Из-за суффиксов утилита nslookup выдала совсем не тот результат, который выдаст например пинг:

Это поведение иногда приводит в замешательство начинающих системных администраторов.

Лично сталкивался с такой проблемой: в домене nslookup выдавал всегда один и тот же адрес в ответ на любой запрос. Как оказалось, при создании домена кто-то выбрал имя domain.com.ru, не принадлежащее организации в «большом интернете». Nslookup добавляла ко всем запросам имя домена, затем родительский суффикс – com.ru. Домен com.ru в интернете имеет wildcard запись, то есть любой запрос вида XXX.com.ru будет успешно разрешен. Поэтому nslookup и выдавал на все вопросы один ответ. Чтобы избежать подобных проблем, не рекомендуется использовать для именования не принадлежащие вам домены.

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

Отсюда частые вопросы – почему ping не работает, а nslookup работает.

В плане поиска и устранения ошибок разрешения имен могу порекомендовать не бояться использовать инструмент для анализа трафика – сниффер. С ним весь трафик как на ладони, и если добавляются лишние суффиксы, то это отразится в запросах DNS. Если запросов DNS и NetBIOS нет, некорректный ответ берется из кэша.

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

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

Источник

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

В этой статье описывается, как устранять неполадки на DNS-серверах. This article discusses how to troubleshoot issues on DNS servers.

Проверка IP-конфигурации Check IP configuration

Выполните ipconfig /all команду из командной строки и проверьте IP-адрес, маску подсети и шлюз по умолчанию. Run ipconfig /all at a command prompt, and verify the IP address, subnet mask, and default gateway.

Проверьте, является ли DNS-сервер полномочным для имени, которое ищется. Check whether the DNS server is authoritative for the name that is being looked up. Если это так, см. раздел Проверка на наличие проблем с достоверными данными. If so, see Checking for problems with authoritative data.

Выполните следующую команду. Run the following command:

Например: For example:

Если вы получаете ответ об ошибке или истечении времени ожидания, см. раздел Проверка проблем с рекурсией. If you get a failure or time-out response, see Checking for recursion problems.

Очистка кэша сопоставителя. Flush the resolver cache. Для этого выполните следующую команду в окне командной строки с правами администратора: To do this, run the following command in an administrative Command Prompt window:

Или в окне администрирования PowerShell выполните следующий командлет: Or, in an administrative PowerShell window, run the following cmdlet:

Повторите шаг 3. Repeat step 3.

Проверка неполадок DNS-сервера Check DNS server problems

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

Проверьте следующие журналы, чтобы узнать, есть ли записанные ошибки: Check the following logs to see whether there are any recorded errors:

DNS-сервер DNS Server

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

Выполните следующую команду и проверьте, доступен ли DNS-сервер с клиентских компьютеров. Run the following command and check whether the DNS server is reachable from client computers.

Если сопоставитель возвращает IP-адрес клиента, у сервера нет проблем. If the resolver returns the IP address of the client, the server does not have any problems.

Если сопоставитель возвращает ответ «сбой сервера» или «Запрос отклонен», зона может быть приостановлена или сервер может быть перегружен. If the resolver returns a «Server failure» or «Query refused» response, the zone is probably paused, or the server is possibly overloaded. Чтобы узнать, приостановлен ли он, перейдите на вкладку Общие окна свойств зоны в консоли DNS. You can learn whether it’s paused by checking the General tab of the zone properties in the DNS console.

Если сопоставитель возвращает ответ «запрос на превышение времени ожидания сервера» или «нет ответа от сервера», возможно, служба DNS не запущена. If the resolver returns a «Request to server timed out» or «No response from server» response, the DNS service probably is not running. Попробуйте перезапустить службу DNS-сервера, введя следующую команду в командной строке на сервере: Try to restart the DNS Server service by entering the following at a command prompt on the server:

Если проблема возникает при запуске службы, сервер может не прослушивать IP-адрес, который использовался в запросе nslookup. If the issue occurs when the service is running, the server might not be listening on the IP address that you used in your nslookup query. На вкладке интерфейсы страницы свойств сервера консоли DNS администраторы могут ограничить DNS-сервер прослушиванием только выбранных адресов. On the Interfaces tab of the server properties page in the DNS console, administrators can restrict a DNS server to listen on only selected addresses. Если DNS-сервер настроен для ограничения службы указанным списком настроенных IP-адресов, то возможно, что IP-адрес, используемый для связи с DNS-сервером, отсутствует в списке. If the DNS server has been configured to limit service to a specific list of its configured IP addresses, it’s possible that the IP address that’s used to contact the DNS server is not in the list. Можно попробовать использовать другой IP-адрес в списке или добавить IP-адрес в список. You can try a different IP address in the list or add the IP address to the list.

В редких случаях DNS-сервер может иметь расширенную конфигурацию безопасности или брандмауэра. In rare cases, the DNS server might have an advanced security or firewall configuration. Если сервер расположен в другой сети, доступной только через промежуточный узел (например, маршрутизатор фильтрации пакетов или прокси-сервер), DNS-сервер может использовать нестандартный порт для прослушивания и получения клиентских запросов. If the server is located on another network that is reachable only through an intermediate host (such as a packet filtering router or proxy server), the DNS server might use a non-standard port to listen for and receive client requests. По умолчанию программа nslookup отправляет запросы на DNS-серверы через порт UDP 53. By default, nslookup sends queries to DNS servers on UDP port 53. Поэтому, если DNS-сервер использует любой другой порт, запросы nslookup завершатся ошибкой. Therefore, if the DNS server uses any other port, nslookup queries fail. Если вы считаете, что это может быть проблема, проверьте, используется ли промежуточный фильтр для блокировки трафика на хорошо известных портах DNS. If you think that this might be the problem, check whether an intermediate filter is intentionally used to block traffic on well-known DNS ports. Если это не так, попробуйте изменить фильтры пакетов или правила портов в брандмауэре, чтобы разрешить трафик через порт UDP/TCP 53. If it’s not, try to modify the packet filters or port rules on the firewall to allow traffic on UDP/TCP port 53.

Читайте также:  Поиск людей по фамилии и имени бесплатно россия без регистрации архив

Проверка на наличие проблем с достоверными данными Checking for problems with authoritative data

Проверьте, является ли сервер, который возвращает неверный ответ, основным сервером для зоны (основным сервером-источником для зоны или сервером, который использует интеграцию Active Directory для загрузки зоны) или сервер, на котором размещена дополнительная копия зоны. Check whether the server that returns the incorrect response is a primary server for the zone (the standard primary server for the zone or a server that uses Active Directory integration to load the zone) or a server that’s hosting a secondary copy of the zone.

Если сервер является сервером-источником If the server is a primary server

Проблема может быть вызвана ошибкой пользователя при вводе пользователем данных в зону. The problem might be caused by user error when users enter data into the zone. Кроме того, это может быть вызвано проблемой, которая влияет на Active Directory репликацию или динамическое обновление. Or, it might be caused by a problem that affects Active Directory replication or dynamic update.

Если на сервере размещается дополнительная копия зоны If the server is hosting a secondary copy of the zone

Изучите зону на главном сервере (сервере, с которого этот сервер извлекает зоны). Examine the zone on the master server (the server from which this server pulls zone transfers).

Чтобы определить, какой сервер является главным сервером, проверьте свойства дополнительной зоны в консоли DNS. You can determine which server is the master server by examining the properties of the secondary zone in the DNS console.

Если на главном сервере указано неправильное имя, перейдите к шагу 4. If the name is not correct on the master server, go to step 4.

Если на главном сервере указано правильное имя, убедитесь, что серийный номер на главном сервере меньше или равен серийному номеру на сервере-получателе. If the name is correct on the master server, check whether the serial number on the master server is less than or equal to the serial number on the secondary server. Если это так, измените либо главный сервер, либо сервер-получатель так, чтобы серийный номер на главном сервере был больше, чем серийный номер на сервере-получателе. If it is, modify either the master server or the secondary server so that the serial number on the master server is greater than than the serial number on the secondary server.

На сервере-получателе выполните принудительную пересылку зоны с помощью консоли DNS или выполните следующую команду: On the secondary server, force a zone transfer from within the DNS console or by running the following command:

Изучите сервер-получатель еще раз, чтобы узнать, правильно ли передана зона. Examine the secondary server again to see whether the zone was transferred correctly. В противном случае у вас, вероятно, возникает проблема с переносом зоны. If not, you probably have a zone transfer problem. Дополнительные сведения см. в статье проблемы зонных передач. For more information, see Zone Transfer Problems.

Если зона была передана правильно, проверьте, правильно ли указаны данные. If the zone was transferred correctly, check whether the data is now correct. В противном случае данные в основной зоне неверны. If not, the data is incorrect in the primary zone. Проблема может быть вызвана ошибкой пользователя при вводе пользователем данных в зону. The problem might be caused by user error when users enter data into the zone. Кроме того, это может быть вызвано проблемой, которая влияет на Active Directory репликацию или динамическое обновление. Or, it might be caused by a problem that affects Active Directory replication or dynamic update.

Проверка проблем с рекурсией Checking for recursion problems

Чтобы рекурсия работала успешно, все DNS-серверы, используемые в пути рекурсивного запроса, должны иметь возможность отвечать и пересылать правильные данные. For recursion to work successfully, all DNS servers that are used in the path of a recursive query must be able to respond and forward correct data. Если это не так, рекурсивный запрос может завершиться ошибкой по одной из следующих причин: If they can’t, a recursive query can fail for any of the following reasons:

Время ожидания запроса истекло, прежде чем его можно будет завершить. The query times out before it can be completed.

Сервер, используемый во время запроса, не отвечает. A server that’s used during the query fails to respond.

Сервер, используемый во время запроса, предоставляет неверные данные. A server that’s used during the query provides incorrect data.

Начните устранение неполадок на сервере, который использовался в исходном запросе. Start troubleshooting at the server that was used in your original query. Проверьте, пересылает ли этот сервер запросы на другой сервер, изучив вкладку серверы пересылки в свойствах сервера в консоли DNS. Check whether this server forwards queries to another server by examining the Forwarders tab in the server properties in the DNS console. Если флажок включить серверы пересылки установлен и в списке присутствует один или несколько серверов, этот сервер перенаправляет запросы. If the Enable forwarders check box is selected, and one or more servers are listed, this server forwards queries.

Если этот сервер пересылает запросы на другой сервер, проверьте наличие проблем, влияющих на сервер, на который сервер пересылает запросы. If this server does forward queries to another server, check for problems that affect the server to which this server forwards queries. Чтобы проверить наличие проблем, см. раздел Проверка неполадок DNS-сервера. To check for problems, see Check DNS Server problems. Когда этот раздел предписывает выполнить задачу на клиенте, выполните его на сервере. When that section instructs you to perform a task on the client, perform it on the server instead.

Если сервер находится в работоспособном состоянии и может пересылать запросы, повторите этот шаг и проверьте сервер, на который сервер пересылает запросы. If the server is healthy and can forward queries, repeat this step, and examine the server to which this server forwards queries.

Читайте также:  Тест по атаке титанов по имени

Если этот сервер не перенаправляет запросы на другой сервер, проверьте, может ли этот сервер запрашивать корневой сервер. If this server does not forward queries to another server, test whether this server can query a root server. Для этого выполните следующую команду: To do this, run the following command:

Тестирование неработающего делегирования Test a broken delegation

Начните тесты в следующей процедуре, запросив допустимый корневой сервер. Begin the tests in the following procedure by querying a valid root server. Этот тест позволяет выполнить запрос всех DNS-серверов из корня к серверу, который тестируется для неработающего делегирования. The test takes you through a process of querying all the DNS servers from the root down to the server that you’re testing for a broken delegation.

В командной строке на тестируемом сервере введите следующее: At the command prompt on the server that you’re testing, enter the following:

Тип записи ресурса — это тип записи ресурса, для которой был выполнен запрос в исходном запросе, а полное доменное имя — полное доменное имя, для которого выполнялись запросы (заканчивающиеся точкой). Resource record type is the type of resource record that you were querying for in your original query, and FQDN is the FQDN for which you were querying (terminated by a period).

Если ответ содержит список записей ресурсов «NS» и «A» для делегированных серверов, повторите шаг 1 для каждого сервера и используйте IP-адрес из записей ресурсов «A» в качестве IP-адреса сервера. If the response includes a list of «NS» and «A» resource records for delegated servers, repeat step 1 for each server and use the IP address from the «A» resource records as the server IP address.

Если ответ не содержит запись ресурса NS, делегирование будет разорвано. If the response does not contain an «NS» resource record, you have a broken delegation.

Если ответ содержит записи ресурсов «NS», но нет записей ресурсов «A», введите » задать рекурсию» и выполните запрос по отдельности для записей ресурсов «a» серверов, перечисленных в записях NS. If the response contains «NS» resource records, but no «A» resource records, enter set recursion, and query individually for «A» resource records of servers that are listed in the «NS» records. Если вы не нашли по меньшей мере один допустимый IP-адрес записи ресурса «A» для каждой записи ресурса NS в зоне, то у вас есть неработающее делегирование. If you do not find at least one valid IP address of an «A» resource record for each NS resource record in a zone, you have a broken delegation.

Если вы определили, что вы используете неработающее делегирование, исправьте его, добавив или обновив запись ресурса «A» в родительской зоне, используя допустимый IP-адрес для соответствующего DNS-сервера для делегированной зоны. If you determine that you have a broken delegation, fix it by adding or updating an «A» resource record in the parent zone by using a valid IP address for a correct DNS server for the delegated zone.

Просмотр текущих корневых ссылок To view the current root hints

Запустите консоль DNS. Start the DNS console.

Добавьте или подключитесь к DNS-серверу, который не прошел рекурсивный запрос. Add or connect to the DNS server that failed a recursive query.

Щелкните правой кнопкой мыши сервер и выберите пункт Свойства. Right-click the server, and select Properties.

Щелкните корневые ссылки. Click Root Hints.

Проверьте наличие базовых подключений к корневым серверам. Check for basic connectivity to the root servers.

Если правильно настроены корневые ссылки, убедитесь, что DNS-сервер, используемый в разрешении имен с ошибками, может проверить связь с корневыми серверами по IP-адресу. If root hints appear to be configured correctly, verify that the DNS server that’s used in a failed name resolution can ping the root servers by IP address.

Если корневые серверы не отвечают на проверку связи по IP-адресу, IP-адреса для корневых серверов могли измениться. If the root servers do not respond to pinging by IP address, the IP addresses for the root servers might have changed. Однако нередко можно увидеть перенастройку корневых серверов. However, it’s uncommon to see a reconfiguration of root servers.

Проблемы с зонными ошибками Zone Transfer Problems

Выполните следующие проверки: Run the following checks:

Проверьте Просмотр событий как для основного, так и для дополнительного DNS-сервера. Check Event Viewer for both the primary and secondary DNS server.

Проверьте главный сервер, чтобы узнать, не отклоняется ли отправка для обеспечения безопасности. Check the master server to see whether it’s refusing to send the transfer for security.

Проверьте вкладку зонные передачи свойств зоны в консоли DNS. Check the Zone Transfers tab of the zone properties in the DNS console. Если сервер ограничит передачу зоны на список серверов, например на вкладке серверы имен в свойствах зоны, убедитесь, что сервер-получатель находится в этом списке. If the server restricts zone transfers to a list of servers, such as those listed on the Name Servers tab of the zone properties, make sure that the secondary server is on that list. Убедитесь, что сервер настроен на отправку зонных передач. Make sure that the server is configured to send zone transfers.

Проверьте, не работает ли на сервере-получателе другая реализация сервера DNS, например BIND. Check whether the secondary server is running another DNS server implementation, such as BIND. Если это так, проблема может быть вызвана одной из следующих причин: If it is, the problem might have one of the following causes:

Главный сервер Windows может быть настроен для отправки быстрых зонных передач, но сервер-получатель стороннего производителя может не поддерживать быструю передачу зоны. The Windows master server might be configured to send fast zone transfers, but the third-party secondary server might not support fast-zone transfers. В этом случае отключите передачу данных на главном сервере в консоли DNS, установив флажок включить вторичные базы данных-получатели на вкладке Дополнительно свойств сервера. If this is the case, disable fast-zone transfers on the master server from within the DNS console by selecting the Enable Bind secondaries check box on the Advanced tab of the properties for your server.

Если зона прямого просмотра в Windows Server содержит тип записи (например, запись SRV), которую сервер-получатель не поддерживает, то на сервере-получателе могут возникнуть проблемы с извлечением зоны. If a forward lookup zone on the Windows server contains a record type (for example, an SRV record) that the secondary server does not support, the secondary server might have problems pulling the zone.

Проверьте, работает ли на главном сервере другая реализация DNS-сервера, например BIND. Check whether the master server is running another DNS server implementation, such as BIND. Если да, то возможно, что зона на главном сервере содержит несовместимые записи ресурсов, которые Windows не распознает. If so, it’s possible that the zone on the master server includes incompatible resource records that Windows does not recognize.

Источник

Оцените статью
Имя, Названия, Аббревиатуры, Сокращения
Добавить комментарий

Adblock
detector