karkarramba 6 июн 2011 в 14:24

DNSSec: Что такое и зачем

6 мин

105K

Предисловие

Как оказалось, не так много людей знают что такое DNSSec, для чего он нужен, для чего нет и стоит ли его внедрять у себя. Так как на русском языке информации на этот счет мало, я постараюсь пролить свет на эти вопросы.

Что такое DNSSec

Немного истории

Изначально система доменных имен не имела никаких механизмов для защиты от подмены информации в ответе — архитектура системы такова, что и запрос, и ответ передаются чистым текстом. При этом резолвер судил о верности полученной информации только по идентификатору запроса, длина которого всего 2 байта. То есть чтобы отравить кэш нужно было просто перебрать 65536 значений. говорить об этом начали еще в 90-х. При этом принялись неспешно описывать первую редакцию DNSSec. Она увидела свет в 1997, через два года появилась следующая. В 2005 появилась нынешняя редакция DNSSec, с которой все и работают. Знаковое событие случилось в 2008 году, когда Дэн Камински показал миру, что отравить кэш можно за 10 секунд. Производители DNS софта ответили тем, что кроме идентификатора запроса стали рандомно выбирать исходящий порт. Попутно началась истерия по поводу внедрения DNSSec.

Как это работает

Принцип работы DNSSec тот же, что и у цифровой подписи. То есть закрытым ключом подписываем, открытым сверяем.
Особенность состоит в том, что DNSSec использует два типа ключей — одним подписывается зона (ZSK, zone signing key), другим подписывается набор ключей (KSK, key signing key). Сделано это из таких соображений: зона может быть достаточно большой чтобы удалось подобрать закрытый ключ, поэтому его надо менять почаще, да и сделать его можно покороче, чтобы зоны подписывались быстрее; KSK же используется для небольших объемов данных, поэтому его можно и подлиннее сделать и менять пореже. Тем более, что хэш от открытой части KSK требуется отправить в родительскую зону, что хотелось бы делать не слишком часто.

ZSK

С помощью этого ключа подписываются все наборы записей в зоне (RRSET), кроме точек делегирования. То есть, допустим у вас есть зона example.com и в ней такой кусок:

$ORGIGIN example.com.
@       SOA dns.example.com ns.example.com {
                 Serial
                 Refresh
                 Retry
                 Expire
                 nTTL
                 }
        NS ns.example.com.
        NS ns1.example.com.

        DNSKEY  256 3 5 (
                                      AwEAAfETe4xtZy3Ml+9NceWE0zTUWk5WgTs5
                                      ogRJ1fVuJ5U2QmBb+t3ltA4BrZObLRjX2
                                      HcMmneVC4C3IdgluAiV6Jpj7hgRZIbbG8les
                                      LaiL0/wOoH/byPvNi5T0OQpG3vgXyhoBdWxl
                                      zghFU3eQSAnWF0xP/c323rtP0irdY7v5
                                      ) ; key id = 38754

         DNSKEY  257 3 5 (
                                      AwEAAdanjntZ82rOdV97sDS5+QH+w1pKnRJ/
                                      b8gmuRBC91q5fQ2YiQ5zzYKi9+gENlqx/1MN
                                      jAFXJ1Fvtf0pJYKjmkiBJoHdZoEVRnJz8ODx
                                      FYgFX/fx+SBKsG3ZioaHP3CEdZQ4k3kutN6o
                                      tawolvHfErSwnJT/3IhAplXDHZrLmwXgWU3M
                                      PvMhnJRR9jd7S4f3WF10oq+3qPkBbJrqxB3x
                                      RydCSaZYfVuJ5U2QmBb+t3ltA4BB8jL8jOLS
                                      zvP2lufa6P8f0TJxtcpx/t9IfvUyWHmr9H7r
                                      inl4k8xDTVvaPnmBScxbuBc=
                                      ) ; key id = 23179

doo     IN A 127.0.0.1
        IN A 127.0.0.2
        IN MX mail

foo      NS ns1.test.ru.
        NS ns2.test.ru.

bar     NS ns1.test.ru.
        NS ns2.test.ru.
        DS 4915 5 1 180DC61CD4A2772DC02EC18934AA4C024D77DC11
        DS 4915 5 2 03EE2B29404BDF6D8891C0E0C89F714FE865E1D59A621F6FB4642648 4BC8C852

И вы решили эту зону подписать. Сделано будет следующее:

Создастся последовательность подписанных записей;
Добавятся записи NSEC (об этом чуть ниже);
Подпишутся записи SOA, набор NS для example.com, адресные и MX записи для doo, каждая NSEC RR и каждый набор DS.
В зависимости от настроек софта также может быть подписан набор DNSKEY.

Точки делегирования, т.е. NS записи для дочерних зон, подписаны не будут.

KSK

Этим ключом подписывается набор DNSKEY записей.
Кроме того, от открытой части KSK берется хэш, который в дальнейшем отправляется в родительскую зону. В вышеприведенном примере это DS записи (Delegation Signer).
В случае с корневой зоной предполагается, что открытая часть ключа будет сообщена резолверу вручную. А чтобы при смене ключа не обновлять его каждый раз вручную, существуют механизмы его автоматического обновления, например у BIND'а есть опция managed-keys.
Очевидно, что закрытую часть KSK следует хранить как зеницу ока — во-первых иначе исчезает весь смысл DNSSec, во-вторых в случае компрометации быстро сменить KSK не получится.

Next SECure

Ну, вот подписали мы зону, но все равно кто-то посторонний может добавить в нее свою информацию и, даже неподписанная, она будет отдаваться сервером наравне с подписанной.

Чтобы такого не происходило, при подписи зоны доменные имена сортируются в алфавитном порядке, к каждому из них добавляется запись NSEC, в которой указывается какое следующее доменное имя защищено и какие записи для него присутствуют в зоне. Последняя NSEC запись указывает на SOA.
Если авторитетный сервер возвращает ответ NXDOMAIN (RCODE=3) или NODATA (RCODE=0), то в ответе обязательно должна присутствовать NSEC запись. Пример такого ответа:

; <<>> DiG 9.7.3 <<>> jhbczxccva.se +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 8766
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;jhbczxccva.se.                 IN      A

;; AUTHORITY SECTION:
se.                     300     IN      SOA     catcher-in-the-rye.nic.se. registry-default.nic.se. 2011053104 1800 1800 864000 7200
se.                     300     IN      RRSIG   SOA 5 1 172800 20110613123930 20110531090447 24825 se. JJGWAvmcB/Bq7t5z7iTQGLr9c0LzQkdwpNFsrIClJctZUn/Z3YN2EMVQ 0r6DvufTGk1L8JMvTaxkI43ZmvasFeNNzfUFjr+td8Mv9h7FF5kTfEO5 R7JMh4j0Kxl/Gy4j+Ofcm0ZiCZTtcnNdHwCIHaVpz9KA6uIubnlJNSLw YXI=

Так как ответ NXDOMAIN всегда сопровождается SOA записью, то в подписанной зоне возвращается SOA и подпись для нее.

se. 300 IN RRSIG NSEC 5 1 7200 20110613011140 20110530130445 24825 se. dKL3iGCxNI51FSNjx4p0NmAMtjhJVqLeAShrRH0rRmdV0Ej1nAH/Z/ip zn7PqB+7j6PguNPfEU4ySHfS8BTprvmod60J//Asi9/2ymadcNkB5VXg fJD1DMBpnCK1aUqG8ieJFsMQuMrrYRkhy0TdrCxGtZmTCpOOxfOMtmKR rcQ= se. 300 IN NSEC 0-0.se. NS SOA TXT RRSIG NSEC DNSKEY
Эта NSEC запись показывает, что указанное имя не попадает под маску.

jhbatar.se. 300 IN RRSIG NSEC 5 2 7200 20110613032526 20110530130445 24825 se. DWXq1ZlzuA9w0McNHWjpLO55H08rkWjtBDd8TewUCYnljM//1oXEvVcJ ORT9AxXoz9TMOEku2wFGydceX5zs4PZLwnEC+ieXu3ri/B0S533XpmKe 6CgQTda6maCvoF8d1gOc2nIbd7zKjdOl2ujMVJKCb6Bv3yoy4WjL3gka Ufk= jhbatar.se. 300 IN NSEC jhbeagleklubb.se. NS RRSIG NSEC
А уже эта NSEC запись говорит о том, что доменное имя не обнаружено.

Недостаток NSEC очевиден — кто угодно может получить содержимое зоны просто опросив для каждого имени эту запись. В связи с этим механизм был доработан и появились записи NSEC3, в которых доменные имена хэшируются.
NSEC3 для вычисления хэша может использовать соль, помимо соли можно задать количество итераций. Стоит заметить, что увеличение количества итераций приводит к увеличению нагрузки как на резолвер, так и на авторитетный сервер, причем на последний в большей степени. Это происходит из-за того, что для возвращения NXDOMAIN, авторитетный сервер должен вычислить хэш, и не один. Процесс описан в RFC 5155.

Кроме того, NSEC3 запись имеет поле флагов, которого нет у NSEC. На данный момент определен только один флаг — OPT-OUT, благодаря которому существует возможность подписывать не всю зону (что при больших размерах может быть весьма длительным процессом), а только те доменные имена, для которых есть DS записи.
С одной стороны OPT-OUT позволяет сильно сократить время подписи, однако при его использовании, наличие у злоумышленника доступа к файлу зоны позволяет ему добавить незащищенную запись, которая в дальнейшем может доставить проблемы.

Механизм работы

Допустим мы хотим узнать адрес test.bar.example.com:

Мы запрашиваем доменное имя у резолвера;
Резолвер выставляет бит DO и запрашивает test.bar.example.com у корневого сервера;
Резолвер знает, что корневая доменная зона подписана — у него указан ключ или хэш ключа для нее (так называемый trust-anchor), поэтому он запрашивает у корневого сервера DNSKEY записи для корневой зоны и сверяет полученное с имеющимся;
Корневой сервер не знает такого доменного имени, да и вообще максимум что ему известно — на каких серверах располагается зона com, он и сообщает адреса этих серверов нашему резолверу вместе с подписанной DS записью для зоны com;
Резолвер валидирует DS запись полученным и проверенным ZSK ключом корневой зоны;
Теперь резолвер знает, что зона com подписана, так что он спрашивает у ее DNS сервера DNSKEY и валидирует их, после чего интересуется про bar.example.com. Естественно, что сервер зоны com про таких не знает, ему только известно, что зона example.com живет на ns.example.com и ns1.example.com, именно это он и отвечает резолверу вместе с — да-да — DS записью;
Так резолвер выстроил цепочку доверия до example.com, где он узнает серверы имен зоны bar.example.com и ее DS;
В конце концов резолвер итеративно узнает адреса DNS серверов, отвечающих за bar.example.com, идет к ним и наконец-то получает желаемое, валидирует всю информацию и отдает нам адресную запись, выставив в ответе бит AD.

При невозможности что-то провалидировать резолвер вернет servfail.

Оказываемые эффекты

Исходящий трафик авторитетного DNS сервера увеличивается примерно в 4 раза;
Размер файла зоны после подписи (без OPT-OUT) вырастает в 6-7 раз;
Увеличение длины ключа приводит к заметному снижению qps резолвера, на авторитетный сервер влияет в меньшей степени;
Наоборот действует увеличение кол-ва итераций при использовании NSEC3;
DNSSec приводит к значительному увеличению DNS ответа и, следовательно, необходимо чтобы все сетевое оборудование корректно работало с DNS пакетами более 512 байт.

Зачем это нужно

Это сложный вопрос. Во-первых, надо учитывать создаваемые эффекты; во-вторых, требуется организовать надежное хранилище для ключей; в-третьих, следить за ротацией ключей; в-четвертых, следить за сроком годности подписей; в-пятых, DNSSec усиливает эффект amplified ddos.
Все это является платой за то, чтобы быть уверенным в информации, получаемой от авторитетных DNS серверов. Сейчас, правда, сообщество придумывает что еще можно включить в DNSSec, чтобы его можно было монетизировать, а некоторые и вовсе задаются весьма смелыми и интересными вопросами, например Phil Regnauld, член научного совета AFNIC, поинтересовавшийся «Will DNSSEC bring down the certificate industry?» на семинаре этого совета.

Что почитать на эту тему

Отсюда стоит начать раскопки;
Очень подробный гайд по внедрению;
Здесь рассказывается про зоны RU, SU, XN--P1AI;
И, конечно же, rfc 4033-4035.

Теги:

Хабы:

Системное администрирование