DNSSEC с прости думи

Модул 8: Сигурност и отстраняване на проблеми · Време за четене: 11 минути

Цел на урока: След този урок ще можете с прости думи да обясните какво защитава DNSSEC, как работи веригата на доверие и защо може да се обърка при трансфер на домейн.

Основни понятия: DNSSEC, подпис (RRSIG), ключ (DNSKEY), DS запис, верига на доверие, валидиращ резолвер, SERVFAIL

Проблемът: откъде знаете, че отговорът е истински?

В модул 1 видяхте, че резолверът задава поредица от въпроси: на root сървъра, на TLD сървъра и на авторитетния DNS сървър. Получаваният отговор се приема за верен и се поставя в кеша. Но обикновеният DNS не проверява дали този отговор наистина идва от правилния DNS сървър. Нападател, който успее да изпрати фалшив отговор преди да пристигне истинският, може да накара резолвера да повярва, че example.com се намира на 203.0.113.66 вместо на 192.0.2.10. Това се нарича cache poisoning: кешът е "отровен" и всеки, който използва този резолвер, попада на грешния сървър.

DNSSEC (DNS Security Extensions) решава този проблем, като подписва отговорите. Тогава резолверът може да провери дали отговорът е истински и дали не е променен по пътя.

Какво прави и какво не прави DNSSEC

Това е най-важното, което трябва да запомните:

Подписът действа като печат върху плик: всеки може да прочете писмото, но веднага виждате дали някой го е отварял.

Трите компонента

DNSSEC добавя няколко типа записи. Не е нужно сами да ги създавате (това го прави Вашият DNS администратор или панел), но ще ги срещнете:

• DNSKEY: публичният ключ на зоната. С него всеки може да провери подписите.
• RRSIG: подписът на група записи. Всеки A, MX или TXT отговор получава свой RRSIG. Подписът има начална и крайна дата: затова зоната трябва редовно да се подписва отново.
• DS (Delegation Signer): кратък "отпечатък" на ключа на Вашата зона. Той се намира не във Вашата собствена зона, а при родителската зона: за example.com това е при регистъра на .com (Verisign), за .nl домейн при SIDN (регистъра на .nl в Нидерландия).

Ето как изглежда подписан отговор (съкратено):

$ dig example.com A +dnssec +noall +answer
example.com.  3600  IN  A      192.0.2.10
example.com.  3600  IN  RRSIG  A 13 2 3600 20261119000000 20261029000000 30794 example.com. s7yJ5o...

В RRSIG виждате между другото алгоритъма (13 = ECDSA P-256 с SHA-256), крайната дата (19 ноември 2026), началната дата и номера на ключа (30794).

Веригата на доверие

Защо DS се намира при родителската зона? Защото ключ в собствената Ви зона не доказва нищо: нападател също би могъл да изпрати собствен ключ. Затова проверката протича от горе надолу:

1. Резолверът се доверява на ключа на root зоната. Той е вграден във всеки валидиращ резолвер (trust anchor).
2. Root зоната има DS за .com, подписан с root ключа. По този начин резолверът знае какъв ключ трябва да има .com.
3. Зоната .com има DS за example.com, подписан с ключа на .com.
4. Зоната example.com има DNSKEY, който съответства на този DS, и с него могат да се проверят всички RRSIG записи.

Всяко звено доказва следващото. Ако едно звено се скъса, цялата верига става ненадеждна.

Валидиращ резолвер (повечето големи публични резолвери и все повече доставчици) преминава по тази верига. Ако е наред, получавате отговора. Ако не е наред, резолверът не дава отговор, а статус на грешка SERVFAIL. За посетителя сайтът тогава изглежда все едно "не съществува", докато Вашите записи може да са напълно наред.

Можете сами да видите това с домейн, който нарочно е повреден:

$ dig dnssec-failed.org A @1.1.1.1
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL
; EDE: 9 (DNSKEY Missing): (no SEP matching the DS found for dnssec-failed.org.)

С +cd ("checking disabled") молите резолвера да пропусне проверката. Ако тогава получите отговор, знаете със сигурност, че проблемът е в DNSSEC:

$ dig +cd dnssec-failed.org A @1.1.1.1 +short
96.99.227.255

Домейн без DNSSEC (без DS при родителската зона) не дава SERVFAIL: той просто не е подписан и се пропуска като "незащитен".

Къде се обърква: трансфер на домейн и смяна на ключове

DNSSEC самостоятелно почти никога не се чупи. Проблемът възниква, когато DS записът при регистъра вече не отговаря на ключа в зоната. Това се случва най-вече:

• При трансфер към нов DNS сървър или нова DNS фирма. Новата фирма подписва със собствен ключ, но при регистъра все още стои DS записът на старата фирма. Резултат: SERVFAIL за всеки с валидиращ резолвер. Това е класическата грешка след трансфер на домейн.
• При смяна на ключове, при която новият DS не е изпратен (навреме) до регистъра.
• Когато подписите изтекат, защото зоната вече не се подписва отново.

Затова безопасната последователност при трансфер е:

1. Премахнете DS записа при регистъра (или оставете новата фирма да предостави DS, който добавяте допълнително).
2. Изчакайте TTL на стария DS да изтече.
3. Сменете DNS сървърите.
4. Включете DNSSEC при новата фирма и поставете новия DS при регистъра.

Много регистратори и панели вече уреждат това автоматично, стига домейнът и DNS да са при една и съща фирма. Ако са при различни фирми, трябва сами да пренесете DS записа.

Проверка сами: DNSViz, Zonemaster и internet.nl

Не е нужно да проследявате веригата с dig. Има безплатни инструменти, които го правят вместо Вас и показват резултата.

DNSViz (https://dnsviz.net/) изчертава цялата верига като схема. Ето как се използва:

1. Въведете на началната страница домейн името в полето за търсене (само името, без https:// и без www) и кликнете върху Go.
2. DNSViz показва последния анализ. Ако е стар, или ако току-що сте променили нещо, кликнете върху Update now. След няколко секунди ще видите схемата.
3. Прочетете схемата от горе надолу: най-горе root зоната (.), под нея TLD (например nl), най-долу Вашият домейн. Всяка зона е в рамка.

Какво виждате в схемата:

Веригата проследявате така: DS (при родителската зона) сочи към DNSKEY (във Вашата зона), а този DNSKEY с RRSIG поставя подписа си под записите. Това е точно веригата от този урок, но изчертана.

Цветовете показват дали всичко е наред:

• Синьо: защитено (secure). Веригата протича непрекъснато от root до тази част.
• Черно: неподписано (insecure). Няма DS, така че няма какво да се провери. Това не е грешка, домейнът просто не използва DNSSEC.
• Червено: повредено (bogus). DS не съответства на ключ, или подпис не е верен. Валидиращ резолвер тогава дава SERVFAIL.
• Лилаво (при подпис): подписът е изтекъл или още не е валиден. Зоната вече не се подписва отново.
• Жълто: предупреждение, например DNS сървър, който не отговаря правилно, или алгоритъм, който инструментът не разпознава.
• Сиво и пунктирано: има позоваване на ключ, който не съществува. Ако видите пунктиран DNSKEY под DS, при родителската зона все още стои DS от стар ключ: класическата грешка след трансфер на домейн.

До даден елемент може да има триъгълник (предупреждение) или кръгъл знак за грешка. Поставете мишката върху него, или погледнете списъка под схемата: там с думи е обяснено какво не е наред.

Опитайте с sidn.nl (всичко синьо) и с dnssec-failed.org (червено, с пунктиран ключ под DS).

Други инструменти, които разглеждат същото от друг ъгъл:

• Zonemaster (https://zonemaster.net/): проверява цялата Ви зона така, както го прави регистър, включително DNSSEC. Резултатът е списък със зелено (добре), оранжево (предупреждение) и червено (грешка).
• internet.nl (https://internet.nl/): тестът за уебсайт и имейл показва между другото дали DNSSEC за Вашия домейн и за Вашите пощенски сървъри е наред, със зелени отметки или червени кръстчета.
• Verisign DNSSEC Debugger (https://dnssec-debugger.verisignlabs.com/): преминава веригата стъпка по стъпка и поставя при всяка стъпка зелена отметка или червено кръстче. Полезен, ако търсите конкретна грешка.

Използвайте ги след всяка промяна по DNSSEC, и особено преди и след трансфер на домейн. Оставете инструмента спокойно да анализира отново: и тези инструменти работят с кешове и TTL стойности.

На практика: така изглежда в панел

В Моят WebOké включвате DNSSEC за домейн под DNSSEC/DANE; панелът създава ключовете и изпраща DS записа към регистъра. В DirectAdmin и при външни доставчици като Cloudflare това обикновено се нарича "DNSSEC inschakelen" (включване на DNSSEC); Cloudflare Ви показва тогава DS запис, който сами трябва да въведете при Вашия регистратор. Другите панели работят по подобен начин: винаги има стъпка "създаване на ключове" (при DNS доставчика) и стъпка "DS при регистъра" (при регистратора).

Обобщение

• DNSSEC подписва DNS отговори, така че резолвер да може да провери дали са истински. Не криптира нищо.
• DNSKEY е ключът, RRSIG е подписът, DS е отпечатъкът при родителската зона.
• Проверката протича като верига от root до Вашия домейн. Ако едно звено се скъса, валидиращ резолвер дава SERVFAIL.
• Почти всички проблеми възникват, защото DS записът при регистъра вече не отговаря, често след трансфер на домейн.
• С dig +cd виждате дали даден проблем идва от DNSSEC.
• DNSViz изчертава веригата: синьо е защитено, черно е неподписано, червено е повредено. Zonemaster, internet.nl и Verisign DNSSEC Debugger са добри второ мнение.

Тест

Задача

Задача Z8.1: Виждане на DNSSEC. Разберете кой от два домейна има наред DNSSEC и кой е нарочно повреден: sidn.nl и dnssec-failed.org. Заявете за двата DS записа и A записа чрез валидиращ резолвер (например 1.1.1.1 или 9.9.9.9), с dig или онлайн инструмент. Попълнете: номера на ключа (key tag, първото число) на DS записа на sidn.nl, и статуса, който получавате за dnssec-failed.org.

Задача Z8.1b: Четене на DNSViz. Анализирайте nlnetlabs.nl в DNSViz (https://dnsviz.net/, въведете името и кликнете върху Go; кликнете върху Update now, ако анализът е стар). Прочетете схемата и попълнете: (1) статуса на nlnetlabs.nl (защитен, неподписан или повреден), (2) номера на алгоритъма на DNSKEY записите (намира се във всеки овал като alg=), (3) колко DNSKEY овала има в зоната на nlnetlabs.nl, (4) номера на ключа (id=) на сиво запълнения DNSKEY, към който сочи DS записът, и (5) статуса, който DNSViz дава за dnssec-failed.org. Проверката заявява същите данни на живо.

Задача O8.1: Оценка на три демонстрационни DNSSEC зони. Подготвили сме три демонстрационни зони: signed-demo.dnspractice.com (правилна верига), broken-demo.dnspractice.com (нарочно повредена) и unsigned-demo.dnspractice.com (неподписана). Разберете за всяка зона дали е защитена, повредена или неподписана, например с DNSViz или с dig +dnssec (обърнете внимание на флага AD, и при SERVFAIL опитайте и с +cd). Изберете по-долу отговора си за всяка зона.

Прочетете още

Тези статии описват стъпките в панелите на WebOké; при други доставчици бутоните се наричат различно.

• Ръководство на WebOké 5.8: DNSSEC и DANE
• Какво е DNSSEC?
• Активиране на DNSSEC
• Уебсайтът или имейлът не работи след преместване или промяна на DNS: проверете Вашия домейн