
Я настраиваю проверку домена-lookaside. Думаю, я почти все сделал правильно. Я следовал инструкциям здесь:https://dlv.isc.org/about/using. Я зарегистрировал свой домен и загрузил ключ подписи ключа, подписал свою зону с помощью -l dlv.isc.org
option, добавил dlv.isc.org как внешний сервер имен для моего домена в файлы зоны. named молча терпит неудачу. Я даже изменил /dev/null
на /var/log/named.log
, чтобы выжать некоторую информацию из named. Я проверил, были ли внесены изменения, но это не сработало. Я не знаю, что проверить или попробовать.
Я задаю 2 вопроса:
- Стратегии сбора информации из названных, когда он молча терпит неудачу, как это происходит
- Правильная ли конфигурация? Мои ограниченные познания в DNS и DNSSEC говорят мне, что это должно работать
переслать файл:
$TTL 3600;
@ IN SOA ns1.sub.db.archives.net. dlv.isc.org. (
2014112100 ; serial
4h ; refresh
1h ; retry
7d ; expiration
1h ; minimum
)
$INCLUDE Ksub.db.archives.net.+008+07374.key
$INCLUDE Ksub.db.archives.net.+008+24586.key
IN NS ns1.sub.db.archives.net.
IN NS ns1.db.archives.net.
IN NS dlv.isc.org.
dlv.isc.org. IN A 149.20.1.5
ns1.db.archives.net. IN A 10.103.35.66
ns1 IN A 10.103.35.64
luke IN A 10.103.35.64
bo IN A 10.103.35.65
daisy IN A 10.103.35.66
sheriff IN A 10.103.35.67
boss IN A 10.103.35.68
dlv.sub.db.archives.net. 0 IN TXT "DLV:1:blablabla"
dlv.isc.org. IN DNSKEY 257 3 5 BEAAAAPHMu ...TDN0YUuWrBNh
обратный файл:
$TTL 3600
@ IN SOA ns1.sub.db.archives.net. dlv.isc.org. (
2014112100 ; serial #
4h ; refresh
1h ; retry
7d ; expiration
1h ; minimum
)
IN NS ns1.sub.db.archives.net.
IN NS ns1.db.archives.net.
IN NS dlv.isc.org.
5.1.20.149 IN PTR dlv.isc.org.
66.35.103.10 IN PTR ns1.db.archives.net.
64 IN PTR ns1.sub.db.archives.net.
64 IN PTR luke.sub.db.archives.net.
65 IN PTR bo.sub.db.archives.net.
66 IN PTR daisy.sub.db.archives.net.
67 IN PTR sheriff.sub.db.archives.net.
68 IN PTR boss.sub.db.archives.net.
Команда dnssec-signzone:
dnssec-signzone -l dlv.isc.org -o sub.db.archives.net -k Ksub.db.archives.net.+008+24586.key sub.db.archives.net.fwd Ksub.db.archives.net.+008+07374.key
по имени:
[root@test master]# service named start
Starting named: [FAILED]
решение1
- Стратегии, позволяющие понять, почему
named
двигатель не запускается:- Проверьте
named-checkconf -zj
вывод. (named-checkconf
и,named-checkzone
вероятно, это должно быть частью вашего обычного рабочего процесса, а не только для устранения неполадок) - Проверьте журналы. (
named
по умолчанию журналы записываются в системный журнал, проверьтеnamed.conf
конфигурацию журналирования, которая у вас есть, и которая может переопределить это) - Если ничего из вышеперечисленного не помогло (что маловероятно), есть также возможность проверить, какие параметры у вас обычно есть в
named
командной строке, и запустить ее вручную,-g
добавив их к обычному набору параметров (это заставит программуnamed
оставаться на переднем плане и выводить данные в stderr).
- Проверьте
Есть множество очевидных проблем с данными зоны, включенными в вопрос, которые никоим образом не являются специфическими для DNSSEC или DLV. Честно говоря, я бы рекомендовал вам прочитать основы DNS в качестве первого шага. Некоторые проблемы, которые я заметил, были следующими, пожалуйста , также
просмотрите журналы и/или вывод.named-check{conf,zone}}
- Записи
SOA
имеют очень маловероятные значения RNAME ([email protected]
) dlv.isc.org
указан как сервер имен, но я очень сомневаюсь, что он размещает ваши зоны.dlv.isc.org. IN A ...
похоже, что ему не место в этой зоне.ns1.db.archives.net. IN A ...
похоже, что ему не место в этой зоне.dlv.isc.org. IN DNSKEY ...
похоже, что ему не место в этой зоне.5.1.20.149 IN PTR dlv.isc.org.
- Несмотря на то, что это написано неправильно, это еще одна запись, которая здесь неуместна.66.35.103.10 IN PTR ns1.db.archives.net.
вероятно, принадлежит, но написано неправильно.
- Записи
(Из вопроса я сделал вывод, что эти две зоны — это sub.db.archives.net
и 35.103.10.in-addr.arpa
, на чем я и основывал утверждения о выходе за пределы зоны. Если посмотреть на фактическую конфигурацию в дополнение к данным о зоне, это подтвердится.)
решение2
Фактические file not found
ошибки кажутся вполне очевидными (таких файлов не существует, я полагаю?).
Однако DS
записи хранятся в родительской зоне, в качестве альтернативы DLV
записи хранятся на сервере DLV.
Это означает, что ваш шаг 4 не существует (согласно руководству, ссылку на которое вы дали).
Неужели нельзя вместо этого перенести записи DS в родительскую зону? DLV изначально был в основном временной мерой и не должен быть первым выбором.
Также смВстроенная подпись (и поддержка автоматического DNS-sec), это, как правило, лучший вариант для подписывания зоны и управления ключами по сравнению с вызовом dnssec-signzone вручную.