Связка dhcp с dns

BIND

Версии BIND 9.9, 9.10 и 9.11 поддерживают валидацию DNSSEC с автоматическим обновлением RFC 5011. Новейшие подверсии этих версий поступают вместе с KSK2017 как элементы якоря доверия.

Сначала удостоверьтесь, что в файле конфигурации настроена валидация DNSSEC. В разделе должна отображаться строка или . Если настроена в режим , то ручное обновление программного обеспечения или конфигурации не требуется. Необходимо просто перезапустить программное обеспечение, используя привычную вам команду завершения работы и запуска BIND; это обеспечит активацию новейшей версии якорей доверия в .

Если конфигурация показана как , перед выполнением дальнейших шагов вы должны изменить ее на и перезапустить свой сервер.

Если у вас есть возможность обновления программного обеспечения:

Выполните обновление до новейшей подверсии BIND 9.9, BIND 9.10 или BIND 9.11 тем же способом, который вы использовали для установки программного обеспечения. Если на вашем оборудовании используется программное обеспечение BIND 9.8, поддержка которого уже прекращена, его необходимо обновить до версии BIND 9.9 или более поздней. Следует использовать подверсию не ранее:
- BIND 9.9.10
- BIND 9.10.5
- BIND 9.11.1
Обязательно удостоверьтесь, что раздел в файле конфигурации содержит строку .
Прекратите работу старой версии BIND и запустите новую версию, используя привычную вам команду завершения работы и запуска BIND.

Если у вас нет возможности обновления программного обеспечения:

Обновите файл , чтобы включить в него новый якорь доверия. Файл должен храниться в том же каталоге, где создаются другие файлы BIND. Как вариант, если файл named.conf содержит раздел , где перечислены якоря доверия, можно обновить этот раздел. Отредактированный файл или раздел конфигурации должны содержать следующее:

managed-keys { 
	. initial-key 257 3 8 "AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF 
		FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX 
		bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD 
		X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz 
		W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS 
		Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq 
		QxA+Uk1ihz0="; 

	. initial-key 257 3 8 "AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3 
		+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv 
		ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF 
		0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+e 
		oZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd 
		RUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwN 
		R1AkUTV74bU="; 
};

Список уведомлений об ошибках в работе DNS-серверов

Атакуем dhcp Сообщение об ошибке	Возможные причины	Рекомендации по устранению
1. При очередной сверке серийного номера зоны (SOA serial number) было зафиксировано, что номер зоны на первичном сервере меньше, чем номер на вторичном сервере.	Ошибка конфигурации первичного (primary) DNS-сервера	Обратитесь к администратору первичного сервера для устранения неисправности
2. При попытке очередного обновления содержимого зоны первичный DNS-сервер сообщил, что зоны не существует.	Неправильно указан IP-адрес первичного (primary) DNS-сервера	Уточните IP-адрес первичного сервера и внесите изменения в настройки услуги
Ошибка конфигурации первичного (primary) DNS-сервера	Обратитесь к администратору первичного сервера для устранения неисправности
Зона не размещена на первичном (primary) DNS-сервере	Обратитесь к администратору первичного сервера за более подробными разъяснениями
3. При попытке очередного обновления содержимого зоны первичный DNS-сервер оказался недоступен.	Неправильно указан IP-адрес первичного (primary) DNS-сервера	Уточните IP-адрес первичного сервера и внесите изменения в настройки услуги
Отсутствие связи или плохая связь между вторичным и первичным DNS-серверами	Обратитесь к администратору первичного сервера или его провайдеру услуг Интернет
Ошибка конфигурации первичного (primary) DNS-сервера	Обратитесь к администратору первичного сервера для устранения неисправности
4. При очередном обновлении содержимого зоны был зафиксирован отказ от передачи зоны со стороны первичного сервера.	Неправильно указан IP-адрес первичного (primary) DNS-сервера	Уточните IP-адрес первичного сервера и внесите изменения в настройки услуги
Ошибка конфигурации первичного (primary) DNS-сервера	Обратитесь к администратору первичного сервера для устранения неисправности
Отклонен запрос на установление соединения с первичным DNS-сервером	Обратитесь к администратору первичного сервера для устранения неисправности
5. При очередном обновлении содержимого зоны в записях зоны обнаружена ошибка: присутствует запись типа CNAME для имени, совпадающего с именем зоны.	Ошибка в описании зоны на первичном DNS-сервере	Не используйте запись типа CNAME для имени, совпадающего с именем зоны
6. При очередном обновлении содержимого зоны в записях зоны обнаружена ошибка: на первичном DNS-сервере отсутствует SOA-запись для домена.	Ошибка конфигурации первичного (primary) DNS-сервера	Обратитесь к администратору первичного сервера для устранения неисправности
7. При очередном обновлении содержимого зоны в записях зоны обнаружена ошибка: на первичном DNS-сервере отсутствует NS-запись для домена	Ошибка в описании зоны на первичном DNS-сервере	Укажите NS-запись для домена в записях зоны.

Инфраструктура ключей

Как включить протокол dhcp на компьютере и роутере

ICANN выбрал такую модель, когда управление подписанием зоны происходит под контролем представителей интернет-сообщества (Trusted community representative, TCR). Представители выбирались из числа не связанных с управлением корневой зоной DNS. Выбранные представители занимали должности крипто-офицеров (Crypto Officer, CO) и держателей частей ключа восстановления (Recovery key shareholder, RKSH). CO были вручены физические ключи, позволяющие активировать генерацию ключа ЭЦП ZSK, а RKSH владеют смарт-картами, содержащими части ключа (KSK), используемого внутри криптографического оборудования. Некоторыми СМИ был сделан вывод, что процедуры, требующие присутствия CO или RKSH, будут проводиться в случае чрезвычайных ситуаций в сети. Однако в соответствии с процедурами ICANN, CO будут привлекаться каждый раз при генерации ключа подписания зоны (ZSK), до 4 раз в год, а RKSH — вероятно, никогда или в случае утраты ключей CO либо скомпрометированной корневой зоны.

Design

Global forwarders

Настройка маршрутизатора cisco как dhcp клиента

Check is done against the root zone.

check if the record «. IN SOA» @forwarder is resolvable (flags: RD)
1. failed: forwarder is not working
2. pass: continue with next step
check if the record «. IN SOA» @forwarder with EDNS0 is resolvable (flags: RD):
1. failed: forwarder does not support EDNS0 -> does not support DNSSEC
2. pass: continue with next step
check if the records «. IN SOA» @forwarder with EDNS0 has DNSSEC signatures (flags: RD, DO)
1. failed: forwarder does not support DNSSEC
2. pass: forwarder supports DNSSEC

Forward zones

Check is done against the forward zone. Check consists of 2 steps:

check before forwarder is added into LDAP/DNS
check after forwarder was added into LDAP/DNS

This check is not 100% reliable, but should catch the most issues. Also there can be false positive results and DNS administrator should check each forwarder. Check is executed just against one of many possible IPA DNS servers. This may cause, if any of the untested IPA DNS servers are configured different then these servers may not resolve forward zone properly.

Steps:

check if the record «fwzone IN SOA» @forwarder is resolvable (flags: RD)
1. failed: forwarder is not working
2. pass: continue with next step
check if the record «fwzone IN SOA» @forwarder with EDNS0 is resolvable (flags: RD):
1. failed: forwarder does not support EDNS0 -> does not support DNSSEC
2. pass: continue with next step
check if the record «fwzone IN SOA» @forwarder with EDNS0 has DNSSEC signatures (flags: RD, DO)
1. failed: forwarder does not support DNSSEC
2. pass: forwarder supports DNSSEC
add forwarder into LDAP/DNS
get answer «fwzone IN SOA» @IPA_DNS with EDNS0 (flags: RD, DO, CD); store result into ans_cd
check if the record «fwzone IN SOA» @IPA_DNS with EDNS0 (flags: RD, DO) is resolvable; store result into ans_do
1. NXDOMAIN: DNSSEC validation error, records was marked as not trusted.
2. pass: continue with next step
compare if ans_cd and ans_do contains the same answer (same values)
1. failed: values differ, zone is probably «shadowed», DNSSEC validation may not work
2. pass: DNSSEC validation seems to be working with this forwarder and forward zone

Проблемы внедрения и недостатки

Внедрение DNSSEC сильно задержалось по таким причинам, как:

Разработка обратно совместимого стандарта, который можно масштабировать до размера интернета;
Разногласия между ключевыми игроками по поводу того, кто должен владеть доменами верхнего уровня (.com, .net);
DNS серверы и клиенты должны поддерживать DNSSEC;
Обновлённые DNS-резолверы, умеющие работать с DNSSEC, должны использовать TCP;
Каждый клиент должен получить хотя бы один доверенный открытый ключ до того момента, как он начнёт использовать DNSSEC;
Возрастание нагрузки на сеть из-за серьёзно (в 6-7 раз) возросшего трафика от запросов;
Возрастание нагрузки на процессор сервера из-за потребности генерации и проверки подписей, так что может потребоваться замена некоторых недостаточно мощных DNS-серверов;
Увеличение требований для хранилищ информации об адресации, так как подписанные данные занимают гораздо больше места;
Нужно создавать, тестировать и дорабатывать программное обеспечение как серверной, так и клиентской части, что требует времени и испытаний в масштабах всего интернета;
Stub-резолверы не защищены от отравления кеша — валидация происходит на стороне рекурсивного сервера, клиент получает только ответ с выставленным битом AD;
Резко возросла опасность атаки DNS Amplification.

Большая часть этих проблем разрешена техническим интернет-сообществом.

Настройки услуги «Secondary»

Для функционирования услуги необходимо:

1. Указать имена предоставленных DNS-серверов при делегировании домена.

2. Настроить первичные и вторичные DNS-серверы.

В настройках услуги Secondary нужно указать IP-адрес первичного DNS-сервера, с которого следует получать файл зоны для домена. Необходимо указывать следующие имена DNS-серверов при делегировании доменов:

для доменов второго уровня, вида domain.ru

ns4-l2.nic.ru	91.217.20.1
ns8-l2.nic.ru	91.217.21.1
ns4-cloud.nic.ru	185.42.137.111 2a01:3f0:400::62
ns8-cloud.nic.ru	194.58.196.62 2a01:3f1:862::53

для доменов третьего уровня, вида domain.msk.ru

ns4-l3.nic.ru	91.217.20.5
ns8-l3.nic.ru	91.217.21.5

для доменов четвертого уровня, вида sub.domain.spb.ru

ns4-l4.nic.ru	91.217.20.9
ns8-l4.nic.ru	91.217.21.9

для доменов пятого уровня, вида sub.sub.domain.spb.ru

ns4-l5.nic.ru	91.217.20.13
ns8-l5.nic.ru	91.217.21.13

Разрешить скачивание зоны для следующих IP-адресов:

91.217.20.0/26

91.217.21.0/26

194.226.96.192/28

31.177.66.192/28

Для своевременного обновления зоны домена на серверах услуги Secondary, необходимо настроить на первичном DNS-сервере отправку notify этим серверам.

В случае если на первичном DNS-сервере отправка notify не будет настроена для перечисленных серверов, измененная зона домена на серверах ns4-l*.nic.ru, ns8-l*.nic.ru обновится в соответствии со значением параметра Refresh в SOA-записи, но не менее чем через 1 час.

На сервере Slave

Открываем на редактирование конфигурационный файл bind.

CentOS:

vi /etc/named.conf

Ubuntu:

vi /etc/bind/named.conf.local

И дописываем туда следующее:

zone «dmosk.ru» {
type slave;
file «slaves/dmosk.ru»;
masters { 192.168.0.10; };
};

* где dmosk.ru — зона (домен); slave — указание, что эта зона вторичная; slave/dmosk.ru — файл с записями зоны

Стоит обратить внимание, что используется относительный путь до файла — это значит, что каталог slave должен находиться в рабочей папке bind (ее путь определяется опцией directory). Можно также прописать абсолютный путь, например, /etc/bind/slave/dmosk.ru; 192.168.0.10 — IP-адрес первичного сервера, с которого будут вытянуты записи для созданной зоны

Создаем каталог для хранения вторичных зон.

CentOS:

mkdir /var/named/slaves

Ubuntu:

mkdir /var/cache/bind/slaves

* используемые в нашем примере каталоги применяются по умолчанию, но в Вашем случае они могут быть другими. Сверяйте данные по опции directory.

Чтобы настройки применились, необходимо перезапустить вторичный bind-сервер одной из команд:

systemctl reload named

systemctl reload bind

service bind9 reload

и перечитать информацию о настроенных DNS-зонах:

rndc reload

Проверяем, что файл с записями появился в базе bind:

CentOS:

ls /var/named/slaves/

Ubuntu:

ls /var/cache/bind/slaves

* команда выведет список файлов, среди которых должен быть наш (в конкретном примере, dmosk.ru).

Чтобы проверить работоспособность вторичного сервера BIND, запускаем консоль на любом компьютере в сети и вводим команду:

nslookup dmosk.ru 192.168.0.15

* где dmosk.ru — домен, который мы создали; 192.168.0.15 — IP-адрес резервного DNS-сервера, на котором мы и создавали slave-зону (в моем примере).

Настройка BIND в режиме кэширующего/неавторитативного DNS сервера

Для начала заставим BIND проверять полученные с определенной зоны данные, в результате клиенты которые будут использовать этот DNS сервер, будут защищены от подмены. Примеры буду показывать на основе Ubuntu. Устанавливаем BIND.

$ sudo apt-get install bind9

При самостоятельной сборке BIND необходимо активировать флаг “—with-openssl”.
После установки в /etc/bind/named.conf (в Ubuntu секция options вынесена в named.conf.options) добавляем следующие параметры:

options { 
      dnssec-enable yes;  # активируется поддержка DNSSEC
      dnssec-validation yes; # включается только для неавторитативного сервера
};

Далее необходимо сконфигурировать доверенные якоря (trust anchor) для тех зон/доменов, которые будут проверяться. Узнать нужный публичный ключ можно разными способами. Самый простой получить при помощи dig из DNS (как это показано выше), но в этом случае нужно четко знать, что ключ принадлежит именно тому, кому нужно. Проверить затем полученный ключ можно зайдя на один из сайтов зоны. Сегодня также доступны специальные сервисы в которых администраторы размещают trust anchor своих доменов . Далее заносим анкоры в файл в секцию trusted-keys файла named.conf:

zone "se." {
	type forward;
	forwarders { 212.247.7.228; };
};

trusted-keys {
# зона se
"se." 257 3 5
4w6RVY0ciZ/a8t1xy5FIxkg2U95ZV5VuLtwmx2rgtAbx
BACzTKrqYIpJ6LYSmjdQ3or+ZiO2tEMr53EwAjA6GKrf
qQ2S1y7Rblz2kaS6PK2Gh5MOCufhGozUhPQSGFTn/mV8
H9hlQptfcFCpFZrQQDAQqFAyxQginDgrwSripBk=

# Далее аналогично добавляются ключи и для других зон
# например для 4x4.org
"4x4.org" 256 3 5 "BEAAAAOxYIG/de/sEWGkMlMw/+WZHw72QMNAdCbneozk4BU4OCAbv9krBFnk52CZ67QPEfDMwV0k12Hr6sXkgZgeBpRV";
 };

Принцип думаю понятен. DLV записи создаются аналогичным образом (в options требуется dnssec-lookaside).

options {
     dnssec-lookaside . trust-anchor dlv.isc.org.;
};

Для удобства отслеживания запросов, можно создать отдельный канал для протоколирования запросов DNSSEC:

logging { 
          channel dnssec_log { 
                  file "log/dnssec" size 20m; 
                  print-time yes; 
                  print-category yes; 
                  print-severity yes;
                  severity debug 3;  
 }; 
category dnssec  { dnssec_log;  }; 
  }

Переконфигурируем BIND:

$ sudo rndc reconfig
$ sudo rndc flush

И проверяем запрос:

> dig @127.0.0.1 4x4.org +retry=1 +dnssec +multiline

Флаг “ad” в полученном ответе должен быть установлен:
В журнале будет показан полный путь проверки имени, все том числе и проблемы с ключами и т.п:

Nov  5 21:41:35 ubuntu named: /etc/bind/named.conf:47: trusted key 'ru.' has a weak exponent
Nov  5 21:43:53 ubuntu named: not insecure resolving 'samag.ru/A/IN': 89.253.192.21#53

И так далее.

Что такое и зачем нужен EDNS0

Что же добавляет EDNS0? В принципе, основным нововведением в нём является добавление нового типа псевдо-записи – OPT. Это специфичный тип RR-записи, которая не несёт DNS-данные (поэтому и “псевдо”), а нужна исключительно для стандартизации обмена служебной информацией. В подавляющем большинстве случаев использования в ней передаётся один блок информации – запись о максимальном обрабатываемом размере DNS-датаграммы.

Данный пункт действительно является важнейшим по простой причине – так как на момент разработки DNS сети были ещё очень медленные, а также в них было множество устаревших на данный момент протоколов канального уровня (сильно различавшихся технически и логически), то датаграмма DNS, в целях повышения её выживаемости в ходе путешествия по Интернету, ограничена размером в 512 байт (чтобы вместе с заголовками транспортного и сетевого уровня не первышать 576 байт). По сути, всё сделано для того, чтобы датаграмма выжила в среде с самым мелким MTU и без поддержки фрагментации. Понятное дело, что в современной ситуации, когда в DNS-ответ может быть добавлена пачка адресов (одно имя теперь часто, для отказоустойчивости, разрешается в несколько адресов сетевого уровня), притом крупных в плане занимаемого места – например, IPv6, ну и всякие дополнительные данные, например DNSSEC’овские RRSIG и DSKEY, да или просто TXT, такое ограничение (“не более 512 байт DNS-данных а то вдруг не дойдёт”) крайне неудобным.

Неприятностей добавляет простая проблема, исходящая из природы UDP – дело в том, что в случае отправки запроса или ответа отправитель, в случае тишины после, никак не сможет понять, что произошло – был ли пакет потерян по случайной причине, или отброшен промежуточным узлом по причине несоответствия максимальному размеру MTU, или потерялся по причине необходимости фрагментации на каком-то отрезке пути, а фрагментация DNS-пакета не получилась, или какой-либо другой. Плюс не надо забывать, что датаграммы от клиента к серверу, а после – в обратном направлении, совершенно необязательно будут идти по одной и той же трассе. В результате возможно множество различных неприятных ситуаций, вида “клиент отправил запрос серверу – сервер отработал, отправив ответ – ответ не дошёл, потому что великоват в части MTU, а клиент ошибочно думает, что сервер технически недоступен”, или “сервер отправил запрос другому серверу – запрос не дошёл, потому что тот сервер не поддерживает EDNS0 – клиент, изначально отправивший запрос, предполагает, что ближайший к нему сервер не работает, т.к. прошёл тайм-аут ожидания ответа”, и многих других. Поэтому понимание и представление о том, как всё это работает, резко помогает понять множество “странных багов DNS”.

Давайте попробуем протестировать работу EDNS0.

Infoblox NIOS

Infobox NIOS поддерживает валидацию DNSSEC, но еще не поддерживает валидацию DNSSEC с помощью автоматического обновления RFC 5011. Это означает, что для Infoblox NIOS необходимо настраивать новый набор якорей доверия при выходе любых изменений для якорей доверия.

Проверка текущих якорей доверия для NIOS включает следующие шаги:

Войдите в NIOS GUI
Перейдите в Data Management → DNS
Нажмите на «Grid DNS Properties» на панели инструментов
Включите «Advanced Mode»
Выберите вкладку «DNSSEC»
Прокрутите вниз до «Trust Anchors»
Все настроенные якори доверия отобразятся в таблице «Trust Anchors». Найдите запись с параметром «.» в столбце «Zone» и в столбце «Secure Entry Point». (Если данный якорь доверия отсутствует, ключ для подписания ключей корневой зоны не настроен.) Наведите указатель мыши на значение в столбце «Public Key», чтобы увидеть полное значение.

Для проверки на уровне участника:

Войдите в NIOS GUI
Перейдите в Data Management → DNS → Members/Servers
Выберите сервер DNS
Нажмите «Edit»
Включите «Advanced Mode»
Выберите «DNSSEC»
Прокрутите вниз до «Trust Anchors»
Все настроенные якори доверия отобразятся в таблице «Trust Anchors». Найдите запись с параметром «.» в столбце «Zone» и в столбце «Secure Entry Point». (Если данный якорь доверия отсутствует, ключ для подписания ключей корневой зоны не настроен.) Наведите указатель мыши на значение в столбце «Public Key», чтобы увидеть полное значение.

Чтобы помочь вам увидеть разницу между ключем для подписания ключей старого корня и нового, обращаем внимание, что ключ для подписания ключей старой корневой зоны будет выглядеть следующим образом:

AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0Ezr
AcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf
5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMj
JPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmR
LKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=

Ключ для подписания ключей новой корневой зоны (текущий) будет выглядеть так:

AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOL
AJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kv ArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3Eg
VLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWe
L3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfd RUfhHdY6+cn8HFRm+2hM8AnXGXws9555Kr
UB5qihylGa8subX2Nn6UwNR1AkUTV74bU=

Зачем нужна технология DNSSEC

DNS Security Extensions (DNSSEC) – технология, предназначена для повышения безопасности службы DNS за счет использования криптографических подписей, позволяющих однозначно удостоверится в подлинности информации, полученной от DNS сервера. Т.е. все запросы и ответы DNS сервера с поддержкой DNSSEC должны обладать цифровой подписью, верность которой может проверить клиент с помощью открытого ключа. Эти цифровые подписи создаются при подписывании зоны (применения к ней DNSSEC).

Упрощенно механизм проверки DNSSEC работает так: клиент отправляет запрос на DNS сервер, сервер возвращает DNS ответ с цифровой подписью. Т.к. клиент обладает открытым ключом центра сертификации, подписавшего записи DNS, он может расшифровать подпись (хэш-значение) и проверить ответ DNS. Для этого и клиент и сервер DNS должны быть настроены на использование одного якоря доверия (trust anchor). Trust anchor – предварительно настроенный открытый ключ, связанный с конкретной зоной DNS. Если DNS сервер поддерживает несколько зон, то может использоваться несколько якорей доверия.

Важно отметить, что основное предназначение DNSSEC – защита от подделки и модификации DNS-запросов и ответов. Но сами передаваемые по сети данные не шифруются (хотя конфиденциальность передаваемых DNS данных и может быть обеспечено с помощью шифрования, но это опционально и не является основной целью DNSSEC)

Основные компоненты DNSSEC определены в следующих стандартах RFC:

RFC 4033
RFC 4034
RFC 4035

Описание

Изначально Domain Name System (DNS) разрабатывался не в целях безопасности, а для создания масштабируемых распределённых систем. Со временем система DNS становится всё более уязвимой. Злоумышленники без труда перенаправляют запросы пользователей по символьному имени на подставные серверы и таким образом получают доступ к паролям, номерам кредитных карт и другой конфиденциальной информации. Сами пользователи ничего не могут с этим поделать, так как в большинстве случаев даже не подозревают о том, что запрос был перенаправлен — запись в строке браузера и сам сайт в точности такие, какими их и ожидает увидеть пользователь. DNSSEC является попыткой обеспечения безопасности при одновременной обратной совместимости.

DNSSEC была разработана для обеспечения безопасности клиентов от фальшивых DNS-данных, например, создаваемых DNS cache poisoning. Все ответы от DNSSEC имеют цифровую подпись. При проверке цифровой подписи DNS-клиент проверяет верность и целостность информации.

DNSSEC не обеспечивает конфиденциальность данных; в частности, все DNSSEC ответы аутентифицированны, но не шифруются. DNSSEC не защищает от DoS-атак непосредственно, хотя в некотором роде делает это косвенно.
Другие стандарты (не DNSSEC) используются для обеспечения большого количества данных, пересылаемых между серверами DNS.

DNSSEC for Users

Modern operating systems support DNSSEC validation out of the box—though not all of them. The alternative is to use a validating resolver in your local network, e.g. a home router with DNSSEC support.

If you’d like to experiment with a validating resolver on your computer, you may want to try Dnssec-Trigger (more information). Keep in mind that web browsers do not distinguish between DNSSEC validation failures and general DNS failures (there is no security warning like with HTTPS errors).

To re-run the above test, you also need to:

Flush the DNS cache of your OS (Windows: )
Restart browser or clear browser cache

Enable DNSSEC support in FreeIPA

Steps to enable DNSSEC support:

choose one server which will act as DNSSEC key master
enable DNSSEC signing for individulal DNS zones

DNSSEC key master

To enable DNSSEC in FreeIPA topology, exactly one FreeIPA replica has to act as the DNSSEC key master.
This replica is responsible for proper key generation and rotation.

Zone signing will not work without DNSSEC key master replica.

Following command will install DNSSEC key master role to a replica. This command can be run on FreeIPA server which is already configured as FreeIPA DNS server:

# ipa-dns-install --dnssec-master

The log file for this installation can be found in /var/log/ipaserver-install.log
==============================================================================
This program will setup DNS for the FreeIPA Server.

This includes:
  * Configure DNS (bind)
  * Configure SoftHSM (required by DNSSEC)
  * Configure ipa-dnskeysyncd (required by DNSSEC)
  * Configure ipa-ods-exporter (required by DNSSEC key master)
  * Configure OpenDNSSEC (required by DNSSEC key master)
  * Generate DNSSEC master key (required by DNSSEC key master)

NOTE: DNSSEC zone signing is not enabled by default

DNSSEC support is experimental!

Plan carefully, current version doesn't allow you to move DNSSEC
key master to different server and master cannot be uninstalled


To accept the default shown in brackets, press the Enter key.

Do you want to setup this IPA server as DNSSEC key master? : yes
Existing BIND configuration detected, overwrite? : yes
...

Please verify the file kasp.xml (/etc/opendnssec/kasp.xml) if it satisfies your DNSSEC configuration requirements.

Enable zone signing

Zones are not signed by default.
Zone signing has to be enabled per zone using following command:

$ ipa dnszone-add example.test. --dnssec=true
  Zone name: example.test.
  Active zone: TRUE
. . .
 Allow query: any;
 Allow transfer: none;
 Allow in-line DNSSEC signing: TRUE

$ ipa dnszone-mod example.test. --dnssec=true

To disable zone signing use command:

$ ipa dnszone-mod example.test. --dnssec=false

Modifying Zone Records

Each time you edit the zone by adding or removing records, it has to be signed to make it work. So we will create a script for this so that we don’t have to type long commands every time.

Save the file and make it executable.

Whenever you want to add or remove records, edit the and NOT the file. This file also takes care of incrementing the serial value, so you needn’t do it each time you edit the file. After editing it run the script by passing the domain name and zone filename as parameters.

You do not have to do anything on the slave nameserver as the incremented serial will ensure the zone if transferred and updated.

Тестим EDNS0 с нашего хоста

Чтобы проверить работоспособность EDNS0, необязательно быть DNS-сервером. Это можно сделать и при помощи утилиты nslookup.

Первым делом – запустим nslookup и скажем, что нас будут интересовать только ответы TXT-типа. Это просто:

Теперь запросим (я предполагаю, что Ваш nslookup уже нацелен на тот сервер, который Вы хотите тестировать – если нет, то настройте его явно командой ) специальный хост – . В качестве ответа Вы должны получить что-то вида:

Плохой китайский EDNS0-ответ(кликните для увеличения до 877 px на 283 px)Учебный центр Advanced Traininginfo@atraining.ruhttps://www.atraining.ru/

или

Хороший китайский EDNS0-ответ(кликните для увеличения до 877 px на 283 px)Учебный центр Advanced Traininginfo@atraining.ruhttps://www.atraining.ru/

Изучим. По сути, каждый из ответов состоит из 6 строк, три последних из которых явно говорят, когда и откуда проводился тест, а также какой максимальный размер EDNS0-датаграммы заказывался. Хорошо заметно, что источником запроса является провайдерский сервер – т.е. тестовый сервер, который , фактически тестирует возможность отправки EDNS0-датаграмм до узла 218.77.159.18, являющегося адресом DNS-сервера провайдера – я даже, благодаря специфике китайской сети, в которой нахожусь, точно не могу сказать, где он, но где-то недалеко:

В поисках китайского провайдерского DNS-сервера(кликните для увеличения до 877 px на 511 px)Учебный центр Advanced Traininginfo@atraining.ruhttps://www.atraining.ru/

Теперь про первые три строки в ответе . Они, по сути, отображают цепочку CNAME вида rst.xAAAA.rs.dns-oarc.net -> rst.xBBBB.xAAAA.rs.dns-oarc.net -> rst.xCCCC.xBBBB.xAAAA.rs.dns-oarc.net, где AAAA BBBB CCCC – это размеры, в байтах, удачно обработанных DNS-ответов. По сути, это некое “пингование” EDNS0-запросами с игрой внутри RR OPT, по аналогии с пингом пакетами с запрещённой фрагментацией с целью методом проб и ошибок выяснить PMTU. На картинках заметно, что размер плавает очень сильно – так бывает в провайдерских сетях, где не всё настроено однотипно. В моём случае оба ответа, в общем, плохие – хорошим считается ответ, где будет показано, что отработала датаграмма в 4К. Очень плохим будет вариант, когда нет ни одного ответа более 1.4К – это значит, что где-то на пути банально не работает фрагментация и всё, что не влезает в стандартный MTU ethernet’а, не выживает – так что у меня просто плохо, а не очень.

Теперь попробуем тестировать более цивилизованным способом.

Как выглядит алгоритм работы DNS Resolver, который с NRPT

Приложение запрашивает какое-либо имя. Если это имя не кончается на точку, система дополняет его суффиксом.
Получившееся имя смотрят в локальном кэше. Если результат есть (что негативный, что позитивный) – он возвращается клиенту. Если нет – далее.
Проверяется, подпадает ли этот FQDN под одно из правил NRPT. Если не подпадает, или подпадает под правило-исключение, в котором стоит “не запрашивать DNSSEC и/или DirectAccess”, то запрос обрабатывается нормально – DNS Client вспоминает, что он тупой стаб и делает рекурсию по списку известных ему DNS-серверов.
Если запрос подпал только под одно NRPT-правило, то он обрабатывается согласно ему. Если под несколько – то правила выстраиваются в порядке приоритета. По порядку:
- Первым идёт FQDN-правило, потому что 100% подпадение.
- Потом правила на совпадение префиксов – выбирается то, у которого совпал максимум символов (т.е. если мы запрашивали, например, , то если такого FQDN нет, нам подойдёт префиксовое правило про , после – и про )
- Потом правила на суффиксы – тоже выиграет самое длинное совпадение, т.к. полного-то уже не будет точно.
- Ну а потом, что логично – точка.
И запрос обрабатывается самым лучшим по приоритету правилом. Одним.