DNS Mark Kosters Carlos Martínez ARIN - LACNIC

Transcription

1 DNS Mark Kosters Carlos Martínez ARIN - LACNIC

2 DNS Refresher and Intro to DNS Security Extension (DNSSEC)

3 Outline Introduction DNSSEC mechanisms to establish authenticity and integrity of data Quick overview New RRs Using public key cryptography to sign a single zone Delegating signing authority ; building chains of trust Key exchange and rollovers Conclusions

4 DNS Resolving Question: A A? root-servers Resolver A? Add to cache Caching forwarder (recursive) A? go ask net X.gtld-servers.net (+ glue) gtld-servers go ask ns1.arin.net (+ glue) 6 A? 10 TTL arin-server

5 DNS: Data Flow Zone administrator Zone file 1 master 4 Caching forwarder Dynamic updates slaves resolver

6 DNS Vulnerabilities Corrupting data Zone administrator 1 Zone file Impersonating master master 4 Caching forwarder Cache impersonation Dynamic updates slaves Unauthorized updates Cache pollution by Data spoofing resolver Server protection Data protection

7 DNS Protocol Vulnerability DNS data can be spoofed and corrupted on its way between server and resolver or forwarder The DNS protocol does not allow you to check the validity of DNS data Exploited by bugs in resolver implementation (predictable transaction ID) Corrupted DNS data might end up in caches and stay there for a long time (TTL) How does a slave (secondary) knows it is talking to the proper master (primary)?

8 Motivation for DNSSEC DNSSEC protects against data spoofing and corruption DNSSEC (TSIG) provides mechanisms to authenticate servers DNSSEC (KEY/SIG/NXT) provides mechanisms to establish authenticity and integrity of data A secure DNS will be used as a public key infrastructure (PKI)

9 Now for the Meat We will be talking now how to solve cache pollution and prevent forgeries The key (pun intended) is to introduce digital signatures and public keys in DNS responses We ll describe how to just do that

10 Overview We will talk about: The problems that DNSSEC addresses The protocol and implementations Things to take into account to deploy DNSSEC The practical problems tied to real-world deployment

11 Contents Scope of the problem DNS reminders Basics of DNSSEC Deployment & operations Issues (what isn't solved) & other aspects Status of DNSSEC today

12 So what are the issues? What's the problem? DNS Cache Poisoning Forgery: respond before the intended nameserver Redirection of a domain's nameserver Redirection of NS records to another target domain DNS Hijacking Response to non-existent domains Rogue DNS servers These have been spotted in the wild code IS available...

13 What's the problem? What risks? See Dan Kaminsky's slides for the extent of the risks - MANY case scenarios MX hijacking Entire domain redirection Take a large.com offline Complete spoofing of a bank's DNS info More fun stuff A great illustrated guide

14 Refresher

15 DNS reminders ISC BIND zone file format is commonly used, and we will use this notation here. zone. SOA nsx.zone. hostmaster.zone. ( ; serial 1d ; refresh 12h ; retry 1w ; expire 1h ) ; neg. TTL zone. zone. NS NS MX A ns.zone. ns.otherzone. 5 server.otherzone

16 DNS reminders Record structure: NAME [TTL] TYPE DATA (type specific) host.zone A sub.zone MX 5 server.otherzone.

17 DNS reminders Multiple resource records with same name and type are grouped into Resource Record Sets (RRsets): mail.zone. mail.zone. MX MX 5 server1.zone. 10 server2.zone. RRset server1.zone. server1.zone. server1.zone. A A A RRset server1.zone. server1.zone. AAAA 2001:123:456::1 AAAA 2001:123:456::2 RRset server2.zone. A RRset

18 DNSSEC concepts

19 DNSSEC quick summary Data authenticity and integrity by signing the Resource Records Sets with a private key Public DNSKEYs published, used to verify the RRSIGs Children sign their zones with their private key Authenticity of that key established by signature/checksum by the parent of the (DS) delegation signer record Repeat for parent... Not that difficult on paper Operationally, it is a bit more complicated

20 DNS SECurity extensions DNSSEC overview Concepts New Resource Records (DNSKEY, RRSIG, NSEC/NSEC3 and DS) New packet options (CD, AD, DO) Setting up a Secure Zone Delegating Signing Authority Key Rollovers

21 DNSSEC concepts Changes DNS trust model from one of open and trusting to one of verifiable Extensive use of public key cryptography to provide: Authentication of origin Data integrity Authenticated denial of existence No attempt to provide confidentiality DNSSEC does not place computational load on the authoritative servers (!= those signing the zone) No modifications to the core protocol Can coexist with today's infrastructure kind of (EDNS0)

22 DNSSEC concepts Build a chain of trust using the existing delegationbased model of distribution that is the DNS Don't sign the entire zone, sign a RRset. ORG NSRC Note: the parent DOES NOT sign the child zone. The parent signs a pointer (hash) to the key used to sign the data of child zone (important!) WS

23 New Resource Records

24 Implementing the Trust Chain New resource records RRSIG: resource record signatures DNSKEY: DNS public key DS: delegation signature NSEC: denial of existence

25 New Resource Record: RRSIG Example: ~ carlosm$ dig +dnssec ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1 ;; ANSWER SECTION: 60 IN A IN RRSIG A nic.se. HeeUZ5h5iExK5uU1SuNRIf2Dbmh2/aWV8FkjmzixUzTAVrHv39PfmfnG DHdHoZxoz85hqqYiWb+t9EZh5+iqxQk8AxRDic9Nn6WxifOoWeS+IUKQ rvyqxf1ntkzvu1a325vwa8obtbevgvkhqg6bdijkyehixjlq4crofcew Izk= ;; AUTHORITY SECTION: nic.se IN NS ns3.nic.se. nic.se IN NS ns2.nic.se. nic.se IN NS ns.nic.se. nic.se IN RRSIG NS nic.se. GSzAUC3SC3D0G/iesCOPnVux8WkQx1dGbw491RatXz53b7SY0pQuyT1W eb063z62rtx7etynncjwpklytg9fembdced9af3kztjhxq6b+tpmmxyk FoKAVaV0cHTcGUXSObFquGr5/03G79C/YHJmXw0bHun5ER5yrOtOLegU IAU= 25

26 New Resource Record: DNSKEY Example: aruba:~ carlos$ DNSKEY lacnic.net. ;; Truncated, retrying in TCP mode. ;; QUESTION SECTION: ;lacnic.net. IN DNSKEY ;; ANSWER SECTION: lacnic.net IN DNSKEY AwEAAb6YDZrhzHo3gu48uNvxFpvQ/I0TvaqGlYFE9VkplBkexiXwMHfm BVZF4SU7zSBcdX23jnotHmJd6Jicbhpk0ZVXS5szwbuC2TXaifx6bTOj fd0z8/zsk62tpvgdroqvgotunkmb1ozamx2vm4q58ofxqkkzm21sceur 6KhZo+pDkUWlDgI/gPLj1MFiorN9EWjUWbfHnnwVAldD6ftZ6KmhWlxm 7ynJ4Q3Glu5BX8ySh6l5JdFNyoVltfPXrwXJ4nqEaAEmPo8Vic++V3l5 2aQIgUnLmZ6mdfOxCT/YGcMIqUaiXRA0CpOMUr+K7GIvJIVyacOzIfe0 FKV/MreaVOk= 26

27 Trust Chains How do clients verify a zone's RRSets? It queries for the corresponding DNSKEY The necessary computations are carried out and then compared with the signature in the RRSIG If they match the signatures are valid But, how can we trust the DNSKEY? It listed on the same zone we want to verify! We need to validate the trust chain 27

28 Trust Chains (ii) DS Record Delegation Signature DS records "sign" the keys in their child zones In this way one can also verify the DNSKEY as it is signed when the parent zone is signed DS records contain a hash of the public key That is a hash of the DNSKEY's record content DS records in the parent zone are signed with the keys of the parent zone To complete the full trust chain we also need the root of the DNS to be signed 28

29 New Resource Record: DS Example: ; <<>> DiG P1 DS lacnic.net. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 68 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;lacnic.net. IN DS ;; ANSWER SECTION: lacnic.net IN DS B BD70481CACDDB1D21E5B0DBC

30 Denial of Existence What happens when you ask DNS about something that does not exist? NXDOMAIN! However, in an NXDOMAIN response the ANSWER section is empty, there is nothing to sign Remember: negative answer are also cached, so they can be a DoS vector

31 Negative Responses Sample NXDOMAIN response: ; <<>> DiG P1 A holy-molly.lacnic.net. ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 6541 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;holy-molly.lacnic.net. IN A ;; AUTHORITY SECTION: lacnic.net IN SOA NS.lacnic.net. Hostmaster.lacnic.net

32 Signed Negative Responses Sample signed NXDOMAIN response: aruba:~ carlos$ dig A holy-molly.lacnic.net. ; <<>> DiG P1 <<>> A holy-molly.lacnic.net. ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 512 ;; QUESTION SECTION: ;holy-molly.lacnic.net. IN A ;; AUTHORITY SECTION: lacnic.net IN SOA NS.lacnic.net. Hostmaster.lacnic.net lacnic.net IN RRSIG SOA lacnic.net. EMkejVSEa3CvVzA2e3ap1n7QlgVUEPonIeBH4vcWjk..(snip) lacnic.net IN NSEC 18.lacnic.net. A NS SOA MX AAAA RRSIG NSEC DNSKEY TYPE

33 Using DNSSEC

34 Response Validation Signing zones is just half of the picture For DNSSEC to be actually useful, responses need to be validated This is the job of the recursive DNS servers Validation is usually just a configuration switch Need to make sure the root zone key is installed

35 Security Status of Data (RFC ) Secure Resolver is able to build a chain of signed DNSKEY and DS RRs from a trusted security anchor to the RRset Insecure Resolver knows that it has no chain of signed DNSKEY and DS RRs from any trusted starting point to the RRset Bogus Resolver believes that it ought to be able to establish a chain of trust but for which it is unable to do so May indicate an attack but may also indicate a configuration error or some form of data corruption Indeterminate Resolver is not able to determine whether the RRset should be signed

36 DNSSEC: new fields Updates DNS protocol at the packet level Non-compliant DNS recursive servers should ignore these: CD: Checking Disabled (ask recursing server to not perform validation, even if DNSSEC signatures are available and verifiable, i.e.: a Secure Entry Point can be found) AD: Authenticated Data, set on the answer by the validating server if the answer could be validated, and the client requested validation A new EDNS0 option DO: DNSSEC OK (EDNS0 OPT header) to indicate client support for DNSSEC options

37 Thank You

38 Signing a zone...

39 Enabling DNSSEC Multiple systems involved Stub resolvers Nothing to be done... but more on that later Caching resolvers (recursive) Enable DNSSEC validation Configure trust anchors manually, or use DLV Authoritative servers Enable DNSSEC logic (if required) Signing & serving need not be performed on same machine Signing system can be offline

40 Signing the zone 1. Generate keypairs 2. Include public DNSKEYs in zone file 3. Sign the zone using the secret key ZSK 4. Publishing the zone 5. Push DS record up to your parent 6. Wait...

41 # Generate ZSK 1. Generating the keys dnssec-keygen -a rsasha1 -b n ZONE myzone # Generate KSK dnssec-keygen -a rsasha1 -b n ZONE -f KSK myzone This generates 4 files: Kmyzone.+005+id_of_zsk.key Kmyzone.+005+id_of_zsk.private Kmyzone.+005+id_of_ksk.key Kmyzone.+005+id_of_ksk.private

42 2. Including the keys into the zone Include the DNSKEY records for the ZSK and KSK into the zone, to be signed with the rest of the data: cat Kmyzone*key >>myzone or add to the end of the zone file: $INCLUDE Kmyzone.+005+id_of_zsk.key $INCLUDE Kmyzone.+005+id_of_ksk.key

43 Sign your zone 3. Signing the zone # dnssec-signzone myzone dnssec-signzone will be run with all defaults for signature duration, the serial will not be incremented by default, and the private keys to use for signing will be automatically determined. Signing will: Sort the zone (lexicographically) Insert: NSEC records RRSIG records (signature of each RRset) DS records from child keyset files (for parent) Generate key-set and DS-set files, to be communicated to the parent

44 3. Signing the zone (2) Since version 9.7.0, BIND can automatically sign/re-sign your zone Makes life much easier Key generation, management & rollover still needs to be done separately

45 4. Publishing the signed zone Publish signed zone by reconfiguring the nameserver to load the signed zonefile.... but you still need to communicate the DS RRset in a secure fashion to your parent, otherwise no one will know you use DNSSEC

46 5. Pushing DS record to parent Need to securely communicate the KSK derived DS record set to the parent RFCs 4310, but what if your parent isn't DNSSEC-enabled?

47 Enabling DNSSEC in the resolver Configure forwarding resolver to validate DNSSEC not strictly necessary, but useful if only to verify that your zone works Test... Remember, validation is only done in the resolver.

48 Summary Generating keys Signing and publishing the zone Resolver configuration Testing the secure zone Questions so far?

49 DATA So, what does DNSSEC protect? MASTER zone file (text, DB) STUB resolver caching resolver (recursive) Zone Transfer dynamic updates SLAVES ATTACK VECTORS man in the middle cache poisoning modified data spoofing master (routing/dos) spoofed updates corrupted data (TSIG) PROTECTION BY DNSSEC

50 What doesn't it protect? Confidentiality The data is not encrypted Communication between the stub resolver (i.e: your OS/desktop) and the caching resolver. For this, you would have to use TSIG, SIG(0), or you will have to trust your resolver It performs all validation on your behalf

51 Why the long timeframe? Many different reasons... It's complicated. Not much best practice. More and more tools are appearing. Operational experience is the keyword. Risks of failure (failure to sign, failure to update) which will result in your zone disappearing Specification has changed several times since the 90s NSEC Allows for zone enumeration. Until Kaminsky, DNSSEC looked like a solution looking for a problem Delay in getting the root signed (politics)

52 Thank You

53 Thank you!