Как получить заказ

Обновлено: 04.07.2024

Вы хотите изменить порядок DNS-серверов, с которыми компьютер под управлением Windows Server 2003 обращается для разрешения DNS-имен.

Использование графического пользовательского интерфейса

<р>1. Откройте апплет «Сетевые подключения».

<р>2. Дважды щелкните значок "Подключение по локальной сети".

<р>3. Нажмите «Протокол Интернета (TCP/IP)» и выберите «Свойства».

<р>4. Убедитесь, что установлен переключатель рядом с параметром Использовать следующий IP-адрес и настроены IP-адрес, маска подсети и шлюз по умолчанию.

<р>5. Нажмите «Дополнительно» и выберите вкладку «DNS». Используйте кнопку «Добавить», чтобы добавить сервер в порядок поиска DNS. Чтобы удалить сервер из списка, выберите IP-адрес сервера и нажмите «Удалить». Чтобы изменить порядок DNS-серверов в списке, выберите IP-адрес сервера и щелкните стрелку вверх или вниз — DNS-серверы запрашиваются сверху вниз в порядке их перечисления. Вы также можете использовать кнопку «Изменить», чтобы изменить IP-адрес существующего DNS-сервера.

<р>6. Нажмите OK, когда закончите. Использование интерфейса командной строки

В следующем примере добавляется новый DNS-сервер 10.0.0.100 в качестве второго сервера в порядке поиска DNS для интерфейса подключения по локальной сети:

> netsh interface ip add dns "Подключение по локальной сети" 10.0.0.100 index=2 Использование реестра

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

[HKey_Local_Machine\System\CurrentControlSet\Services\Tcpip\Parameters\] "NameServer" = REG_SZ:" " " " " "

В этом примере кода DNS-сервер с IP-адресом 192.168.1.151 будет добавлен в начало порядка поиска DNS.

strComputer = "." strNewDNSServer = "192.168.1.151" ' --------- ЗАВЕРШИТЬ НАСТРОЙКУ ------

Set objWMIService = GetObject("winmgmts:" _ & "!\\" & strComputer & Set nics = objWMIService.ExecQuery _ ("SELECT * FROM Win32_NetworkAdapterConfiguration WHERE

Для каждого ник в ник

' получить текущий порядок поиска DNS arrDNSServerOrder = nic.DNSServerSearchOrder

' создать новый массив для хранения текущих DNS-серверов плюс один новый intNewArraySize = UBound(arrDNSServerOrder) + 1 ReDim Preserve arrDNSServerOrder(intNewArraySize)

"\root\cimv2") IPEnabled = True")

' Считать в обратном порядке от конца массива до первого ' элемента с индексом (0) For i = (intNewArraySize - 1) To 0 Шаг -1

' Перемещение каждого элемента на один индекс "выше" в массиве arrDNSServerOrder(i + 1) = arrDNSServerOrder(i) Next

' Добавить новый сервер в индекс (0) массива arrDNSServerOrder(0) = strNewDNSServer intNewDNS = nic.SetDNSServerSearchOrder(arrDNSServerOrder) If intNewDNS = 0 Then

WScript.Echo "Успешно!! Добавлено " " в начало поиска DNS Еще

WScript.Echo "Ошибка!! Невозможно завершить, если будет следующее

Как это работает

Поскольку запросы DNS отправляются на каждый сервер в порядке их перечисления, правильная настройка порядка поиска DNS может оптимизировать производительность разрешения имен. При запросе поиска DNS клиентский компьютер (в данном случае компьютер Windows Server 2003) отправит запрос на первый сервер, указанный в порядке поиска DNS. Если первый сервер не отвечает через определенное время (5 секунд по умолчанию), компьютер 2003 отправит запрос на второй сервер в порядке поиска и так далее. Запрос на разрешение имени завершится ошибкой только в том случае, если ни один из DNS-серверов в порядке поиска не ответил или если какой-либо сервер в порядке поиска предоставил отрицательный ответ на запрос. В зависимости от конфигурации вашей сети вы можете настроить своих клиентов Windows Server 2003 для запросов к DNS-серверу во внутренней сети или (как это часто бывает в среде небольшого или домашнего офиса) вы можете настроить их для запросов к вашему интернет-провайдеру. DNS-серверы напрямую.

Из-за важности порядка поиска DNS оптимизация производительности разрешения имен вашего компьютера включает несколько важных факторов:

<р>1. Какие DNS-серверы с наибольшей вероятностью будут успешно отвечать на запросы клиентов?

<р>2. Какие DNS-серверы смогут удовлетворить требования к обработке и памяти многочисленных клиентских запросов?

<р>3. Какие DNS-серверы расположены физически близко к DNS-клиентам, что обеспечивает быстрое реагирование?

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

& strNewDNSServer & _ порядок."

изменить порядок поиска DNS-серверов."

Использование интерфейса командной строки

Синтаксис index = x в команде netsh interface ip add dns добавит новый DNS-сервер в место, указанное x. В этом случае последовательность нумерации начинается с 1, поэтому добавление DNS-сервера с индексом = 2 поместит новый сервер вторым в порядке поиска DNS. Все существующие DNS-серверы, в том числе указанные DHCP или групповой политикой, будут перемещены вниз, чтобы освободить место для только что добавленного.

Использование VBScript

Информация о DNS-сервере хранится в WMI в виде массива IP-адресов. Типичный массив состоит из ряда похожих элементов (обычно называемых элементами), каждый из которых имеет связанный индекс, который используется для ссылки на элемент, содержащийся в этом месте. В большинстве языков программирования индексы массивов начинаются с нуля, а не с единицы, и VBScript не является исключением. Таким образом, массив IP-адресов с именем myArray можно представить следующим образом:

myArray[0] = 10.0.0.1 myArray[1] = 10.0.0.2 myArray[2] = 10.0.0.154

В случае порядка поиска DNS эти элементы массива считываются в порядке от индекса 0 до индекса (n – 1), где n – количество элементов в массиве. Это может иногда сбивать с толку людей, которые плохо знакомы со сценариями или программированием, поэтому посмотрите на это так: если в массиве пять элементов, они расположены в 0, 1, 2, 3 и 4. В этом случае n равно 5, а последний элемент массива расположен по индексу массива (n - 1) или 4.

Одним из ограничений массивов является то, что вам нужно сообщить VBScript, насколько велик массив, прежде чем вы начнете его использовать. В этом случае мы делаем это, устанавливая массив равным текущему массиву DNS-серверов, настроенному в порядке поиска DNS, например:

Чтобы добавить новый сервер в этот массив, нам нужно сначала увеличить массив на один элемент, чтобы сохранить новое значение. Мы делаем это с помощью команды ReDim Preserve arrDNSServerOrder(intNewArraySize). Здесь ReDim задает новый размер массива, а Preserve гарантирует, что элементы, уже присутствующие в массиве, не будут стерты. (Если бы мы не использовали здесь Preserve, все существующие записи в массиве arrDNSServerOrder были бы стерты.) Как вы видели в комментариях к коду, мы затем переместили каждый элемент в массиве на позицию, которая была на единицу выше в массиве, так что arrDNSServerOrder[4] был перемещен в arrDNSServerOrder[5] и так далее. Чтобы добавить новый DNS-сервер в начало порядка поиска, мы, наконец, добавили новый сервер в arrDNSServerOrder[0], который является первым элементом массива.

2 ответа 2

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

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

Далее некоторые реализации DNS будут опрашивать каждую NS параллельно и использовать тот из них, который ответит первым. Другие будут обращаться к каждому, определять самый быстрый из нескольких запросов и использовать его. Или это может быть просто круговой алгоритм.

Я понимаю, что это что-то вроде отсутствия ответа, и нет ничего определенного, что вы могли бы вынести, но, учитывая вышеизложенное, единственный верный способ определить поведение для данного домена — это протестировать.

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

Наиболее распространенная реализация, которую я видел на уровне клиента, например, у интернет-провайдеров по всему миру, выглядит следующим образом:

Кто-то (например, абонент широкополосного доступа) просит DNS-серверы провайдера разрешить запись A для foo.example.com.
Интернет-провайдер проверяет свой собственный кеш, и если эта запись находится в кеше и все еще считается «свежей», она немедленно возвращается через кеш. (Так работают все кэши DNS, чтобы они не нагружали DNS-серверы соответствующего сайта без необходимости.)
Если эта запись не была кэширована или кэш считается "устаревшим", интернет-провайдер знает, что ему нужно снова разрешить последнюю запись.
Теперь интернет-провайдеру необходимо знать, какие серверы имен запрашивать о последней записи.
Интернет-провайдер начинает с проверки кэшированного списка авторитетных серверов имен для домена (это ns1.example.com, ns2.example.com и т. д. вместе с их IP-адресами). Если эти записи все еще считаются свежими, выполняется переход к шагу 8.
Если кэшированные записи серверов имен считались просроченными или у них не было кэшированных записей для этого домена, интернет-провайдер запрашивает корневые серверы имен TLD (например, реестр .com, если это домен .com), чтобы получить самые последние пары имя сервера имен/IP, например, например.com. (Вы можете попробовать сделать это самостоятельно, выполнив команду «dig @b.gtld-servers.net example.com», чтобы узнать, что корневые серверы имен вашего TLD знают о вашем домене — если ваш домен принадлежит обычному домену com/net/etc. TLD. Другие TLD должны будут запрашивать свои соответствующие корневые серверы.)
Корневые серверы имен для TLD всегда возвращают серверы имен именно в том порядке, в котором они были указаны вами; никакой рандомизации не происходит. Они также возвращают IP-адреса для каждого сервера имен; это известно как «GLUE», и это то, что позволяет Интернету решать проблему «курицы и яйца», заключающуюся в том, как преобразовать имя хоста сервера имен в IP-адрес, прежде чем вообще что-либо узнать о домене. Более того, большинство из них (например, реестры com/net/etc, которые являются крупнейшими) используют время кэширования 2 дня, чтобы их не забивали постоянно вопросом «какой список серверов имен для домена X?» Запросы. Это общеизвестный источник информации о том, что вы ДОЛЖНЫ подождать 2 дня, прежде чем сможете с уверенностью сказать, что ваши новые серверы имен известны во всем мире, после того как вы отредактировали список серверов имен.
Когда провайдеру известны DNS-серверы example.com и их IP-адреса, например ns1.example.com, ns2.example.com, ns3.example.com, провайдер выбирает случайный сервер из этого списка и отправляет запрос. (Это хорошо, они не забивают без необходимости все DNS-серверы рассматриваемого сайта, а также помогают с балансировкой нагрузки, не всегда запрашивая первый указанный сервер имен.)
Если поставщик услуг Интернета не получает ответа от этого сервера имен в течение заданного времени ожидания, он запрашивает другой сервер из списка.
Получив ответ, провайдер сохраняет его в своем локальном кэше. Что касается того, как долго он будет оставаться в кэше; каждая запись, возвращаемая любым DNS-сервером, также имеет связанное с ней время «мягкого истечения срока действия» (в секундах), которое показывает, как долго запрашивающему клиенту (например, DNS-серверу интернет-провайдера) разрешено кэшировать эту запись, прежде чем она будет рассмотрена. все еще пригодный для использования, но, возможно, устаревший, теперь должен быть выполнен новый запрос, ЕСЛИ ВОЗМОЖНО, просто чтобы убедиться, что он не изменился». Существует также «жесткий срок действия», указанный в записи «SOA» (Start of Authority) каждого отдельного сервера имен (вы можете увидеть свой с помощью «dig @ns1.example.com example.com -t soa»), который определяет глобальное «жесткое ограничение» для всех записей, возвращаемых этим сервером, после чего любой кэш ДОЛЖЕН УДАЛИТЬ свою кэшированную запись, ДАЖЕ ЕСЛИ серверы имен не работают и невозможно снова просмотреть записи. Обычно мягкое истечение составляет от 30 минут до 5 часов, а жесткое — от 1 до 3 недель.
После этой изнурительной работы интернет-провайдер, наконец, получает последнюю запись DNS и может вернуть ее запрашивающему широкополосному подписчику, который не знает, какая огромная работа была проделана за кулисами!

Этот процесс повторяется для поиска КАЖДОЙ записи. Однако всю работу выполняет только первый запрос; после этого IP-адреса серверов имен будут кэшироваться, а последующие запросы к кэширующему DNS-серверу интернет-провайдера можно будет быстро перейти к шагу 8.

Теперь, что касается рандомизации шага 8, она работает на рекордном уровне. Допустим, абонент широкополосного доступа этого интернет-провайдера спросил о следующих записях:

Каждая запись будет обрабатываться как отдельная "сущность", независимо кэшируемая и просматриваемая. Итак, предположим, что подписчик и интернет-провайдер никогда раньше не сталкивались с доменом, и оба имеют полностью нулевые кэшированные записи. Поиски могут быть следующими:

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

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

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

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

Отказ от ответственности: могут быть доступны более высокие жизненные цели, чем управление DNS, но они продаются отдельно, используйте свое воображение. ;-)

Как работает процесс DNS?

Шаг 1. Запрос информации о веб-сайте

Шаг 2. Обратитесь к рекурсивным DNS-серверам

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

Шаг 3. Запрос авторитетных DNS-серверов

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

Шаг 4. Доступ к записи DNS

Шаг 5. Заключительный этап DNS

Рекурсивный DNS-сервер имеет информацию и возвращает запись A на ваш компьютер. Затем наш компьютер сохраняет запись в своем локальном кеше. Он считывает IP-адрес из записи DNS и передает его нашему браузеру. Веб-браузер подключится к веб-серверу, связанному с IP-записями A, и отобразит веб-сайт.

Весь процесс поиска, от начала до конца, занимает всего миллисекунды. Для лучшего понимания давайте разберем компоненты, из которых состоит процесс поиска.

DNS-серверы

Авторитетный DNS-сервер

Рекурсивный сервер имен

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

Зоны DNS

Зона DNS — это административное пространство в системе доменных имен. Зона образует часть пространства имен DNS, делегированного администраторам или определенным объектам. Каждая зона содержит записи ресурсов для всех своих доменных имен.

Файл зоны DNS

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

Типы записей DNS

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

В этой статье обсуждаются различные методы преобразования имени хоста в IP-адрес, используемые клиентами Microsoft Windows. Последовательность методов отличается от последовательности, используемой для преобразования имен NetBIOS в IP-адреса.

Дополнительная информация

В сети, использующей протокол TCP/IP, необходимо преобразовывать имена ресурсов в IP-адреса для подключения к этим ресурсам. Клиенты Microsoft Windows будут следовать последовательности методов при попытке преобразовать имя в адрес, останавливая поиск, когда он успешно сопоставляет имя с IP-адресом.

Практически во всех случаях используются две основные последовательности: разрешение NetBIOS и разрешение имени хоста. Клиенты, подключающиеся к ресурсам на серверах Microsoft, как правило, через диспетчер файлов Windows или сетевое окружение, чаще всего используют разрешение имен NetBIOS.

Дополнительную информацию см. в следующей статье базы знаний Майкрософт:

119493 NetBIOS через разрешение имен TCP/IP и WINS

Разрешение имени хоста разрешает имена ресурсов TCP/IP, которые не подключаются через интерфейс NetBIOS. Наиболее распространенным примером этого является веб-браузер, такой как Microsoft Internet Explorer. Другие примеры включают интернет-приложения, такие как Ping, FTP и Telnet. Многие современные базы данных и почтовые приложения, которые подключаются с помощью Winsock, реализации сокетов TCP/IP в Microsoft Windows, также используют разрешение имени хоста. Примерами таких приложений являются Outlook и Exchange.

При устранении неполадок, связанных с разрешением имен, важно определить, разрешает ли приложение имя NetBIOS или имя хоста.

ПРИМЕЧАНИЕ. В контексте этой статьи термин "клиент" не обязательно относится к рабочей станции. Сервер Windows NT возьмет на себя роль клиента, когда ему потребуется доступ к ресурсам, требующим разрешения имени хоста.

При разрешении имени хоста обычно используется следующая последовательность:

Клиент проверяет, является ли запрошенное имя своим собственным.

Затем клиент ищет локальный файл Hosts, список IP-адресов и имен, хранящихся на локальном компьютере.

ПРИМЕЧАНИЕ. Расположение файла Hosts зависит от операционной системы:

Windows NT %Systemroot%\System32\Drivers\Etc
Windows 95 \
Windows для рабочих групп \
Windows 3.1 \
MS-Client 3.0 \Net
Lan Manager 2.2c Client \Net
Где %Systemroot% — это папка, в которой установлена Windows NT, это диск, на котором установлена ОС, и ссылка на загрузочную дискету или диск C.

Пример файла hosts, Hosts.sam, устанавливается с протоколом TCP/IP, отображающим правильный формат.

Опрашиваются серверы системы доменных имен (DNS).

Если имя по-прежнему не разрешено, в качестве резервной копии используется последовательность разрешения имен NetBIOS. Этот порядок можно изменить, настроив тип узла NetBIOS клиента.

Клиент Windows будет пробовать каждый из этих методов до тех пор, пока он либо успешно не разрешит имя, либо не исчерпает эти методы. Клиенты Windows NT, Windows 95 и Windows для рабочих групп, использующие Microsoft TCP/IP 3.11b, следуют этой последовательности. Клиенты Lan Manager 2.2c или Microsoft Client 3.0 не будут использовать разрешение имен NetBIOS в качестве резервной копии.

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

Способ изменения порядка разрешения имен хостов зависит от операционной системы и версии. Они задокументированы в наборах ресурсов для конкретных операционных систем, а также в базе знаний Майкрософт.

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

171567 Значения приоритета поставщика услуг Windows NT 4.0 не применяются

139270 Как изменить порядок разрешения имен в Windows 95 и Windows NT

119372 Настройка порядка поиска разрешения имен для TCP/IP-32

Устранение неполадок

Проблема: Клиент не может разрешить имя хоста.

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

Кроме того, убедитесь, что клиент пытается разрешить имя хоста, а не имя NetBIOS. Многие приложения имеют несколько методов, которые они могут использовать для разрешения имен, особенно это касается почтовых приложений и приложений баз данных. Приложение может быть настроено для подключения к ресурсам с использованием NetBIOS. В зависимости от конфигурации клиента клиент может обойти разрешение имени хоста. Оттуда необходимо будет либо изменить тип подключения на сокеты TCP/IP, либо устранить проблему как проблему NetBIOS.

Проблема: Клиент очень медленно разрешает имя или не может разрешить имя, и требуется много времени, чтобы сообщить об ошибке.

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

Есть три способа решить эту проблему.

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

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

Если DNS-серверы настроены на клиенте, но эти серверы постоянно недоступны, удалите IP-адреса DNS-серверов из конфигурации клиента. Затем клиент без промедления обходит поиск DNS. -или-

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

Дополнительную информацию о TCP/IP и разрешении имен см. в следующем техническом документе, доступном на анонимном FTP-сервере Microsoft:

У меня есть запись DNS с тремя записями A: основной сайт и две резервные копии. Однако когда клиенты выполняют поиск DNS, они достигают резервного сайта.

Как изменить порядок записей DNS на DNS-сервере dot.tk?

Пока работает DNS, имеет ли значение, в каком порядке выполняется поиск DNS? это то, что вам не нужно делать на регулярной основе. Вы всегда можете написать PHP для собственного поиска и сортировки в том порядке, который вам нравится. Меня больше заботит размещение важного сайта на бесплатном домене .tk :P

@Simon Hayter, резервные ссылки могут иметь ограниченную инфраструктуру (т. е. меньшую пропускную способность, меньшее оборудование и т. д.), что ухудшит работу конечных пользователей.

3 ответа 3

Вы затрагиваете "особенность" DNS, известную как DNS Round Robin. Это преднамеренно. Вы не можете контролировать порядок предоставления записей, удовлетворяющих конкретному запросу.

Это грубо; но удивительно эффективен в качестве балансировщика нагрузки.

Если на самом деле «резервные» машины не следует трогать, пока не выйдет из строя основная, вам нужно быть более изощренным с вашими файлами зон. Вы можете изменить TTL (время жизни) для записи A на небольшое число (например, 60 секунд), а затем настроить сценарий для изменения этой записи A с помощью RFC 2136, когда вы хотите, чтобы люди выполняли отработку отказа.

Если у вас есть 3 записи A, выдающие 3 разных ответа, предполагается, что вы получите примерное распределение поровну между тремя. (Можно также предположить, что M$ DNS все испортит, но я на самом деле не знаю. )

Записи ресурсов, которые существуют для определенной комбинации имени, класса и типа, образуют то, что называется набором записей ресурсов (RRSet). Как предполагает этот термин (это набор), для этих записей нет определенного порядка.

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

В качестве примера взгляните на эти запросы, отправленные в прямой последовательности к серверу кэширующего преобразователя:

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

Читайте также: