co.uk.проверка зоны DNS с помощью DNSSEC - PullRequest
Новая
       54

co.uk.проверка зоны DNS с помощью DNSSEC

0 голосов
/ 21 мая 2018

Долгое время слушатель, впервые звонивший сюда.

Я пишу распознаватель DNS со встроенной проверкой DNSSEC и заметил кое-что, что я не могу понять, после нескольких прочтений затронутых проблем.RFC.

Во время разрешения, которое является доменом в TLD uk. (в частности, co.uk.), я сталкиваюсь с бесконечным циклом, инициированным валидацией DNSSEC.Для простоты давайте предположим, что процесс уже кэшировал всю корневую зону, поэтому продолжим:

  • выполнить запрос для co.uk. IN NS на одном из зарегистрированных uk. серверов имен

    ; <<>> DiG 9.10.5 <<>> co.uk. NS @nsa.nic.uk +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54513
;; flags: qr aa rd; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 14
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;co.uk.                         IN      NS

;; ANSWER SECTION:
co.uk.                  172800  IN      NS      dns3.nic.uk.
co.uk.                  172800  IN      NS      dns2.nic.uk.
co.uk.                  172800  IN      NS      dns1.nic.uk.
co.uk.                  172800  IN      NS      nsb.nic.uk.
co.uk.                  172800  IN      NS      nsc.nic.uk.
co.uk.                  172800  IN      NS      nsa.nic.uk.
co.uk.                  172800  IN      NS      nsd.nic.uk.
co.uk.                  172800  IN      NS      dns4.nic.uk.
co.uk.                  172800  IN      RRSIG   NS 8 2 172800         20180622150723 20180518150505 33621 co.uk.         pYoHwxWpkPP6FfIUk14o5qsO0cxA3CaPvfKGT++MuBhW9Ls/7Xnl6WwE pyU3BIDylkVyELe6be6hCwVOfV3VWcT1JW86RJexhRtU74ZHWdVNnjYd +oQVOQ0V/rhDorVSKdA0G+uDyq11T6Z1ecCERlks63GF21aPM9bWEJD6 cOo=

;; ADDITIONAL SECTION:
nsa.nic.uk.             172800  IN      A       156.154.100.3
nsb.nic.uk.             172800  IN      A       156.154.101.3
nsc.nic.uk.             172800  IN      A       156.154.102.3
nsd.nic.uk.             172800  IN      A       156.154.103.3
dns1.nic.uk.            172800  IN      A       213.248.216.1
dns2.nic.uk.            172800  IN      A       103.49.80.1
dns3.nic.uk.            172800  IN      A       213.248.220.1
dns4.nic.uk.            172800  IN      A       43.230.48.1
nsa.nic.uk.             172800  IN      AAAA    2001:502:ad09::3
dns1.nic.uk.            172800  IN      AAAA    2a01:618:400::1
dns2.nic.uk.            172800  IN      AAAA    2401:fd80:400::1
dns3.nic.uk.            172800  IN      AAAA    2a01:618:404::1
dns4.nic.uk.            172800  IN      AAAA    2401:fd80:404::1
  • перед чем-либо (например, с обработкой правильных элементов ответа) должна произойти проверка DNSSEC;поэтому естественно мы выполняем запрос для DNSKEY, с которым был подписан RRSIG (мы замечаем, что co.uk. является подписывающим лицом записей)
  • , чтобы получить DNSKEY для зоны co.uk., нам нужно знатьуполномоченный NS в этой зоне (напоминание, что мы уже имеем эту информацию, но еще не смогли ее проверить), поэтому мы запускаем запрос co.uk. IN NS к серверу имен родительской зоны (uk.), и мыв начале.

Я уверен, что это недостаток дизайна, но не могу понять, что именно.Логически (и ключевой шаг здесь, который запускает цикл в том, что) не следует рассматривать использование RR перед проверкой, и записи делегирования дочерней зоны, опять же, логически, не должны подписываться с DNSKEY дочерней зоны, я думаю, что дажеесли родительская зона также является доверенной для дочерней зоны.

Пожалуйста, помогите и заранее благодарим вас

1 Ответ

0 голосов
/ 02 июля 2018

Как вы заметили, одни и те же серверы имен являются полномочными как для .UK, так и для CO.UK, поэтому вы не получили нормальный реферальный ответ из родительской зоны, где в разделе прав доступа были бы записи DS и NS, носкорее авторитетный ответ из дочерней зоны с записями NS в разделе ответов.

Так что вам нужен дополнительный запрос DS к серверам имен .UK, как вы поняли, но имейте в виду, что вы этого не делаетенужна эта запись DS для проверки записей DNSKEY и RRSIG для записей NS.Записи (не вершины) NS, возвращаемые в ответе обычного делегирования, не подписаны и не требуют проверки.Когда вы получаете ответ дочерней зоны, записи NS являются апекс-записями, и (если зона подписана DNSSEC) будет RRSIG для набора записей NS, но проверять эти записи NS перед их использованием не требуется.в качестве серверов имен для зоны.Проверяющий рекурсивный сервер имен только когда-либо должен проверять записи NS, когда он обрабатывает явный запрос NS от клиента.

В конечном счете, DNSSEC полагается на проверку данных в зонах, а не имен или адресов серверов именкоторые предоставляют их.Это несколько отличается от многих других протоколов безопасности, таких как HTTPS, которые аутентифицируют только конечные точки сервера (и, возможно, клиента).

...