Perché non possiamo ignorare DNSSEC

Question

Perché non possiamo ignorare DNSSEC

#1 da (3 voti)

11

DNSSEC è una suite di estensioni di sicurezza per migliorare la sicurezza DNS. (ad es .: evitare l'avvelenamento della cache)

Tuttavia mi chiedevo come fa il resolver a sapere che il prossimo NS userà DNSSEC?

E.g.: qualcuno vuole risolvere www.example.com. . Supponiamo che l'autorevole NS example.com. abbia DNSSEC abilitato e configurato correttamente.

Il resolver contatterà prima i root server . , quindi i server TLD com. e infine l'autorevole example.com. . Tuttavia, poiché il resolver invia una query DNS all'ultimo NS, non sa se DNSSEC è abilitato.

Ciò significa che un utente malintenzionato può contraffare pacchetti DNS e fare i suoi avvelenamenti ...

So che ho torto, il resolver deve essere consapevole che il prossimo NS usa DNSSEC. Ma non capisco come!?

dnssec

posta Posterrr57 27.04.2015 - 17:25

fonte

1 risposta

Leggi altre domande sui tag dnssec

Come conservare i dati privati in modo sicuro e accessibile al pubblico? La centralizzazione riduce la probabilità ma aumenta il danno degli exploit?

score 3 · Answer 1

L'autorevole per .com indicherà nella sua risposta firmata che anche example.com è firmato (alcuni output omessi)

$ dig +norec +dnssec a www.example.com @c.gtld-servers.net

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.example.com.       IN  A

;; AUTHORITY SECTION:
example.com.        172800  IN  NS  a.iana-servers.net.
example.com.        172800  IN  NS  b.iana-servers.net.
example.com.        86400   IN  DS  31589 8 1 3490A6806D47F17A34C29E2CE80E8A999FFBE4BE
example.com.        86400   IN  DS  31589 8 2 CDE0D742D6998AA554A92D890F8184C698CFAC8A26FA59875A990C03 E576343C
example.com.        86400   IN  RRSIG   DS 8 2 86400 20150503041532 20150426030532 33878 com. P7R78q8UpfNTw+oVYJkL4BizSB4b8sglabdODISZEFSP3/z7CPAXOa4C 31rbNeLvD/O0I6pmYbg33HILGyj+yxAlZj7x3LNuLzaun86S201XcLkH /Xe/tLA+kEBgwZ6RV+1Vvqc51kAcQuN0U+6v5nZFaCJ1ZhvZ/S8w7FMf dfY=

Nota RRSIG: è firmato con la chiave per .com e consente al client di convalidare i record DS. I record DS (Delegation Signer), a loro volta, sono un hash di DNSKEY per example.com. Quando un cliente riceve questa risposta, sa che example.com DEVE essere firmato e DEVE essere firmato con una chiave che corrisponde a uno dei record di DS. Se il client riceve quindi dati non DNSSEC dai server dei nomi example.com, sa che qualcosa non funziona e tratterà i dati come BOGUS.