Как мне защитить зону с помощью службы DLV dlv.isc.org? [закрыто]

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

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

  1. Стратегии сбора информации из named, когда он терпит неудачу, тихо, как при его выполнении.
  2. Правильная ли конфигурация. Мое ограниченное понимание DNS и DNSSEC говорит мне, что это должно работать

forward file:

$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

reverse file:

$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 command:

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

named:

[root@test master]# service named start
Starting named:                                            [FAILED]
-1
задан 25 November 2014 в 16:47
2 ответа
  1. Стратегии, позволяющие понять, почему с именем не запускается:
    • Проверить вывод named-checkconf -zj . ( named-checkconf , а также named-checkzone , вероятно, должны быть частью вашего обычного рабочего процесса, а не только для устранения неполадок)
    • Проверьте журналы. ( named записывает в системный журнал по умолчанию, см. Ваш named.conf для любой имеющейся у вас конфигурации ведения журнала, которая может переопределить это)
    • Если ничего из вышеперечисленного не помогает (маловероятно), есть также возможность проверить, какие параметры у вас обычно есть в командной строке с именем , и запустить его вручную с помощью -g , добавленного к вашему обычному набору параметров (это заставляет named , чтобы оставаться на переднем плане и регистрироваться в stderr).


  1. Существует множество очевидных проблем с данными зоны, включенными в вопрос, которые никоим образом не относятся к DNSSEC или DLV. Честно говоря, я бы порекомендовал вам в качестве первого шага ознакомиться с основами DNS.
    Некоторые проблемы, которые я обнаружил, были следующие, пожалуйста, обратитесь к журналам и / или к выходным данным named-check {conf, zone}} .

    • Записи SOA очень маловероятны Значения RNAME (скрытые) указаны как сервер имен, но я очень сомневаюсь, что он поддерживает ваши зоны.
    • dlv.isc.org. IN A ... не похоже, что он принадлежит к этой зоне.
    • ns1.db.archives.net. IN A ... не похоже, что он принадлежит к этой зоне.
    • dlv.isc.org. В 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
ответ дан 5 December 2019 в 19:08

Фактические ошибки файл не найден довольно очевидны (таких файлов, я полагаю, не существует?).

Однако DS записи живут в родительской зоне, или записи DLV живут на сервере DLV.

Это означает, что ваш шаг 4 не существует (согласно руководству, которое вы связали).

Можете ли вы неужели вместо этого не получить записи DS в родительскую зону? DLV изначально был временной мерой и не должен быть первым выбором.

См. Также Встроенная подпись (и автоматическая поддержка dnssec) , которая обычно является лучшим вариантом для подписи зоны и управления ключами по сравнению с вызовом dnssec-signzone вручную.

2
ответ дан 5 December 2019 в 19:08

Теги

Похожие вопросы