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!?

Improve this question
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 en.wikipedia.org/wiki/… .
    – dave_thompson_085
    Apr 28, 2015 at 8: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, 2015 at 9:42

1 Answer 1

Reset to default
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.

Improve this answer
3
  • And does Firefox notifies me that something sneaky is going on?
    – ilhan
    Nov 6, 2015 at 23:50
  • @lihan currently no, not without some extension
    – Patrick Mevzek
    Jun 28, 2017 at 19:37
  • In particular, you can't treat example.com as if it were unsigned without a cryptographic proof that the delegation lacks DS records.
    – R.. GitHub STOP HELPING ICE
    Jun 13, 2021 at 22:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .