11

DNSSEC is a suite of security extensions to enhance DNS security. (e.g.: avoid cache poisoning)

However I was wondering how does the resolver know that the next NS will use DNSSEC?

E.g.: Someone wants to resolve www.example.com.. Let's assume that the authoritative NS example.com. has DNSSEC enabled and properly configured.

The resolver will first contact the root servers ., then the TLD servers com. and finally the authoritative example.com.. However, as the resolver send a DNS query to that last NS, he doesn't know if DNSSEC is enabled.

This means that an attacker may forge DNS packet and do his poisoning stuff...

I know I'm wrong, the resolver must be aware that the next NS uses DNSSEC. But I don't get how!?

Posterrr57
  • 111
  • 2
  • Assuming the higher levels (here root and gtld) are DNSSEC-capable, DNSSEC status and key is included in each delegation level forming a trust chain. Explained in http://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions#The_lookup_procedure . – dave_thompson_085 Apr 28 '15 at 08:24
  • There is a trust chain only of all the NS involved are DNSSEC-capable. What if the attacker impersonate the last NS `example.com.` and reply as a non-DNSSEC-capable NS ? The resolver could check the trust chain if he receive any DNSSEC data, but (I think) he doesn't expect to receive such data, and thus, should accept the attacker's forged packet. – Posterrr57 Apr 28 '15 at 09:42

1 Answers1

3

The authoritative for .com will indicate in its signed answer that example.com is also signed (some output omitted)

$ 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=

Note the RRSIG - this is signed with the key for .com, and it allows the client to validate the DS records. The DS (Delegation Signer) records, in turn, are a hash of the DNSKEY for example.com. When a client receives this reply, it knows example.com MUST be signed, and MUST be signed with a key that matches one of the DS records. If the client then gets non-DNSSEC data from the example.com name servers, it knows something is wrong and will treat the data as BOGUS.

Habbie
  • 508
  • 3
  • 4