Почему адрес на который отправлен dns запрос не совпадает с адресом посещаемого сайта
Недавно я участвовал в обсуждении того, что происходит, когда клиент запрашивает страницу с прокси-сервера. Я просто хотел убедиться, что мое понимание этой последовательности событий было правильным в общем случае:
Любая обратная связь будет наиболее ценной.
Не совсем: это зависит от того, как настроен клиент. Давайте использовать IE в качестве основного примера.
Если вы настраиваете IE с явным прокси: например, никакие другие опции не отмечены, прокси установлен на что-то: 8080.
Пользователь вводит адрес
IE проверяет адрес на совпадение строк со списком исключений прокси-сервера IE (т. Е. «Обойти прокси для этих адресов:»)
а. Если он соответствует записи в списке обхода , клиент использует собственный DNS для разрешения имени, а затем клиент подключается напрямую к целевому IP-адресу через порт 80 (предположительно), а затем отправляет запрос следующим образом:
б. Если записи в списке обхода не совпадают , продолжайте:
IE подключается к своему настроенному прокси и отправляет запрос в форме:
Фактический бонус: это использование полного доменного имени в URL-адресе - это один из способов сказать, что клиент думает, что он говорит с прокси, а не с реальным веб-сервером.
Прокси-сервер разрешает это имя хоста, используя собственный DNS, а затем подключается к целевому сайту (действует как клиент в шаге 2 выше) и т. Д. И т. Д.
При использовании WPAD / PAC:
В случае использования сценария автоматического обнаружения веб-прокси (WPAD) или автоматической настройки прокси (PAC или Autoconfig), например, предоставляемого ISA / TMG при включенной автоматической настройке, он отличается:
Пользователь вводит адрес
Клиент загружает текущий файл wpad.dat / autoproxy.js / .pac из своего настроенного расположения
Клиент ищет функцию « FindProxyForUrl » в файле js и выполняет ее
Сценарий Autoproxy обрабатывает имя хоста и URL . Это файл javascript с ограниченными функциями, но многое еще возможно:
а. это может включать разрешение имен (IsInNet, DnsResolve)
б. это может включать сопоставление строк (ShExpMatch)
с. это может включать в себя подсчет до миллиона (i ++)
Функция FindProxyForUrl возвращает хотя бы одну строку : упорядоченный список лучших прокси-серверов для использования (через точку с запятой)
а. либо «DIRECT» , в этом случае клиенту необходимо разрешить само имя и подключиться напрямую, как в случае обхода выше
б. или «PROXY proxyname: 8080» или подобное, в этом случае клиент подключается к этому порту на этом прокси, сообщает ему ПОЛУЧИТЬ полный URL , и прокси выполняет разрешение имен .
- В качестве примера : если функция сценария вернула «PROXY yourProxy: 8080; DIRECT», который говорит клиенту подключиться к вашему прокси через TCP-порт 8080, чтобы запросить этот URL, и если это соединение не может быть установлено, попробуйте перейти напрямую. Обратите внимание, что сбой настройки сеанса TCP не совсем быстрый, так что это вряд ли будет приятным переключением при сбое для пользователя, но ничего не сравнится. Может быть.
Иногда бывают сбои, тонкости и необъяснимое поведение, но по большей части, когда вещи не ломаются странными и интересными способами, выше, как я видел, это работает на протяжении многих лет. Новые браузеры оптимизируют поведение, распараллеливают вещи и постоянно пробуют интересные вещи, поэтому ознакомьтесь с последними документами для вашего браузера, чтобы понять мелкие детали.
WinSock Proxy / ISA Firewall Client / TMG Client :
Если вы заинтересованы в Winsock Proxy Client (от TMG / ISA Server), это другая история, с большей гибкостью и подвижностью деталей. Здесь слишком много информации, но есть документы, которые описывают, как это работает. Вкратце: он подключается к Windows Sockets и может перехватывать как трафик на основе TCP / UDP, так и запросы разрешения имен для каждого приложения и для каждого пользователя. Очень мощный, но также устарел и не обновлялся в течение нескольких лет.
Клиенты могут быть действительно Clingy:
Как только клиент решает, что конкретный URL-адрес обслуживается через прокси-сервер, наступает захват прокси-смерти .
Единственный способ избежать этого - получить логику выбора прямо перед тем, как клиент установит соединение, в списке PAC или Bypass.
Последнее замечание о зонах и файлах PAC
IE рассматривает сайты, которые имеют прямое подключение - даже если они имеют точки в URL - как часть зоны локальной интрасети (по умолчанию - устанавливается в свойствах зоны), и поэтому делает такие вещи, как разрешить встроенную проверку подлинности Windows для этих сайтов (т.е. Kerberos и / или NTLM-аутентификация (прозрачно). Таким образом, управление тем, находится ли что-то в зоне локальной интрасети, определяет, насколько доверенным оно является с точки зрения автоматической аутентификации. Опять же, по крайней мере, по умолчанию.
Существует ли стандарт или часть RFC, в котором говорится, что клиенты не должны выполнять разрешение DNS перед подключением через прокси-сервер?
Просто условность и / или эффективность, насколько я понимаю. Старый Microsoft Winsock Proxy Client использовался, чтобы позволить вам играть с опциями разрешения имен. И ничто не помешает вам написать PAC, который выполняет разрешение имен, а затем использует прокси-сервер . это просто не так, как это было сначала.
Я не уверен, что ваша часть DNS верна. Я видел машину без действительных DNS-серверов, которые нормально выбирают страницы в IE, используя прокси.
. и упс. Я только что сделал тест, который показал себя неправильно, по крайней мере, в IE. Итак, я думаю, что мой следующий вопрос будет, как тогда разрешается DNS для адресов, которые находятся в списке исключений прокси? Может быть, пришло время вытащить сниффер.
Я пытаюсь в Ubuntu 10.04, Wine, IE 6.0 и Squid 2.7 (система имеет один DNS и Squid есть другой сервер DNS)
Веб-страница недоступна
Сервер google.ru не найден из-за ошибки поиска DNS (веб-службы, которая преобразует название веб-сайта в интернет-адрес) . Обычно это вызвано отсутствием подключения к Интернету или неправильной настройкой сети. Возможно, недоступен сервер DNS. Кроме того, доступ программы Google Chrome к сети может блокировать брандмауэр.
Вот несколько советов и рекомендаций:
• Обновите эту страницу позже.
• Проверьте подключение к Интернету. Перезагрузите все используемые маршрутизаторы, модемы и другие сетевые устройства.
• Проверьте настройки DNS. Если вы не знаете, как это сделать, обратитесь к администратору сети.
• Попробуйте отключить предварительное определение сети, выполнив следующие шаги: нажмите на меню инструментов > "Настройки" > "Показать дополнительные настройки" и снимите флажок "Предсказывать сетевые действия для ускорения загрузки страниц". Если это не устранит проблему, рекомендуем снова включить этот параметр, чтобы повысить быстродействие.
• Добавьте Google Chrome в список разрешенных приложений в настройках брандмауэра или антивирусной программы. Если это приложение уже находится в списке разрешенных, попробуйте удалить его из этого списка, а затем добавить снова.
• При использовании прокси-сервера проверьте его настройки или обратитесь к администратору сети, чтобы убедиться, работает ли прокси-сервер. Если прокси-сервер использовать необязательно, установите соответствующие настройки: Нажмите на меню инструментов > "Настройки" > "Показать дополнительные настройки" > "Изменить настройки прокси-сервера. " > "Настройка сети" и снимите флажок "Использовать прокси-сервер для локальных подключений".
Днс сервера настроил, а инет не пашет .
Настроить то настроил, а остальные рекомендации не выполнил. Возьми и тупо выключи модем. Включи. Если не пойдет, в центре управления сетями выкл-вкл-диагнстика (справа внизу будет) -ждать устранения проблемы.
Ты настроил, а запроса не было. При переключении будет.
Что такое ошибка DNS?
Перейти в меню "Пуск" и выберите команду "Выполнить". Сейчас "IPCONFIG / релиз" типа и нажмите «OK». Это позволит освободить старый IP адрес. Теперь вам нужно написать 'Ipconfig / обновить' и нажмите 'OK' для того, чтобы продлить свой текущий адрес IP.
Вы даже имеете возможность вводить свои собственные настройки DNS. Если вы используете подключение по локальной беспроводной, вы будете проинформированы о предпочтениях DNS и альтернативный DNS. Вы можете изменить эту настройку, перейдя в "Свойства" подключения к сети.
Вы также должны убедиться, что все кабели и провода подсоединены правильно. Если ничего не работает, то попробуйте использовать на другой машине с тем же соединением.
Вы должны также проверить настройки брандмауэра на персональном компьютере, так как Брандмауэр блокирует конкретный URL, который вы посещаете.
Внимательный читатель найдет на этой картинке IPv6
Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.
Что такое DNS
DNS расшифровывается как Domain Name System. Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.
Базовые штуки
Давайте взглянем на маппинг между именем и адресом:
Команда 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 ). Так какой именно корневой сервер это был? Давайте узнаем!
Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS -серверов. Он отвечает за домен верхнего уровня info . dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info , и получает в ответ еще один набор NS -серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info. . И, наконец, получает ответ!
Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер. Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» — прим. от rrrav). Домены верхнего уровня com , net , org , и т.д. тоже обычно сильно закэшированы.
Другие типы
Заметьте, что MX -запись указывает на имя, а не на IP-адрес.
Еще один тип, который вам скорее всего знаком, это CNAME . Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:
Типичные ситуации
Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.
Редирект домена на www
Заключение
Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:
Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.
Есть клиентский компьютер в сети 192.168.1.0/24, получает ip по DHCP.
Почему то иногда выбирает DNS запись из другой сети, 10.0.0.10, которая ему недоступна. Насколько я знаю, должен выбирать из той подсети, в которой он находится, или я не прав?
Round robin понятно, точно, про netmask ordering я забыл.
"В настройках сервера DNS по умолчанию включена и опция Enable netmask ordering. Смысл опции заключаются в том, что при наличии нескольких IP адресов для одного и того же имени хоста сервер DNS анализирует из какой сети пришел запрос от клиента. Если IP сеть клиента совпадает с номером сети одного из IP адресов хоста, то такой IP всегда возвращается первым"
ну тогда и Split-Brain DNS для кучи, если вдруг клиентских сетей будет больше одной или захочется убрать интерфейс DNS сервера из клиентской сети
НУ и вот зачем вы клиенту отдаете DNS из серверной сети куда у нет доступа? Уберите его из DHCP и будет вам счастье
Максим Забелин: DNS он один, но с двумя сетевухами - одна смотрит в серверную подсеть, а другая в пользовательскую.
Во-первых, DHCP на mutihomed серверах - нерекомендованая вендором конфигурация, но это не существенно. Во-вторых, услышьте меня: вы в параметрах DHCP отдаете клиенту адрес DNS сервера из серверной сети. Зачем?
Максим Забелин: Вы ошибаетесь, клиенту отдаётся IP адрес из его подсети. Как я уже написал несколько раз, у DNS два интерфейса, один из пользовательской сети 192, а второй для серверной подсети. Соответственно при запросе сервера получают первыми IP из своей подстети, а пользователи из своей.
". Есть клиентский компьютер в сети 192.168.1.0/24, получает ip по DHCP.
Почему то иногда выбирает DNS запись из другой сети, 10.0.0.10, которая ему недоступна. "
Вы упорно не хотите слышать, что вам говорят. У вас клиент получает DNS 10.0.0.10 от DHCP. Это значит что вы в параметрах DHCP этот адрес передаете. Если 10.0.0.10 недоступен клиенту - то не надо этого делать.
Максим Забелин: Нет, по DHCP он получает IP адрес DNS сервера 192.168.0.10. Также у DNS сервера есть второй интерфейс 10.0.0.10, его никто по DHCP не получает, эти настройки прописаны ручками на серверах. А вот на самом DNS, в зоне firma.local для серверов прописаны две A записи - из 10-й и из 192-й сети. При запросе сервера SERVER1 DNS выдаёт две записи - но в зависимости от запроса (из какой сети пришёл запрос) Выдаёт первым тот адрес, из которой пришёл запрос.
нет, вы не правы.
Например, Microsoft DNS при первом обращении отдаст клиенту обе записи, клиент должен будет выбрать первую и работать с ней, а вот при повторном обращении DNS уже отдаст клиенту вторую запись.
Поведение других DNS серверов (например -- Bind) может отличаться.
В любом случае, на клиентский IP DNS смотреть не будет.
Я неправильно понимаю этот материал DNS? Не разрешается ли сторонним DNS-серверам, таким как наш, распространять информацию DNS на другие серверы в сети?
С чего мне начать расследование того, почему изменения не вносятся? Я вижу на нашем брандмауэре, что трафик порта 53 направляется на наши DNS-серверы должным образом.
ОБНОВИТЬ
Да, вы неправильно понимаете, как работает DNS. Я собираюсь использовать некоторые акценты здесь, но, пожалуйста, не обижайтесь, так как никто не предназначен.
ЗАПИСИ DNS НЕ РАСПРОСТРАНЯЮТСЯ. Они кешируются.
При этом, вот упрощенное объяснение того, что происходит:
Вы создаете новую запись DNS (A, CNAME и т. Д.)
Ваши серверы имен отвечают с ответами
DNS-сервер пользователя затем отправляет эту информацию пользователю (более конкретно, клиентскому распознавателю DNS-пользователя), который, в свою очередь, возвращает информацию процессу \ приложению. Эта информация поставляется с так называемым TTL (Time To Live), который сообщает распознавателю DNS-клиента, как долго эта информация может храниться в его DNS-кэше (в памяти) и как долго эта информация может считаться текущей и точной.
DNS-клиент пользователя пользователя сбрасывает эту информацию, когда истекает TTL. Любые новые запросы для рассматриваемых записей DNS требуют нового поиска DNS, и вышеуказанный процесс повторяется.
Таким образом, длинный и короткий это это:
Ваши записи DNS не распространяются. Ни один другой DNS-сервер не имеет копии ваших DNS-записей или зон. DNS-клиент или сервер может кэшировать информацию о ваших DNS-записях или зонах (на основе их DNS-запросов ваших DNS-записей и зон) в свой DNS-кеш. Эта информация временно кэшируется и будет удалена из их DNS-кэша по истечении TTL.
Если ваши серверы имен не работают, разрешить эти записи DNS смогут только те DNS-клиенты, которые имеют какие-либо записи DNS в своем кэше, и только до истечения срока действия TTL. Кроме того, когда истекает срок действия TTL (не требуется новый DNS-локуп), эти DNS-клиенты больше не смогут разрешать ваши записи DNS.
Хорошее объяснение, и я могу добавить пример протокола, где есть распространение (в отличие от DNS): BGP.
Было бы очень полезно, если бы вы сообщили нам свое реальное доменное имя, тогда мы могли бы ответить на ваш вопрос со ссылкой на ваши фактические настройки и указать на любые ошибки.
Вы не можете мгновенно публиковать изменения DNS - ну, вы можете публиковать их мгновенно, но остальной мир будет отставать в соответствии с настройками TTL каждой записи, например, если вы установили запись TTL в 86400 секунд ( один день) и вы внесете изменение, другие увидят старую запись на целый день, потому что их локальный кэш не будет спрашивать вас, пока не истечет срок действия их копии записи.
Я хотел бы предложить, чтобы перед любыми существенными изменениями в DNS вы сократили свой TTL до 600 (10 минут), чтобы кеши по всему Интернету не хранили старые записи очень долго. Но некоторые кеши игнорируют это, или предполагают, что 1 день или даже 1 неделя.
Беспорядочный ответ на бессвязный вопрос, надеюсь, в этом было что-то полезное.
+1. Просто для ясности, изменение затронет только те DNS-клиенты, которые уже имеют информацию в своем кэше, для которых срок действия TTL не истек. Любые новые запросы, для которых нет данных в кеше, будут разрешены немедленно.
Да, старая поговорка «Изменения DNS могут распространяться через Интернет через 24-48 часов» была бы более точной: «Изменения DNS могут кэшироваться на любых DNS-серверах, которые запросили эту запись в течение последних 86400 секунд».
Все DNS-серверы в Интернете «контролируются третьими лицами» (я полагаю, вы могли бы считать корневые DNS-серверы как-то «проприетарными» для Интернета, но нет никаких технических причин, по которым вы могли бы также создать свой собственный частный корень).
Ваш DNS-сервер предоставляет предполагаемое время жизни (TTL) в каждом ответе. Удаленные распознаватели (другие DNS-серверы, выполняющие рекурсивное разрешение для клиентов, клиентские библиотеки распознавателей и т. Д.) Должны кешировать ответ до этого TTL, прежде чем выбросить его из своего кеша.
Если вы не видите изменений, которые вы вносите в существующие записи, которые отражаются в реальных запросах, это, вероятно, означает, что ваши значения TTL достаточно высоки, и вы не ждете достаточно долго, чтобы увидеть, что существующие ответы устарели из решателя. кеши вокруг инета
Когда кто-то (или какой-то компьютер) в Интернете, так сказать, хочет подключиться к одному из ваших компьютеров, он запрашивает у своего локального сервера имен IP-адрес, совпадающий с именем хоста, в котором они заинтересованы.
Буквальный ответ на ваш вопрос - почему ваши записи DNS не распространяются в Интернете - заключается в том, что они этого не делают, потому что не должны этого делать.
Кроме того, если вы просматриваете свою собственную информацию DNS, используя сайт, предназначенный для исследования или отладки информации DNS, есть вероятность, что сайт не будет долго кэшировать данные, или вообще, независимо от того, что вы предлагаете TTL, потому что цель сайта, вероятно, состоит в том, чтобы предоставить информацию о том, что система DNS говорит ПРЯМО СЕЙЧАС, а не 5, 50 или 500 секунд назад. Вот почему ваши изменения отражаются немедленно, и поэтому служба перестает работать, как только вы отключаете свои серверы имен.
Я подозреваю, что ваш основной вопрос может быть следующим: «Как я могу настроить все так, чтобы в случае перезагрузки моего DNS-сервера или его жесткого диска другие люди в Интернете по-прежнему могли видеть мои веб-страницы?»
Ответ на этот вопрос заключается в том, чтобы настроить несколько серверов имен для вашего домена и обеспечить их работу на разных компьютерах - в идеале, не просто на разных физических компьютерах, а с разными сетевыми подключениями, возможно, даже в разных городах, штатах, странах или континентах. Большинство из этих серверов имен будут настроены как «ведомые», что означает, что они обращаются к «главному» серверу имен за своей информацией, а затем повторяют эту информацию всем, кто запрашивает у них данные.
Таким образом, в данных WHOIS вашего регистратора доменных имен вы можете настроить четыре сервера имен для своего домена:
Самый простой способ решить эту проблему - зарегистрироваться у поставщика услуг DNS, который будет обрабатывать DNS для вашего домена - цена за него варьируется от бесплатных до тысяч (возможно, даже десятков или сотен тысяч) долларов в месяц, в зависимости от уровень сервиса вы хотите. Вы можете получить достаточно надежную услугу за $ 30 / год или около того. Бесплатные услуги не являются ужасными и, следовательно, имеют довольно хорошее соотношение цены и качества, но если вы зависите от своего веб-сайта, чтобы зарабатывать деньги, вы должны иметь возможность получить 30 долларов за год DNS ,
Затем следуйте инструкциям поставщика услуг DNS, чтобы изменить записи NS у вашего регистратора доменных имен, и все будет готово.
Запросы к другим серверам
Давайте представим, что конфигурация DNS испорчена. Вам кажется, что вы исправили проблему, но не хотите ждать когда обновится кэш чтобы удостовериться. С помощью dig можно сделать запрос к публичному DNS-серверу вместо своего дефолтного, вот так:
Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2 .
Что не так с CNAME
Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.
CNAME для Heroku или Github
С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME . См. документацию.
Что не так с CNAME
Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.
Wildcards
Большинство DNS-серверов поддерживают шаблоны (wildcards). Например, есть wildcard CNAME для *.web01.bugsplat.info указывает на web01.bugsplat.info . Тогда любой хост на web01 будет указывать на web01.bugsplat.info и не нужно создавать новые записи:
Читайте также: