Enable dns srv lookup что это
В этой статье описывается проверка записей ресурсов локатора расположения службы (SRV) для контроллера домена после установки службы каталогов Active Directory.
Применяется к: Windows Server 2012 R2
Исходный номер КБ: 816587
Сводка
Запись SRV — это запись ресурсов системы доменных имен (DNS). Он используется для идентификации компьютеров, на которые размещены определенные службы. Записи ресурсов SRV используются для поиска контроллеров домена для Active Directory. Чтобы проверить записи ресурсов локатора SRV для контроллера домена, используйте один из следующих методов.
Что не так с CNAME
Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX , ни A , ни NS , ничего.
Метод 3. Использование Nslookup
Nslookup это средство командной строки, отображает сведения, которые можно использовать для диагностики инфраструктуры системы доменных имен (DNS).
Чтобы проверить Nslookup записи SRV, выполните следующие действия:
- В DNS выберите > запуск.
- В поле Открыть введите cmd .
- Введите nslookup и нажмите кнопку ENTER.
- Введите set type=all и нажмите кнопку ENTER.
- Введите имя домена и нажмите _ldap._tcp.dc._msdcs.Domain_Name кнопку ENTER.
Nslookup возвращает одну или несколько записей расположения службы SRV, которые отображаются в следующем формате, где находится имя хозяина контроллера домена, и где домен, к котором принадлежит контроллер домена, и является адресом internet Protocol (IP) контроллера домена:
Запись SRV, заданная на сервере доменных имен (DNS), помогает соединиться с SIP пользователем, так же как MX запись помогает доставить электронную почту на сервер адресата. Когда вы отправляете почту на адрес "john@example.com", тогда MX запись для домена example.com может указать агенту, отвечающему за доставку почты, совсем другую машину, которая является почтовым сервером для этого домена, например, "zaphod.foobar.com". Подобным образом, когда вы хотите совершить вызов на SIP телефон: , запись типа SRV, может сказать Вашему компьютеру, что для этого следует подключиться к хосту "galaxy.starsystem.tw".
Зачем может понадобиться использование DNS SRV записей для SIP протокола?
Совершение вызовов с использованием имен доменов дает возможность SIP пользователю иметь один публичный Интернет адрес "SIP адрес", поступающие туда вызовы будут перенаправлены конечному пользователю, на его фактический адрес. SRV записи позволяют в некоторой степени защитить систему, при этом так же давая возможность использовать Ваше собственное доменное имя, вне зависимости от имени домена Вашего SIP провайдера.
Записи SRV в DNS указывают, как найти сервисы для различных протоколов.
Выдержка из RFC:
Этот документ описывает записи DNS RR, которые описывают местоположение сервисов для определенных протоколов и доменов.
На данный момент, она может содержать точный адрес сервера для связи с ним, или широковещательный запрос.
Запись SRV RR позволяет администраторам использовать несколько серверов для одного домена, перемещая обслуживание определенного сервиса от хоста к хосту в случайном порядке, и для назначения некоторого сервера основным для заданного сервиса, а другой - в качестве резервного.
Клиент запрашивает нужный ему сервис/протокол для определенного домена (имена используемых здесь доменов должны отвечать требованиям RFC 1034), и получает в ответ имена всех доступных серверов.
Решение на виртуальных сервисах
В последнее время большую популярность приобрели сервисы виртуальных АТС и многие из них позволяют совершать и принимать вызовы на SIP URI. Также есть сервис Цифровой Офис, который позволяет сделать привязку вашего домена к сервису телефонии. Использование сервисов избавляет вас от самостоятельной настройки и защиты сервера телефонии. Большинство из них работают по предоплате и исключают риск получения больших счетов.
После настройки можно будет принимать звонки с других сервисов и звонить на них. Так же можно звонить и на сервера Asterisk других компаний, если они поддерживают гостевые звонки.
В своё время открыл для себя простую истину: хочешь запомнить что-то — веди конспект (даже при чтении книги), а хочешь закрепить и систематизировать — донеси до людей (напиши статью). Поэтому, после двух лет работы в системной интеграции (сфере, которую я в бытность свою системным администратором, считал просто рогом изобилия для жаждущих прокачки специалистов), когда я понял, что знания постепенно вытесняются навыками правки документации и конфигурированию по мануалам и инструкциям, для поддержания формы я начал писать статьи о базовых вещах. Например вот — о DNS. Делал тогда я это больше для себя, но подумал — вдруг кому пригодится.
Сервис в современных сетях если не ключевой, то один из таковых. Те, для кого служба DNS — не нова, первую часть могут спокойно пропустить.
Содержание:
(анкеров нет, поэтому содержание без ссылок)
1. Основные сведения
DNS — это база данных, содержащая, в основном, информацию о сопоставлении имён сетевых объектов их IP-адресам. «В основном» — потому что там и ещё кое-какая информация хранится. А точнее, ресурсные записи (Resource Records — RR) следующих типов:
А — то самое сопоставление символьного имени домена его IP адресу.
АААА — то же что А, но для адресов IPv6.
CNAME — Canonical NAME — псевдоним. Если надо чтобы сервер с неудобочитаемым именем, типа nsk-dc2-0704-ibm, на котором вертится корпоративный портал, откликался также на имя portal, можно создать для него ещё одну запись типа А, с именем portal и таким же IP-адресом. Но тогда, в случае смены IP адреса (всякое бывает), нужно будет пересоздавать все подобные записи заново. А если сделать CNAME с именем portal, указывающий на nsk-dc2-0704-ibm, то ничего менять не придётся.
MX — Mail eXchanger — указатель на почтовый обменник. Как и CNAME, представляет собой символьный указатель на уже имеющуюся запись типа A, но кроме имени содержит также приоритет. MX-записей может быть несколько для одного почтового домена, но в первую очередь почта будет отправляться на тот сервер, для которого указано меньшее значение в поле приоритета. В случае его недоступности — на следующий сервер и т.д.
NS — Name Server — содержит имя DNS-сервера, ответственного за данный домен. Естественно для каждой записи типа NS должна быть соответствующая запись типа А.
SOA — Start of Authority — указывает на каком из NS-серверов хранится эталонная информация о данном домене, контактную информацию лица, ответственного за зону, тайминги хранения информации в кэше.
SRV — указатель на сервер, держатель какого-либо сервиса (используется для сервисов AD и, например, для Jabber). Помимо имени сервера содержит такие поля как Priority (приоритет) — аналогичен такому же у MX, Weight (вес) — используется для балансировки нагрузки между серверами с одинаковым приоритетом — клиенты выбирают сервер случайным образом с вероятностью на основе веса и Port Number — номер порта, на котором сервис «слушает» запросы.
Все вышеперечисленные типы записей встречаются в зоне прямого просмотра (forward lookup zone) DNS. Есть ещё зона обратного просмотра (reverse lookup zone) — там хранятся записи типа PTR — PoinTeR — запись противоположная типу A. Хранит сопоставление IP-адреса его символьному имени. Нужна для обработки обратных запросов — определении имени хоста по его IP-адресу. Не требуется для функционирования DNS, но нужна для различных диагностических утилит, а также для некоторых видов антиспам-защиты в почтовых сервисах.
Кроме того, сами зоны, хранящие в себе информацию о домене, бывают двух типов (классически):
Основная (primary) — представляет собой текстовый файл, содержащий информацию о хостах и сервисах домена. Файл можно редактировать.
Дополнительная (secondary) — тоже текстовый файл, но, в отличие от основной, редактированию не подлежит. Стягивается автоматически с сервера, хранящего основную зону. Увеличивает доступность и надёжность.
Для регистрации домена в интернет, надо чтоб информацию о нём хранили, минимум, два DNS-сервера.
В Windows 2000 появился такой тип зоны как интегрированная в AD — зона хранится не в текстовом файле, а в базе данных AD, что позволяет ей реплицироваться на другие контроллеры доменов вместе с AD, используя её механизмы репликации. Основным плюсом данного варианта является возможность реализации безопасной динамической регистрации в DNS. То есть записи о себе могут создать только компьютеры — члены домена.
В Windows 2003 появилась также stub-зона — зона-заглушка. Она хранит информацию только о DNS-серверах, являющихся полномочными для данного домена. То есть, NS-записи. Что похоже по смыслу на условную пересылку (conditional forwarding), которая появилась в этой же версии Windows Server, но список серверов, на который пересылаются запросы, обновляется автоматически.
Итеративный и рекурсивный запросы.
DNS-сервер обращается к одному из корневых серверов интернета, которые хранят информацию о полномочных держателях доменов первого уровня или зон (ru, org, com и т.д.). Полученный адрес полномочного сервера он сообщает клиенту.
Клиент обращается к держателю зоны ru с тем же запросом.
DNS яндекса возвращает нужный адрес.
Такая последовательность событий редко встречается в наше время. Потому что есть такое понятие, как рекурсивный запрос — это когда DNS-сервер, к которому клиент изначально обратился, выполняет все итерации от имени клиента и потом возвращает клиенту уже готовый ответ, а также сохраняет у себя в кэше полученную информацию. Поддержку рекурсивных запросов можно отключить на сервере, но большинство серверов её поддерживают.
Клиент, как правило, обращается с запросом, имеющим флаг «требуется рекурсия».
Заголовок состоит из следующих полей:
Идентификация — в это поле клиентом генерируется некий идентификатор, который потом копируется в соответствующее поле ответа сервера, чтобы можно было понять на какой запрос пришёл ответ.
Флаги — 16-битовое поле, поделенное на 8 частей:
Вторая строка — ответ сервера: на указанный исходный порт с указанным идентификатором запроса. Ответ содержит одну RR (ресурсную запись DNS), являющуюся ответом на запрос, 2 записи полномочий и 5 каких-то дополнительных записей. Общая длина ответа — 196 байт.
3. TCP и UDP
Также передача зон от основных серверов к дополнительным осуществляется по TCP, поскольку в этом случае передаётся куда больше 512 байт.
4. DNS в Windows Server 2008 и 2012
В Windows 2008 появились следующие возможности:
Фоновая загрузка зон
- определяются все зоны, которые должны быть загружены;
- из файлов или хранилища доменных служб Active Directory загружаются корневые ссылки;
- загружаются все зоны с файловой поддержкой, то есть зоны, хранящиеся в файлах, а не в доменных службах Active Directory;
- начинается обработка запросов и удаленных вызовов процедур (RPC);
- создаются один или несколько потоков для загрузки зон, хранящихся в доменных службах Active Directory.
Поскольку задача загрузки зон выполняется отдельными потоками, DNS-сервер может обрабатывать запросы во время загрузки зоны. Если DNS-клиент запрашивает данные для узла в зоне, который уже загружен, DNS-сервер отправляет в ответ данные (или, если это уместно, отрицательный ответ). Если запрос выполняется для узла, который еще не загружен в память, DNS-сервер считывает данные узла из доменных служб Active Directory и обновляет соответствующим образом список записей узла.
Поддержка IPv6-адресов
Протокол Интернета версии 6 (IPv6) определяет адреса, длина которых составляет 128 бит, в отличие от адресов IP версии 4 (IPv4), длина которых составляет 32 бита.
DNS-серверы с ОС Windows Server 2008 теперь полностью поддерживают как IPv4-адреса, так и IPv6-адреса. Средство командной строки dnscmd также принимает адреса в обоих форматах. Cписок серверов пересылки может содержать и IPv4-адреса, и IPv6-адреса. DHCP-клиенты также могут регистрировать IPv6-адреса наряду с IPv4-адресами (или вместо них). Наконец, DNS-серверы теперь поддерживают пространство имен домена ip6.arpa для обратного сопоставления.
Изменения DNS-клиента
Разрешение имен LLMNR
Клиентские компьютеры DNS могут использовать разрешение имен LLMNR (Link-local Multicast Name Resolution), которое также называют многоадресной системой DNS или mDNS, для разрешения имен в сегменте локальной сети, где недоступен DNS-сервер. Например, при изоляции подсети от всех DNS-серверов в сети из-за сбоя в работе маршрутизатора клиенты в этой подсети, поддерживающие разрешение имен LLMNR, по-прежнему могут разрешать имена с помощью одноранговой схемы до восстановления соединения с сетью.
Кроме разрешения имен в случае сбоя в работе сети функция LLMNR может также оказаться полезной при развертывании одноранговых сетей, например, в залах ожидания аэропортов.
Изменения Windows 2012 в части DNS коснулись, преимущественно, технологии DNSSEC (обеспечение безопасности DNS за счет добавления цифровых подписей к записям DNS), в частности — обеспечение динамических обновлений, которые были недоступны, при включении DNSSEC в Windows Server 2008.
5. DNS и Active directory
Active Directory очень сильно опирается в своей деятельности на DNS. С его помощью контроллеры домена ищут друг друга для репликации. С его помощью (и службы Netlogon) клиенты определяют контроллеры домена для авторизации.
Для обеспечения поиска, в процессе поднятия на сервере роли контроллера домена, его служба Netlogon регистрирует в DNS соответствующие A и SRV записи.
SRV записи регистрируемые службой Net Logon:
_ldap._tcp.DnsDomainName
_ldap._tcp.SiteName._sites.DnsDomainName
_ldap._tcp.dc._msdcs.DnsDomainName
_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName
_ldap._tcp.pdc._msdcs.DnsDomainName
_ldap._tcp.gc._msdcs.DnsForestName
_ldap._tcp.SiteName._sites.gc._msdcs. DnsForestName
_gc._tcp.DnsForestName
_gc._tcp.SiteName._sites.DnsForestName
_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName
_kerberos._tcp.DnsDomainName.
_kerberos._udp.DnsDomainName
_kerberos._tcp.SiteName._sites.DnsDomainName
_kerberos._tcp.dc._msdcs.DnsDomainName
_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName
_kpasswd._tcp.DnsDomainName
_kpasswd._udp.DnsDomainName
Первая часть SRV-записи идентифицирует службу, на которую указывает запись SRV. Существуют следующие службы:
_ldap — Active Directory является службой каталога, совместимой с LDAP-протоколом, с контроллерами домена, функционирующими как LDAP-серверы. Записи _ldap SRV идентифицирует LDAP серверы, имеющиеся в сети. Эти серверы могут быть контроллерами домена Windows Server 2000+ или другими LDAP-серверами;
_kerberos — SRV-записи _kerberos идентифицируют все ключевые центры распределения (KDC — Key Distribution Centers) в сети. Они могут быть контроллерами домена с Windows Server 2003 или другими KDC-серверами;
_kpassword — идентифицирует серверы изменения паролей kerberos в сети;
_gc — запись, относящаяся к функции глобального каталога в Active Directory.
В поддомене _mcdcs регистрируются только контроллеры домена Microsoft Windows Server. Они делают и основные записи и записи в данном поддомене. Не-Microsoft-службы делают только основные записи.
Записи, содержащие идентификатор сайта SiteName, нужны для того чтобы клиент мог найти контроллер домена для авторизации в своём сайте, а не лез авторизовываться в другой город через медленные каналы.
DomainGuid — глобальный идентификатор домена. Запись, содержащщая его, нужна на случай переименования домена.
Как происходит процесс поиска DC
Во время входа пользователя, клиент инициирует DNS-локатор, при помощи удалённого вызова процедуры (Remote Procedure Call — RPC) службой NetLogon. В качестве исходных данных в процедуру передаются имя компьютера, название домена и сайта.
Служба посылает один или несколько запросов с помощью API функции DsGetDcName()
DNS сервер возвращает запрошенный список серверов, рассортированный согласно приоритету и весу. Затем клиент посылает LDAP запрос, используя UDP-порт 389 по каждому из адресов записи в том порядке, как они были возвращены.
Все доступные контроллеры доменов отвечают на этот запрос, сообщая о своей работоспособности.
После обнаружения контроллера домена, клиент устанавливает с ним соединение по LDAP для получения доступа к Active Directory. Как часть их диалога, контроллер домена определяет к в каком сайте размещается клиент, на основе его IP адреса. И если выясняется, что клиент обратился не к ближайшему DC, а, например, переехал недавно в другой сайт и по привычке запросил DC из старого (информация о сайте кэшируется на клиенте по результатам последнего успешного входа), контроллер высылает ему название его (клиента) нового сайта. Если клиент уже пытался найти контроллер в этом сайте, но безуспешно, он продолжает использовать найденный. Если нет, то инициируется новый DNS-запрос с указанием нового сайта.
Служба Netlogon кэширует информацию о местонахождении контроллера домена, чтобы не инициировать всю процедуру при каждой необходимости обращения к DC. Однако, если используется «неоптимальный» DC (расположенный в другом сайте), клиент очищает этот кэш через 15 минут и инициирует поиски заново (в попытке найти свой оптимальный контроллер).
Если у комьютера отсутствует в кэше информация о его сайте, он будет обращаться к любому контроллеру домена. Для того чтобы пресечь такое поведение, на DNS можно настроить NetMask Ordering. Тогда DNS выдаст список DC в таком порядке, чтобы контроллеры, расположенные в той же сети, что и клиент, были первыми.
Пример: Dnscmd /Config /LocalNetPriorityNetMask 0x0000003F укажет маску подсети 255.255.255.192 для приоритетных DC. По умолчанию используется маска 255.255.255.0 (0x000000FF)
Внимательный читатель найдет на этой картинке 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 (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:
Рассмотрим настройку на популярной офисной АТС Asterisk
При настройке собственного сервера очень большое внимание следует уделять безопасности. К сожалению, сегодня телефония является лакомым кусочком для взлома.
Считаем, что Asterisk уже установлен и настроен для обычных звонков.
Первым делом проверяем, включен ли и настроен брандмауэр на этом сервере. Пример конфигурации для iptables для Debian. Конфигурацию сохраняем в /etc/iptables.up. Загружаем с помощью iptables-restore.
Файл настроек /etc/iptables.up:
По необходимости дописываем правила для таблиц nat и mangle, если сервер используется в качестве шлюза в локальную сеть.
Делаем автозагрузку конфигурации. Для этого в файл /etc/network/interfaces после описания интерфейса добавляем строчку post-up iptables-restore < /etc/iptables.up:
Далее настраиваем fail2ban для анализа логов. Рекомендую включить модули SSH и Asterisk. Подробнее настройка описана здесь.
Определение записи DNS:
_Service._Proto.Name TTL Class SRV Priority Weight Port Target
Пример:
_sip._udp.domain.tld. IN SRV 20 0 5060 mysipproxy.domain.tld.
_stun._udp.domain.tld. IN SRV 20 0 3478 mystunserver.domain.tld.
Настройка DNS записей
Для звонков на SIP URI нужно рассказать звонящим вам, где искать сервер телефонии. Для этого используются NAPTR и SRV записи:
Подробнее по связи телефонии с DNS можно почитать в соответствующем стандарте.
Типичные ситуации
Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.
Редирект домена на www
Пример
Для использования SRV записей, Вам может понадобиться следующая информация:
Все эта информация должна располагаться в Вашем файле описания зоны в следующем порядке:
Например, Если Вы хотите указать, что SIP сервер Вашего домена находиться по адресу host.tld, то запись может быть такой:
_sip._udp SRV 0 5060 host.tld.
Как описано выше, _sip._udp - это тип сервиса IETF для SIP протокола через транспорт UDP. SRV - это тип записи в DNS, 0 - это приоритет записи, значения нагрузки мы не указали тут, а 5060 - это номер порта, по которому SIP сервер принимает запросы. host.tld = это имя хоста.
Вы можете тоже самое сделать и для протокола iax, например, так:
_iax._udp SRV 0 4569 host.tld.
И конечно, Вам нужна соответствующая запись для хоста host.tld типа "A" или "CNAME", для того, чтобы можно было определить его IP адрес, например, такая:
host.tld A xxx.xxx.xxx.xxx
По этой ссылке Вы можете найти исчерпывающую документацию, с очень подробно описанными примерами на сайте компании Cisco:
Пример, с использованием фиктивного домена
Ниже приведен простой файл с описанием зоны из RFC. Обратите внимание, что тип сервиса для SRV записей указанный тут, *не* для протокола SIP, вследствие этого, у Вас он будет другой:
В данном примере используется фиктивный сервис "foobar", работающий на порту 9,
для помощи в понимании механизма использования SRV записей.
- проверяет, существует ли SRV запись для заданного домена.
- Если SRV запись существует, используем их по кругу, пока один из них не ответит в течение заданного периода.
- Если SRV запись не существует, используется "стандартный" поиск адреса в DNS, для соединения с сервером.
$ORIGIN sipdomain.com.
@ SOA ns1.sipdomain.com. root.sipdomain.com. (
1995032001 3600 3600 604800 86400 )
NS ns1.sipdomain.com.
NS ns1.elsewhere.ca.
NS ns2.elsewhere.ca.
;
; Для сервиса sip, распределяем нагрузку, по принципу:
; 3 запроса - на сервер 3x-load, на каждый 1 запрос,
; отправляемый на сервер 1x-load.
_sip._udp SRV 0 1 5060 1x-load.sipdomain.com.
SRV 0 3 5060 3x-load.sipdomain.com.
;
; Если сервера с наивысшим приоритетом не отвечают,
; то переключаемся на использование этой группы,
; равномерно распределяя запросы к этим серверам
SRV 1 0 5060 failover1.sipdomain.com.
SRV 1 0 5060 failover2.sipdomain.com.
;
; Если все вышеописанные сервера не отвечают.
; используем SIP сервера другого провайдера:
SRV 2 0 5060 offsite-failover1.elsewhere.ca.
SRV 2 0 5060 offsite-failover2.elsewhere.ca.
;
; Вам необходимо определить записи "A" типа для каждого хоста,
; указанных в записях SRV
ns1 A 10.0.0.1
1x-load A 10.0.0.3
3x-load A 10.0.0.4
failover1 A 10.0.0.5
failover2 A 10.0.0.6
;
; описание "A" записей для двух последних серверов,
; описанных здесь в SRV записях, находится в зоне
; для домена elsewhere.ca
;
; Другие сервисы НЕ поддерживаются
*._tcp SRV 0 0 0 .
*._udp SRV 0 0 0 .
Метод 2. Просмотр Netlogon.dns
Если для поддержки Active Directory вы используете не microsoft DNS-серверы, можно проверить записи ресурсов локатора SRV, просмотрев Netlogon.dns. Netlogon.dns расположен в %systemroot%\System32\Config папке. Для просмотра этого файла можно использовать текстовый редактор, например Блокнот.
Первая запись в файле — запись SRV-протокола доступа к легкому каталогу контроллера домена (LDAP). Эта запись должна выглядеть так же, как и следующая:
Wildcards
Большинство DNS-серверов поддерживают шаблоны (wildcards). Например, есть wildcard CNAME для *.web01.bugsplat.info указывает на web01.bugsplat.info . Тогда любой хост на web01 будет указывать на web01.bugsplat.info и не нужно создавать новые записи:
Бесплатные звонки
Время, когда можно будет позвонить через Интернет любому человеку на его SIP URI номер, так же как и на обычный телефон — еще далеко, но уже сейчас можно получить явные преимущества.
Маркетинговая составляющая: Можно рекламировать свою компанию как максимально нацеленную на контакт с клиентом, и давать им различные способы связи с сотрудниками.
Можно совершать звонки на телефон бесплатно прямо с браузера через WebRTC с различных web сервисов — это возможность сэкономить на оплате счетов за телефон горячей линии 8 800. Многим вашим клиентам может быть удобно звонить сразу с компьютера в один клик через гарнитуру, а не набирать номер на мобильнике.
В большинстве случаев, звонки на SIP номера бесплатны для обеих сторон. И позволяют по полной использовать возможности современной телефонии, например видеосвязь. Можно проводить открытые конференции и семинары.
Заключение
Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:
Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.
Метод 1. Использование диспетчера DNS
После установки Active Directory на сервере, на который работает служба DNS, можно использовать консоль управления DNS для проверки создания соответствующих зон и записей ресурсов для каждой зоны DNS.
Active Directory создает свои записи SRV в следующих папках, где находится имя домена:
- Forward Lookup Zones/Domain_Name/_msdcs/dc/_sites/Default-First-Site-Name/_tcp
- Forward Lookup Zones/Domain_Name/_msdcs/dc/_tcp
В этих расположениях должна отображаться запись SRV для следующих служб:
CNAME для Heroku или Github
С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME . См. документацию.
Тестирование реализаций поддержки SRV записей для SIP клиентов:
SRV implementations: Результаты тестирования различных реализаций поддержки SRV записей
Настройка сервера Asterisk
Для начала, нужно разрешить звонки без авторизации и поместить их в отдельный контекст. Для этого в sip.conf:
Далее нужно создать этот контекст в файле extensions.conf:
Применяем конфигурацию sip reload и dialplan reload. В данном контексте мы логируем все неавторизованные вызовы. Далее происходит вызов локального абонента. Поменяйте default на ваш контекст с локальными пользователями. Прописываем сюда всех пользователей, для которых будем принимать неавторизованные звонки.
Особое внимание надо уделить этому диалплану — разрешать стоит только звонки локальным пользователям. Корректная настройка избавит вас от неприятных неожиданностей получить большой счет за телефонные звонки.
Так же следует помнить, что уязвимости могут быть найдены в любом программном обеспечении, например в реализации протокола SIP или даже SSH сервере. Поэтому, желательно устанавливать лимиты по балансу у вашего провайдера, чтобы избежать риска получения огромного счета.
Запросы к другим серверам
Давайте представим, что конфигурация DNS испорчена. Вам кажется, что вы исправили проблему, но не хотите ждать когда обновится кэш чтобы удостовериться. С помощью dig можно сделать запрос к публичному DNS-серверу вместо своего дефолтного, вот так:
Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2 .
Читайте также: