Пытался найти подходящее место, чтобы спросить об этом. надеюсь, это место!
Я пытаюсь понять несколько тонкостей 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 flag (но это значение по умолчанию) запрашивает проверку 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) about (о) 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, это просто создает дополнительный уровень подписей, но не меняет концептуально то, что указано выше).
Для доменного имени сервера имен может не быть включена поддержка DNSSEC, это не повлияет на проверку DNSSEC. ietf.org. Однако это имеет практические последствия для безопасности, потому что это означает, что их доменное имя может быть взломано, и, следовательно, вы можете теоретически перенаправить трафик на мошеннические серверы имен, которые будут давать другие ответы и могут вызвать сбои проверки DNS или DNSSEC. В лучшем случае эти мошеннические серверы имен смогут вызывать ошибки SERVFAIL только для всех проверяющих преобразователей, поскольку они не смогут обслуживать подписи, подписанные ключом, совпадающим с записью DS в родительской зоне. Таким образом, DNSSEC здесь, даже если сам домен серверов имен не использует DNSSEC, все же позволяет убедиться, что никакие другие / ложные записи не могут быть вставлены.
Конечно, в идеальном мире все может или должно быть включено DNSSEC, но это все равно будет проблема курицы и яйца: корневая зона . использует серверы имен в root-servers.net домен, поэтому вы не сможете защитить обе части одновременно. По факту, root-servers.net по сей день не поддерживает DNSSEC ... что мало влияет на разрешение или проверку DNSSEC всех доменов.
Короче говоря, DNSSEC не работает, потому что авторитетные серверы имен будут напрямую предоставлять IP-адреса «дочерних» серверов имен, эта часть работает так же, как и до DNSSEC. DNSSEC работает, потому что в очень широком смысле каждая зона публикует ключи, используемые для генерации подписей для каждой записи в зоне, а хэш ключа публикуется в родительской зоне для создания цепочки доверия вплоть до корневого якоря доверия.