DNS Workshop @CaribNOG12 Mark Kosters Carlos Martnez {ARIN, - PowerPoint PPT Presentation

DNS Workshop @CaribNOG12 Mark Kosters – Carlos Martínez {ARIN, LACNIC} CTO

DNS Refresher and Intro to DNS Security Extension (DNSSEC)

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

DNS Resolving Question: www.arin.net A root-servers www.arin.net A ? 2 1 “ go ask net server @ X.gtld-servers.net ” 3 www.arin.net A ? (+ glue) Caching Resolver 192.168.5.10 forwarder www.arin.net A ? 4 8 (recursive) gtld-servers “ go ask arinserver @ ns1.arin.net ” 5 (+ glue) 9 Add to cache www.arin.net A ? 6 TTL 10 “ 192.168.5.10 ” 7 arin-server

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

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

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

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)

Now for the Meat l We will be talking now how to solve cache pollution l It is quite complicated

Overview We will talk about: l 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

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

What's the problem? So what are the issues? 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...

What's the problem? What risks ? See Dan Kaminsky's slides for the extent of the risks l - 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 l http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html

Refresher

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

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

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

DNS points of attack

DNS Data Flow Points of attack zone file (text, MASTER DB) caching DATA STUB Zone dynamic resolver updates resolver Transfer (recursive) SLAVES spoofing cache man in the modified spoofed corrupted ATTACK master middle data data poisoning updates VECTORS (routing/DoS)

DNSSEC concepts

DNSSEC quick summary Data authenticity and integrity by signing the l Resource Records Sets with a private key l Public DNSKEYs published, used to verify the RRSIGs l 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... l l Not that difficult on paper − Operationally, it is a bit more complicated

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

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

DNSSEC concepts Build a chain of trust using the existing delegation- l based model of distribution that is the DNS l Don't sign the entire zone, sign a RRset “.” ORG NSRC WS l 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!)

New Resource Records

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

New Resource Record: RRSIG • Example: ~ carlosm$ dig +dnssec www.nic.se dig +dnssec www.nic.se ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 1 ;; ANSWER SECTION: www.nic.se. 60 IN A 212.247.7.218 www.nic.se. 60 IN RRSIG A 5 3 60 20101021132001 20101011132001 23369 nic.se. HeeUZ5h5iExK5uU1SuNRIf2Dbmh2/ aWV8FkjmzixUzTAVrHv39PfmfnG DHdHoZxoz85hqqYiWb +t9EZh5+iqxQk8AxRDic9Nn6WxifOoWeS+IUKQ rVyqXf1NtkZvu1A325vwa8obtbeVGVkhqg6bDIjKYeHixjlQ4cRoFcEW Izk= ;; AUTHORITY SECTION: nic.se. 2974 IN NS ns3.nic.se. nic.se. 2974 IN NS ns2.nic.se. nic.se. 2974 IN NS ns.nic.se. nic.se. 3600 IN RRSIG NS 5 2 3600 20101021132001 20101011132001 23369 nic.se. GSzAUC3SC3D0G/ iesCOPnVux8WkQx1dGbw491RatXz53b7SY0pQuyT1W eb063Z62rtX7etynNcJwpKlYTG9FeMbDceD9af3KzTJHxq6B+Tpmmxyk FoKAVaV0cHTcGUXSObFquGr5/03G79C/YHJmXw0bHun5ER5yrOtOLegU IAU= 27

New Resource Record: DNSKEY • Example: aruba:~ carlos$ dig @8.8.8.8 DNSKEY lacnic.net. ;; Truncated, retrying in TCP mode. ;; QUESTION SECTION: ;lacnic.net. IN DNSKEY ;; ANSWER SECTION: lacnic.net. 6272 IN DNSKEY 257 3 8 AwEAAb6YDZrhzHo3gu48uNvxFpvQ/I0TvaqGlYFE9VkplBkexiXwMHfm BVZF4SU7zSBcdX23jnotHmJd6Jicbhpk0ZVXS5szwbuC2TXaifx6bTOj fd0z8/zsk62tpvGDROQVgOTUNKmb1oZamX2Vm4Q58oFXQKkZm21sCeuR 6KhZo+pDkUWlDgI/gPLj1MFiorN9EWjUWbfHnnwVAldD6ftZ6KmhWlxm 7ynJ4Q3Glu5BX8ySh6l5JdFNyoVltfPXrwXJ4nqEaAEmPo8Vic++V3l5 2aQIgUnLmZ6mdfOxCT/YGcMIqUaiXRA0CpOMUr+K7GIvJIVyacOzIfe0 FKV/MreaVOk= 28

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 29

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 30 • DS records in the parent zone are

New Resource Record: DS • Example: ; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 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. 21599 IN DS 57814 8 1 10B742924448BD70481CACDDB1D21E5B0DBC8802 31

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