Інструменти мережевої діагностики
Повний звіт про делегування та стан DNS
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Перевірка стану DNS досліджує, як домен делегується та налаштовується від початку до кінця, а не лише один тип запису. Вона запитує батьківські (TLD) сервери, що вони публікують для вашого домену, потім напряму звертається до ваших власних серверів імен і порівнює обидва результати. Розбіжності між батьківським і вашими серверами — відсутній glue, неузгоджені списки NS, розсинхронізовані серійні номери SOA, lame-сервери або сервери з відкритою рекурсією — це саме ті проблеми, що спричиняють повільну, періодичну або непомітно зламану роботу DNS. IPeek виконує кожну перевірку й простими словами пояснює, чому кожна з них важлива та як її виправити.
Кожен пошук вашого домену починається з батьківської зони — реєстру TLD (наприклад, .es чи .com), — яка містить записи NS, що спрямовують резолвери до ваших серверів імен. Якщо ці сервери імен розташовані всередині вашого власного домену, батьківський рівень має також публікувати їхні IP-адреси як «glue», інакше резолвери потрапляють у замкнене коло «курка чи яйце». При здоровому делегуванні батьківський і ваші власні сервери узгоджені щодо одного набору NS, а glue присутній там, де потрібно. Коли вони не збігаються, частина резолверів використовує застарілу інформацію, і ваші зміни нібито працюють для одних користувачів, але не для інших.
RFC 2182 рекомендує мати кілька серверів імен у різних мережах, щоб один збій ніколи не виводив ваш домен з ладу. Кожен із них має відповідати авторитетно для вашої зони — «lame»-сервер, який цього не робить, є прихованою прогалиною в надійності. Ваші авторитетні сервери також мають відмовляти в рекурсії стороннім: відкритий рекурсивний сервер імен можуть використати для отруєння кешу та DDoS-ампліфікації. IPeek напряму опитує кожен ваш сервер імен, щоб переконатися, що він відповідає, дає авторитетні відповіді, узгоджений з іншими, підтримує TCP і тримає рекурсію закритою.
Запис SOA містить серійний номер вашої зони та значення таймерів; кожен сервер імен має повідомляти однаковий серійний номер, інакше ваша зона розсинхронізована і зміни поширюються нерівномірно. Серійний номер має відповідати конвенції YYYYMMDDnn, а таймери refresh/retry/expire/minimum мають перебувати в межах, рекомендованих RFC. На поштовому боці записи MX мають бути іменами хостів (ніколи не «голими» IP чи CNAME), які розв’язуються в публічні адреси. Нарешті, apex (ваш кореневий домен) має публікувати адресу, але не CNAME, який RFC 1912 забороняє поряд з іншими записами.
Пошук DNS показує записи такими, якими їх бачить рекурсивний резолвер. Перевірка стану йде далі: вона напряму опитує батьківські сервери TLD і кожен ваш власний сервер імен, а потім порівнює їх. Це дозволяє виявити проблеми делегування, які приховує звичайний пошук, — відсутній glue, розбіжності NS між батьківським і дочірнім рівнями, lame-сервери чи неузгоджені сервери імен і розсинхронізовані серійні номери SOA.
Glue — це IP-адреса сервера імен, яку батьківська зона публікує поряд із записом NS. Вона потрібна, коли ваші сервери імен розташовані в тому самому домені, який вони обслуговують (наприклад, ns1.example.com обслуговує example.com), бо інакше резолверам довелося б спочатку розв’язати сам сервер імен, перш ніж розв’язувати будь-що інше. Відсутній glue у такому разі ламає розв’язання; якщо ваші сервери імен розташовані в іншому домені, glue необов’язковий і лише економить один додатковий запит.
Авторитетні сервери імен мають відповідати лише за зони, які вони обслуговують. Сервер імен, що виконує рекурсію для будь-кого («відкритий резолвер»), можуть використати для DDoS-атак з ампліфікацією DNS, і він більш вразливий до отруєння кешу. Якщо перевірка стану позначає відкриту рекурсію, вимкніть рекурсію на авторитетному сервері або розділіть авторитетну і рекурсивну ролі між різними хостами.
Серійний номер SOA — це номер версії вашої зони. Коли ваші сервери імен повідомляють різні серійні номери, принаймні один обслуговує застарілі дані — зазвичай це вторинний сервер, якому не вдалося перенести найновішу зону з первинного. Як наслідок — суперечливі відповіді залежно від того, на який сервер потрапить резолвер. Перевірте передачі зони (AXFR/IXFR), налаштування NOTIFY на первинному сервері і таймер refresh у SOA.
Ні те, ні інше не є помилкою, але обидва — це єдині точки відмови. З одним MX пошту можна втратити, якщо цей сервер достатньо довго недоступний; резервний MX додає стійкості. Два сервери імен прийнятні згідно з RFC 2182, але три чи більше в різних мережах безпечніше. Перевірка стану позначає це як попередження, а не збої — їх варто покращити, але це не екстрена ситуація.