Приклади:
- правильний сертифікат не допоможе, якщо запис
Aведе до старого сервера, - коректний запис
Aне буде достатнім, якщоAAAAспрямовує трафік IPv6 на непрацюючу машину, - автоматичне поновлення сертифіката не спрацює, якщо запис
_acme-challengeне може бути створений або порт 80 заблокований, - DNSSEC може підвищити довіру до відповідей DNS, але хибний запис
DSможе спричинитиSERVFAILдля всього домену, - короткий TTL не виправить неправильної делегації серверів імен,
- сертифікат wildcard не охоплює головного домену ані багаторівневих субдоменів, якщо їх не було вписано окремо.
У 2026 році обслуговування сертифікатів має бути повністю автоматичним. Від 15 березня 2026 року публічні сертифікати TLS типу Subscriber Certificate можуть мати щонайбільше 200 днів чинності. Ліміт знизиться до 100 днів у березні 2027 року та до 47 днів у березні 2029 року. Let's Encrypt і надалі за замовчуванням видає 90-денні сертифікати, але надає також коротші профілі, а від травня 2026 року профіль tlsserver видає 45-денні сертифікати для користувачів, які свідомо його оберуть.
TL;DR: підтримуйте щонайменше два незалежно доступні авторитетні сервери DNS, контролюйте записи
AтаAAAA, впроваджуйте DNSSEC лише з безпечним процесом обслуговуванняDS, обмежуйте центри сертифікації через CAA, використовуйте TLS 1.3 з TLS 1.2 як сумісним мінімумом, автоматизуйте видачу та поновлення сертифікатів через ACME, а також відстежуйте дату чинності, ланцюжок сертифікатів, SNI, HSTS і помилки перевірки з багатьох локацій.
Інформацію та вимоги перевірено 23 липня 2026 року.
DNS, SSL і TLS в одній таблиці
| Рівень | Відповідає за | Найважливіші елементи | Типові збої |
|---|---|---|---|
| Реєстратор домену | власність домену та делегування | сервери імен, блокування трансферу, DS | захоплення облікового запису, неправильне делегування, старий DS |
| Авторитетний DNS | справжні записи зони | A, AAAA, CNAME, MX, TXT, CAA, NS, SOA, DNSSEC | неправильна адреса, відсутній запис, split-brain, неправильний підпис |
| Рекурсивний резолвер | пошук та кешування відповіді | TTL, кеш, перевірка DNSSEC, DoH/DoT | застарілі дані в кеші, хибна перевірка |
| TCP/QUIC і TLS | безпечний канал до сервера | TLS 1.2/1.3, SNI, ALPN, сертифікат | слабкий протокол, неправильний ланцюжок, невідповідність імені хоста |
| Сертифікат | підтвердження ідентичності імені | SAN, issuer, чинність, ключ, підпис | закінчення терміну, відсутнє ім'я, неправильний intermediate |
| HTTP | перенаправлення та політика HTTPS | 301/308, HSTS, заголовки безпеки | redirect loop, mixed content, відсутній HSTS |
Як насправді працює розв'язання домену?
DNS є ієрархічною та розподіленою системою імен. Резолвер не отримує всієї відповіді з одного центрального сервера. Спрощено:
- браузер і система перевіряють локальний кеш,
- рекурсивний резолвер запитує кореневі сервери,
- корінь вказує на сервери відповідного домену найвищого рівня, наприклад
.pl, - сервер TLD вказує на авторитетні сервери домену,
- авторитетний сервер повертає запис, наприклад
A,AAAAабоCNAME, - відповідь зберігається відповідно до TTL.
użytkownik
↓
lokalny cache
↓
rekurencyjny resolver
↓
root → TLD → autorytatywny DNS
↓
A / AAAA / CNAME / HTTPS
↓
połączenie TLS z serwerem
DNS не гарантує, що вказаний сервер справний, ані що відповідь HTTP буде правильною. Він повертає дані, записані в зоні. Тому моніторинг DNS слід поєднувати з тестами TCP, TLS і HTTP.
1. Найважливіші записи DNS
A і AAAA
example.com. 300 IN A 192.0.2.10
example.com. 300 IN AAAA 2001:db8::10
Aвказує на адресу IPv4,AAAAвказує на адресу IPv6.
Запис AAAA не є доповненням без наслідків. Якщо він існує, клієнти з підтримкою IPv6 можуть намагатися з'єднатися саме з ним. Не публікуйте AAAA, доки міжмережевий екран, маршрутизація, вебсервер, сертифікат і challenge ACME не працюють правильно через IPv6.
Let's Encrypt під час перевірки http-01 надає перевагу IPv6, коли домен має запис AAAA. Хибний IPv6 може призвести до невдалої видачі або поновлення сертифіката навіть тоді, коли IPv4 правильний.
CNAME
www.example.com. 300 IN CNAME app.hosting.example.
CNAME створює псевдонім (alias) до іншого імені DNS. Ім'я з CNAME не повинно одночасно мати інших звичайних даних, таких як A, AAAA чи MX, оскільки CNAME вказує, що належні дані містяться під іншим іменем.
На апексі зони, тобто example.com, класичний CNAME конфліктує з обов'язковими записами SOA і NS. Провайдери обходять це через власні механізми ALIAS, ANAME або flattening, але це не звичайні записи CNAME, що передаються в зоні.
NS і SOA
example.com. 86400 IN NS ns1.dns-provider.example.
example.com. 86400 IN NS ns2.dns-provider.example.
NS визначає авторитетні сервери імен. Делегування в реєстратора та записи NS всередині зони мають бути узгодженими.
SOA містить адміністративні дані зони, зокрема серійний номер і параметри, що використовуються вторинними серверами. За ручного обслуговування зони серійний номер має зростати після змін.
Гарна операційна практика - це щонайменше два авторитетні сервери, що працюють в окремих мережах або локаціях. ICANN рекомендує кілька окремих авторитетних серверів, найкраще розділених географічно й топологічно.
MX
example.com. 3600 IN MX 10 mail1.example.net.
example.com. 3600 IN MX 20 mail2.example.net.
Менше число означає вищий пріоритет. Метою запису MX має бути ім'я хоста, а не IP-адреса чи CNAME.
Зміна вебхостингу не повинна автоматично змінювати пошту. Перед міграцією DNS збережіть записи MX, SPF, DKIM і DMARC.
TXT
TXT є текстовим контейнером, який використовують, зокрема:
- SPF,
- DKIM,
- DMARC,
- перевірку власності домену,
- ACME
dns-01, - інтеграції SaaS.
example.com. 300 IN TXT "v=spf1 include:_spf.example.net -all"
_acme-challenge.example.com. 60 IN TXT "TOKEN"
Кілька записів TXT під одним іменем можуть бути коректними, але декілька конкурентних записів SPF, що починаються з v=spf1, є проєктною помилкою.
CAA
CAA дозволяє власнику домену вказати, які центри сертифікації можуть видавати сертифікати для домену.
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
example.com. 3600 IN CAA 0 iodef "mailto:[email protected]"
issueстосується звичайних сертифікатів,issuewildстосується wildcard,iodefвказує канал звітування про порушення політики.
CAA не замінює контролю облікового запису в реєстратора, DNSSEC ані моніторингу Certificate Transparency. Це додаткове обмеження для публічних CA. Відсутність CAA зазвичай означає, що будь-який публічно довірений CA може видати сертифікат після правильної перевірки домену.
PTR
PTR реалізує reverse DNS, тобто зіставлення IP-адреси з іменем. Запис встановлює власник діапазону IP, зазвичай провайдер VPS або хостингу. Він особливо важливий для поштових серверів.
192.0.2.10 → mail.example.com
Для пошти ім'я PTR зазвичай має вести назад через A або AAAA до тієї самої адреси.
HTTPS і SVCB
Записи HTTPS і SVCB можуть передавати клієнту інформацію про спосіб з'єднання з сервісом, альтернативні endpoint-и, підтримувані протоколи та параметри, потрібні перед встановленням з'єднання.
Концептуальний приклад:
example.com. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint="192.0.2.10"
Не слід вписувати ipv4hint або ipv6hint як заміну правильних адресних записів без розуміння поведінки клієнтів. HTTPS RR є механізмом оптимізації та сигналізації, а не виправленням хибного DNS чи TLS.
2. TTL і «поширення DNS»
TTL визначає, як довго резолвер може зберігати відповідь у кеші. Не існує єдиного глобального годинника поширення. Після зміни:
- частина резолверів усе ще має стару відповідь,
- частина одразу запитає сервер,
- негативні відповіді, такі як
NXDOMAIN, також можуть кешуватися, - локальна система, браузер, оператор і застосунок можуть мати окремі кеші.
Розумні значення TTL
| Ситуація | Типове значення |
|---|---|
| стабільний продакшн-запис | 3600-86400 с |
| підготовка міграції | 300-600 с |
| запис ACME DNS-01 | 30-300 с, якщо провайдер дозволяє |
| запис NS або SOA | зазвичай довший |
| аварійне перемикання | низький TTL допомагає лише після закінчення попереднього кешу |
Перед міграцією зменшіть TTL щонайменше за один старий період TTL заздалегідь. Зниження TTL за п'ять хвилин до зміни не видаляє відповідей, які резолвер уже зберіг на 24 години.
Після завершення міграції підніміть TTL, щоб зменшити кількість запитів і залежність від тимчасових проблем авторитетного DNS.
3. DNSSEC: цілісність відповіді, а не шифрування
DNSSEC додає автентифікацію походження даних DNS та захист цілісності за допомогою цифрових підписів. Він не шифрує запитів і не приховує імен доменів від мережевого провайдера чи резолвера.
Ланцюжок довіри використовує, зокрема:
DNSKEY- публічні ключі зони,RRSIG- підписи наборів записів,DS- відбиток ключа, записаний у батьківській зоні,NSECабоNSEC3- криптографічне підтвердження неіснування імені або типу.
root
↓ podpisana delegacja
TLD
↓ rekord DS
example.com
↓ DNSKEY + RRSIG
rekord A / AAAA / MX / CAA
RFC 9364 визначає використання DNSSEC для автентифікації походження даних DNS як актуальну гарну практику.
Найбільший ризик DNSSEC
Найчастішою проблемою є не відсутність DNSSEC, а хибний ланцюжок DNSSEC. Якщо в реєстратора залишиться запис DS, що вказує на старий ключ, а новий оператор DNS підписує зону іншим ключем, резолвери, які виконують перевірку, повернуть SERVFAIL.
Безпечна міграція DNSSEC вимагає:
- перевірки, хто підписує зону,
- визначення методу трансферу або rollover ключів,
- публікації належного
DSу батьківському домені, - очікування TTL записів DNSKEY і DS,
- лише потім видалення старих ключів або старої зони,
- тестування через резолвери, що виконують перевірку.
Не вмикайте DNSSEC, якщо провайдер не забезпечує чіткого процесу обслуговування DS і ротації ключів.
4. DNSSEC проти DoH і DoT
Ці механізми вирішують різні проблеми:
| Механізм | Захищає | Не забезпечує |
|---|---|---|
| DNSSEC | автентичність і цілісність даних DNS | конфіденційності запиту |
| DNS over TLS | шифрування між клієнтом і резолвером через TLS, зазвичай порт 853 | автентичності даних без перевірки DNSSEC |
| DNS over HTTPS | шифрування DNS у HTTPS | автентичності даних без DNSSEC |
| звичайний DNS | базове розв'язання імен | конфіденційності та криптографічної цілісності |
DNS over TLS описує RFC 7858, а DNS over HTTPS - RFC 8484. Шифрований транспорт захищає запит від простого прослуховування на відрізку клієнт-резолвер, але оператор резолвера все одно бачить запити, а подальше розв'язання залежить від його політики.
5. SSL проти TLS: правильна термінологія
«Сертифікат SSL» досі є поширеним маркетинговим терміном, але сучасні сайти використовують TLS. SSL 2.0 і SSL 3.0 застаріли, а TLS 1.0 і 1.1 було офіційно виведено з ужитку IETF.
У 2026 році:
- TLS 1.3 має бути пріоритетним,
- TLS 1.2 залишається сумісним мінімумом для старіших, досі підтримуваних клієнтів,
- TLS 1.0, TLS 1.1, SSLv2 і SSLv3 мають бути вимкнені,
- конфігурація TLS 1.2 має використовувати сучасні набори з AEAD і forward secrecy,
- сервер не повинен пропонувати застарілих алгоритмів і обмінів ключів.
RFC 9325 містить актуальні рекомендації щодо безпечного використання TLS і замінив попередній BCP 195.
6. Що браузер перевіряє в сертифікаті?
Під час з'єднання TLS клієнт перевіряє, зокрема:
- чи сертифікат перебуває в періоді чинності,
- чи ім'я хоста присутнє в
subjectAltName, - чи підпис веде через правильний проміжний ланцюжок до довіреного root CA,
- чи сертифікат не використовується для невідповідної мети,
- чи параметри з'єднання прийнятні,
- чи політики браузера не відхиляють сертифіката.
Ідентичність сервера нині перевіряється на основі SAN, а не поля Common Name як основного джерела імені.
SAN
Один сертифікат може охоплювати кілька імен:
example.com
www.example.com
api.example.com
Кожне ім'я має бути в SAN.
Wildcard
*.example.com
охоплює:
www.example.com
api.example.com
shop.example.com
але не охоплює автоматично:
example.com
www.eu.example.com
Головний домен слід додати окремо, а wildcard працює лише для одного рівня мітки.
SNI
Server Name Indication дозволяє клієнту передати ім'я хоста під час handshake, завдяки чому одна IP-адреса може обслуговувати кілька сертифікатів. Хибна конфігурація SNI часто спричиняє показ сертифіката іншого домену.
Ланцюжок сертифікатів
Сервер має надсилати сертифікат домену та потрібні проміжні сертифікати, але зазвичай не root. Відсутність intermediate може працювати на одному пристрої, який раніше зберіг сертифікат, і зазнавати збою на іншому.
7. Чинність сертифікатів у 2026 році
CA/Browser Forum ухвалив графік скорочення публічних сертифікатів TLS:
| Дата видачі | Максимальна чинність |
|---|---|
| до 15 березня 2026 | 398 днів |
| 15 березня 2026 - 14 березня 2027 | 200 днів |
| 15 березня 2027 - 14 березня 2029 | 100 днів |
| від 15 березня 2029 | 47 днів |
Це не означає, що кожен CA видає сертифікат на максимальний період. Let's Encrypt за замовчуванням і надалі видає 90-денні сертифікати, має опціональні шестиденні сертифікати та профіль tlsserver з 45-денними сертифікатами, доступний для ранніх впроваджень від травня 2026 року.
Висновок простий: ручне поновлення сертифікатів перестає бути розумною операційною практикою.
8. ACME і автоматизація сертифікатів
ACME є стандартним протоколом, що автоматизує реєстрацію облікового запису, перевірку контролю над доменом, видачу, поновлення та відкликання сертифіката.
HTTP-01
CA завантажує файл:
http://example.com/.well-known/acme-challenge/TOKEN
Переваги:
- проста конфігурація для одного вебсервера,
- легка автоматизація,
- не вимагає API DNS.
Обмеження:
- вимагає доступного порту 80,
- не видає wildcard,
- challenge має дістатися до належного сервера,
- хибний
AAAA, проксі, redirect або балансувальник навантаження можуть перервати перевірку.
Let's Encrypt рекомендує залишати порт 80 для публічних вебсерверів і перенаправляти звичайний трафік на HTTPS.
DNS-01
Клієнт публікує TXT:
_acme-challenge.example.com. 60 IN TXT "VALIDATION_TOKEN"
Переваги:
- підтримує wildcard,
- працює без публічного HTTP-сервера,
- підходить для централізованого обслуговування сертифікатів.
Ризики:
- вимагає безпечного доступу до API DNS,
- поширення та кеш можуть затримати перевірку,
- токен API з правом редагування всієї зони збільшує наслідки витоку,
- старі TXT можуть ускладнити діагностику.
Let's Encrypt чітко рекомендує використовувати DNS-01 з провайдером, що пропонує API, оскільки автоматизація поновлень є ключовою. Надавайте токену якнайменший можливий обсяг: найкраще лише до записів _acme-challenge, а не до керування доменом, обліковим записом чи всіма зонами.
Wildcard у Let's Encrypt вимагає DNS-01.
TLS-ALPN-01
Перевірка відбувається через спеціальне з'єднання TLS на порту 443 та протокол ALPN. Вона корисна для спеціалізованих проксі та систем керування сертифікатами, але рідше налаштовується вручну.
Renewal Information
Сучасний клієнт ACME має підтримувати ACME Renewal Information, тобто ARI. Замість поновлювати кожен сертифікат за одним жорстким порогом клієнт може отримати від CA рекомендоване вікно поновлення. Let's Encrypt рекомендує перевіряти інформацію ARI щонайменше двічі на день.
9. CAA і ACME: практичний приклад
Для сертифікатів Let's Encrypt:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild "letsencrypt.org"
Якщо ви не хочете wildcard:
example.com. 3600 IN CAA 0 issue "letsencrypt.org"
example.com. 3600 IN CAA 0 issuewild ";"
Перед видачею публічний CA зобов'язаний перевірити CAA. Від 15 березня 2026 року вимоги CA/Browser Forum наказують також перевірку DNSSEC для запитів, пов'язаних із CAA, що виконуються з основної мережевої перспективи, а помилку перевірки DNSSEC не можна трактувати як згоду на видачу.
Після зміни CA не забудьте оновити CAA перед запуском нового процесу видачі.
10. HTTPS, перенаправлення і HSTS
Мінімальна схема:
http://example.com
↓ 301 lub 308
https://example.com
Після підтвердження повної роботи HTTPS можна додати:
Strict-Transport-Security: max-age=31536000; includeSubDomains
HSTS повідомляє браузеру, щоб у майбутньому він використовував лише HTTPS і не дозволяв обійти частину помилок сертифіката.
Не починайте з довгого max-age, includeSubDomains і preload, якщо:
- існують субдомени без HTTPS,
- частина інфраструктури керується партнером,
- процес поновлень не протестовано,
- немає моніторингу сертифікатів,
- невідомо, чи старий сервіс усе ще буде потрібен.
HSTS preload розміщує правило в дистрибутиві браузерів. Видалення запису може тривати тижнями.
11. Найпоширеніші помилки DNS
Хибний запис AAAA
IPv4 працює, але частина клієнтів обирає непрацюючий IPv6. Симптоми випадкові залежно від мережі користувача.
CNAME та інші записи під тим самим іменем
Псевдонім конфліктує з адресними записами, MX або TXT. Панель провайдера може блокувати зміну або генерувати неоднозначну зону.
Неузгоджена делегація NS
Реєстратор вказує на інші сервери, ніж зона, або один із серверів має старішу версію даних.
Старий DS після зміни DNS
Домен повертає SERVFAIL лише в резолверів, які виконують перевірку DNSSEC.
Постійно занадто низький TTL
Збільшує кількість запитів і чутливість до тимчасової недоступності DNS, не забезпечує автоматично швидкого failover.
Занадто високий TTL перед міграцією
Старі адреси залишаються в кеші протягом багатьох годин.
Залишені записи TXT
Старі верифікаційні токени та ACME ускладнюють аудит і збільшують операційний хаос.
Відсутність узгодженості www та apex
example.com і www.example.com спрямовують до різних систем, мають різні сертифікати або утворюють цикл перенаправлень.
12. Найпоширеніші помилки TLS і сертифікатів
Сертифікат прострочено
Найчастіше причиною є не відсутність автоматизації, а автомат, який перестав працювати без сповіщення.
Сертифікат не охоплює хоста
Сертифікат для example.com не захищає автоматично www.example.com.
Неповний chain
Бракує проміжного сертифіката. Проблема може виникати лише на нових пристроях або окремих клієнтах.
Неправильний сертифікат через SNI
Reverse proxy має хибний default virtual host або новий домен не було додано до зіставлення.
Старі протоколи та cipher suites
Сервер усе ще пропонує TLS 1.0/1.1 або старі набори, бо конфігурація походить з багаторічної давнини.
Відсутність узгодженості на кількох рівнях
CDN має правильний публічний сертифікат, але з'єднання CDN→origin не шифрується або не перевіряє імені хоста.
Поновлення виконано, але процес не перезавантажив сервер
Новий файл сертифіката існує на диску, але Nginx, Apache, HAProxy чи застосунок усе ще використовує старий сертифікат із пам'яті.
13. Діагностика крок за кроком
Записи DNS
dig example.com A
dig example.com AAAA
dig www.example.com CNAME
dig example.com MX
dig example.com CAA
dig example.com DNSKEY +dnssec
dig example.com DS +dnssec
Делегація
dig example.com NS
dig +trace example.com
DNSSEC
dig example.com A +dnssec
delv example.com A
SERVFAIL за працездатності без перевірки є сильним сигналом проблеми DNSSEC.
Сертифікат і SNI
openssl s_client \
-connect example.com:443 \
-servername example.com \
-showcerts
Дати сертифіката
echo | openssl s_client \
-connect example.com:443 \
-servername example.com 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName
TLS
openssl s_client -connect example.com:443 -servername example.com -tls1_3
openssl s_client -connect example.com:443 -servername example.com -tls1_2
HTTP і HSTS
curl -I http://example.com/
curl -I https://example.com/
curl -IL http://example.com/
Перевірте redirect, Strict-Transport-Security, hostname, кінцевий статус і відсутність циклу.
Ви також можете скористатися безкоштовним Інспектором DNS і SSL POLPROG, який показує записи DNS та інформацію про сертифікат TLS. Доповніть тест за допомогою Інспектора заголовків безпеки, Стану вебсайту і статті Основи безпеки вебзастосунків.
14. Продакшн-моніторинг
Не відстежуйте лише головну сторінку з однієї локації. Мінімальний набір:
- відповідь авторитетного DNS,
- записи
A,AAAA,CNAME,NS,MXіCAA, - перевірка DNSSEC,
- доступність через IPv4 та IPv6,
- дати сертифіката,
- відповідність SAN,
- повний chain,
- TLS 1.2 і TLS 1.3,
- кінцевий redirect HTTP→HTTPS,
- HSTS,
- відповідь origin за CDN,
- робота ACME та останнє успішне поновлення.
Пороги сповіщень сертифіката
Для повністю автоматичної системи:
| Час, що залишився | Реакція |
|---|---|
| 30 днів | попередження або контроль тренду |
| 14 днів | сповіщення, що вимагає аналізу |
| 7 днів | операційний інцидент |
| 3 дні | критичне сповіщення та ескалація |
| менше ніж 24 год | неминучий збій |
Пороги слід узгодити з тривалістю сертифіката. Для шестиденних або 45-денних сертифікатів моніторинг має реагувати значно раніше пропорційно до циклу поновлення.
15. Безпечний чек-лист DNS і TLS
Реєстратор і DNS
- Обліковий запис реєстратора має MFA.
- Трансфер домену заблоковано.
- Контактні дані та процес відновлення актуальні.
- Використовуються щонайменше два авторитетні сервери DNS.
- Сервери працюють в окремих мережах або локаціях.
- Делегація NS у реєстратора та в зоні узгоджена.
- Записи
AіAAAAвказують на активну інфраструктуру. - IPv6 справді відстежується.
- Записи MX, SPF, DKIM і DMARC зберігаються під час міграцій.
- CAA дозволяє лише використовувані CA.
- Немає зайвих записів TXT і верифікаційних токенів.
- TTL знижено заздалегідь перед міграцією.
- TTL підвищено після стабілізації.
- Доступ до API DNS має мінімальні привілеї.
DNSSEC
- Провайдер підтримує DNSSEC і ротацію ключів.
- Запис DS у реєстратора відповідає активному DNSKEY.
- Зміни оператора DNS мають план міграції DNSSEC.
- Старі DS і ключі видаляються лише після закінчення терміну кешу.
- Домен тестується через резолвер, що виконує перевірку.
- Сповіщення виявляє
SERVFAILі закінчення терміну підписів.
Сертифікати
- Сертифікати видаються та поновлюються через ACME.
- Поновлення протестовано, а не лише першу видачу.
- Процес перезавантажує сервер після встановлення нового сертифіката.
- Усі хости присутні в SAN.
- Wildcard використовується свідомо.
- Chain містить належні intermediates.
- Приватний ключ не залишає належної системи.
- Привілеї до ключа обмежені.
- Сповіщення працюють незалежно від самого клієнта ACME.
- DNS-01 використовує обмежений токен API.
- HTTP-01 працює через IPv4 та IPv6.
- Staging CA використовується для тестів автоматизації.
TLS і HTTPS
- TLS 1.3 увімкнено.
- TLS 1.2 залишається лише для потрібної сумісності.
- TLS 1.0, TLS 1.1 і SSL вимкнено.
- Сервер не пропонує застарілих cipher suites.
- SNI повертає належний сертифікат для кожного хоста.
- HTTP перенаправляє безпосередньо на HTTPS.
- Немає mixed content.
- HSTS впроваджено поетапно.
-
includeSubDomainsбезпечний для всього домену. - Preload проаналізовано перед поданням.
- CDN→origin також використовує правильно перевірений TLS.
Вердикт
Гарна конфігурація DNS і TLS у 2026 році ґрунтується на чотирьох принципах:
- DNS має бути узгодженим і операційно стійким.
- DNSSEC слід впроваджувати лише з правильним керуванням DS і ключами.
- Сертифікати мають обслуговуватися автоматично через ACME.
- TLS 1.3, правильний chain, моніторинг і HSTS є частиною одного процесу, а не окремими завданнями.
Найбільшим ризиком є не відсутність «зеленого замка» у день запуску. Ним є тихий збій за кілька місяців: прострочений сертифікат, застарілий запис AAAA, залишений DS, токен DNS із надмірними привілеями або автомат поновлення, який ніхто не відстежував.
