Wildcard dns что это

Обновлено: 24.01.2025

СОДЕРЖАНИЕ

Определения подстановочных знаков DNS

Запись DNS с подстановочными знаками в файле зоны выглядит примерно так:

Исходное определение того, как ведет себя подстановочный знак DNS, указано в разделах 4.3.2 и 4.3.3 RFC 1034 , но только косвенно, на определенных этапах алгоритма поиска, и в результате правила не являются интуитивно понятными или четко определенными. В результате, 20 лет спустя, RFC 4592 «Роль подстановочных знаков в системе доменных имен» был написан, чтобы помочь прояснить правила.

Примеры использования

Следующий пример взят из раздела 2.2.1 RFC 4592 и полезен для пояснения того, как работают подстановочные знаки.

Скажем, есть зона DNS со следующими записями ресурсов:

Полезно взглянуть на доменные имена в древовидной структуре:

Следующие ответы будут синтезированы из одного из подстановочных знаков в зоне:

Запрошенный домен	Запрошенный тип RR	Полученные результаты
host3.example.	MX	Ответом будет "host3.example. IN MX . "
host3.example.	А	Ответ будет отражать «нет ошибок, но нет данных», потому что не установлена запись ресурса «A» (RR) *.example .
foo.bar.example.	текст	Ответ будет «foo.bar.example. IN TXT . », потому bar.example. что не существует, но есть подстановочный знак.

Следующие ответы не будут синтезированы ни с одним из подстановочных знаков в зоне:

Запрошенный домен	Запрошенный тип RR	Полученные результаты
host1.example.	MX	Подстановочный знак не будет совпадать, потому что он host1.example. существует. Вместо этого вы получите ответ «нет ошибок, но нет данных». Запись MX с подстановочными знаками не предоставляет записи MX для доменов, которые в противном случае существуют.
sub.*.example.	MX	Подстановочный знак не будет совпадать, потому что он sub..example. существует. Домен sub..example. никогда не будет действовать как подстановочный знак, даже если в нем есть звездочка.
_telnet._tcp.host1.example.	SRV	Никакой подстановочный знак не будет совпадать, потому что _tcp.host1.example. существует (без данных).
host.subdel.example.	А	Никакой подстановочный subdel.example. знак не будет совпадать, потому что существует и является разрезом зоны, помещенным host.subdel.example. в другую зону DNS . Даже если host.subdel.example. он не существует в другой зоне, подстановочный знак из родительской зоны использоваться не будет.
ghost.*.example.	MX	Подстановочный *.example. знак не будет совпадать, потому что он существует, это домен с подстановочным знаком, но он все еще существует.

Последний пример подчеркивает одно распространенное заблуждение о подстановочных знаках. Подстановочный знак «блокирует себя» в том смысле, что подстановочный знак не соответствует своим собственным поддоменам. То есть *.example. не соответствует всем именам в example. зоне; это не соответствует именам ниже *.example. . Чтобы скрыть имена *.example. , необходимо другое доменное имя с подстановочными знаками, *.*.example. которое охватывает все, кроме собственных поддоменов.

На практике

Процитируем RFC 4592 : многие реализации DNS по-разному расходятся с исходным определением подстановочных знаков. Некоторые из вариантов включают:

С помощью djbdns , помимо проверки подстановочных знаков на текущем уровне, сервер проверяет наличие подстановочных знаков во всех включающих супердоменах, вплоть до корня. В приведенных выше примерах запрос _telnet._tcp.host1.example записи MX будет соответствовать подстановочному знаку, несмотря на то, что домен _tcp.host1.example существует.
DNS-сервер Microsoft (если настроен для этого) и MaraDNS (по умолчанию) имеют подстановочные знаки, также соответствующие всем запросам для пустых наборов записей ресурсов; т.е. доменные имена, для которых нет записей нужного типа . В приведенных выше примерах запрос sub.*.example записи MX будет соответствовать *.example , несмотря на то, что он sub.*.example явно существует только с записью TXT .

Регистранты

Домены с подстановочными знаками широко используются веб-сайтами блогов, которые позволяют пользователям создавать поддомены по запросу; например, такие сайты, как WordPress или Blogspot . Еще одно популярное использование - это веб-сайты Free Dynamic DNS, которые позволяют пользователям создавать DNS-имя, которое изменяется в соответствии с IP-адресом их хоста, поскольку IP-адрес периодически изменяется DHCP-сервером их провайдера.

Новые TLD

Новые рДВУ запрещено публиковать символы (или с использованием эквивалентных механизмов сервера имен) по спецификации 6 в ICANN соглашения о новом рДВУ базы реестра. Однако структура управления конфликтами имен ICANN (PDF ) явно требует, чтобы новые рДВУ публиковали (в течение как минимум 90 дней) специальные символы записи MX, SRV, TXT и 127.0.53.53 A, которые предупреждают о потенциальных конфликтах имен из-за использования относительных доменные имена с путями поиска домена .

Реестры / интернет-провайдеры

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

Игнорирование подстановочных знаков от других

Консорциум Internet Software выпустил версию BIND DNS программного обеспечения , которое может быть сконфигурировано для фильтра из подстановочных DNS записей из определенных доменов. Различные разработчики выпустили программные исправления для BIND и djbdns .

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

Внимательный читатель найдет на этой картинке 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 (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:

Что не так с CNAME

Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.

Запросы к другим серверам

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

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

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

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

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

CNAME для Heroku или Github

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

Wildcards

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

Заключение

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

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

Если у вас небольшой бизнес в сети или вы ведете блог на WordPress, то вы, вероятно, уже сталкивались с настройкой записей A и CNAME. А если вы пытались перенести почту со своего сайта, то и с настройкой записи MX. И, возможно, какой-нибудь веб-сервис просил настроить TXT, чтобы работать с вашим сайтом. Для чего все это нужно и какие здесь сложности?

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

Серверы DNS

Все настройки, которые вы зададите, будут настроены и опубликованы в сети с помощью этих серверов.

Теперь перейдем к типам записей DNS, основной из них является A-запись.

Записи А

Вот образец запроса A-записи на Kloth:

Записи поддомена

Записи wildcard

В конфигурацию DNS можно добавлять записи Wildcard (с помощью астериска * ), позволяющие направлять весь трафик поддоменов на один IP. Например, если я хочу, разместить все поддомены городов на одном сервере, я сделаю так:

Записи wildcard облегчают привязку нескольких поддоменов к одному серверу.

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

Я также продаю домены с динамическими расценками. Вот как Apache обрабатывает трафик для всех этих доменов и записей DNS.

Теперь мы плавно перейдем к CNAME записям. Они полезны в разных случаях, а особенно в упрощении управления IP-адресами и миграциях с одного сервера на другой.

Записи CNAME

CNAME это по сути текстовый псевдоним для направления трафика домена и поддомена. Например, если вы сталкивались с настройкой сервиса типа WordPress или Tumblr, они могли предложить настроить домен именно с помощью записи CNAME, а A-записи c IP.

Примечание: обязательно ставьте точку в адресе CNAME.

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

Что происходит, когда вы меняете записи DNS

Записи DNS для корневого домена и поддоменов, как правило, не зависимы друг от друга. Изменение A-записи корневого домена не влияет на существующий адрес CNAME поддомена. Однако недавно я регистрировался на сервисе сетевой безопасности Incapsula и обнаружил, что он требует две А-записи для одного корневого домена — это может сделать все более сложным. Другими словами, технически у вас может быть несколько А-записей для одного домена, что может породить конфликты.

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

На иллюстрации ниже показаны DNS-серверы, захватившие мои последние изменения:

Записи MX

Теперь перейдем к записям MX. Эти записи сообщают системе DNS, куда слать все приходящие вам email. Поэтому, если я купли домен StarWars.io и захочу получать почту по адресу [email protected] , мне надо сделать две вещи.

Во-первых, мне нужно зарегистрироваться на почтовом сервисе типа Google Apps или FastMail, чтобы разместить там почту. Во-вторых, мне надо сконфигурировать записи MX так, чтобы почта шла на эти серверы.

Например, так будет выглядеть конфигурация Google Apps:

А для FastMail так:

Если вы захотите запустить свой собственный почтовый сервер, вам нужно указать в записи MX IP-адрес этого сервера.

Многие пользователи используют MX Toolbox для просмотра записей MX, но это может сделать и любой другой сервис просмотра DNS.

Смена провайдера Email и перенос почты

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

Смена записи MX не повредит содержимое вашего старого хранилища почты, просто новые письма перестанут туда поступать.

Записи TXT

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

Например, Google может попросить вас добавить такую запись:

База ключей, подготовленная мной для цикла статей о PGP и шифровании использует записи TXT для верификации моего сайта и меня, с помощью моих публичных ключей.

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

Записи AAAA

Когда IP-адреса в интернете закончатся, мы неторопливо перейдем на имена IPv6. подробнее об этом вы можете узнать из статьи о запуске IPV6.

Если вы решили поддерживать адресацию IPv6, вам надо сконфигурировать запись AAAA:

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

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

Что представляет собой DNS?

Интернет - это сеть, которая объединяет между собой миллионы компьютеров. В сети находятся компьютеры, работающие круглосуточно и без остановок. Как правило, это серверы, которые используются для хранения сайтов и электронной почты. Каждый компьютер при подключении к сети интернет получает специальный идентификатор в числовом виде. Другими словами, ip-адрес. Конечно, к серверу можно обратиться и с помощью числового идентификатора, но вот практика показывает, что людям не будет удобно запоминать адреса в виде чисел. Поэтому разработчики ввели систему буквенных доменов.

Domain Name System, или DNS - это специальная система, которая обеспечивает соответствие доменов их числовым адресам. В интернете есть специальный класс серверов - ns-серверы, которые отвечают за хранение DNS. Там можно проверить домена DNS записи. Их поддерживают с двух сторон - со стороны интернет-провайдеров и хостеров, а также со стороны администраторов доменных зон. Данные сервера имеют свою иерархию.

Сроки обновления DNS-записей

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

Быстрее приступить к работе

Если вы только что прошли процедуру регистрации домена или изменили DNS-записи, при этом появилась необходимость срочно начать работу с интернет-сайтом, можно воспользоваться одним хитрым трюком, который ускорит время, необходимое для начала работы. Добавьте в файл hosts, который по умолчанию есть по адресу C:\WINDOWS\system32\drivers\etc (папка может быть скрытой) одну строчку:

Подстановочный wildcard ssl сертификат: что это такое и зачем он нужен

На рисунке ниже подробно описаны уровни доменных имен, начиная с домена верхнего уровня(TLD) и вплоть до поддоменов 4-го уровня. Обратите внимание, что количество уровней субдоменов не ограничивается цифрой 4 и определяется потребностями их владельца.

Кому наиболее выгодно использовать wildcard сертификаты

Wildcard SSL имеет смысл использовать для сайта с большим количеством поддоменов, этот вид сертификата позволит защитить их все сразу.

Некоторые распространенные сценарии, когда использование подстановочного SSL сертификата является наиболее выгодным, включают в себя:

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

Основные принципы того как работает сертификат wildcard и особенности его интеграции

Подстановочные SSL сертификаты обеспечивают зашифрованное соединение между пользователем(его веб-браузером или другим программным обеспечением) и веб-сервером. При этом данные шифруются с помощью набора ключей — один из которых хранится в самом сертификате, а другой на сервере. Разница между обычным и wildcard сертификатом заключается в том, что первый может работать только на одном сервере, в то время как второй может быть скопирован и загружен на столько серверов, сколько необходимо для размещения основного домена и всех его поддоменов.

Обратите внимание! - При использовании одного подстановочного SSL-сертификата на нескольких серверах нужно соблюдать осторожность, так как они будут снабжены одним и тем же закрытым ключом. В случае компрометации одного сервера, все остальные также окажутся под угрозой.

Как настроить подстановочный SSL-сертификат

Для установки wildcard сертификата на сайт нужно последовательно выполнить несколько простых шагов:

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

Оплатите сертификат. На рынке существует множество поставщиков которые предлагают ssl сертификаты wildcard (WC) на выбор. Наилучшее решение зависит от конкретных потребностей покупателя и его бюджета. Для обеспечения большей защищенности основного домена и его поддоменов можно выбрать сервис с поддержкой функции создания уникальных закрытых ключей для каждой копии подстановочного SSL-сертификата загружаемого на сервер. Это несколько затруднит управление сертификатом, но сделает защищенные им сайты менее уязвимыми для хакеров и других угроз безопасности.

После того как поставщик SSL сертификата сгенерирует CSR, будет произведена оплата и пройдена проверка подтверждения домена можно загружать полученные от центра сертификации файлы на свой сервер.

Типы подстановочных SSL сертификатов

Wildcard сертификаты бывают двух типов:

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

К сожалению wildcard сертификаты не выпускаются в самой защищенной версии — EV (Extended Validation), поскольку она требует углубленного процесса проверки домена и запрашивающей организации, прежде чем какой-либо авторитетный CAS выдаст их. При необходимости добавления EV SSL для поддоменов нужно приобретать платный сертификат для каждого из них в отдельности.

Чем подстановочный сертификат отличается от других видов защиты

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

Плюсы wildcard сертификатов SSL

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

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

Вывод

Установка wildcard SSL сертификата, это один из самых важных шагов в оптимизации и защите сайта. Если этот этап пропустить — возникнут трудности с ранжированием в поисковых системах и значительная часть пользователей откажется от посещения ресурса из-за статуса небезопасного. Различные виды сертификатов позволяют избежать этих трудностей. Выбор конкретного типа сертификата зависит от специфики сайта, для проектов которые используют поддомены — лучшее решение, это wildcard SSL. Установка такого сертификата позволяет экономить время, деньги и усилия, защищая неограниченное количество субдоменов. Процесс получения сертификата занимает от нескольких минут до 3 дней в зависимости от его типа, интеграция wildcard SSL на сайт происходит в три несложных шага.

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