LINUX.ORG.RU
решено Форум — Admin  

Как при помощи dig'а валидировать домен подписанный DNSSEC?


0

2

Есть у меня потребность валидировать домен подписанный DNSSEC'ом.

nox.su подписан DNSSEC'ом. http://dnssec-debugger.verisignlabs.com/nox.su это подтверждает.

http://bryars.eu/2010/08/validating-and-exploring-dnssec-with-dig/ рассказывает что валидация осуществляется командой

dig +topdown +sigchase nox.su

но для этого нужно добавить ключи корневой зоны в доверенные:

dig +nocomments +nostats +nocmd +noquestion -t dnskey . > trusted-key.key

Однако ни для nox.su ни для обсуждаемого в статье примера это не работает, заканчивая цепочку проверок словами ";; DSset is missing to continue validation: FAILED" Испоьзую dig из debian testing.

Кто-то из присутвующих разбирается в DNSSEC настолько чтобы объяснить в чем дело, и как это делать правильно?

★★★

Последнее исправление: shaplov (всего исправлений: 2)
← fprobe не запускается
Что за шум про сломанную загрузку без /usr и почему теперь надо засунуть туда /bin? →

[code]$ dig +dnssec nox.su a

; <<>> DiG 9.5.1-P3 <<>> +dnssec nox.su a ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20442 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 [/code]

flags: qr rd ra;

А должно быть `flags: qr rd ra ad;', не?

anonymous
()
Ответ на: комментарий от shaplov

Ничего не знаю.

$ dig +dnssec www.udp53.org a

; <<>> DiG 9.5.1-P3 <<>> +dnssec www.udp53.org a
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2906
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

flags: qr rd ra ad;

anonymous
()
Ответ на: комментарий от anonymous

А

dig @8.8.8.8 +dnssec http://www.udp53.org a

?

Ты не свой собственный ns сервер случайно опрашиваешь? ;-)

Потому как у меня и для udp53 не дают ad

shaplov ★★★
() автор топика
Ответ на: комментарий от anonymous

A trusted-key.key заинклюжен в trusted-keys {} в конфиге?

В конфиге чего? Бинд тут не нужен. dig берет доверенные ключи либо из /etc либо из текущей директории. формат файла ключа заведомо правильный, потому как я нашкл федорину rpm'ку в которой этот файл давали. Там он такой же как если его вышеуказанным способом заполучить...

shaplov ★★★
() автор топика
Ответ на: комментарий от shaplov

Конечно свой :) Откуда мне твой знать. Я про неверно настроенный рекурсор подумал.

ТОгда в первую очередь проверить скопилен ли dig с -DDIG_SIGCHASE. И попробовать файл с ключём передать опцией при запросе +trusted-key=file

anonymous
()
Ответ на: комментарий от anonymous

Конечно свой :) Откуда мне твой знать. Я про неверно настроенный рекурсор подумал.

Ну просто твой домен на твоем же сервере может давать другие флаги, чем у всех остальных :-)

ТОгда в первую очередь проверить скопилен ли dig с -DDIG_SIGCHASE. И попробовать файл с ключём передать опцией при запросе +trusted-key=file

Да... пожалуй надо скачать сорцы пакета и проверить... Хорошая мысль...

shaplov ★★★
() автор топика
Ответ на: комментарий от anonymous

ТОгда в первую очередь проверить скопилен ли dig с -DDIG_SIGCHASE. И попробовать файл с ключём передать опцией при запросе +trusted-key=file

Да вроде да...

export CFLAGS=-fno-strict-aliasing -DDIG_SIGCHASE $(DEBUG) $(OPT)

shaplov ★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← fprobe не запускается
Admin
Что за шум про сломанную загрузку без /usr и почему теперь надо засунуть туда /bin? →