TOC

Как настроить DNSSEC на сервере имен NSD в Ubuntu 14.04

О DNSSEC

Расширения безопасности DNS (DNSSEC) - это технология, разработанная для защиты приложений и распознавателей DNS от использования поддельных или манипулированных данных DNS.

  • Проблема: * + Злоумышленник может подделать ответ DNS или poison кеш DNS и перенаправить пользователей на вредоносный сайт с допустимым доменным именем в их адресной строке.

  • Решение: * + DNSSEC настроил авторитетные DNS-серверы для предотвращения такого рода атак путем цифровой подписи каждой записи ресурса закрытым ключом. DNS-распознаватель проверяет целостность записи зоны, используя открытый ключ и цифровую подпись.

О НРД

Name Server Daemon (* NSD *) - это официальное программное обеспечение DNS-сервера с открытым исходным кодом, разработанное NLNet Labs. Он использует файлы зон в стиле BIND для легкой настройки.

Только DNS-сервер, имеющий полномочия, предоставляет ответы на запросы для зон, за которые он отвечает. В этой статье мы будем настраивать наши собственные авторитетные серверы имен NSD для двух доменных имен. Мы настроим NSD для предоставления подписанных ответов DNSSEC для обоих доменных имен.

Предпосылки

Эта статья требует от читателя знания в следующих областях:

Domain Name Nameservers

example.com

master.example.com

slave.example.com

foobar.org

master.example.com

slave.example.com

  • Следующие две капли будут запускать NSD: *

Hostname IP Address

master.example.com

1.1.1.1

slave.example.com

2.2.2.2

Вы должны заменить IP-адресом своего главного сервера имен на протяжении всего руководства, а также IP-адресом своего подчиненного сервера имен.

Цель этой статьи - показать, как настроить сервер имен, который, независимо от статуса DNSSEC в его собственном домене, может обслуживать домены, которые используют DNSSEC. Домен используется для серверов имен для удобства; не требуется настраивать DNSSEC для доменного имени сервера имен. Серверы имен можно так же легко установить на master.my-soa.com и slave.my-soa.com.

Вам также нужно иметь в виду IP-адрес, по которому вы хотите разрешить свои домены. Если у вас еще не настроены веб-хосты для этих доменов, вы можете создать еще один тестовый дроплет, который будет запускать веб-сервер. Выберите изображение * LAMP на Ubuntu 14.04 *.

изображение: https: //assets.digitalocean.com/articles/dnssec_nsdnameserver/1.png [ЛАМПА на Ubuntu 14.04 image]

IP-адрес капли ЛАМПЫ будет * 3.3.3.3 *. Этот IP-адрес будет использоваться в качестве записи A для обоих доменных имен, чтобы проверить, разрешаются ли они из веб-браузера. Вы должны заменить ваш IP-адрес (адреса) веб-хоста на протяжении всего учебника.

DNSSEC Терминология

DNSSEC работает над концепцией криптографии public-key и вводит новые типы записей DNS. В этом разделе мы обсудим некоторые термины, которые будут использоваться в этой статье.

Keys

  • * ZSK *: Z one S igning K ey - это частная / открытая пара ключей. Закрытый ключ создает цифровую подпись для всех записей DNS, в то время как открытый ключ используется распознавателем DNS для его проверки.

  • * KSK *: K ey S igning K ey - это частная / открытая пара ключей. Закрытый ключ подписывает ZSK, а открытый ключ проверяет его.

документация

  • * DNSKEY *: Содержит открытые ключи KSK и ZSK.

  • * RRSIG *: R источник R ecord Sig характер существует для каждой записи и обеспечивает цифровую подпись этой записи. Запись RRSIG основана на самой записи и ZSK.

  • * DS *: Запись игнорирования D elegance S используется для проверки целостности записей DNSKEY. Эта запись заносится в панель управления регистратора домена и находится на официальном сервере имен ДВУ.

Настройка DNSSEC для домена требует соответствующих записей как для серверов имен, так и для регистратора.

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

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

Так как вы это настроите? Во-первых, для каждого домена вы должны сгенерировать две уникальные пары закрытых / открытых ключей на сервере имен. Открытые ключи домена хранятся в записях DNSKEY, которые перечислены в файле зоны для этого домена. Два других типа записей, записи DS и записи RRSIG, генерируются из записей DNSKEY. Эти три типа записей все криптографически связаны. То есть, увидев одну из трех, вы можете сказать, действительны ли две другие.

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

Затем вы загружаете запись DS в свой регистратор, который публикует ее на серверах имен TLD для вашего домена. Поскольку единственный способ опубликовать запись DS - через регистратора, это доказывает, что владельцем домена является тот, кто опубликовал запись DS, что подтверждает достоверность этой записи DS. Целью записи DS является создание цепочки authentication между сервером имен TLD и серверами имен, которые вы используете для своего домена. Это работает, потому что запись DS основана на DNSKEY, поэтому любой распознаватель DNS может проверить, соответствует ли ваш DNSKEY записи DS и, таким образом, является ли она правильной для домена.

Запись RRSIG - это подпись, которая сопровождает другие типы записей DNS (например, A, MX и т. Д.), Которая основана на самом значении записи (например, IP-адресе) и DNSKEY.

С настроенными записями DNSKEY, DS и RRSIG DNSSEC теперь настроен для вашего домена.

Далее мы поговорим об этом с точки зрения пользователя. Скажем, что пользователь хочет посетить ваш домен, поэтому он запрашивает преобразователь DNS для записи A вашего домена. В этом примере рекурсивный распознаватель DNS уже проверил действительность DNSKEY для этого домена по сравнению с записью DS на серверах имен TLD, хотя он также может легко проверить это в первый раз.

  • Вот иллюстрация того, как работает этот запрос: *

    1. Пользователь отправляет запрос на запись A, которая достигает рекурсивного DNS-сервера с поддержкой DNSSEC.

    2. DNS-сервер обнаруживает, что запрашиваемый домен поддерживает DNSSEC, обнаруживая его записи DS. Он отправляет запрос на запись A с DO bit вашим авторитетным серверам имен.

    3. Ваши серверы имен отвечают записью A и соответствующей записью RRSIG.

    4. Рекурсивный DNS-сервер вычисляет значение записи A + запись DNSKEY, которую он имеет в файле, и сравнивает ее с дешифрованной записью RRSIG. (Он может проверить запись DS, чтобы сначала проверить запись DNSKEY, если ее нет в файле.) Если хэши совпадают, DNS-сервер возвращает запись A пользователю, который теперь может посетить ваш веб-сайт.

изображение: https: //assets.digitalocean.com/articles/dnssec_nsdnameserver/2.png [проверка DNSSEC]

Чтобы узнать больше о том, как работает DNSSEC, вы можете прочитать this article. Более полный список терминологии DNSSEC см. По адресу this.

Step Zero - проверка поддержки домена и регистратора

Прежде чем принять решение о настройке DNSSEC на своих собственных серверах имен NSD, убедитесь, что расширение вашего домена (.com, .org и т. Д.) И регистратор поддерживают DNSSEC.

Чтобы проверить, готово ли расширение домена к DNSSEC, запросите его запись DNSKEY с помощью следующей команды:

dig DNSKEY . +short

Это должно вернуть открытые ключи следующим образом:

256 3 8 AQPbokupKUJ5LLAtDEs6R3nDOHxF2jQEFtJEFTiDcfbsZia4fg3EK9Wv D9ZIr+7t2n1ddqRGHnTTInHTjduaKFPqm2iKaDHdrc6095o1mzqojnd1 bTtI45XNu61QmT5IU4VPT7HDUSby+53gLAsjLPyNsNEMp7Cc52RVxCHD no9efw==
257 3 8 AQPDzldNmMvZFX4NcNJ0uEnKDg7tmv/F3MyQR0lpBmVcNcsIszxNFxsB fKNW9JYCYqpik8366LE7VbIcNRzfp2h9OO8HRl+H+E08zauK8k7evWEm u/6od+2boggPoiEfGNyvNPaSI7FOIroDsnw/taggzHRX1Z7SOiOiPWPN IwSUyWOZ79VmcQ1GLkC6NlYvG3HwYmynQv6oFwGv/KELSw7ZSdrbTQ0H XvZbqMUI7BaMskmvgm1G7oKZ1YiF7O9ioVNc0+7ASbqmZN7Z98EGU/Qh 2K/BgUe8Hs0XVcdPKrtyYnoQHd2ynKPcMMlTEih2/2HDHjRPJ2aywIpK Nnv4oPo/

Отсутствие вывода указывает на отсутствие поддержки DNSSEC для этого расширения домена.

Недостаточно, если ваш TLD поддерживает DNSSEC; Регистратор домена также должен иметь возможность ввода записей DS в своей панели управления. Это может быть подтверждено поиском в Google «dnssec» или запросом у регистратора напрямую. Ниже приведены некоторые популярные регистраторы, которые поддерживают DNSSEC:

После того как вы подтвердите, что ваш TLD и регистратор доменов поддерживают DNSSEC, вы можете приступить к настройке пользовательских серверов имен.

Шаг первый - установить и настроить NSD на обоих серверах

На этом этапе мы установим и настроим NSD на главном и подчиненном серверах. Мы также настроим записи DNS для домена * example.com *. Этот раздел будет служить быстрой настройкой для NSD. Прочитайте https://www.digitalocean.com/community/tutorials/how-to-use-nsd-an-authoritative-only-dns-server-on-ubuntu-14-04 раскладать эту статью] для получения подробных инструкций по настройке НРД.

Мастер Сервер

В дополнение к пакету сервера NSD для главного сервера требуются следующие пакеты:

  • * ldnsutils *: для генерации ключа DNSSEC и подписания зоны.

  • * hasged *: для increasing entropy. Установка этого пакета ускоряет процесс генерации ключей.

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

useradd -r nsd

Опция создает системного пользователя. Обновите репозиторий и установите NSD, ldnsutils и hasged.

apt-get update
apt-get install nsd ldnsutils haveged

Передача зоны DNS с главного сервера на подчиненный сервер обеспечивается общим секретом. Используйте следующую команду для генерации секрета случайным образом:

dd if=/dev/random count=1 bs=32 2> /dev/null | base64

Запишите выходную строку. Мы будем использовать его в файле конфигурации как главного, так и подчиненного серверов.

Создайте отдельный каталог для файлов зон:

mkdir /etc/nsd/zones

Отредактируйте файл конфигурации NSD:

nano /etc/nsd/nsd.conf

Первый - это раздел, в котором указаны расположения файлов зон, журналов и файлов PID (ID процесса):

server:
   username: nsd
   hide-version: yes
   zonesdir: "/etc/nsd/zones"
   logfile: "/var/log/nsd.log"
   pidfile: "/run/nsd/nsd.pid"

Директива запрещает NSD returning его версию, когда запрос класса CHAOS сделан.

В разделе мы определяем ключ с именем * mykey * и вводим ранее сгенерированный секрет.

key:
   name: "mykey"
   algorithm: hmac-sha256
   secret: ""

Каждый раздел будет содержать имя домена, имя файла зоны и сведения о своем подчиненном сервере:

zone:
   name:
   zonefile: .zone
   notify:  mykey
   provide-xfr:  mykey
zone:
   name:
   zonefile: .zone
   notify:  mykey
   provide-xfr:  mykey

Строки и должны иметь * IP-адрес подчиненного сервера *. Сохраните файл и создайте файл зоны для * example.com *.

nano /etc/nsd/zones/.zone

Мы добавим следующие данные в файл зоны. Переменные не помечены, так как вам нужно будет настроить все записи:

$ORIGIN example.com.
$TTL 1800
@       IN      SOA     master.example.com.    email.example.com. (
                       2014080301
                       3600
                       900
                       1209600
                       1800
                       )
@       IN      NS      master.example.com.
@       IN      NS      slave.example.com.
master  IN      A       1.1.1.1
slave   IN      A       2.2.2.2
@       IN      A       3.3.3.3
www     IN      CNAME   example.com.
@       IN      MX      10 aspmx.l.google.com.
@       IN      MX      20 alt1.aspmx.l.google.com.
@       IN      MX      20 alt2.aspmx.l.google.com.
@       IN      MX      30 aspmx2.googlemail.com.
@       IN      MX      30 aspmx3.googlemail.com.

Сохраните этот файл и создайте файл зоны для * foobar.org *.

nano /etc/nsd/zones/.zone

Второй файл зоны:

$ORIGIN foobar.org.
$TTL 1800
@       IN      SOA     master.example.com.    email.example.com. (
                       2014080301
                       3600
                       900
                       1209600
                       1800
                       )
@       IN      NS      master.example.com.
@       IN      NS      slave.example.com.
@       IN      A       3.3.3.3
www     IN      CNAME   foobar.org.
@       IN      MX      0 mx.sendgrid.com.

Сохраните файл и проверьте наличие ошибок конфигурации с помощью команды:

nsd-checkconf /etc/nsd/nsd.conf

Действительная конфигурация не должна ничего выводить. Перезагрузите сервер NSD:

service nsd restart

Проверьте, действуют ли записи DNS для доменов, используя команду.

dig ANY . @localhost +norec +short

Пример вывода из этой команды:

master.example.com. email.example.com. 2014080301 3600 900 1209600 1800
master.example.com.
slave.example.com.
3.3.3.3
10 aspmx.l.google.com.
20 alt1.aspmx.l.google.com.
20 alt2.aspmx.l.google.com.
30 aspmx2.googlemail.com.
30 aspmx3.googlemail.com.

Повторите команду для второго домена:

dig ANY . @localhost +norec +short

Мы успешно установили и настроили NSD на главном сервере, а также создали две зоны.

Подчиненный сервер

Для подчиненного сервера требуется только пакет NSD, поскольку на нем не производится генерация или подпись ключей.

Создайте системного пользователя с именем:

useradd -r nsd

Обновите репозиторий и установите NSD:

apt-get update
apt-get install nsd

Создайте каталог для файлов зоны:

mkdir /etc/nsd/zones

Отредактируйте файл конфигурации NSD:

nano /etc/nsd/nsd.conf

Добавьте директивы конфигурации:

server:
   username: nsd
   hide-version: yes
   zonesdir: "/etc/nsd/zones"
   logfile: "/var/log/nsd.log"
   pidfile: "/run/nsd/nsd.pid"

key:
   name: "mykey"
   algorithm: hmac-sha256
   secret: ""

zone:
   name:
   zonefile: .zone
   allow-notify:  mykey
   request-xfr:  mykey
zone:
   name:
   zonefile: .zone
   allow-notify:  mykey
   request-xfr:  mykey

Параметр for * mykey * должен быть точно таким же, как введенный на главном сервере. Используйте * IP-адрес главного сервера * в строках и.

Проверьте на ошибки конфигурации:

nsd-checkconf /etc/nsd/nsd.conf

Перезапустите службу NSD:

service nsd restart

Принудительно передайте зону для обоих доменов с помощью команды:

nsd-control force_transfer
nsd-control force_transfer

Теперь проверьте, может ли этот сервер отвечать на запросы для домена * example.com *.

dig ANY . @localhost +norec +short

Если это возвращает тот же результат, что и мастер, эта зона настроена правильно. Повторите команду для домена * foorbar.org *, чтобы проверить, правильно ли настроена его зона. Теперь у нас есть пара DNS-серверов NSD, которые являются полномочными для доменов * example.com * и * foobar.org *.

На этом этапе вы должны иметь возможность посещать свои домены в веб-браузере. Они разрешат сервер LAMP по умолчанию, который мы настроили, или какой хост вы указали.

Шаг второй - сгенерируйте ключи и подпишите зону

На этом этапе мы создадим пару (частную и общедоступную) ключей подписи зоны (ZSK) и ключей подписи ключа (KSK) для каждого домена. Команды в разделе должны выполняться на главном сервере, если не указано иное .

Измените текущий каталог на каталог зоны NSD:

cd /etc/nsd/zones

Команда генерирует файлы ключей и печатает их имена в формате + K <домен> + <алгоритм> + <идентификатор ключа> +. Вместо того, чтобы записывать это имя, мы назначим его переменной, чтобы на него можно было легко ссылаться позже.

Сгенерируйте ZSK в алгоритме:

export ZSK=`ldns-keygen -a RSASHA1-NSEC3-SHA1 -b 1024 `

Затем сгенерируйте KSK, добавив опцию к той же команде:

export KSK=`ldns-keygen -k -a RSASHA1-NSEC3-SHA1 -b 2048 `

Этот каталог теперь будет иметь следующие шесть дополнительных файлов:

  • 2 приватных ключа с расширением.

  • 2 открытых ключа с расширением.

  • 2 записи DS с расширением.

На третьем этапе мы будем генерировать записи DS другого типа * дайджеста, поэтому, чтобы избежать путаницы, удалите эти файлы записей DS.

rm $ZSK.ds $KSK.ds

Повторите команды для домена * foobar.org *:

export ZSK2=`ldns-keygen -a RSASHA1-NSEC3-SHA1 -b 1024 `
export KSK2=`ldns-keygen -k -a RSASHA1-NSEC3-SHA1 -b 2048 `
rm $ZSK2.ds $KSK2.ds

Команда используется для подписи зоны DNS. Опция этой команды принимает значение salt. Мы генерируем случайные символы, вычисляем хэш SHA1 и передаем это значение в виде соли.

ldns-signzone -n -p -s $(head -n 1000 /dev/random | sha1sum | cut -b 1-16) .zone $ZSK $KSK

Будет создан новый файл с именем * example.com.zone.signed *.

Выполните команду для домена * foobar.org *:

ldns-signzone -n -p -s $(head -n 1000 /dev/random | sha1sum | cut -b 1-16) .zone $ZSK2 $KSK2

NSD должен быть настроен на использование файлов зоны. Отредактируйте файл конфигурации:

nano /etc/nsd/nsd.conf

Измените параметр в разделе для обоих доменов.

zone:
   name: example.com
   zonefile: example.com.zone
   notify: 2.2.2.2 mykey
   provide-xfr: 2.2.2.2 mykey
zone:
   name: foobar.org
   zonefile: foobar.org.zone
   notify: 2.2.2.2 mykey
   provide-xfr: 2.2.2.2 mykey

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

nsd-control reconfig
nsd-control reload
nsd-control reload

Проверьте записи DNSKEY, выполнив запрос DNS:

dig DNSKEY . @localhost +multiline +norec

Это должно напечатать открытые ключи ZSK и KSK следующим образом:

; <<>> DiG 9.9.5-3-Ubuntu <<>> DNSKEY example.com. @localhost +norec +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14231
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;example.com.                IN DNSKEY

;; ANSWER SECTION:
example.com.            1800 IN DNSKEY 256 3 7 (
                               AwEAAbUfMzOJWWWniRSwDb2/2Q6bVpVoEPltPj0h5Qu6
                               hzBdYA4HJYlVXTJ6veNENI/5lV1y84Dhc47j4VAoA66F
                               j7xuTTZjzcuu0KAkQg8Jr2uCmmOuI/rZR7sWZMooHFZ1
                               JPPJZak8HKSNGvHXlMJiz9JPOA3ebJ/liG6lCGJshPah
                               ) ; ZSK; alg = NSEC3RSASHA1; key id = 2870
example.com.            1800 IN DNSKEY 257 3 7 (
                               AwEAAeMDpaVQJixHg1deUDBRRwVldJadgyRZPlieSoVf
                               ps3tYPvTD0nVBOQxenf+m4N/ALpnC5TH4GpxZLYS9IFc
                               rujudQrqA0UuTXBvIWP+XvuJ1yoyZCxO9PHV+GsefjI7
                               kvnmBD1V9UJlGVlHlB3YXHa3f/J5E0RujMnE4a19KG7b
                               HkYebK/2zjzhqXan9442VAG6jhw0lUUJZrCpZjMDEi9n
                               LhJOUSymxglQv1BftALmYnYcuHId9NCwZbvZMb7bS239
                               bm6ONjwqSHqW2slNhBnDVnng2tDfNwjR+eDz5oUbtw4b
                               LMtVACx1WzJEKbIN4rHY7aRe7Ao+4jvSJ8ozVrM=
                               ) ; KSK; alg = NSEC3RSASHA1; key id = 17385

;; Query time: 5 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Sep 04 01:37:18 IST 2014
;; MSG SIZE  rcvd: 467

Повторите команду для второго домена и проверьте ответ:

dig DNSKEY . @localhost +multiline +norec

Главный сервер теперь предоставляет * подписанные * ответы DNS.

рабыня

Эта зона должна быть перенесена на подчиненный сервер. Войдите на подчиненный сервер и принудительно перенесите обе зоны.

nsd-control force_transfer
nsd-control force_transfer

Запросите записи DNSKEY на этом сервере:

dig DNSKEY . @localhost +multiline +norec

Это должно вернуть тот же DNSKEY, который мы видели на главном сервере. Оба DNS-сервера были настроены для предоставления * подписанных ответов DNS *.

Шаг третий - Генерация записей DS

На этом шаге мы создадим две записи DS, которые на следующем шаге вы введете в панель управления регистратора домена. Записи DS будут иметь следующую спецификацию:

Algorithm Digest Type

DS record 1

RSASHA1-NSEC3-SHA1

SHA1

DS record 2

RSASHA1-NSEC3-SHA1

SHA256

  • Следующие команды должны выполняться на главном сервере. *

Команда генерирует записи DS из подписанного файла зоны. Перейдите в каталог файлов зоны и выполните команды:

cd /etc/nsd/zones
ldns-key2ds -n -1 .zone.signed && ldns-key2ds -n -2 .zone.signed

Опция использует SHA1 в качестве хэш-функции, а SHA256 - для той же. Опция записывает результирующую запись DS в стандартный вывод вместо файла.

Это возвращает две строки вывода:

example.com. 1800    IN      DS      17385 7 1 c1b9f7f1425bc44976dc19165e48c60032e7820d
example.com. 1800    IN      DS      17385 7 2 98216f4d66d24dbb752c46523a747a97bbad49d5846bbaa6256b6950b4a40995

В следующей таблице показано каждое поле этих записей DS:

Key tag Algorithm Digest type Digest

DS record #1

17385

7

1

c1b9f7f1[…]

DS record #2

17385

7

2

98216f4d[..]

Создайте записи DS для * foobar.org *:

cd /etc/nsd/zones
ldns-key2ds -n -1 .zone.signed && ldns-key2ds -n -2 .zone.signed

Запишите все фрагменты всех четырех записей DS (по две на домен), как показано в таблице выше. Они понадобятся нам на следующем этапе.

Шаг четвертый - Настройка записей DS с регистратором

В этом разделе мы добавим записи DS в панель управления регистратора домена. Это публикует записи DS на серверах имен домена верхнего уровня (TLD). Этот шаг будет использовать панель управления GoDaddy в качестве примера.

Войдите в GoDaddy и выберите свое доменное имя.

  • Только первая настройка сервера имен: *

Раздел * Host Names * необходимо выполнить один раз, чтобы впервые настроить серверы имен. Если ваш домен сервера имен отличается от * my-soa.com *, вы должны выполнить этот шаг только для домена сервера имен *.

Нажмите * Управление * в разделе * Имена хостов *.

изображение: https: //assets.digitalocean.com/articles/dnssec_nsdnameserver/3.png [Имена хостов GoDaddy]

Некоторые регистраторы могут называть это «дочерними серверами имен». Нажмите * Добавить имя хоста * и создайте имя хоста * master. *, Указывая IP-адрес первой капли.

изображение: https: //assets.digitalocean.com/articles/dnssec_nsdnameserver/4.png [Добавление имен хостов]

Нажмите * Добавить *. Повторите этот шаг еще раз и создайте имя хоста * slave. *, Указывающее на IP-адрес второй капли.

  • Все домены: *

Эти два имени хоста должны быть установлены в качестве серверов имен для этого домена. Нажмите * Manage * в разделе * Nameservers * и добавьте их оба.

изображение: https: //assets.digitalocean.com/articles/dnssec_nsdnameserver/5.png [Добавление серверов имен]

Нажмите * Управление * в разделе * DS records *.

изображение: https: //assets.digitalocean.com/articles/dnssec_nsdnameserver/6.png [GoDaddy управляет записями DS]

Заполните данные в соответствующих полях. При необходимости обратитесь к таблице на предыдущем шаге.

image: https: //assets.digitalocean.com/articles/dnssec_nsdnameserver/7.png [Введите ключевой тег, алгоритм, тип дайджеста и дайджест для первой записи DS.]

image: https: //assets.digitalocean.com/articles/dnssec_nsdnameserver/8.png [Введите ключевой тег, алгоритм, тип дайджеста и дайджест для второй записи DS.]

Сохраните обе записи.

Изображение: HTTPS: //assets.digitalocean.com/articles/dnssec_nsdnameserver/9.png [изображение]

Через несколько минут запросите записи DS.

dig DS . +trace +short | egrep '^DS'

Вывод должен содержать обе записи DS.

DS 17385 7 2 98216F4D66D24DBB752C46523A747A97BBAD49D5846BBAA6256B6950 B4A40995 from server 192.55.83.30 in 1 ms.
DS 17385 7 1 C1B9F7F1425BC44976DC19165E48C60032E7820D from server 192.55.83.30 in 1 ms.

Выполняя эти шаги для второго домена, убедитесь, что вы установили серверы имен в соответствующий домен сервера имен.

изображение: https: //assets.digitalocean.com/articles/dnssec_nsdnameserver/10.png [Второй сервер доменных имен]

Для этого домена не нужно создавать имена хостов.

Шаг пятый - проверка работы DNSSEC

DNSSEC можно проверить на следующих сайтах:

Успешный тест с первого сайта показывает следующий результат:

изображение: https: //assets.digitalocean.com/articles/dnssec_nsdnameserver/11.png [тест DNSSEC]

Обратите внимание на отмеченные линии. Проще говоря, они читают:

  1. DS запись № 2 (тип дайджеста SHA256) проверяет KSK (идентификатор ключа 17385)

  2. KSK (идентификатор ключа 17385) проверяет другой DNSKEY (ZSK)

  3. ZSK (идентификатор ключа 2870) проверяет подпись записи А

И главный, и подчиненный сервер теперь предоставляют ответы DNSSEC.

Вы также должны иметь возможность просматривать оба домена в своем веб-браузере. Они должны указывать на страницу Apache / Ubuntu по умолчанию на тестовом веб-сервере, который мы настроили на 3.3.3.3, или на любые веб-хосты, которые вы указали в записях * @ * доменов.

Изменение записей зоны

Для изменения записи зоны необходимо отредактировать файл без подписи (* .zone *). После изменения серийный номер SOA должен быть увеличен, и зона должна быть снова подписана, чтобы изменения вступили в силу.

Сериал SOA имеет следующий формат.

YYYYMMDD

При внесении изменений в файлы зоны установите текущую дату. Таким образом, при внесении первого изменения 22 сентября 2014 года серийный номер будет следующим:

20140922

Первые две цифры следует увеличивать при внесении последующих изменений в тот же день. Если вы забудете увеличить последовательность SOA, изменения, внесенные в файл зоны, не будут переданы на подчиненный сервер.

  • Примечание: внесение изменений в файл + .signed + напрямую приведет к аннулированию подписи и приведет к сбою проверки. *

Вместо того, чтобы вводить длинные команды каждый раз, чтобы подписать зону, мы создадим скрипт оболочки. Создайте файл * на главном DNS-сервере * и отредактируйте его.

nano /usr/local/bin/dnszonesigner

Вставьте следующий код:

#!/bin/bash
PDIR=`pwd`
ZONEDIR="/etc/nsd/zones" #location of your zone files
DOMAIN=$1
cd $ZONEDIR
KSK=$(basename $(grep -r "`grep '(ksk)' $DOMAIN.zone.signed | cut -f3-10`" K$DOMAIN.*.key | cut -d':' -f1) .key)
ZSK=$(basename $(grep -r "`grep '(zsk)' $DOMAIN.zone.signed | cut -f3-10`" K$DOMAIN.*.key | cut -d':' -f1) .key)
/usr/bin/ldns-signzone -n -p -s $(head -n 1000 /dev/random | sha1sum | cut -b 1-16) -f $ZONEDIR/$DOMAIN.zone.signed $DOMAIN.zone $ZSK $KSK
/usr/sbin/nsd-control reload $DOMAIN
/usr/sbin/nsd-control notify $DOMAIN
cd $PDIR

Вы должны распознать большинство из этих строк в руководстве, где мы выполнили их вручную.

Сделайте этот файл исполняемым:

chmod +x /usr/local/bin/dnszonesigner

Теперь, после добавления, удаления или редактирования записей DNS, убедитесь, что * увеличиваете последовательность SOA * и выполняете этот скрипт.

dnszonesigner

Этот сценарий оболочки работает из любого каталога, поскольку мы поместили его в каталог, определенный в переменной.

Дополнительное чтение

Дополнительная копия Шарон Кэмпбелл

Related