Інструменти мережевої діагностики
Записи розташування сервісів
DNS та записи
Пошук DNS Усі записи DNS для будь-якого домену Пошук запису A IPv4-адреси домену Пошук запису AAAA IPv6-адреси домену Пошук MX Поштові сервери домену Пошук NS Авторитетні сервери імен Пошук TXT Записи TXT, SPF, верифікація Пошук CNAME Записи канонічного імені (псевдонім) Пошук SOA Запис Start of Authority Пошук SRV Записи розташування сервісів Пошук CAA Які CA можуть видавати сертифікати Зворотний DNS (PTR) IP-адреса до імені хоста Перевірка DNSSEC Чи підписаний і валідований домен? Перевірка стану DNS Повний звіт про делегування та стан DNSДоставлюваність пошти
Перевірка SPF Перевірте свій запис Sender Policy Framework Перевірка DMARC Перевірте та оцініть свою політику DMARC Перевірка DKIM Знайдіть і перевірте свій відкритий ключ DKIM Перевірка чорних списків Перевірте IP за поштовими чорними списками (DNSBL) Тест SMTP Підключіться до поштового сервера та перевірте STARTTLS Перевірка MTA-STS Примусова політика TLS для вхідної пошти Перевірка BIMI Запис логотипа бренду для пошти Перевірка TLS-RPT Політика звітності SMTP TLSМережа та веб
Перевірка SSL-сертифіката Перевірте TLS-сертифікат сайту та термін дії Перевірка заголовків HTTP Перевірте заголовки відповіді, перенаправлення та безпеку Ping (TCP) Доступність і затримка через TCP Перевірка портів Які поширені порти відкритіДомен
Пошук WHOIS Реєстраційні дані для доменів, IP та ASNЗапис SRV (Service) оголошує ім’я хоста й порт для конкретного сервісу — як-от SIP, XMPP, LDAP чи Microsoft autodiscover — разом із пріоритетом і вагою для балансування навантаження. На відміну від запису A, він каже клієнтам не лише, де живе сервіс, а й на якому порту, тож застосунки можуть знаходити сервіси без жорстко прописаної конфігурації. Запитуйте їх у формі _service._proto.domain.
Запис SRV іменується за характерним шаблоном: _service._proto.domain, наприклад _sip._tcp.example.com. Підкреслення запобігають зіткненню зі звичайними іменами хостів. Дані запису містять чотири значення: priority, weight, port і target. Priority працює як MX — менші числа пробуються першими. Weight розподіляє навантаження між цілями з однаковим пріоритетом, де вищі ваги отримують пропорційно більше трафіку. Port — це TCP- чи UDP-порт, який слухає сервіс, а target — ім’я хоста, що його надає, яке має мати власний запис A чи AAAA.
IPeek повертає priority, weight, port і цільовий хост кожного запису SRV для запитаного імені сервісу. Читайте priority першим: клієнти використовують цілі з найнижчим пріоритетом перед переходом до вищих. Серед однакових пріоритетів weight вирішує частку трафіку, яку отримує кожна ціль. Підтвердьте, що порт відповідає очікуваному сервісу — 5060 для SIP, 389 для LDAP, 443 для багатьох налаштувань autodiscover. Перевірте, що кожна ціль резолвиться в чинний хост. Порожній результат означає, що сервіс не оголошено під цим іменем на домені.
Записи SRV важливі щоразу, коли клієнти мають автоматично виявляти сервіс, а не покладатися на фіксовані налаштування. Microsoft Teams, Skype for Business і SIP-провайдери використовують їх, щоб знаходити сервери голосу й присутності. XMPP-чат, запити до каталогів LDAP, сервери Minecraft і Kerberos усі залежать від виявлення через SRV. Велика перевага — гнучкість: перенесіть сервіс на новий хост чи порт або розподіліть його між кількома серверами, і клієнти йдуть за записами SRV без переналаштування. Якщо сервіс вимагає конкретного імені _service._proto, опублікуйте відповідний запис SRV, інакше клієнти його не знайдуть.
Цей шаблон іменує запис SRV за сервісом і протоколом, які він описує. _service — це мітка сервісу (як-от _sip чи _ldap), _proto — це транспорт (_tcp чи _udp), а domain — ваш домен. Наприклад, _sip._tcp.example.com оголошує SIP через TCP. Початкові підкреслення не дають цим міткам зіткнутися зі звичайними іменами хостів.
Priority і weight контролюють, яку ціль обирає клієнт. Priority працює як записи MX: клієнти спершу пробують цілі з найнижчим пріоритетом і переходять до вищих чисел. Серед цілей з однаковим пріоритетом weight задає частку трафіку, яку отримує кожна, тож вища вага притягує більше з’єднань. Разом вони забезпечують і відмовостійкість, і балансування навантаження.
Запис A зіставляє ім’я хоста з IP-адресою, тоді як запис SRV додатково вказує порт і додає priority й weight для іменованого сервісу. SRV дозволяє клієнтам виявити і де, і на якому порту працює сервіс, а також як балансувати навантаження, чого простий запис A виразити не може. Цілі SRV усе одно покладаються на записи A для резолвінгу.
SIP- та VoIP-системи, XMPP-чат, LDAP та Active Directory, Kerberos, Microsoft Teams і Skype for Business, ба навіть сервери Minecraft зазвичай використовують записи SRV. Будь-який протокол, що виграє від автоматичного виявлення сервісів без жорстко прописаних налаштувань хоста й порту, є кандидатом. Клієнт має бути написаний так, щоб запитувати відповідне ім’я _service._proto.
Порожній результат SRV зазвичай означає, що під цим точним іменем _service._proto.domain не опубліковано жодного запису. Перевірте, що мітку сервісу, протокол і домен написано правильно, включно з підкресленнями. Сервіс може використовувати інше ім’я, ніж очікувалося, або запису може просто не існувати. Підтвердьте точне ім’я, яке вимагає клієнтський застосунок.