DNSSEC и BIND9 - кратко ръководство

Веселин Колев, Софийски Университет "Св. Климент Охридски"

Обобщение на идеята и методите заложени в DNSSEC

KSK - Key-signing key

ZSK - Zone-signing key

DS ресурсни записи

Конвенция за наименоване на файловете за съхранение на ключове

Работна директория за извършване на подписването

Инструментариум на BIND9 за генериране на двойки ключове и подписване на ресурсни записи на зони

Генериране на двойката ключове за подписване на ключове (KSK)

Генериране на двойката ключове за подписване на ресурсни записи (ZSK)

Изготвяне на шаблон на зоната за подписване

Подписване на шаблона на зоната

Създаване на DS ресурсните записи

Настройки на BIND9 за използване на DNSSEC

Механизъм за подмяна на ZSK двойката ("key rollover")

Предишни версии на публикацията

Забележка: Документацията обхваща версии на BIND 9.3.3 или по-високи. Всички бележки относно пакетното представяне на BIND в системата важат за Red Hat Enterprise Linux 5.

1. Обобщение на идеята и методите заложени в DNSSEC

DNSSEC е протокол, чието актуално описание е направено в следните документи: RFC4033, RFC4034 и RFC4035.

Основната идея на DNSSEC е начин за удостоверяване на автентичността на ресурсните записите в зоната на даден домейн, на база проверка на електроннния подпис извършен върху тях. Така се гарантира, че записите наистина принадлежат на съответната зона на домейн и не са генерирани с цел измама по пътя на DNS заявката. Извършването и проверката на електронния подпис в рамките на DNSSSEC става чрез използването на криптографска система с публичен ключ. За момента използваните в DNSSEC криптографски алгоритми с публичен ключ са DSA и RSA. Генерира се двойка ключове по един от споменатите два криптографски алгоритъма и с помощта на частния ключ от двойката, администратора на домейна подписва ресурсните записи в зоната. Електронните подписи върху ресурсните записи се влагат в зоната също като ресурсни записи. Проверката на електронния подпис върху даден ресурсен запис става чрез публичния ключ от същата двойка ключове. Самият публичен ключ се публикува като ресурсен запис в зоната на домейна. Когато даден клиент иска да провери автентичността на даден запис в зоната на домейна, извлича записа, който иска да провери, след това извлича записа, който съдържа публичния ключ и ако подписът е проверяем с публичния ключ, има автентичност. Разбира се този, който проверява електронния подпис трябва да знае дали публичния ключ, който извлича като запис е автентичен или не. Това става с методи извън DNSSEC, които ще бъдат дискутирани по-долу.

От техническа гледна точка може да се каже, че проверката на електронния подпис, извършен чрез криптографски алгоритъм с публичен ключ не е лека задача (свързана е с повишаване на натоварването на процесора). Пренесено върху DNSSEC, това означава повишено процесорно натоварване на сървърите, върху които са реализирани сървърите за имена, които ще извличат и проверяват подписаните заявки.

Както йерархията на домейните в един домейн от първо ниво започва от неговия регистър, така и DNSSEC подлежи на йерархичност. Това означава, че ако в зоната на родителския домейн има удостоверяване на ключовете, чрез които да се проверят електронните подписи върху ресурните записи в дъщерна зона, до електронните подписи в дъщерната зона са проверяеми с начало родителската зона. По този начин родителската зона гарантира автентичността на дъщерните зони. За да има подобно унаследяване, трябва оператора на дъщерната зона да предаден на оператора на родителската зона съответните DS ресурсни записи, които той е генерирал (създал).

2. KSK - Key-signing key

Това е двойка ключове (частен KSK ключ и публичен KSK ключ) със следните роли:

Двойката KSK ключове не се използва за подписване на ресурсните записи в зоната на домейна, с изкючение на записа, който представлява публичня ZSK ключ. Тя притежава специален числов идентификатор, който носи стойност 257. Този идентификатор е част от DNSKEY ресурсния запис за публичния ключ на KSK двойката.

3. ZSK - Zone-signing key

Това е двойка ключове (частен ZSK ключ и публичен ZSK ключ) със следните роли:

Практиката на DNSSEC определя следната гледна точка към ролите на KSK и ZSK. KSK е двойка ключове, чиито подписващ ключ е с голяма дължина. Това позволява той да се използва за по-продължителен период от време. ZSK е двойка ключове, чиито ключ за подписване е със сравнително малка дължина. Той може да се генерира много по-бързо от KSK, но се използва за по-малък период от време. Идеологията е такава, че операторът може да генерира ZSK на определен период от време (сравнително къс) и да подписва тези генерирани ключове с един и същ KSK, който да използва за по-дълъг период от време.

ZSK притежава специален числов идентификатор, който носи стойност 256. Този идентификатор е част от DNSKEY ресурсния запис за публичния ключ на ZSK двойката.

4. DS ресурсни записи

Наименованието на ресурсния запис DS идва от съкращението на "Delegation Signer". Това са ресурсни записи, които се поставят в съответната родителска зона на домейн и делегират в рамките на DNSSEC съответната дъщерна зона. Обикновено тези записи се генерират при подписването на дъщерната зона от нейния оператор. Алгоритъмът, по който се генерира DS ресурсния запис е описан в RFC документите по темата DNSSEC.

Когато операторът на дъщерната зона иска тя да бъде делегирана в рамките на DNSSEC от родителската зона, той се свързва с оператора на родителската зона и по сигурен канал му предава DS записите. При използването на роли на двойките ключове, DS запсиите се изчисляват за KSK. Така няма да се налага на оператора на дъщерната зона при всяко ново генериране на ZKS да изпраща съответните DS записи на оператора на родителската зона. В този случай на оператора на родителската зона се изпращат само DS записите, касаещи KSK, а доколкото KSK двойката е дългоживуща, то обмена на DS записи между операторите ще е сравително рядък.

5. Конвенция за наименоване на файловете за съхранение на ключове

Всяко име на файл съдържащ ключ, се съставя така, че да може да се разгледа като изградено от представка и наставка разделени с точка. Инструментариумът на BIND за работа с DNSSEC използва тази конвенция.

Представката е символен низ, който съдържа последователно:

Наставката заема две стойности: "key" и "private". Наставката "key" обозначава файла като съдържащ публичния ключ на двойката, а "private" обозначава файла като съдържащ частния (подписващия) ключ на двойката.

Пример за файлове съдържащи двойка ключове генерирани чрез набора алгоритми RSASHA1:

6. Работна директория за извършване на подписването

Наличието на подобна директория не е задължително, а е израз на използване и изграждане на добра практика при администрирането. Всеки оператор на зона е свободен сам да изгради или не работна директория, в която да извършва подписването. Посоченият по-долу пример за работна директория не е задължителен и е само един възможен вариант за изграждането на директорията.

В примерите по-долу ще се приема, че пътят до работната директория е присвоен като стойност на променливата ${DNSSECDIR}. Работната директория има следната поддиректорийна структура:

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

Най-лесният начин за задаване обявяване на променливата ${DNSSECDIR} и присвояването на стойност е чрез команден ред, но това обявяване важи само за текущия терминал:

По-удобно е тази променлива да се зададе чрез инициализацията на променливите в съответната за потребителя командна обвивка, най-често bash. В този случай в съответната домашна директория на потребителя трябва да е наличен файла .bashrc. В него променливата се обявява и след това й се присвоява стойност чрез прибавяне във файла на следната информация:

За да се избегне излизане от терминални сесии, промените могат да бъдат въведени веднага така:

Достъпът до работната директория, файловата система, която я съдържа и компютърната система, върху която се намира файловата система, трябва да бъде рестриктивен. Достъп до работната директория и файловете в нея трябва да се имат само потребителите, които имат операторски правомощия спрямо зоната. Препоръчително е във всички случаи частните ключове да се криптират (примерно чрез използването на GnuP) или цялата директория да се намира върху криптирана файлова система.

7. Инструментариум на BIND9 за генериране на двойки ключове и подписване на ресурсни записи на зони

Инструментариумът на BIND за работа с DNSSEC (тук не говорим за вградените функционалности в самия демон named), включва инструментите dnssec-keygen и dnssec-signzone. Ако пакетът bind не присъства в системата, той може да бъде инсталиран. В Red Hat Enterprise Linux проверката на присъствието на пакета bind може да бъде извършена с права на непривилигерован потребител:

Ако пакетът присъства в системата, ще бъде изведена информация за версията му. Ако пакетът не присъства в системата отговор няма да се получи. Следователно пакетът bind трябва да бъде инсталиран от пакетната система на дистрибуцията (нужни са права на супер потребител):

Пълната информация за използването на инструментите dnssec-keygen и dnssec-signzone може да бъде намерена в техните man или info страници, който се инсталират заедно с останалите файлове от пакета bind.

8. Генериране на двойката ключове за подписване на ключове (KSK)

За генерирането на двойки ключове се използва инструмента dnssec-keygen от състава на пакета bind.

Генерираната двойка ключове се съхранява в подиректория KSK/ на работната директория ${DNSSECDIR}. Преди да се генерира следва да се избере вида на алгоритъма, чрез който ще се генерира двойката ключове, използвания хеш-алгоритъм (хеш-функция) и дължина на криптиращия ключ.

Към настоящия момент препоръките са да се използва алгоритъм с публичен ключ RSA, хеш-алгоритъм (хеш-функция) SHA-1 и дължина на криптиращия RSA ключ 4096 бита. Ето примерно генериране на двойка ключове по алгоритъм RSA с използване на хеш-функсия SHA-1 и дължина на криптиращия ключ 4096 бита за зоната на домейна localhost:

Указването на опцията "-f KSK" при генерирането, определя тази двойка като KSK.

Използването на източник на случайни числа (/dev/urandom) е задължителна част от процеса на генериране на ключовете. Не се препоръчва генерирането на двойка ключове (особено последователното генериране на такива двойки), без използването на източник на случайни числа.

След завършване на процеса на генериране на двойката, двата файла с ключове ще се съдържат в директория ${DNSSECDIR}/KSK/.

9. Генериране на двойката ключове за подписване на ресурсни записи (ZSK)

За генерирането на двойки ключове се използва инструмента dnssec-keygen от състава на пакета bind.

Генерираната двойка ключове се съхранява в подиректория ZSK/ на работната директория ${DNSSECDIR}. Преди да се генерира следва да се избере вида на алгоритъма, чрез който ще се генерира двойката ключове, използвания хеш-алгоритъм (хеш-функция) и дължина на криптиращия ключ.

Към настоящия момент препоръките са да се използва алгоритъм с публичен ключ RSA, хеш-алгоритъм (хеш-функция) SHA-1 и дължина на криптиращия RSA ключ 1024 бита. Ето примерно генериране на двойка ключове по алгоритъм RSA с използване на хеш-функсия SHA-1 и дължина на криптиращия ключ 4096 бита за зоната на домейна localhost:

След завършване на процеса на генериране на двойката, двата файла с ключове ще се съдържат в директория ${DNSSECDIR}/ZSK/.

10. Изготвяне на шаблон на зоната за подписване

Шаблоните на зоните за подписване се съдържат в поддиректория zones/ на работната директория ${DNSSECDIR}.

Шаблонът на зоната се изработва от изходния код на зоната, който не е в DNSSEC формат, като в края му чрез директивата $include се включват KSK и ZSK публичните ключове, като обявяването им става с пълен или относителен път до файловете, които ги съдържат.

Ето примерно съставяне на шаблон на зона, който подлежи на подписване:

Готовият шаблон се запазва като файл в директория ${DNSSECDIR}/zones/, като му се дава име, което достатъчно добре да говори за това, че този файл е шаблон на зона. Добре е в името на файла да фигурира името на зоната, например localhost.unsigned.

Накрая шаблона се проверява за правилност на синтаксиса чрез инструмента named-checkzone. Ето пример за такава проверка:

В този пример localhost е името на домейна, чиято зона се намира във файла localhost.unsigned. Ако проверката протече успешно, т.е. не бъдат открити грешки, инструментът ще върне съобщение "OK". С това изграждането на шаблона може да се счита за приключено.

Оттук нататък всяка промяна, прибавяне или изтриване на запис в зоната, се прави директно в шаблона.

11. Подписване на шаблона на зоната

При подписването на шаблона на зоната трябва да се зададе валидност на електронния подпис на записите в зоната. Крайната дата (година, месец, ден от месеца) и час на валидност (час, минути, секунди) на електронния подпис върху записите в зоната се подава като опция на инструмента dnssec-signzone.

За да се подпише шаблона на зоната са необходими KSK и ZSK двойките ключове, нужно е да се укаже името на домейна, записи от чиито домейн ще се подписват (указва се с опцията "-o")

При изпълнението на командния ред за подписване на ресурсните записи в зоната на домейна, ще се извърши следното. Ще се прочетат двойките KSK и ZKS ключове. С опцията "-k" се указва файла, който съдържа публичния ключ на KSK двойката, а в края на командния ред се указва файла, който съдържа публичния ключ на ZKS двойката. Въпреки, че в командния ред са указани само файловете, които съдържат публичните ключове на KSK и ZSK двойките, по подразбиране се приема, че в същата директория, в която се намира съответния публичен ключ, се намира и файла, който съдържа частния ключ (в името на файла има наставка .private). След опцията "-o" в командния ред се указва домейна, записи от чиято зона ще бъдат електронно подписвани (в случая localhost). Чрез "-f" се указва файла, в който ще се запазят електронно подписаните записи. Поставянето в името на този файл на наставката .private не е задължително, но е добре да се прави, за да може да се съди по името на файла, за какво точно съдържание в него става дума. Файлът със шаблона на зоната се намира във файла ${DNSSECDIR}/zones/localhost.unsigned. Той се указва за прочит непосредствено преди файла с публичния ключ на KSK двойката, който е последната информация в командния ред.

Подписаните ресурсни записи на зоната на домейна (за примера домейна е localhost), ще се намират във файла ${DNSSECDIR}/zones/localhost.signed. Този файл се указва за прочит в конфигурацията на съответната зона в BIND. Например:

По подразбиране валидността на електронните подписи върху ресурсните записи е един календарен месец. Въаможно е обаче да се укаже и друг срок на валидност, както и от какво време нататък подписът е валиден. За целта се използват опциите "-s" (стартово време на валидност) и "-e" (крайно време на валидност) на инструмента dnssec-signzone.

Пример за указване на начално време на валидност и крайно време на валидност на електронните подписи върху ресурсните записи:

В този пример стартовото време за валидност на електронния подпис върху записите в зоната на домейна localhost е 20070428103959 - 28 април 2007 година, 10 часа, 39 минути и 59 секунди. Срокът на валидност на електронните подписи върху ресурсните записи в зоната на домейна localhost е 20070623234540 - 23 юни 2007 година, 23 часа, 45 минути и 40 секунди.

Възможно е относително задаване (без абсолютно време). Например, използването на "-e +86400" ще направи подписите валидни до "сега+86400 секунди". Разбира се, резултатът е пак абсолютно време, но не се иска указането на началния репер от време, а само дължината на времевия интервал на валидност. Същото относително задаване може да се използва и към началното време за валидност, като може то да се пренесе в бъдещето, чрез използването на опцията "-s". Например, указването на "-s +86400", ще генерира подписите с начало на валидност 86400 секунди след извършване на подписването. Тук се изисква повишено внимание. Във всички случаи при генерирането на крайното или начално време на валидността на електронния подпис върху записите, се отчита локалното време за системата, върху която е извършено подписването. За да може подписите да се валидират върху други системи, то следва да се използва източник на точно време.

Това, че е указан краен срок на валидност на електронните подписи върху ресурсните записи на зоната, не означава, че преди изтичане на този срок не може да има ново подписване на преопределяне на крайния срок!

2. Създаване на DS ресурсните записи

В хода на подписване на ресурсните записи в шаблона на зоната, се създават и съответните DS ресурсни записи. Те се намират в директорията, в която е извършено подписването на зоната и се съдържат във файла, чието име носи представката "dsset". Наример, при изпълнение на подписването на шаблона на зоната чрез командния ред:

в директория ${DNSSECDIR}/zones/ ще се намира файла dsset-localhost. Той ще съдържа съответните DS записи.

13. Настройки на BIND9 за използване на DNSSEC

За да може да се обслужват зоните, за които има DNSSEC подписване и да се валидират техните записи, следва да се направят настройки в конфигурационния файл на bind, който обикновено носи името named.conf.

В секцията options на този файл се задава директива за използването на DNSSEC от демона named:

За удобство може да се създаде журнален канал за описание на събитията по обслужването на DNSSEC заявки чрез категоризация. Описанието в named.conf може да бъде от вида:

Използването на trusted-keys и др. особености на валидирането на заявките ще бъде обект на отделно ръководство.

14. Механизъм за подмяна на ZSK двойката ("key rollover")

Съгласно казаното по-горе, когато в подписването на зоната има разделение на двойките ключове по роли - ZSK и KSK, ZSK двойката е с по-малка дължина на частния ключ, защото се използва за по-къс период от време (има по-кратко време на живот), докато KSK двойката е с по-голяма дължина на частния ключ, защото тя се използва за по-дълъг период от време (характеризира се с по-дълго време на живот). Ако се следва казаното относно ролите на двойките и времето им на живот (жизнен цикъл), то следва в рамките на времето на живот на KSK двойката да се използват много ZSK двойки с по-кратък жизнен цикъл, които последователно да се въвеждат и извеждат от употреба, т.е. да се подменят. Когато една ZSK двойка бъде изведена от употреба, тя следва да не се използва отново за подписване на ресурсни записи в зонта (а най-добре да се унищожи криптиращия й ключ, за да се предотврати възможността за последващо подписване с него).

Подобна периодична подмяна на ZSK двойката се нарича в англоезичната документацията "key rollover".

Ето как би изглеждала последователността от действия, която води до подмяната на ZSK двойката.

Нека разгледаме ресурсен запис (RR - Resource Record), например A запис, със стойност на параметъра TTL равна на 86400 секунди, който е електронно подписан чрез използване на DNSSEC. Когато този запис бъде електронно подписан, в зоната на домейна се генерира съответен RRSIG запис. Следователно за всеки ресурсен запис (RR) в зоната на домейна, има прилежащ RRSIG запис, в който се съдържа електронния подпис върху RR записа. Времето на живот на всеки един RRSIG запис е равно на времето на живот на този ресурсния запис, за който той е генериран и следвателно в нашия случай, той ще има време на живот 86400 секунди. Когато един кеширащ сървър за имена, който поддържа проверка на автентичността на ресурсните записи чрез DNSSEC, изтегли ресурсен запис и прилежащия му RRSIG запис, той ги складира и двата в своя кеш. За да провери валидността на електронния подпис в RRSIG записа, кеширащият сървър се нуждае и от DNSKEY записите от зоната на домейна, от която са извлечени RR и RRSIG записите. Следва извличането на всички DNSKEY записи от зоната. Те също се складират в кеша на сървъра. След складирането на всеки ресурсен запис в кеша, започва да тече обратно броене, което продължава толкова секунди, колкото е обявения TTL на записа. След като изминат TTL секунди, сървърът за имена изтрива този ресурсен запис.

Ако TTL на кешираните RR и RSIG записи е 86400 секунди, а TTL на кешираните DNSKEY записи е 3600 секунди, то е ясно, че времето на живот на RR и RRSIG записите е по-голямо от времето на живот на DNSKEY записите, които служат за проверка на електронния подпис върху RR. Ако някой смени DNSKEY записите за ZSK двойките в зоната, като премахне старите и постави само новите и преподпише записите в зоната, ще се получи ситуация, при която някъде из сървърите за имена в Интернет ще има кеширани RRSIG записи, електронния подпис в които няма да може да бъде проверен, защото той е проверяем само със стария публичен ключ, който е премахнат с премахването на стария DNSKEY запис.

Следователно, ако се следва описаното в примера, DNSKEY записа, който съдържа стария публичния ключ от старата ZSK двойка, трябва да стои в зоната на домейна след подписването с новата ZSK двойка толкова време, че да покрие времето на живот на най-дългоживущите RRSIG записи от зонатата. Чак след това той може да бъде премахнат. Това задължително трябва да се знае от всеки оператор на DNSSEC базирана зона на домейн.

Едно прибързано решение на задачата за стойностите на TTL е стойността на този параметър за DNSKEY записа да се укаже равна на максималната стойност, която има ресурсен запис в зоната. Ако става въпрос за времена над 3600 секунди, това крие опасност. Тя се състои в следното. Какво би станало, ако частния ключ на ZSK двойката бъде разкрит (това е вероятно, като се има предвид малката дължина по дефиниция на ZSK)? В този случай някой ще може да подписва злонамерено генерирани от него ресурсни записи и да заразява с тях кеш сървъри за имена в Интернет. Дори администраторът на зоната да установи разкриването и да въведе нова ZSK двойка, кешираният стар DNSKEY запис, съдържащ публичния ключ от разкритата вече двойка ключове, все още ще живее в кеш сървърите и ще валидира подхвърлените записи (подписани с разкрития частен ключ). Докато кешираният DNSKEY запис не достигне края на живота си в кеша на кеширащите сървъри, те и техните рекурсивни клиенти ще бъдат податливи на измама. Да, преждевременото премахване на един DNSKEY запис (този, който съдържа публичния ключ на ZSK двойката, чиито частен ключ е разкрит), може да доведе до там, че кешираните с голяма стойност на TTL електронни подписи (в RRSIG записите), могат да спрат да бъдат валидни, но това е временен проблем и е определено по-малкото зло в случая.

Именно поради гореописаното, стойността на TTL за DNSKEY записа не бива да бъде висока. Максималната й стойност трябва да е 3600 секунди, а минималната нула, но последното би довело до по-голям трафик свързан с DNS и по-голям товар върху достоверните сървъри за подписаните зони.