Разрешение DNSSEC, когда записи NS не сопровождаются записями A
Пытался найти нужное место, чтобы задать этот вопрос. Надеюсь, это то место!
За DNS и, в частности, DNSSEC стоит несколько тонкостей, которые я пытаюсь понять. DNSSEC использует цепочку доверия для перехода от доверенных корневых DNS-серверов к целевому хосту. Согласно http://dnsviz.net/d/ietf.org/dnssec/ , хост ietf.org защищен DNSSEC. Выполнив следующую команду Unix, мы получим образец трассировки:
$ dig ietf.org +dnssec +trace +multi
; <<>> DiG 9.9.5 <<>> ietf.org +dnssec +trace +multi
;; global options: +cmd
. 24638 IN NS a.root-servers.net.
. 24638 IN NS b.root-servers.net.
. 24638 IN NS c.root-servers.net.
. 24638 IN NS d.root-servers.net.
. 24638 IN NS e.root-servers.net.
. 24638 IN NS f.root-servers.net.
. 24638 IN NS g.root-servers.net.
. 24638 IN NS h.root-servers.net.
. 24638 IN NS i.root-servers.net.
. 24638 IN NS j.root-servers.net.
. 24638 IN NS k.root-servers.net.
. 24638 IN NS l.root-servers.net.
. 24638 IN NS m.root-servers.net.
. 24638 IN RRSIG NS 8 0 518400 (
20180223050000 20180210040000 41824 .
e8itIEYiVRvPxv5mkNzkBZTltFgDUIFLB/KxV7RFpXzj
X8Rqre85GiIFlAM01rIi0YGTkb6k6U+TGdDxXabQmr4q
wHIBTEd2MjrHb+0XsY4dIlZJ3qvLPdnDPHSlIBx17K3A
+AqMZdINCCA7QlxnUd3+agMpc9jkJrsNBO2x1CVBP8R2
w4a2kHcpxILr9T/heamOJOpHjd3r3l6/mhGkY0ut2I+Y
4vbzplayG0f6Br461y4qtX4h6JUJk8BBDvzcqzovpUSk
VSqLeM9YXVC5XzrWNb8081u7ct37J5g+5vJLHAMcac7L
8qQ4rtmQqzHn1reS6wOogYxsUVlOxdxP2Q== )
;; Received 525 bytes from 10.211.254.254#53(10.211.254.254) in 109 ms
org. 172800 IN NS a0.org.afilias-nst.info.
org. 172800 IN NS a2.org.afilias-nst.info.
org. 172800 IN NS b0.org.afilias-nst.org.
org. 172800 IN NS b2.org.afilias-nst.org.
org. 172800 IN NS c0.org.afilias-nst.info.
org. 172800 IN NS d0.org.afilias-nst.org.
org. 86400 IN DS 9795 7 1 (
364DFAB3DAF254CAB477B5675B10766DDAA24982 )
org. 86400 IN DS 9795 7 2 (
3922B31B6F3A4EA92B19EB7B52120F031FD8E05FF0B0
3BAFCF9F891BFE7FF8E5 )
org. 86400 IN RRSIG DS 8 1 86400 (
20180223050000 20180210040000 41824 .
Weag50NNvW6pqxODjMj3F0LrcFizxaK76PhdGtVv0iDg
tgZw4DzcDU8WrD6q/pm7kzKwLpXryhfMo3ASKgP+Usyr
V1uW0WyCh0cwZs6yfMKfZNtF1X47PulkiHgrc7AI/+nO
oQGv6FlUAROyh+aak7QN6/IEVO5CE6nzpsyzDqewnGmt
xYNgeWJr0RJR81VqBN6/Y4t/NthxsPEyLoXl1ijju99h
Tf9UP2+1GFLqaf6uINsSD/EsHryQB7W6ZUz6pdmE5C3W
jbqZ+7heu7xK9Tzz7Fv3tS2nei0xk0puNh5vCHjGzjG5
+lIfY6dJxxvxh/ywqS6Fm8yhIRjLgscpQw== )
;; Received 810 bytes from 199.7.83.42#53(l.root-servers.net) in 100 ms
ietf.org. 86400 IN NS ns1.yyz1.afilias-nst.info.
ietf.org. 86400 IN NS ns0.amsl.com.
ietf.org. 86400 IN NS ns1.sea1.afilias-nst.info.
ietf.org. 86400 IN NS ns1.ams1.afilias-nst.info.
ietf.org. 86400 IN NS ns1.mia1.afilias-nst.info.
ietf.org. 86400 IN NS ns1.hkg1.afilias-nst.info.
ietf.org. 86400 IN DS 45586 5 1 (
D0FDF996D1AF2CCDBDC942B02CB02D379629E20B )
ietf.org. 86400 IN DS 45586 5 2 (
67FCD7E0B9E0366309F3B6F7476DFF931D5226EDC534
8CD80FD82A081DFCF6EE )
ietf.org. 86400 IN RRSIG DS 7 2 86400 (
20180302153210 20180209143210 1862 org.
K1JT67FsQ9Dl4W8V7pYp6MlbbNSe2IKfmgXiqXPlPLsy
5mZYhnUilXE40icI9Eea6KZY5eEZIdvEDzfMXaAshLXh
6gLAtPTviTa9aFUid2dd/McNUdSrWQjZKicpW//XJ6fw
9v5coQTrnP9HA9oCwb5TXWAKY7Ju+j5hkrBPy7M= )
;; Received 441 bytes from 199.19.54.1#53(b0.org.afilias-nst.org) in 134 ms
ietf.org. 1800 IN A 4.31.198.44
ietf.org. 1800 IN RRSIG A 5 2 1800 (
20190109135858 20180109130036 40452 ietf.org.
O8fJkB4ISG/SzpRd0EBvh49pLzR21cXJEH7ZWUSfpFjX
fv7pqIEX9FUMEjP+VHdsP7iCQ3Gkd3PQul7PNFqbdMnk
4O5NomCyg71J73G4rLlaBYZYTCTVW+8CdgviqrNoIFSz
gPcN7kxDdg25YKi5ywjbMqCU9BWhnGw+4kS7TrXtd92c
/YUqViYDN0OCTMn5b05+a6FJd0Fu4iKbYpFQJ1/dDh5F
/RAhIGFbOd2/zGK6xCE3IU8ICzRhIJL0ZiNMRtbZOc1u
POeHd3SQ66ZrNRbl0pxwQlzizRkaeFchCZ9+w71AmrGG
0K4BWNNsW1PwkgJwb/trlWSTroA4X/6oUg== )
ietf.org. 1800 IN NS ns1.yyz1.afilias-nst.info.
ietf.org. 1800 IN NS ns1.hkg1.afilias-nst.info.
ietf.org. 1800 IN NS ns1.ams1.afilias-nst.info.
ietf.org. 1800 IN NS ns0.amsl.com.
ietf.org. 1800 IN NS ns1.sea1.afilias-nst.info.
ietf.org. 1800 IN NS ns1.mia1.afilias-nst.info.
ietf.org. 1800 IN RRSIG NS 5 2 1800 (
20190109135847 20180109130036 40452 ietf.org.
nfZKxJsrSozyiyPvWcn0fJCAz4qVE5xiwLOTGkOAh/Mh
SH9xv6sNqWEJtul4rRYLJQ7S1AyFHT4PwhjyypG0KMnW
SAEMTpXhMqO2Mlf2/LoVPoPGsFfs3LqhgyAYxjgbOxix
zG1grS/AXHzUzudrLjWUfgQB+N4jb0VmvVBtp4XS6soa
C+ZHdyLr4pnT8PwE2Qbge405lhEIAHfx+RLWkrkQUJEU
JKTjyXsQcRp/2MRniHXf4udSWSvjcwNuFKEng6eHzWg7
tQwBHmluZVHhN7U/xcplREvKRg/5YV4K3OjRcXAXK0XW
kauSoZWiLHvRTgPnZJdhNDv5uqHvHVGNbw== )
;; Received 994 bytes from 65.22.8.1#53(ns1.sea1.afilias-nst.info) in 100 ms
Однако, если мы запустим
$ dig ietf.org +dnssec
; <<>> DiG 9.9.5 <<>> ie
tf.org +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35753
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 8192
;; QUESTION SECTION:
;ietf.org. IN A
;; ANSWER SECTION:
ietf.org. 1800 IN A 4.31.198.44
ietf.org. 1800 IN RRSIG A 5 2 1800 20190109135858 20180109130036 40452 ietf.org. O8fJkB4ISG/SzpRd0EBvh49pLzR21cXJEH7ZWUSfpFjXfv7pqIEX9FUM EjP+VHdsP7iCQ3Gkd3PQul7PNFqbdMnk4O5NomCyg71J73G4rLlaBYZY TCTVW+8CdgviqrNoIFSzgPcN7kxDdg25YKi5ywjbMqCU9BWhnGw+4kS7 TrXtd92c/YUqViYDN0OCTMn5b05+a6FJd0Fu4iKbYpFQJ1/dDh5F/RAh IGFbOd2/zGK6xCE3IU8ICzRhIJL0ZiNMRtbZOc1uPOeHd3SQ66ZrNRbl 0pxwQlzizRkaeFchCZ9+w71AmrGG0K4BWNNsW1PwkgJwb/trlWSTroA4 X/6oUg==
;; Query time: 101 msec
;; SERVER: 10.211.254.254#53(10.211.254.254)
;; WHEN: Sat Feb 10 07:00:56 EST 2018
;; MSG SIZE rcvd: 349
, то заметим, что Dig не устанавливает флаг «ad», что наводит меня на мысль, что, возможно, целевой хост (ietf.org) не защищен DNSSEC.
Предполагая, что он защищен, я пытаюсь понять цепочку доверия. Часть, которую я не понимаю, заключается в том, что во время разрешения DNS, если вы запрашиваете
$ dig @199.19.54.1 ietf.org +dnssec +multi
; <<>> DiG 9.9.5 <<>> @199.19.54.1 ietf.org +dnssec +multi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30334
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;ietf.org. IN A
;; AUTHORITY SECTION:
ietf.org. 86400 IN NS ns1.ams1.afilias-nst.info.
ietf.org. 86400 IN NS ns0.amsl.com.
ietf.org. 86400 IN NS ns1.hkg1.afilias-nst.info.
ietf.org. 86400 IN NS ns1.mia1.afilias-nst.info.
ietf.org. 86400 IN NS ns1.sea1.afilias-nst.info.
ietf.org. 86400 IN NS ns1.yyz1.afilias-nst.info.
ietf.org. 86400 IN DS 45586 5 1 (
D0FDF996D1AF2CCDBDC942B02CB02D379629E20B )
ietf.org. 86400 IN DS 45586 5 2 (
67FCD7E0B9E0366309F3B6F7476DFF931D5226EDC534
8CD80FD82A081DFCF6EE )
ietf.org. 86400 IN RRSIG DS 7 2 86400 (
20180302153210 20180209143210 1862 org.
K1JT67FsQ9Dl4W8V7pYp6MlbbNSe2IKfmgXiqXPlPLsy
5mZYhnUilXE40icI9Eea6KZY5eEZIdvEDzfMXaAshLXh
6gLAtPTviTa9aFUid2dd/McNUdSrWQjZKicpW//XJ6fw
9v5coQTrnP9HA9oCwb5TXWAKY7Ju+j5hkrBPy7M= )
;; Query time: 143 msec
;; SERVER: 199.19.54.1#53(199.19.54.1)
;; WHEN: Sat Feb 10 06:55:30 EST 2018
;; MSG SIZE rcvd: 441
, тогда нет A-записи для любого из этих серверов имен. Итак, если я не ошибаюсь, DNS должен выполнить какое-то дополнительное разрешение, чтобы получить IP-адрес для этих серверов имен (например, ns0.amsl.com.), Чтобы у них, в свою очередь, можно было запросить запись A окончательного целевой хост (ietf.org). Единственная проблема заключается в том, что ни один из этих серверов имен, например ns0.amsl.com., Не является безопасным DNSSEC, согласно Dig и http://dnsviz.net/d/ns1.sea1.afilias-nst. info / dnssec / !
Итак, как DNSSEC устанавливает безопасность и как сохраняется доверие на этом дополнительном этапе разрешения адреса? Возможно, я неправильно понимаю DNS или DNSSEC, и вся помощь приветствуется!
Несколько точек в вашем вопросе:
1)
dig + dnssec просто запрашивает dig для отправки вам записей, связанных с DNSSEC, то есть RRSIG с вашими результатами, он ничего не проверяет.
Флаг + ad (но это по умолчанию) запрашивает проверку DNSSEC ... но это работает, только если вы запрашиваете распознаватель проверки DNSSEC. Напротив, + cd отключает любые проверки DNSSEC.
См .:
; <<>> DiG 9.10.3-P4-Ubuntu <<>> @9.9.9.9 +ad ietf.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31296
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ietf.org. IN A
;; ANSWER SECTION:
ietf.org. 1800 IN A 4.31.198.44
;; Query time: 228 msec
2) о dig @ 199.19.54.1 ietf.org + dnssec + multi
Это нормально, что у вас нет А-записей.
199.19.54.1 он же b0.org.afilias-nst.org. не является официальным для ietf.org , он является официальным только для org .
Поэтому, если вы запросите у него домен, который находится в его зоне, он просто даст рефералы, то есть записи NS.
Некоторые серверы имен могут также предоставлять записи A / AAAA в дополнительном разделе, чтобы помочь распознавателям, но они больше используются, чтобы не доверять им.
Но обратите внимание, что в ответе у вас был DS ietf.org и связанный с ним RRSIG.
Итак, следующим шагом распознавателя является использование записей NS, запрос их записей A / AAAA и затем обращение к ним, чтобы получить запись A ietf.org . Если им необходимо выполнить проверку DNSSEC, они будут запрашивать DNSKEY и проверять, что DNSKEY соответствует DS в зоне org и что запись A для ietf.org имеет соответствующий RRSIG, подписанный с помощью DNSKEY (я упрощаю, в большинстве случаев у вас есть KSK и ZSK, это просто создает дополнительный уровень подписей, но не меняет концептуально то, что указано выше).
Домен серверов имен name может не иметь поддержки DNSSEC, это не повлияет на проверку DNSSEC ietf.org . Однако это имеет практические последствия для безопасности, потому что это означает, что их доменное имя может быть взломано, и, следовательно, вы теоретически можете перенаправить трафик на мошеннические серверы имен, которые будут давать другие ответы и могут вызвать сбои проверки DNS или DNSSEC. В лучшем случае эти мошеннические серверы имен смогут вызывать ошибки SERVFAIL только для всех проверяющих преобразователей, поскольку они не смогут обслуживать подписи, подписанные ключом, соответствующим записи DS в родительской зоне. Таким образом, DNSSEC здесь, даже если сам домен серверов имен не использует DNSSEC, все же позволяет убедиться, что никакие другие / ложные записи не могут быть вставлены.
Конечно, в идеальном мире все может или должно быть включено DNSSEC, но это все равно будет проблема с курицей и яйцом:корневая зона . использует серверы имен в домене root-servers.net , поэтому вы не сможете защитить обе части одновременно. Фактически, root-servers.net не поддерживает DNSSEC по сей день ... что имеет небольшие последствия для разрешения или проверки DNSSEC всех доменов.
Короче говоря, DNSSEC не работает, потому что авторитетные серверы имен будут напрямую предоставлять IP-адреса «дочерних» серверов имен, эта часть работает так же, как и до DNSSEC. DNSSEC работает, потому что, в очень широком смысле, каждая зона публикует ключи, используемые для генерации подписей для каждой записи в зоне, а хэш ключа публикуется в родительской зоне для создания цепочки доверия вплоть до корневого якоря доверия.