Запись srv автообнаружения не найдена в службе dns
Обновлено: 07.07.2024
Ошибка при динамической регистрации записи DNS "_ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.ываыа.ru. 600 IN SRV 0 100 389 rstserver.rstrd.ru." на следующем DNS-сервере.
IP-адрес DNS-сервера: 173.192.121.232
Возвращенный код ответа (RCODE): 5
Возвращенный код состояния: 9017
Чтобы компьютеры и пользователи могли определять местоположение этого контроллера домена, необходимо зарегистрировать запись в DNS.
Действие пользователя
Определите, что могло стать причиной ошибки, устраните ее и инициируйте регистрацию записей DNS контроллером домена. Для определения возможной причины ошибки запустите программу DCDiag.exe. Ее можно найти на установочном компакт-диске Windows Server 2003 в файле Support\Tools\support.cab. Дополнительные сведения о программе DCDiag.exe см. в Центре справки и поддержки. Чтобы инициировать регистрацию записей DNS данным контроллером домена, запустите процедуру "nltest.exe /dsregdns" в командной строке контроллера домена или перезапустите службу сетевого входа в систему. Программа Nltest.exe имеется на компакт-диске "Комплект ресурсов Microsoft Windows Server".
Можно также вручную добавить эту запись в DNS, но это не рекомендуется.
Дополнительные сведения
Значение с ошибкой: Неверный раздел DNS.
Дополнительные сведения можно найти в центре справки и поддержки, в "http://go.microsoft.com/fwlink/events.asp".
вот логи команды dcdiag /test:replications
Domain Controller Diagnosis
Performing initial setup:
Done gathering initial info.
Doing initial required tests
address (192.168.0.1) and was pingable. Check that the IP address is
registered correctly with the DNS server.
. RSTSERVER failed test Connectivity
Doing primary tests
Testing server: Default-First-Site-Name\RSTSERVER
Skipping all tests, because server RSTSERVER is
not responding to directory service requests
Running partition tests on : ForestDnsZones
Running partition tests on : DomainDnsZones
Running partition tests on : Schema
Running partition tests on : Configuration
Running partition tests on : rstrd
АД пашет, ДХСП стоит но не запущен,днс стоит и запущен >Чтобы инициировать регистрацию записей DNS данным контроллером домена, запустите процедуру "nltest.exe /dsregdns"(3) Попробовать не хочешь?
при запуске команды nltest.exe /dsregdns выводит следующее
Flags: 0
Connection Status = 0 0x0 NERR_Success
The command completed successfully
а какие действия выполняет эт команда?
мики, можешь мыло скинуть мне, я те туда отправлю лог файл, посмотри плз, может получится у нас починить все это? зону обратного просмотра не создавал, есть необходимость, создавать зону обратного просмотра?(15)Я только вечером буду в сети - уезжаю.
Логи сюда можешь выложить - может кто поможет
Начти с ipconfig /all
вот логи команды netdiag
Domain membership test . . . . . . : Passed
NetBT transports test. . . . . . . : Passed
List of NetBt transports currently configured:
NetBT_Tcpip_
1 NetBt transport currently configured.
Autonet address test . . . . . . . : Passed
IP loopback ping test. . . . . . . : Passed
Default gateway test . . . . . . . : Passed
NetBT name test. . . . . . . . . . : Passed
[WARNING] You don't have a single interface with the <00> 'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names defined.
Winsock test . . . . . . . . . . . : Passed
DNS test . . . . . . . . . . . . . : Failed
[WARNING] The DNS entries for this DC cannot be verified right now on DNS server 81.24.80.229, ERROR_TIMEOUT.
[WARNING] The DNS entries for this DC are not registered correctly on DNS server '81.24.83.2'. Please wait for 30 minutes for DNS server replication.
[WARNING] The DNS entries for this DC are not registered correctly on DNS server '192.168.0.1'. Please wait for 30 minutes for DNS server replication.
[FATAL] No DNS servers have the DNS records for this DC registered.
Redir and Browser test . . . . . . : Passed
List of NetBt transports currently bound to the Redir
NetBT_Tcpip_
The redir is bound to 1 NetBt transport.
List of NetBt transports currently bound to the browser
NetBT_Tcpip_
The browser is bound to 1 NetBt transport.
DC discovery test. . . . . . . . . : Passed
DC list test . . . . . . . . . . . : Passed
Trust relationship test. . . . . . : Skipped
Kerberos test. . . . . . . . . . . : Passed
LDAP test. . . . . . . . . . . . . : Passed
Bindings test. . . . . . . . . . . : Passed
WAN configuration test . . . . . . : Skipped
No active remote access connections.
Modem diagnostics test . . . . . . : Passed
dns сервера на которые он ругается
81.24.80.229
81.24.83.2
я вбил в настройках сетевой
ipconfig /all
.
.
.
.
.
.
.
DNS-серверы . . . . . . . . . . . : 81.24.80.229
Да даже если имя зарегено, всё равно первым должен быть локальный DNS, который при необходимости форвардит запросы к прову. И если имя зарегено, то оно должно резольвится со внешних серверов.
Что такое 81.24.83.2? Почему твой сервант хочет реплику с него? 81.24.x.x у тебя прописаны как NS?
А так он ожидает, что твои DNS (81.24.80.229 и 81.24.83.2) должны ему вернуть адрес DC, а они про него, по-ходу и слухом не слышали (если они вообще есть).
У тебя, вероятно, чужие записи в DNS. Хороший способ - снести роль DNS и поднять заново, зоны создать визардом, предварительно прочитав хоть какой-то мануал. Или спрашивать по ходу сетапа тут, как вариант.
ipconfig лучше бы выложил без купюр.
Настройка протокола IP для Windows
Имя компьютера . . . . . . . . . : rstserver
Тип узла. . . . . . . . . . . . . : гибридный
IP-маршрутизация включена . . . . : нет
WINS-прокси включен . . . . . . . : нет
lan - Ethernet адаптер:
DNS-суффикс этого подключения . . :
Описание . . . . . . . . . . . . : Realtek PCIe GBE Family Controller
Физический адрес. . . . . . . . . : 1C-6F-65-8A-83-93
DHCP включен. . . . . . . . . . . : нет
Маска подсети . . . . . . . . . . : 255.255.255.0
Основной шлюз . . . . . . . . . . : 192.168.0.174
Мики, я создал зону не правильно или вообще не нужно было зону создавать?(28)Зону надо создавать, если конечно не кэширующий DNS, но зачем такой на DC?
У тебя имена хостов и доменных служб пытаются резольвится на NS прова, что не будет работать (они ведь не согласяться обслуживать твою зону).
1. поставь первым (а лучше и единственным, если нет второго NS в домене) ip своего сервера. Если у него 192.168.0.1, то он и должен быть примари (127.0.0.1, как вариант).
2.
>>да днс 81.24.80.229 и 81.24.83.2
чужие провайдер то что выдавал, для инета :) должен же инет работать на серваке, обновления качать и итд, поэтому вписал
Так не делают. Для инета достачно шлюза по умолчанию, а имена он будет разрешать через DNS-форвардинг (обычно, через корневые ссылки обычнчо не делают. Для этого ищи вкладку что-то_типа "пересылка", там и пропиши DNS прова "для всех имен кроме домена rstrd.ru".
1. поставь первым (а лучше и единственным, если нет второго NS в домене) ip своего сервера. Если у него 192.168.0.1, то он и должен быть примари (127.0.0.1, как вариант).
что значит NS ? и где ставить этот ip
а статьи сегодня прочту обязательно
а если у меня один домен rstrd например и он включает 30+, тоже есть необходимость настраивать DNS?я вроде настроил все как написано в мануале, но эти ошибки при динамической регистрации записи DNS, не пропадают:(
кое где еще поковырялся, буду наблюдать
Есть еще вопрос Мики, бывает и такое, что если клиентская машина запущена, а сервер перегрузить, то клиенты при попытки доступа к шаре (одна клиентская машина пытается попасть на шару к др. клиентской машине) вылазит запрос на лог и пасс, это нормальная ситуация? Типа сервер должен быть запущен, а после рядовые машины загружаются? И если Сервер перегрузить на рядовой машине тоже нужно делать релог?
(35)если ты про домен AD, то да.
(36)тесты могут показывать ошибки давно пофиксенные, поэтому после fix'ов логи рекомендуется чистить.
Что за ошибки? Показывай и те, в журнале - по их id обычно можно найти решение в сети.
>>вылазит запрос на лог и пасс, это нормальная ситуация
да. Некому обработать запрос на полномочия.
>>Типа сервер должен быть запущен, а после рядовые машины загружаются?
>>на рядовой машине тоже нужно делать релог?
Обычно да. Или долго потерпеть.
проверь:
Для AD (DNS на DC)
- должны быть разрешены динамические обновления.
- зона должна быть интегрирована в AD.
- нет ли корневой зоны (".") в DNS.
и ещё:
работает ли, собственно, служба DNS на твоём DC?
нет ли записей об ошибках в журнале событий DNS?
фуу по-моему разобрался
выложу лог команды netdiag
Netcard queries test . . . . . . . : Passed
GetStats failed for 'Прямой параллельный порт'. [ERROR_NOT_SUPPORTED]
[WARNING] The net card 'Минипорт WAN (PPTP)' may not be working because it has not received any packets.
[WARNING] The net card 'Минипорт WAN (PPPoE)' may not be working because it has not received any packets.
[WARNING] The net card 'Минипорт WAN (IP)' may not be working because it has not received any packets.
GetStats failed for 'Минипорт WAN (L2TP)'. [ERROR_NOT_SUPPORTED]
Per interface results:
Netcard queries test . . . : Passed
Host Name. . . . . . . . . : rstserver
IP Address . . . . . . . . : 192.168.0.1
Subnet Mask. . . . . . . . : 255.255.255.0
Default Gateway. . . . . . : 192.168.0.174
Dns Servers. . . . . . . . : 192.168.0.1
AutoConfiguration results. . . . . . : Passed
Default gateway test . . . : Passed
NetBT name test. . . . . . : Passed
[WARNING] At least one of the <00> 'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names is missing.
WINS service test. . . . . : Skipped
There are no WINS servers configured for this interface.
Domain membership test . . . . . . : Passed
NetBT transports test. . . . . . . : Passed
List of NetBt transports currently configured:
NetBT_Tcpip_
1 NetBt transport currently configured.
Autonet address test . . . . . . . : Passed
IP loopback ping test. . . . . . . : Passed
Default gateway test . . . . . . . : Passed
NetBT name test. . . . . . . . . . : Passed
[WARNING] You don't have a single interface with the <00> 'WorkStation Service', <03> 'Messenger Service', <20> 'WINS' names defined.
Winsock test . . . . . . . . . . . : Passed
DNS test . . . . . . . . . . . . . : Passed
PASS - All the DNS entries for DC are registered on DNS server '192.168.0.1'.
Redir and Browser test . . . . . . : Passed
List of NetBt transports currently bound to the Redir
NetBT_Tcpip_
The redir is bound to 1 NetBt transport.
List of NetBt transports currently bound to the browser
NetBT_Tcpip_
The browser is bound to 1 NetBt transport.
DC discovery test. . . . . . . . . : Passed
DC list test . . . . . . . . . . . : Passed
Trust relationship test. . . . . . : Skipped
Kerberos test. . . . . . . . . . . : Passed
LDAP test. . . . . . . . . . . . . : Passed
Bindings test. . . . . . . . . . . : Passed
WAN configuration test . . . . . . : Skipped
No active remote access connections.
Modem diagnostics test . . . . . . : Passed
IP Security test . . . . . . . . . : Skipped
Note: run "netsh ipsec dynamic show /?" for more detailed information
The command completed successfully
вот еще логи команды dcdiag
Domain Controller Diagnosis
Performing initial setup:
Done gathering initial info.
Doing initial required tests
Testing server: Default-First-Site-Name\RSTSERVER
Starting test: Connectivity
. RSTSERVER passed test Connectivity
Doing primary tests
Testing server: Default-First-Site-Name\RSTSERVER
Starting test: Replications
. RSTSERVER passed test Replications
Starting test: NCSecDesc
. RSTSERVER passed test NCSecDesc
Starting test: NetLogons
. RSTSERVER passed test NetLogons
Starting test: Advertising
. RSTSERVER passed test Advertising
Starting test: KnowsOfRoleHolders
. RSTSERVER passed test KnowsOfRoleHolders
Starting test: RidManager
. RSTSERVER passed test RidManager
Starting test: MachineAccount
. RSTSERVER passed test MachineAccount
Starting test: Services
. RSTSERVER passed test Services
Starting test: ObjectsReplicated
. RSTSERVER passed test ObjectsReplicated
Starting test: frssysvol
. RSTSERVER passed test frssysvol
Starting test: frsevent
. RSTSERVER passed test frsevent
Starting test: kccevent
. RSTSERVER passed test kccevent
Starting test: systemlog
. RSTSERVER passed test systemlog
Starting test: VerifyReferences
. RSTSERVER passed test VerifyReferences
Running partition tests on : ForestDnsZones
Starting test: CrossRefValidation
. ForestDnsZones passed test CrossRefValidation
Starting test: CheckSDRefDom
. ForestDnsZones passed test CheckSDRefDom
Running partition tests on : DomainDnsZones
Starting test: CrossRefValidation
. DomainDnsZones passed test CrossRefValidation
Starting test: CheckSDRefDom
. DomainDnsZones passed test CheckSDRefDom
Running partition tests on : Schema
Starting test: CrossRefValidation
. Schema passed test CrossRefValidation
Starting test: CheckSDRefDom
. Schema passed test CheckSDRefDom
Running partition tests on : Configuration
Starting test: CrossRefValidation
. Configuration passed test CrossRefValidation
Starting test: CheckSDRefDom
. Configuration passed test CheckSDRefDom
Running partition tests on : rstrd
Starting test: CrossRefValidation
. rstrd passed test CrossRefValidation
Starting test: CheckSDRefDom
. rstrd passed test CheckSDRefDom
а что тут комментировать? passed он и в Африке passed :)
Лучше для остальных сообщи как и что исправлял.
Для полноты картины попробуй ввести клиента в домен,
проверь разрешение имен и в обратку разрешение ip-адресов, сначала можно ping'ом, а потом и nslookup'ом проверь резольвинг для хостов своего домена и внешних (для них проверь и через свой NS и через NS прова).
клиентов завел в домен норм, nslookup по ip дает имя сервера и обратно.
Проблема тока с днс провайдера, не знаю как добавить пересылку :(
а говоришь читал статьи.Зоны "." быть _не должно_. Уничтожь и пропиши форвардинг DNS.
Мдаа не внимательный я ----->
Мы применили этот прием при установке (см. выше) именно потому, что не имеем выхода в интернет. В противном случае, когда наша служба ДНС будет обращаться к инетернет-зоне, этот "." корень мы создавать не должны.
Точно, удалил корень и форвардинг заработал, спасибо Миша :)
Есть еще вопрос такой:
На рядовой машине подключенной к домену, при входе в систему, долго висит на . Применение личных параметров. Применение параметров пользователя, висит дольше чем при загрузке через локального пользователя (без домена)
Так и должно быть? Система каждый раз загружает параметры безопасности?
Контроллер домена отмечен как глобальный каталог в Sites & Services.
Этот DC работал нормально несколько лет. Затем пришлось переместить офис, в котором он находится. Зная, что он будет отключен от 3 до 6 недель или больше, я понизил уровень сервера. Казалось, все прошло нормально. Когда перемещение было завершено и сервер снова был в сети, я повторно продвинул его.
По ошибке я изначально добавил сервер не на тот сайт (в наш центр обработки данных). Но как только я понял это, я переместил его на правильный сайт (свой).
Приведенный выше dcdiag показывает, что SRV-запись отсутствует как для него самого, так и для его партнера по репликации в нашем центре обработки данных. Первоначально он сообщал только об отсутствии записи SRV у партнера по репликации.
Если BRANCHDC1 перезагружается или принудительная репликация, он воссоздает эту запись SRV на себе. Но он никогда не копируется на своего партнера по репликации (HQDC1) и, похоже, в конечном итоге будет удален из BRANCHDC1.
Выполнение dcdiag / fix проходит все тесты, кроме NCSecDesc. Но все наши контроллеры домена выходят из строя, и я уверен, что это можно игнорировать (mskb 967482).
Я запустил nltest / dsregdns.
Я пробовал registerdns, остановить / запустить netlogon. Я поменял местами DNS-серверы на сетевом адаптере BRANCHDC1 (указывающем на себя и HQDC1) и снова выполнил эти шаги.
Я проверил netlogon.dns на BRANCHDC1, и он выглядит правильно (по сравнению с другими DC). Никаких других записей SRV, которые я нашел до сих пор, не пропало нигде.
Я запустил инструмент AD Replication Status, который не обнаруживает ошибок при репликации и показывает, что BRANCHDC1 распознается как GC.
Насколько я могу судить, BRANCHDC1 настроен так же, как и все остальные контроллеры домена нашей ветви, включая его сетевой адаптер.
Я в тупике. Я не знаю, что попробовать дальше, кроме как выложить пачку денег на поддержку от MS.
Любая помощь будет принята с благодарностью.
- If BRANCHDC1 is rebooted, or replication forced, it will recreate that SRV record on itself. But that never gets copied over to its replication partner (HQDC1), and it appears that it will eventually get deleted from BRANCHDC1. Это сильно пахнет проблемами репликации .
- В любом случае, вы можете попробовать удалить флаг DC с сервера, а затем снова включить его? Или, что еще лучше, понижение и повторное продвижение сервера (после очистки любых ссылок на него из AD)?
- Понижение / повторное продвижение - это то, чего я надеялся отложить. Но я могу попробовать это завтра.
У Microsoft есть статья о перемещении контроллера домена на другой сайт, которую вы, вероятно, захотите подробно изучить. Убедитесь, что у вас настроены подсети, соединители сайтов и серверы-плацдармы. Похоже, что у ваших серверов все еще есть разные представления о том, какой должна быть топология репликации, и они не находятся на одной странице.
Разберем процесс создания инфраструктуры для автоматической настройки почтовых клиентов. Для корректной работы Autodiscover нужен комплексный подход, так как у разных почтовых клиентов свои требования.
1. Microsoft Outlook
С DNS все просто — создаем А- (или CNAME-) и SRV-записи. Пример таких записей в bind:
autodiscover IN A 111.111.111.111
* где 111.111.111.111 — IP-адрес на наш веб-сервер, который будет возвращать документ XML.
Веб-сервер
В качестве примера, настройку выполним на веб-сервере NGINX, который работает на Linux. Если он не установлен, выполняем инсталляцию.
а) если сервер под CentOS / Red Hat:
yum install epel-release
yum install nginx
б) если сервер под Debian / Ubuntu:
apt-get install nginx
После разрешаем автозапуск и стартуем сервис:
systemctl enable nginx
systemctl start nginx
Затем создаем виртуальный домен:
error_page 405 =200 $uri;
>
Проверяем корректность настройки:
Если ошибок нет, перечитываем конфиг:
systemctl reload nginx
Создаем каталог, в котором будет наш XML:
mkdir -p /usr/share/nginx/html/autodiscover/autodiscover
Создадим сам XML:
* где из основных параметров на нужны:
- Type — тип протокола, используя который мы будем подключаться к почтовой системе.
- Server — сервер для подключения. Для каждого типа протокола может быть задан свой сервер или один и тот же.
- Port — порт, на котором слушает сервис. Как правило, для
- IMAP: 143, 993.
- POP: 110, 995.
- SMTP: 25, 465, 587.
Все адреса
Наш файл конфигурации рассчитан только на настройку одного адреса. Теперь нужно настроить его на обслуживание любого email. Для этого необходимо написать скрипт, например, на php и немного донастроить сервер.
PHP и php-fpm
Установим php и php-fpm, после разрешаем автозапуск php-fpm и стартуем его:
а) если сервер под CentOS / Red Hat:
yum install php php-fpm
systemctl enable php-fpm
systemctl start php-fpm
б) если сервер под Debian / Ubuntu:
apt-get install php php-fpm
systemctl enable php7.2-fpm
systemctl start php7.2-fpm
* где 7.2 — версия установленной php (проверяется командой php -v).
Настроим php-fpm
а) если сервер под CentOS / Red Hat:
systemctl restart php-fpm
б) если сервер под Debian / Ubuntu:
systemctl restart php7.2-fpm
NGINX
Внесем настройки в наш виртуальный домен:
.
error_page 405 =200 $uri;\.php$ set $root_path /usr/share/nginx/html/autodiscover;
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME $root_path$fastcgi_script_name;
include fastcgi_params;
fastcgi_param DOCUMENT_ROOT $root_path;
>
.* мы добавили обработку скриптов php с помощью php-fpm.
Перезапускаем наш сервер:
systemctl reload nginx
Готовим скрипт
Создадим скрипт php:
<?php
//get raw POST data so we can extract the email address
$data = file_get_contents("php://input");
preg_match("/\<EMailAddress\>(.*?)\<\/EMailAddress\>/", $data, $matches);Переадресация с xml на php
Теперь настроим, чтобы наш веб-сервер переводил запросы xml на наш скрипт php. Открываем настройку нашего виртуального домена:
.
location = /autodiscover/autodiscover.xml rewrite ^/autodiscover/autodiscover.xml$ /autodiscover/autodiscover.php;
>
.systemctl reload nginx
Теперь можно открывать Outlook и проверять автонастройку для других почтовых ящиков.
2. Mozilla Thunderbird
Также, как с Outlook, необходимо настроить DNS и веб-сервер.
создаем А-запись (или CNAME). Пример в bind:
autoconfig IN A 111.111.111.111
* где 111.111.111.111 — IP-адрес на наш веб-сервер, который будет возвращать документ XML.
Веб-сервер
Настраивая autodiscovery для Microsoft, мы уже настроили веб-сервер NGINX. Теперь нужно добавить виртуальный домен и создать соответствующий документ.
Откроем уже созданный нами файл конфигурации:
. и добавим в него:
Создаем каталог для хранения XML:
mkdir -p /usr/share/nginx/html/autodiscover/mail
- hostname — имя сервера для подключения. Для каждого типа протокола может быть задан свой сервер или один и тот же.
- port — порт, на котором слушает сервис. Как правило, для
- IMAP: 143, 993.
- POP: 110, 995.
- SMTP: 25, 465, 587.
- plain — без шифрования.
- SSL — SSL или TLS шифрование на отдельном порту (465, 993, 995).
- STARTTLS — TLS шифрование через STARTTLS на обычном порту.
3. DNS SRV
Это метод, призванный быть универсальным. Более того, он описан стандартом RFC.
Суть заключается в создании SRV-записей в DNS. Данная запись создается по следующему синтаксису:
- <имя службы> — имя сервиса (например, imap).
- <протокол> — сетевой протокол (TCP, UDP, TLS).
- <приоритет> — порядок, в котором идет учет строки.
- <вес> — если приоритеты совпадают у служб, порядок определяется по их весу.
- <порт> — порт, на котором слушает служба.
- <хост> — имя сервера, на который будет вести запись.
Пример записей для настройки почты:
* в данном примере мы отдаем приоритет более защищенным средствам подключения (smtps, imaps, pop3s).
Подробнее в пункте 11.2 RFC 3921 и пунктах 14.3 и 14.4 RFC 3920.
SSL-сертификаты
Вы можете сказать «мы люди честные, нам шифровать нечего», но это не совсем так. Вспомните GMail — они принудительно используют шифрование при работе с почтой через IMAP или POP3. Вполне возможно, что при полном отсутствии какого-либо SSL-сертификата соединение между вашим сервером и GTalk не будет установлено. Также год назад XMPP-консулом была озвучена идея Trusted Federation, т.е. запрета незашифрованных соединений между серверами. Из всего этого следует, что SSL использовать стоит.
Пункт 14.2 RFC 3920 разрешает использование любых сертификатов, в том числе и самоподписанных сертификатов, которые зачастую устанавливаются по-умолчанию. Но также этот пункт гласит о том, что в случае самоподписанного сертификата клиент ОБЯЗАН выдать пользователю предупреждение о недостоверном сертификате — это, конечно же, верно с точки зрения безопасности, но пользователю радости не доставит. Итак, следовательно, стоит получить «нормальный» сертификат.
Если у вас нет собственного CA , которому доверяют все ваши пользователи или вы не желаете тратить несколько сотен долларов на приобретение SSL-сертификата у одного из известных CA, то можно воспользоваться ICA XMPP Foundation, получение SSL-сертификата для вашего jabber-сервера в данном случае бесплатно. Более того, заметное число популярных jabber-клиентов «доверяет» сертификатам, выданным XMPP ICA.
Заблуждения о транспортах
Основное заблуждение пользователей о транспортах звучит так:нужно зарегистрироваться на сервере, где много транспортов.
Это заблуждение, предположительно, культивируется тем, что большинство администраторов jabber-серверов либо запрещают доступ к своим транспортам с других серверов, либо просто забывают прописать соответствующие A и SRV citation needed! [2] DNS-записи для своих транспортов и, таким образом, пользователи других сервером не имеют технической возможности использовать их.
P.S. кстати, jabber 4го января исполнилось 10 лет :-)
[1] Да, MX записи не обязательны. RFC 5321 это утверждает.
[2] Я не уверен, что для транспортов требуется прописывать SRV-записи. По логике — требуется, но нигде упоминания об этом я не встречал.Читайте также: