Как защитить зону с помощью сервиса DLV dlv.isc.org?

Как защитить зону с помощью сервиса DLV dlv.isc.org?

Я настраиваю проверку домена-lookaside. Думаю, я почти все сделал правильно. Я следовал инструкциям здесь:https://dlv.isc.org/about/using. Я зарегистрировал свой домен и загрузил ключ подписи ключа, подписал свою зону с помощью -l dlv.isc.orgoption, добавил dlv.isc.org как внешний сервер имен для моего домена в файлы зоны. named молча терпит неудачу. Я даже изменил /dev/nullна /var/log/named.log, чтобы выжать некоторую информацию из named. Я проверил, были ли внесены изменения, но это не сработало. Я не знаю, что проверить или попробовать.

Я задаю 2 вопроса:

  1. Стратегии сбора информации из названных, когда он молча терпит неудачу, как это происходит
  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

  1. Стратегии, позволяющие понять, почему namedдвигатель не запускается:
    • Проверьте named-checkconf -zjвывод. ( named-checkconfи, named-checkzoneвероятно, это должно быть частью вашего обычного рабочего процесса, а не только для устранения неполадок)
    • Проверьте журналы. ( namedпо умолчанию журналы записываются в системный журнал, проверьте named.confконфигурацию журналирования, которая у вас есть, и которая может переопределить это)
    • Если ничего из вышеперечисленного не помогло (что маловероятно), есть также возможность проверить, какие параметры у вас обычно есть в namedкомандной строке, и запустить ее вручную, -gдобавив их к обычному набору параметров (это заставит программу namedоставаться на переднем плане и выводить данные в stderr).


  1. Есть множество очевидных проблем с данными зоны, включенными в вопрос, которые никоим образом не являются специфическими для 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 вручную.

Связанный контент