SlideShare uma empresa Scribd logo

DANE and Application Uses of DNSSEC

•
•
Shumon Huque
Shumon Huque

DANE and Application Uses of DNSSEC; Internet2 Technology Exchange; October 2014

Tecnologia
1 de 59
Baixar para ler offline
DANE & Application Uses of DNSSEC! Shumon Huque, Verisign Labs! Internet2 Technology Exchange, Indianapolis, IN! October 29th, 2014!
Verisign Public! 2! This session will give an overview of application uses of DNSSEC, available software tools, and application programmer interfaces. With the increasing deployment of DNSSEC, new, exciting uses are emerging that leverage the DNS to store and verify cryptographic keying material (like public keys, certificates, fingerprints, etc). The DANE (DNS-based Authentication of Named Entities) protocol and new DNS records like TLSA are among the principal enablers of these uses. This session will give an overview of DANE in the context of DNSSEC, use cases that it enables today and in the future, and available software tools. It will also talk about a new open DNS API called "getdns" that allows application programmers to more easily use DNS and DNSSEC enhanced responses without needing to be deep experts in the DNS protocol. The Research & Education community has long been a pioneer in deploying new technologies, including DNSSEC. Technologies like DANE are the next step in the evolution of DNSSEC, and we expect that DANE and new software APIs will be adopted and experimented with in this community.!
Verisign Public! DNSSEC at a glance! 3!
4! . (root)! .edu! upenn.edu!www.upenn.edu! recursive! resolver! endstation! (stub resolver)! 1! 2! 3! 4! 5! 6! 8! 7! answer 1.2.3.4! Recursive Resolver is prepopulated with root DNS server addresses! www.upenn.edu! referral to .edu! referral to upenn.edu!
Verisign Public! DNSSEC at a glance! •  Original DNS protocol wasn’t built with security in mind! •  No way to verify the authenticity of DNS data other than trusting the connection to the DNS server! •  DNSSEC: “DNS Security Extensions”! •  A system to verify the authenticity of DNS data! •  Specifications: RFC 4033, 4034, 4035, 5155! •  Protects against DNS spoofing & cache poisoning! •  Secondary benefits:! •  Ability to store and verify cryptographic keying material in the DNS, which could be used by new & existing application protocols! •  SSHFP, IPSECKEY, CERT, DKIM, etc.! •  DANE family: TLSA, OPENPGPKEY, SMIMEA, etc.! 5!
Verisign Public! DNSSEC at a glance! •  Uses public key cryptography! •  Each zone has a public and private key! •  Typically a 2-level hierarchy (KSK and ZSK) is used for each zone! •  Zone owner uses private key to sign the zone data, producing digital signatures for each resource record set! •  Public key is used by DNS resolvers to validate the signatures -> proof of authenticity! •  Public key is published in the zone! •  Zone public keys are organized in a chain of trust that follows the DNS delegation hierarchy! •  Resolvers authenticate signatures from the root down to the target zone containing the queried name! 6!
7! . (root)! .edu! upenn.edu!www.upenn.edu! recursive! resolver! endstation! (stub resolver)! 1! 2! 3! 4! 5! 6! 8! 7! answer 1.2.3.4! Recursive Resolver is prepopulated with root DNS server addresses! www.upenn.edu! referral to .edu! referral to upenn.edu!
8! . (root)! .edu! upenn.edu!www.upenn.edu! recursive! resolver! endstation! (stub resolver)! 1! 2! 3! 4! 5! 6! 8! 7! Recursive Resolver is prepopulated with root DNS server addresses and the root’s public key! referral to .edu! + DS,RRSIG! referral to upenn.edu! + DS, RRSIG! answer 1.2.3.4! + RRSIG! www.upenn.edu! set DO bit! (has root’s pubkey)! answer! + AD bit! root’s pubkey! edu pubkey! upenn pubkey! (Also queries for DNSKEY and DS records are performed as needed)!
Verisign Public! DNSSEC: Additional DNS record types! 9! Record Name! Description! DNSKEY! Contains zone’s public key! RRSIG! Contains digital signature of record set! NSEC! Points to next name in the zone! (for authenticated denial of existence)! DS! Delegation signer! (signs/authenticates key for a child zone)! NSEC3! Enhanced version of NSEC! (provides zone enumeration defense & opt-out)! NSEC3PARAM! Parameters for NSEC3! (flags, hash, iterations, salt)!
Verisign Public! Changes in a signed zone! •  One or more DNSKEY records at zone apex! •  One or more NSEC for each DNS name! •  One or more RRSIG (signature) for each RR Set! •  One or more DS records (in parent zone) for every secure delegation to a child zone! •  Exceptions: non-authoritative data like delegation NS record sets and glue records do not have signatures! 10!
$ dig jabber.upenn.edu A! ! ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 337! ! ;; QUESTION SECTION:! ;jabber.upenn.edu.! !IN !A! ! ;; ANSWER SECTION:! jabber.upenn.edu. ! 86400 ! IN ! A! 128.91.2.172! ! ;; AUTHORITY SECTION:! upenn.edu. ! ! 86400 ! IN ! NS sns-pb.isc.org.! upenn.edu. ! ! 86400 ! IN NS ! adns3.upenn.edu.! upenn.edu. ! ! 86400 ! IN ! NS ! adns2.upenn.edu.! upenn.edu. ! ! 86400 ! IN ! NS ! adns1.upenn.edu.! upenn.edu. ! ! 86400 ! IN NS ! dns2.udel.edu.! upenn.edu. ! ! 86400 ! IN ! NS ! dns1.udel.edu.! ! ;; ADDITIONAL SECTION:! adns1.upenn.edu. ! 81904 ! IN ! A! 128.91.3.128! adns1.upenn.edu. ! 81904 ! IN ! AAAA ! 2607:f470:1001::1:a! adns2.upenn.edu. ! 81904 ! IN ! A! 128.91.254.22! adns2.upenn.edu. ! 81904 ! IN ! AAAA ! 2607:f470:1002::2:3! adns3.upenn.edu. ! 81904 ! IN ! A! 128.91.251.33! adns3.upenn.edu. ! 81904 ! IN ! AAAA ! 2607:f470:1003::3:c! 11! RRset without! signature!
$ dig jabber.upenn.edu A +dnssec! ! ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 690! ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 7! ! ;; OPT PSEUDOSECTION:! ; EDNS: version: 0, flags: do; udp: 4096! ;; QUESTION SECTION:! ;jabber.upenn.edu. IN A! ! ;; ANSWER SECTION:! jabber.upenn.edu. ! 86400 IN A 128.91.2.172! jabber.upenn.edu. ! 86400 IN RRSIG A 5 3 86400 (! ! ! ! ! 20140909070510 20140810061231 50475 upenn.edu.! ! ! ! ! jFElfhdkNeWsIwEZcV/n2nt9T2KXKogYYtyemVEf3X4l! ! ! ! ! 4nbhyXGvFdGEtmDS9cVl3RgiwwUVaY78jaz7cQPX2lc3! ! ! ! ! raYDrLY3irRh1NSbt9v/esF4SI06KwRmhTv3Z2GBVP+C! ! ! ! ! jFkMLJnN1dFBEa2UHzFzIk7cKoQcdmEdbiDJ3Ag= )! ! ;; AUTHORITY SECTION:! upenn.edu. 86400 IN NS dns1.udel.edu.! upenn.edu. 86400 IN NS noc3.dccs.upenn.edu.! upenn.edu. 86400 IN NS dns2.udel.edu.! upenn.edu. 86400 IN NS noc2.dccs.upenn.edu.! upenn.edu. 86400 IN RRSIG NS 5 2 86400 20140919232217 (! 20140819223616 50475 upenn.edu.! WWpT4uD9p5zORM+2O7pRZ46+Qo3cHj9tnjxH62Xt9QBR! yu9V7+3ihlIM1HCd9kjsddskT8GJ+5hEzykB8fPIjSli! bqG6hCnCccGdTsGzmPoGdlz95H7Nf2yfrlGLAcSCix6I! EJb8Aj4+OW9Zq1dmeZrnJDXSzm8joQg5+IlkzR4= )! DNSSEC Ok flag! Authenticated Data! Answer &! Signature! (Algorithm 5: RSA-SHA1)!
Verisign Public! DNSViz – Visual DNS Analysis! •  Online analysis (query/response) of DNS name, authoritative servers, and dependencies! •  Graphical representation of chain of trust! •  DNSKEY, DS, RRsets! •  Authenticated denial of existence! •  Web interface! 13! . com baz.com http://dnsviz.net/!
Verisign Public! 14! RRset (authenticated)! Broken chain of trust! Trust anchor! RRSIG! DS digest! DNSKEY! RRset (bogus)!
Verisign Public! DNSSEC Deployment overview! A very brief overview of DNSSEC deployment in the Internet! 15!
Verisign Public! Brief DNSSEC Deployment status! •  DNS Root was signed in July 2010! •  TLDs signed [1]: .COM, .NET, .EDU, .ORG, .GOV, etc.:! •  All TLDs: 543 of 726 (74.8%), as of October 2014! •  ccTLDs: 102 of 286 (36%)! •  New gTLDs: all are signed (418 of 418)! •  Reverse trees (in-addr.arpa and ip6.arpa) are signed! •  Levels beneath TLDs are where more needs to be done! •  US .GOV federal: ~ 82% [3](Oct 2014) – FISMA OMB Mandate! •  Internet2 Higher Ed members [1]: 27 of ~ 266 (10.2%)! •  .NL (Netherlands) has over 1.8 million signed delegations [2]! •  .COM has 384,100 signed delegations (0.33%)! 16! [1] http://www.huque.com/app/dnsstat/! [2] https://xs.powerdns.com/dnssec-nl-graph/! [3] http://la51.icann.org/en/schedule/wed-dnssec/presentation-dnssec-deployment-gov-15oct14-en! [4] htttp://statdns.com/ & http://scoreboard.verisign.com/!
Verisign Public! Signed zones at Internet2 full members! 17!http://www.huque.com/app/dnsstat/category/internet2/dnssec/!
Verisign Public! Use of DNSSEC Validation by resolvers! •  US Gov FISMA IT security policy DNSSEC validation mandate (Spring 2014)! •  Some very large DNS resolver services are doing DNSSEC validation:! •  Google Public DNS (free; very widely used)! •  Comcast DNS [1]: ~ 18.1 million subscriber homes! •  A number of US R&E institutions and NRENs! •  Worldwide there is substantial amount of validation, as measured by APNIC! •  Roughly ¼ of DNS queries by resolvers in the US perform DNSSEC validation! 18! [1] http://la51.icann.org/en/schedule/wed-dnssec/presentation-dnssec-dns-15oct14-en!
Verisign Public! DNSSEC Validation map (from APNIC)! 19!gronggrong.rand.apnic.net/cgi-bin/worldmap!
Verisign Public! Application Uses of DNSSEC! 20!
Verisign Public! Application uses of DNSSEC! •  One of the more exciting prospects for DNSSEC! •  DNSSEC can be employed to store cryptographic keys in the DNS, and ..! •  Allow applications to securely obtain (authenticate) those keys and use them in application security protocols! •  Some possible applications: SSH, SSL/TLS, HTTPS, S/ MIME, PGP, SMTP, DKIM, and many others ..! •  Existing records:! •  SSHFP, IPSECKEY, DKIM TXT record, …! •  DANE records: TLSA, OPENPGPKEY! •  Upcoming:! •  SMIMEA, IPSECA, …! 21!
Verisign Public! SSHFP record! 22! grodd.magpi.net.!86400!IN!SSHFP!(1 1! F60AE0994C0B02545D444F7996088E9EA7359CBA)! • SSH Host Key Fingerprint (RFC 4255)! • Allows you to validate SSH host keys using DNSSEC! algorithm! number! fingerprint ! type (1= SHA1)! fingerprint! In OpenSSH, you can use the client configuration directive “VerifyHostKeyDNS” to use this. Enabled by default in some newer operating systems like FreeBSD 10.!
Verisign Public! IPSECKEY record! 23! 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2! 192.0.2.38! AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )! • RFC 4025: method for storing IPsec keying material in DNS! • rdata format: precedence, gateway-type, algorithm, gateway address, public key! • Not much uptake of this record! • Will likely be superseded by newer proposals, like IPSECA!
Verisign Public! TLS and the Internet PKI! •  A very large number of security protocols authenticate server names with SSL/TLS certificates! •  TLS, IPsec, HTTPS, SIPS, SMTP, IMAP, XMPP, …! •  These certificates are issued and signed by the Internet PKI, composed of a set of globally trusted public Certification Authorities (CAs)! ! 24!
Verisign Public! Public CA model issues! •  Applications need to trust a large number of global Certification Authorities (CA)! •  No namespace constraints! Any CA can issue certificates for any entity on the Internet! •  Least common denominator security: our collective security is equal to the weakest one!! •  Furthermore, many of them issue subordinate CA certificates to their customers, again with no naming constraints! •  Most CAs aren’t capable of issuing certificates with any but the most basic capabilities (e.g. alternate name forms or other extensions)! 25!
Verisign Public! Public CA model issues! •  “Analysis of the HTTPS Certificate Ecosystem”, UMich, October 2013, Internet Measurement Conference! •  http://conferences.sigcomm.org/imc/2013/papers/imc257- durumericAemb.pdf! •  Over 1,800 separate CAs are capable of issuing certificates for anyone! (Root CAs and intermediate CAs issued by them)! •  “The Shape & Size of Threats: Defining a Networked System’s Attack Surface”! •  Eric Osterweil (Verisign), Danny McPherson (Verisign), Lixia Zhang (UCLA), NPsec 2014 conference! ! 26!
Verisign Public! Can DNSSEC help?! •  Can we leverage DNSSEC to address these deficiencies?! •  DNS has hierarchical, decentralized administration! •  Certificates and public keys placed in the DNS can be authenticated with DNSSEC signatures! •  Name constraints are inherent! •  Deployed infrastructure is becoming real! •  Root and many of the TLDs are signed, so most organizations can sign their zones and have an intact secure chain of trust to the root! •  Validation is also becoming more prevalent (see prior slides in deployment status)! 27!
Verisign Public! DANE and the TLSA record! •  RFC 6698: The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security! •  http://tools.ietf.org/html/rfc6698! •  Defines a new DNS record type “TLSA”, that can be used for better & more secure ways to authenticate SSL/TLS certificates! •  By specifying constraints on which CA can vouch for a certificate, or which specific PKIX end-entity certificate is valid! •  By specifying that a service certificate or a CA can be directly authenticated in the DNS itself.! 28!
29! _443._tcp.www.example.com. IN TLSA (! 0 0 1 d2abde240d7cd3ee6b4b28c54df034b9! 7983a1d16e8a410e4561cb106618e971 )! port, transport proto & ! server domain name! TLSA rrtype! certificate association data! usage! selector! matching! type! TLSA record example!
Verisign Public! TLSA configuration parameters! 30! Usage field:! 0 PKIX-TA: CA Constraint! 1 PKIX-EE: Service Certificate Constraint! 2 DANE-TA: Trust Anchor Assertion! 3 DANE-EE: Domain Issued Certificate! ! Selector field:! 0 Match full certificate! 1 Match only SubjectPublicKeyInfo! ! Matching type field:! 0 Exact match on selected content! 1 SHA-256 hash of selected content! 2 SHA-512 hash of selected content! ! ! Certificate Association Data: raw cert data in hex!
Verisign Public! TLSA configuration parameters! 31! Usage field:! 0 PKIX-TA: CA Constraint! 1 PKIX-EE: Service Certificate Constraint! 2 DANE-TA: Trust Anchor Assertion! 3 DANE-EE: Domain Issued Certificate! ! Selector field:! 0 Match full certificate! 1 Match only SubjectPublicKeyInfo! ! Matching type field:! 0 Exact match on selected content! 1 SHA-256 hash of selected content! 2 SHA-512 hash of selected content! ! ! Certificate Association Data: raw cert data in hex! Co-exists with and ! Strengthens Public ! CA system! Operation without! Public CAs!
Verisign Public! Usage types! 32! 0 PKIX-TA: CA Constraint! Specify which CA should be trusted to authenticate the! !certificate for the service. Full PKIX certificate! !chain validation needs to be performed.! ! 1 PKIX-EE: Service Certificate Constraint! !Define which specific service certificate (“EE cert”)! !should be trusted for the service. Full PKIX cert! !validation needs to be performed.! ! 2 DANE-TA: Trust Anchor Assertion! !Specify a domain operated CA which should be trusted! !independently to vouch for the service certificate.! ! 3 DANE-EE: Domain Issued Certificate! !Define a specific service certificate for the service! !at this domain name.!
Verisign Public! Example TLSA record (for WWW)! 33! _443._tcp.fedoraproject.org. 263 IN TLSA 0 0 1 (! ! ! ! !19400BE5B7A31FB733917700789D2F0A2471C0C9D506! ! ! ! !C0E504C06C16D7CB17C0 )! ! _443._tcp.fedoraproject.org. 263 IN RRSIG TLSA 5 4 300 (! ! ! ! !20141114150617 20141015150617 7725 fedoraproject.org.! ! ! ! !hrk0si7I/BWTz0wEtMcFZNUCj/0o5796k5FVuZx6eXrc! ! ! ! !YOe/ChHA/Shu/WHr3iM1yNGi86+8t4wMq9GA+JZthWZC! ! ! ! !ZmENxf9OTNe/t/LBAc2EDW/fMBJq0JO2b4ZkJHXCEyX0! ! ! ! !CDsIYz8shZ20nPGlrsYqwLdQiCeravWcwcJiPuc= )! ! ! Usage 0 (“CA Constraint”) – this record says:! -  For service at fedoraproject.org tcp port 443! -  only the CA with the specified SHA-256 certificate fingerprint (19400BE5B…) should be trusted!
Verisign Public! 34!
Verisign Public! DANE/TLSA tools and software! •  TLSA Record Generation! •  Command line tools: “swede”, “hash-slinger”, “ldns-dane”! •  Web based tool: https://www.huque.com/bin/gen_tlsa! •  TLSA validators for web! •  Some 3rd party validator plugins are available (Firefox, Chrome, Opera, Safari):! •  https://www.dnssec-validator.cz/! •  http://blog.huque.com/2014/02/dnssec-dane-tlsa-browser- addons.html! •  Bloodhound Mozilla fork:! •  https://www.dnssec-tools.org/wiki/index.php/Bloodhound! ! 35!
Verisign Public! DANE for SMTP! 36!
Verisign Public! DANE for SMTP! •  DANE in conjunction with SMTP over TLS, or SMTP + STARTTLS can be used to more fully secure email delivery! •  DANE can authenticate the certificate of the SMTP submission server that the user’s mail client (MUA) communicates with! •  DANE can authenticate TLS connections between SMTP servers (“MTA”s or Mail Transfer Agents)! •  This second use case is where DANE solves some important problems that are unaddressed today! 37!
Verisign Public! DANE for SMTP! •  Most connections between SMTP servers today use encryption opportunistically (i.e. if both sides support and advertise it, it is used)! •  Even when encryption is used, it is vulnerable to attack:! •  Attackers can strip away the TLS capability advertisement and downgrade the connection to not use TLS! •  TLS connections are often unauthenticated (e.g. the use of self signed certificates as well as mismatched certificates is common)! •  DANE can address both these vulnerabilities! •  Authenticate the certificate using a DNSSEC signed TLSA record! •  Use the presence of the TLSA record as an indicator that encryption must be performed (prevent downgrade)! •  http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane! 38!
Verisign Public! Example TLSA record (for SMTP)! 39! _25._tcp.mx1.freebsd.org. 2389 IN TLSA 3 0 1 (! ! ! ! !5EC0508C3F337D18509F41BFF9D8AB07FED588A132FA! ! ! ! !12FA1E223BA6B9403ACB )! ! _25._tcp.mx1.freebsd.org. 2389 IN RRSIG !TLSA 8 5 3600 (! ! ! ! !20141023072418 20141009105807 39939 freebsd.org.! ! ! ! !ll6DEQ7oP2lbEcOeJyPk+I8tYiGz4CzuDiqiMbr4Mzp3! ! ! ! !90UWdej3kdAz4t+1BT0dO3/o0nz0pp3HFsDu+gkwT6YH! ! ! ! !Jg4C6mi3STPciCP1tjbFuW/dv4lPkCUaN7kJt/qwPrR6! ! ! ! !0kQmyvcuUoYgUDPbNYbJNJXai+mFai5WqLS2MEP15ydU! ! ! ! !nt8KympnjHS5mVLVGXW0e7tLY1afQz1VrIeYsGW8YztM! ! ! ! !DYUpCXjWiq+YpCFv7rZ7ICejQR6ot1M35CDsfjk68eu0! ! ! ! !EAjx+HlqaTdGyilcMB+GduFwqkULDPIgiFu/3xb+srJR! ! ! ! !zuR89YpHga9OCnz6nXJgQ6cxvSImZWbKuw== )! ! This is a domain-issued certificate (usage 3), which can be authenticated without a trusted CA.!
Verisign Public! Early large adopters of SMTP + DANE! •  posteo.de! •  mailbox.org! •  umbkw.de! •  bund.de! •  denic.de! •  freebsd.org! •  unitybox.de! •  debian.org, debian.net! •  ietf.org! •  nlnetlabs.nl! •  nic.cz! •  nic.ch! •  torproject.org! 40! Quite a few are large email systems in Germany. See a! larger list at https://www.tlsa.info/! !
Verisign Public! SMTP servers that support DANE! •  Postfix MTA (works today, version 2.11 onwards)! •  Exim (currently under development)! ! 41!
Verisign Public! XMPP servers! •  XMPP (Jabber) has seen some uptake of DANE.! •  To authenticate the c2s and/or s2s portion of the XMPP protocol! •  List of XMPP servers with DANE TLSA records:! •  https://xmpp.net/reports.php#dnssecdane! 42! Example:! ! _xmpp-server._tcp.mail.de. 3600!IN!SRV! 10 20 5269 jabber.mail.de.! ! _5269._tcp.jabber.mail.de. 600 !IN!TLSA !3 1 1 (! A0315F0CF61CAC787140833C2C608550476! 246DDA54122D66BB339D5 0FBB10E3 )! !
Verisign Public! OpenPGPKEY! •  OPENPGPKEY record! •  Used to publish an OpenPGP public keys in the DNS! •  DNSSEC signature provides authentication! •  Spec under development, but RR code already assigned! •  http://tools.ietf.org/html/draft-wouters-dane-openpgp-02! ! ! 43!
Verisign Public! Example OPENPGPKEY record! 44! For shuque@huque.com! ! 1st label: sha224 hash of “shuque” = ! 4f7c2705c0f139ede60573f8537a0790fb64df5d4a819af951d259bc! ! 2nd label: “_openpgpkey”! ! Remaining labels: domain name portion of the email addr:! Huque.com! ! ! Resulting record looks like this:! ! 4f7c2705c0f139ede60573f8537a0790fb64df5d4a819af951d259bc. _openpgpkey.huque.com.! IN OPENPGPKEY <base64 encoding of the openpgp key>! !
Verisign Public! SMIMEA! •  Using DNSSEC to associate certificates with domain names for S/MIME! •  http://tools.ietf.org/html/draft-hoffman-dane-smime! •  S/MIME is a method of encrypting and signing MIME data used in e-mail messages! •  The SMIMEA DNS record proposes to associate S/MIME certificates with DNS domain names! •  Verisign DANE/SMIMEA early Mail User Agent Prototype! •  http://la51.icann.org/en/schedule/wed-dnssec/presentation- dnssec-dane-smime-15oct14-en! 45!
Verisign Public! getdns: a brief introduction! A new application friendly interface to the DNS! 46!
Verisign Public! Application access to any kind of DNS data! •  Today’s commonly used DNS application interfaces, like getaddrinfo(), getnameinfo() are designed to obtain the most common types of DNS data, e.g. name to IP address mappings, reverse DNS mappings, etc.! •  How do applications ask for other types of data, eg. TLSA, SSHFP records, or even SRV records?! •  How can we tell if a response was successfully authenticated with DNSSEC?! •  Some lower level, harder to use libraries exist (libresolv etc) that can do some of this, but application developers deserve something much better! 47!
. (root)! .edu! upenn.edu!www.upenn.edu! referral to .edu! + DS, RRSIG! recursive! resolver! endstation! (uses DNS stub resolver)! 1! 2! 3! 4! 5! 6! 8! 7! referral to upenn.edu! + DS, RRSIG! answer 1.2.3.4! + RRSIG! www.upenn.edu! set DO bit! root’s pubkey! (has root’s pubkey)! edu pubkey! upenn pubkey! Stub to Recursive! Resolver channel! 48! Securing the first hop?!
Verisign Public! DNS first hop protection! •  Applications normally query a DNS stub resolver! •  The stub resolver communicates over the network with a recursive resolver. How do we secure that path?! •  Complex solutions exist (but rarely used)! •  e.g. employ a channel security mechanism between the stub and the validating recursive resolver:! •  TSIG, SIG(0), IPsec! •  Run full-service validating resolver on endstation! •  There may be other solutions, like DNScrypt – not standards based, only supported by a few resolvers, not widely used! •  getdns can solve this problem! 49!
Verisign Public! getdns: a new DNS library for applications! •  getdns: A new application-friendly interface to the DNS! •  Get and use arbitrary data in the DNS easily! •  Get this data securely, authenticated with DNSSEC if it’s available! •  Full iterative resolver mode with validation! •  Validating stub resolver mode! •  Designed by application developers. Most previous APIs have been developed by DNS protocol people with less concern for the needs of app developers.! 50!
Verisign Public! getdns! •  API specification:! •  http://www.vpnc.org/getdns-api/! •  Latest revision: February 2014! •  Creative Commons Attribution 3.0 Unported license! •  An opensource implementation at http://getdnsapi.net/! •  A joint project of Verisign Labs and NLNet Labs! •  First release (0.1.0) in February 2014! •  Latest release (0.1.4) in August 2014! •  C library! •  Bindings in Python, and Node.js (upcoming: go, ruby, perl)! •  BSD 3 License! 51!
Verisign Public! getdns features! •  Asynchronous and synchronous modes of operation! •  Sensible defaults suitable for consumption by most users! •  But behavior highly configurable for users with advanced knowledge of the DNS! •  DNS query results are returned in an easy to parse “response dictionary” data structure! •  Members of the data structure can be lists, dictionaries, integers, and binary strings! •  Can return DNSSEC status, and can be instructed to only return DNSSEC authenticated results! 52!
Verisign Public! getdns functions! 53! Four main functions defined.! ! getdns_address() Obtain IPv4 and/or IPv6 addresses! ! getdns_hostname() Obtain reverse DNS mappings! ! getdns_service() Obtain SRV record answers! ! getdns_general() General purpose DNS record query! ! Read the API specification for full details:! ! http://www.vpnc.org/getdns-api/! !
Verisign Public! getdns response dictionary (partial)! 54! {! "answer_type": GETDNS_NAMETYPE_DNS,! "canonical_name": <bindata of "www.internet2.edu.">,! "just_address_answers”: [! {! "address_data": <bindata for 207.75.164.248>,! "address_type": <bindata of "IPv4">! },! {! "address_data": <bindata for 2001:48a8:68fe::248>,! "address_type": <bindata of "IPv6">! }! ],! "replies_full":! [! <bindata of 0x000081a0000100040000000103777777...>,! <bindata of 0x000081a0000100040005000d03777777...>! ], …!
Verisign Public! getdns response dictionary (partial)! 55! "dnssec_status": GETDNS_DNSSEC_SECURE,! ! "replies_tree":! [! {! "additional": [],! "answer":! [! {! "class": GETDNS_RRCLASS_IN,! "name": <bindata for www.internet2.edu.>,! "rdata":! {! "cname": <bindata for webprod2.internet2.edu.>,! "rdata_raw": <bindata for webprod2.internet2.edu.>! },! "ttl": 120,! "type": GETDNS_RRTYPE_CNAME! },! […]!
Verisign Public! getdns: example code: hostname lookup! 56! # Example python code to query a domain name and! # return all associated IPv4 and IPv6 addresses.! ! hostname = sys.argv[1]! ! ctx = getdns.Context()! extensions = {"return_both_v4_and_v6”:getdns.GETDNS_EXTENSION_TRUE}! ! results = ctx.address(name=hostname, extensions=extensions)! status = results['status']! ! if status == getdns.GETDNS_RESPSTATUS_GOOD:! for addr in results['just_address_answers']:! print addr['address_data']! else:! print "%s: getdns.address() error: %d" % (hostname, status)! ! ! $ ./program.py www.internet2.edu! 207.75.164.248! 2001:48a8:68fe::248!
Verisign Public! getdns: example code: TLSA record lookup! 57! # Example python code to lookup an authenticated TLSA! # record for a domain name, transport, & service port.! ! qname = “_443._tcp.fedoraproject.org”! qtype = getdns.GETDNS_RRTYPE_TLSA! ! ctx = getdns.Context()! extensions = {! "dnssec_return_only_secure”:getdns.GETDNS_EXTENSION_TRUE ! }! ! results = ctx.general(name=qname, request_type=qtype, ! extensions=extensions)! status = results['status']! ! if status == getdns.GETDNS_RESPSTATUS_GOOD:! # here we’d normally parse and do something useful with the! # result data. For now just pretty print the dict.! pprint.pprint(results)! else:! print "%s: getdns.address() error: %d" % (hostname, status)! !
Verisign Public! Questions or comments?! Shumon Huque! shuque @ verisign.com! 58!
© 2014 VeriSign, Inc. All rights reserved. VERISIGN and other trademarks, service marks, and designs are registered or unregistered trademarks of VeriSign, Inc. and its subsidiaries in the United States and in foreign countries. All other trademarks are property of their respective owners.!

Recomendados

DNSSEC at Penn
DNSSEC at PennDNSSEC at Penn
DNSSEC at Penn
Shumon Huque
 
Using Algorithms to Brute Force Algorithms...A Journey Through Time and Names...
Using Algorithms to Brute Force Algorithms...A Journey Through Time and Names...Using Algorithms to Brute Force Algorithms...A Journey Through Time and Names...
Using Algorithms to Brute Force Algorithms...A Journey Through Time and Names...
OpenDNS
 
DNS fragmentation attacks - the dangers of not validating DNSSEC
DNS fragmentation attacks - the dangers of not validating DNSSEC DNS fragmentation attacks - the dangers of not validating DNSSEC
DNS fragmentation attacks - the dangers of not validating DNSSEC
Men and Mice
 
Cryptolocker Webcast
Cryptolocker WebcastCryptolocker Webcast
Cryptolocker Webcast
OpenDNS
 
DEF CON 27 - TRAVIS PALMER - first try dns cache poisoning with ipv4 and ipv6...
DEF CON 27 - TRAVIS PALMER - first try dns cache poisoning with ipv4 and ipv6...DEF CON 27 - TRAVIS PALMER - first try dns cache poisoning with ipv4 and ipv6...
DEF CON 27 - TRAVIS PALMER - first try dns cache poisoning with ipv4 and ipv6...
Felipe Prado
 
deftcon 2015 - Dave Piscitello - DNS Traffic Monitoring
deftcon 2015 - Dave Piscitello - DNS Traffic Monitoringdeftcon 2015 - Dave Piscitello - DNS Traffic Monitoring
deftcon 2015 - Dave Piscitello - DNS Traffic Monitoring
Deft Association
 
RIPE 70 Report Webinar
RIPE 70 Report WebinarRIPE 70 Report Webinar
RIPE 70 Report Webinar
Men and Mice
 
The KNOT DNS Server
The KNOT DNS ServerThe KNOT DNS Server
The KNOT DNS Server
Men and Mice
 

Recomendados

DNSSEC at Penn
DNSSEC at PennDNSSEC at Penn
DNSSEC at Penn
Shumon Huque
 
Using Algorithms to Brute Force Algorithms...A Journey Through Time and Names...
Using Algorithms to Brute Force Algorithms...A Journey Through Time and Names...Using Algorithms to Brute Force Algorithms...A Journey Through Time and Names...
Using Algorithms to Brute Force Algorithms...A Journey Through Time and Names...
OpenDNS
 
DNS fragmentation attacks - the dangers of not validating DNSSEC
DNS fragmentation attacks - the dangers of not validating DNSSEC DNS fragmentation attacks - the dangers of not validating DNSSEC
DNS fragmentation attacks - the dangers of not validating DNSSEC
Men and Mice
 
Cryptolocker Webcast
Cryptolocker WebcastCryptolocker Webcast
Cryptolocker Webcast
OpenDNS
 
DEF CON 27 - TRAVIS PALMER - first try dns cache poisoning with ipv4 and ipv6...
DEF CON 27 - TRAVIS PALMER - first try dns cache poisoning with ipv4 and ipv6...DEF CON 27 - TRAVIS PALMER - first try dns cache poisoning with ipv4 and ipv6...
DEF CON 27 - TRAVIS PALMER - first try dns cache poisoning with ipv4 and ipv6...
Felipe Prado
 
deftcon 2015 - Dave Piscitello - DNS Traffic Monitoring
deftcon 2015 - Dave Piscitello - DNS Traffic Monitoringdeftcon 2015 - Dave Piscitello - DNS Traffic Monitoring
deftcon 2015 - Dave Piscitello - DNS Traffic Monitoring
Deft Association
 
RIPE 70 Report Webinar
RIPE 70 Report WebinarRIPE 70 Report Webinar
RIPE 70 Report Webinar
Men and Mice
 
The KNOT DNS Server
The KNOT DNS ServerThe KNOT DNS Server
The KNOT DNS Server
Men and Mice
 
End-to-End Analysis of a Domain Generating Algorithm Malware Family
End-to-End Analysis of a Domain Generating Algorithm Malware FamilyEnd-to-End Analysis of a Domain Generating Algorithm Malware Family
End-to-End Analysis of a Domain Generating Algorithm Malware Family
CrowdStrike
 
Dns security threats and solutions
Dns security threats and solutionsDns security threats and solutions
Dns security threats and solutions
Frank Victory
 
Monica Salas & Raul Siles - Hype Potter and the Chamber of DNSSECrets [rooted...
Monica Salas & Raul Siles - Hype Potter and the Chamber of DNSSECrets [rooted...Monica Salas & Raul Siles - Hype Potter and the Chamber of DNSSECrets [rooted...
Monica Salas & Raul Siles - Hype Potter and the Chamber of DNSSECrets [rooted...
RootedCON
 
DNSSEC and DANE – E-Mail security reloaded
DNSSEC and DANE – E-Mail security reloadedDNSSEC and DANE – E-Mail security reloaded
DNSSEC and DANE – E-Mail security reloaded
Men and Mice
 
DNS Security Threats and Solutions
DNS Security Threats and SolutionsDNS Security Threats and Solutions
DNS Security Threats and Solutions
InnoTech
 
ION Trinidad and Tobago - The Business Case for DNSSEC
ION Trinidad and Tobago - The Business Case for DNSSECION Trinidad and Tobago - The Business Case for DNSSEC
ION Trinidad and Tobago - The Business Case for DNSSEC
Deploy360 Programme (Internet Society)
 
Intro To Hacking
Intro To HackingIntro To Hacking
Intro To Hacking
nayakslideshare
 
Class Project Showcase: DNS Spoofing
Class Project Showcase: DNS SpoofingClass Project Showcase: DNS Spoofing
Class Project Showcase: DNS Spoofing
Beibei Yang
 
Строим ханипот и выявляем DDoS-атаки
Строим ханипот и выявляем DDoS-атакиСтроим ханипот и выявляем DDoS-атаки
Строим ханипот и выявляем DDoS-атаки
Positive Hack Days
 
DNS как линия защиты/DNS as a Defense Vector
DNS как линия защиты/DNS as a Defense VectorDNS как линия защиты/DNS as a Defense Vector
DNS как линия защиты/DNS as a Defense Vector
Positive Hack Days
 
( Ethical hacking tools ) Information grathring
( Ethical hacking tools ) Information grathring( Ethical hacking tools ) Information grathring
( Ethical hacking tools ) Information grathring
Gouasmia Zakaria
 
Passive DNS Collection – Henry Stern, Cisco
Passive DNS Collection – Henry Stern, CiscoPassive DNS Collection – Henry Stern, Cisco
Passive DNS Collection – Henry Stern, Cisco
Henry Stern
 
Actividad configuración de cisco asa vpn
Actividad configuración de cisco asa vpnActividad configuración de cisco asa vpn
Actividad configuración de cisco asa vpn
Andres Ldño
 
DNS High-Availability Tools - Open-Source Load Balancing Solutions
DNS High-Availability Tools - Open-Source Load Balancing SolutionsDNS High-Availability Tools - Open-Source Load Balancing Solutions
DNS High-Availability Tools - Open-Source Load Balancing Solutions
Men and Mice
 
Dns tunnelling its all in the name
Dns tunnelling its all in the nameDns tunnelling its all in the name
Dns tunnelling its all in the name
Security BSides London
 
DNSTap Webinar
DNSTap WebinarDNSTap Webinar
DNSTap Webinar
Men and Mice
 
10 - IDNOG04 - Enrico Hugo (Indonesia Honeynet Project) - The Rise of DGA Mal...
10 - IDNOG04 - Enrico Hugo (Indonesia Honeynet Project) - The Rise of DGA Mal...10 - IDNOG04 - Enrico Hugo (Indonesia Honeynet Project) - The Rise of DGA Mal...
10 - IDNOG04 - Enrico Hugo (Indonesia Honeynet Project) - The Rise of DGA Mal...
Indonesia Network Operators Group
 
OC Big Data Monthly Meetup #5 - Session 2 - Sumo Logic
OC Big Data Monthly Meetup #5 - Session 2 - Sumo LogicOC Big Data Monthly Meetup #5 - Session 2 - Sumo Logic
OC Big Data Monthly Meetup #5 - Session 2 - Sumo Logic
Big Data Joe™ Rossi
 
Incident response: Advanced Network Forensics
Incident response: Advanced Network ForensicsIncident response: Advanced Network Forensics
Incident response: Advanced Network Forensics
Napier University
 
Day 2 Dns Cert 4a Cache Poisoning
Day 2 Dns Cert 4a Cache PoisoningDay 2 Dns Cert 4a Cache Poisoning
Day 2 Dns Cert 4a Cache Poisoning
vngundi
 
ION Toronto - Why Implement DNSSEC?
ION Toronto - Why Implement DNSSEC? ION Toronto - Why Implement DNSSEC?
ION Toronto - Why Implement DNSSEC?
Deploy360 Programme (Internet Society)
 
DNSSEC FIRST
DNSSEC FIRSTDNSSEC FIRST
DNSSEC FIRST
Victor Ramiro
 

Mais conteúdo relacionado

Mais procurados

End-to-End Analysis of a Domain Generating Algorithm Malware Family
End-to-End Analysis of a Domain Generating Algorithm Malware FamilyEnd-to-End Analysis of a Domain Generating Algorithm Malware Family
End-to-End Analysis of a Domain Generating Algorithm Malware Family
CrowdStrike
 
ION Trinidad and Tobago - The Business Case for DNSSEC
ION Trinidad and Tobago - The Business Case for DNSSECION Trinidad and Tobago - The Business Case for DNSSEC
ION Trinidad and Tobago - The Business Case for DNSSEC
Deploy360 Programme (Internet Society)
 
DNS как линия защиты/DNS as a Defense Vector
DNS как линия защиты/DNS as a Defense VectorDNS как линия защиты/DNS as a Defense Vector
DNS как линия защиты/DNS as a Defense Vector
Positive Hack Days
 
Passive DNS Collection – Henry Stern, Cisco
Passive DNS Collection – Henry Stern, CiscoPassive DNS Collection – Henry Stern, Cisco
Passive DNS Collection – Henry Stern, Cisco
Henry Stern
 
Actividad configuración de cisco asa vpn
Actividad configuración de cisco asa vpnActividad configuración de cisco asa vpn
Actividad configuración de cisco asa vpn
Andres Ldño
 

Mais procurados (20)

End-to-End Analysis of a Domain Generating Algorithm Malware Family
End-to-End Analysis of a Domain Generating Algorithm Malware FamilyEnd-to-End Analysis of a Domain Generating Algorithm Malware Family
End-to-End Analysis of a Domain Generating Algorithm Malware Family
 
Dns security threats and solutions
Dns security threats and solutionsDns security threats and solutions
Dns security threats and solutions
 
Monica Salas & Raul Siles - Hype Potter and the Chamber of DNSSECrets [rooted...
Monica Salas & Raul Siles - Hype Potter and the Chamber of DNSSECrets [rooted...Monica Salas & Raul Siles - Hype Potter and the Chamber of DNSSECrets [rooted...
Monica Salas & Raul Siles - Hype Potter and the Chamber of DNSSECrets [rooted...
 
DNSSEC and DANE – E-Mail security reloaded
DNSSEC and DANE – E-Mail security reloadedDNSSEC and DANE – E-Mail security reloaded
DNSSEC and DANE – E-Mail security reloaded
 
DNS Security Threats and Solutions
DNS Security Threats and SolutionsDNS Security Threats and Solutions
DNS Security Threats and Solutions
 
ION Trinidad and Tobago - The Business Case for DNSSEC
ION Trinidad and Tobago - The Business Case for DNSSECION Trinidad and Tobago - The Business Case for DNSSEC
ION Trinidad and Tobago - The Business Case for DNSSEC
 
Intro To Hacking
Intro To HackingIntro To Hacking
Intro To Hacking
 
Class Project Showcase: DNS Spoofing
Class Project Showcase: DNS SpoofingClass Project Showcase: DNS Spoofing
Class Project Showcase: DNS Spoofing
 
Строим ханипот и выявляем DDoS-атаки
Строим ханипот и выявляем DDoS-атакиСтроим ханипот и выявляем DDoS-атаки
Строим ханипот и выявляем DDoS-атаки
 
DNS как линия защиты/DNS as a Defense Vector
DNS как линия защиты/DNS as a Defense VectorDNS как линия защиты/DNS as a Defense Vector
DNS как линия защиты/DNS as a Defense Vector
 
( Ethical hacking tools ) Information grathring
( Ethical hacking tools ) Information grathring( Ethical hacking tools ) Information grathring
( Ethical hacking tools ) Information grathring
 
Passive DNS Collection – Henry Stern, Cisco
Passive DNS Collection – Henry Stern, CiscoPassive DNS Collection – Henry Stern, Cisco
Passive DNS Collection – Henry Stern, Cisco
 
Actividad configuración de cisco asa vpn
Actividad configuración de cisco asa vpnActividad configuración de cisco asa vpn
Actividad configuración de cisco asa vpn
 
DNS High-Availability Tools - Open-Source Load Balancing Solutions
DNS High-Availability Tools - Open-Source Load Balancing SolutionsDNS High-Availability Tools - Open-Source Load Balancing Solutions
DNS High-Availability Tools - Open-Source Load Balancing Solutions
 
Dns tunnelling its all in the name
Dns tunnelling its all in the nameDns tunnelling its all in the name
Dns tunnelling its all in the name
 
DNSTap Webinar
DNSTap WebinarDNSTap Webinar
DNSTap Webinar
 
10 - IDNOG04 - Enrico Hugo (Indonesia Honeynet Project) - The Rise of DGA Mal...
10 - IDNOG04 - Enrico Hugo (Indonesia Honeynet Project) - The Rise of DGA Mal...10 - IDNOG04 - Enrico Hugo (Indonesia Honeynet Project) - The Rise of DGA Mal...
10 - IDNOG04 - Enrico Hugo (Indonesia Honeynet Project) - The Rise of DGA Mal...
 
OC Big Data Monthly Meetup #5 - Session 2 - Sumo Logic
OC Big Data Monthly Meetup #5 - Session 2 - Sumo LogicOC Big Data Monthly Meetup #5 - Session 2 - Sumo Logic
OC Big Data Monthly Meetup #5 - Session 2 - Sumo Logic
 
Incident response: Advanced Network Forensics
Incident response: Advanced Network ForensicsIncident response: Advanced Network Forensics
Incident response: Advanced Network Forensics
 
Day 2 Dns Cert 4a Cache Poisoning
Day 2 Dns Cert 4a Cache PoisoningDay 2 Dns Cert 4a Cache Poisoning
Day 2 Dns Cert 4a Cache Poisoning
 

Destaque

DNSSEC - Domain Name System Security Extensions
DNSSEC - Domain Name System Security ExtensionsDNSSEC - Domain Name System Security Extensions
DNSSEC - Domain Name System Security Extensions
Peter R. Egli
 
150928 - Verisign Public DNS
150928 - Verisign Public DNS150928 - Verisign Public DNS
150928 - Verisign Public DNS
Michael Kaczmarek
 
BIND’s New Security Feature: DNSRPZ - the &quot;DNS Firewall&quot;
BIND’s New Security Feature: DNSRPZ - the &quot;DNS Firewall&quot;BIND’s New Security Feature: DNSRPZ - the &quot;DNS Firewall&quot;
BIND’s New Security Feature: DNSRPZ - the &quot;DNS Firewall&quot;
Barry Greene
 
Approaches to application request throttling
Approaches to application request throttlingApproaches to application request throttling
Approaches to application request throttling
Maarten Balliauw
 

Destaque (20)

ION Toronto - Why Implement DNSSEC?
ION Toronto - Why Implement DNSSEC? ION Toronto - Why Implement DNSSEC?
ION Toronto - Why Implement DNSSEC?
 
DNSSEC FIRST
DNSSEC FIRSTDNSSEC FIRST
DNSSEC FIRST
 
Deploying New DNSSEC Algorithms (IEPG@IETF93 - July 2015)
Deploying New DNSSEC Algorithms (IEPG@IETF93 - July 2015)Deploying New DNSSEC Algorithms (IEPG@IETF93 - July 2015)
Deploying New DNSSEC Algorithms (IEPG@IETF93 - July 2015)
 
AEP Netwrorks Keyper HSM & ICANN DNSSEC
AEP Netwrorks Keyper HSM & ICANN DNSSECAEP Netwrorks Keyper HSM & ICANN DNSSEC
AEP Netwrorks Keyper HSM & ICANN DNSSEC
 
ION Hangzhou - Why Deploy DNSSEC?
ION Hangzhou - Why Deploy DNSSEC?ION Hangzhou - Why Deploy DNSSEC?
ION Hangzhou - Why Deploy DNSSEC?
 
MCSA 70-412 Chapter 01
MCSA 70-412 Chapter 01MCSA 70-412 Chapter 01
MCSA 70-412 Chapter 01
 
CNIT 40: 6: DNSSEC and beyond
CNIT 40: 6: DNSSEC and beyondCNIT 40: 6: DNSSEC and beyond
CNIT 40: 6: DNSSEC and beyond
 
DNSSEC - Domain Name System Security Extensions
DNSSEC - Domain Name System Security ExtensionsDNSSEC - Domain Name System Security Extensions
DNSSEC - Domain Name System Security Extensions
 
DNSSEC: What a Registrar Needs to Know
DNSSEC: What a Registrar Needs to KnowDNSSEC: What a Registrar Needs to Know
DNSSEC: What a Registrar Needs to Know
 
Internet2 DNSSEC Pilot
Internet2 DNSSEC PilotInternet2 DNSSEC Pilot
Internet2 DNSSEC Pilot
 
Network security
Network securityNetwork security
Network security
 
150928 - Verisign Public DNS
150928 - Verisign Public DNS150928 - Verisign Public DNS
150928 - Verisign Public DNS
 
Query-name Minimization and Authoritative Server Behavior
Query-name Minimization and Authoritative Server BehaviorQuery-name Minimization and Authoritative Server Behavior
Query-name Minimization and Authoritative Server Behavior
 
DNS for Developers - NDC Oslo 2016
DNS for Developers - NDC Oslo 2016DNS for Developers - NDC Oslo 2016
DNS for Developers - NDC Oslo 2016
 
TTÜ Geeky Weekly
TTÜ Geeky WeeklyTTÜ Geeky Weekly
TTÜ Geeky Weekly
 
BIND’s New Security Feature: DNSRPZ - the &quot;DNS Firewall&quot;
BIND’s New Security Feature: DNSRPZ - the &quot;DNS Firewall&quot;BIND’s New Security Feature: DNSRPZ - the &quot;DNS Firewall&quot;
BIND’s New Security Feature: DNSRPZ - the &quot;DNS Firewall&quot;
 
Approaches to application request throttling
Approaches to application request throttlingApproaches to application request throttling
Approaches to application request throttling
 
Creating Domain Specific Languages in Python
Creating Domain Specific Languages in PythonCreating Domain Specific Languages in Python
Creating Domain Specific Languages in Python
 
Remediating Violated Customers
Remediating Violated CustomersRemediating Violated Customers
Remediating Violated Customers
 
OpenDNS Enterprise Web Content Filtering
OpenDNS Enterprise Web Content FilteringOpenDNS Enterprise Web Content Filtering
OpenDNS Enterprise Web Content Filtering
 

Semelhante a DANE and Application Uses of DNSSEC

PLNOG 5: Eric Ziegast, Zbigniew Jasinski - DNSSEC
PLNOG 5: Eric Ziegast, Zbigniew Jasinski - DNSSECPLNOG 5: Eric Ziegast, Zbigniew Jasinski - DNSSEC
PLNOG 5: Eric Ziegast, Zbigniew Jasinski - DNSSEC
PROIDEA
 
6 technical-dns-workshop-day3
6 technical-dns-workshop-day36 technical-dns-workshop-day3
6 technical-dns-workshop-day3
DNS Entrepreneurship Center
 
8 technical-dns-workshop-day4
8 technical-dns-workshop-day48 technical-dns-workshop-day4
8 technical-dns-workshop-day4
DNS Entrepreneurship Center
 

Semelhante a DANE and Application Uses of DNSSEC (20)

Spark Summit EU talk by Debasish Das and Pramod Narasimha
Spark Summit EU talk by Debasish Das and Pramod NarasimhaSpark Summit EU talk by Debasish Das and Pramod Narasimha
Spark Summit EU talk by Debasish Das and Pramod Narasimha
 
Spark Summit EU talk by Debasish Das and Pramod Narasimha
Spark Summit EU talk by Debasish Das and Pramod NarasimhaSpark Summit EU talk by Debasish Das and Pramod Narasimha
Spark Summit EU talk by Debasish Das and Pramod Narasimha
 
Hardening the Core of the Internet
Hardening the Core of the InternetHardening the Core of the Internet
Hardening the Core of the Internet
 
DNSSEC for Registrars by .ORG & Afilias
DNSSEC for Registrars by .ORG & AfiliasDNSSEC for Registrars by .ORG & Afilias
DNSSEC for Registrars by .ORG & Afilias
 
DNSSEC best practices Webinar
DNSSEC best practices WebinarDNSSEC best practices Webinar
DNSSEC best practices Webinar
 
Signing DNSSEC answers on the fly at the edge: challenges and solutions
Signing DNSSEC answers on the fly at the edge: challenges and solutionsSigning DNSSEC answers on the fly at the edge: challenges and solutions
Signing DNSSEC answers on the fly at the edge: challenges and solutions
 
PowerDNS Webinar
PowerDNS Webinar PowerDNS Webinar
PowerDNS Webinar
 
Introduction DNSSec
Introduction DNSSecIntroduction DNSSec
Introduction DNSSec
 
DNSSEC - WHAT IS IT ? INSTALL AND CONFIGURE IN CHROOT JAIL
DNSSEC - WHAT IS IT ? INSTALL AND CONFIGURE IN CHROOT JAILDNSSEC - WHAT IS IT ? INSTALL AND CONFIGURE IN CHROOT JAIL
DNSSEC - WHAT IS IT ? INSTALL AND CONFIGURE IN CHROOT JAIL
 
PLNOG 5: Eric Ziegast, Zbigniew Jasinski - DNSSEC
PLNOG 5: Eric Ziegast, Zbigniew Jasinski - DNSSECPLNOG 5: Eric Ziegast, Zbigniew Jasinski - DNSSEC
PLNOG 5: Eric Ziegast, Zbigniew Jasinski - DNSSEC
 
Hadoop
HadoopHadoop
Hadoop
 
Tsig 17022011
Tsig 17022011Tsig 17022011
Tsig 17022011
 
6 technical-dns-workshop-day3
6 technical-dns-workshop-day36 technical-dns-workshop-day3
6 technical-dns-workshop-day3
 
DANE and Application Uses of DNSSEC
DANE and Application Uses of DNSSECDANE and Application Uses of DNSSEC
DANE and Application Uses of DNSSEC
 
IETF 90 Report – DNS, DHCP, IPv6 and DANE
IETF 90 Report – DNS, DHCP, IPv6 and DANEIETF 90 Report – DNS, DHCP, IPv6 and DANE
IETF 90 Report – DNS, DHCP, IPv6 and DANE
 
IETF 92 Webinar
IETF 92 WebinarIETF 92 Webinar
IETF 92 Webinar
 
Computer forensics libin
Computer forensics libinComputer forensics libin
Computer forensics libin
 
HPCC Systems vs Hadoop
HPCC Systems vs HadoopHPCC Systems vs Hadoop
HPCC Systems vs Hadoop
 
Testing Rolling Roots
Testing Rolling RootsTesting Rolling Roots
Testing Rolling Roots
 
8 technical-dns-workshop-day4
8 technical-dns-workshop-day48 technical-dns-workshop-day4
8 technical-dns-workshop-day4
 

Mais de Shumon Huque

Mais de Shumon Huque (20)

DANE and DNSSEC Authentication Chain Extension for TLS
DANE and DNSSEC Authentication Chain Extension for TLSDANE and DNSSEC Authentication Chain Extension for TLS
DANE and DNSSEC Authentication Chain Extension for TLS
 
Client Certificates in DANE TLSA Records
Client Certificates in DANE TLSA RecordsClient Certificates in DANE TLSA Records
Client Certificates in DANE TLSA Records
 
Hands-on getdns Tutorial
Hands-on getdns TutorialHands-on getdns Tutorial
Hands-on getdns Tutorial
 
IPv6 Tutorial; USENIX LISA 2013
IPv6 Tutorial; USENIX LISA 2013IPv6 Tutorial; USENIX LISA 2013
IPv6 Tutorial; USENIX LISA 2013
 
DNSSEC Tutorial; USENIX LISA 2013
DNSSEC Tutorial; USENIX LISA 2013DNSSEC Tutorial; USENIX LISA 2013
DNSSEC Tutorial; USENIX LISA 2013
 
IPv6 Transition in Research & Education
IPv6 Transition in Research & EducationIPv6 Transition in Research & Education
IPv6 Transition in Research & Education
 
Authorization at Penn
Authorization at PennAuthorization at Penn
Authorization at Penn
 
IPv6 Deployment Panel
IPv6 Deployment PanelIPv6 Deployment Panel
IPv6 Deployment Panel
 
A survey of DNSSEC Deployment in the US R&E Community
A survey of DNSSEC Deployment in the US R&E CommunityA survey of DNSSEC Deployment in the US R&E Community
A survey of DNSSEC Deployment in the US R&E Community
 
World IPv6 Launch at Penn
World IPv6 Launch at PennWorld IPv6 Launch at Penn
World IPv6 Launch at Penn
 
IPv6 Security Panel (U of Penn)
IPv6 Security Panel (U of Penn)IPv6 Security Panel (U of Penn)
IPv6 Security Panel (U of Penn)
 
Open Source VoIP at Penn
Open Source VoIP at PennOpen Source VoIP at Penn
Open Source VoIP at Penn
 
Kerberos at Penn (MIT Kerberos Consortium)
Kerberos at Penn (MIT Kerberos Consortium)Kerberos at Penn (MIT Kerberos Consortium)
Kerberos at Penn (MIT Kerberos Consortium)
 
.EDU DNSSEC Testbed - Lessons Learned
.EDU DNSSEC Testbed - Lessons Learned.EDU DNSSEC Testbed - Lessons Learned
.EDU DNSSEC Testbed - Lessons Learned
 
IPv6 Campus Deployment Panel
IPv6 Campus Deployment PanelIPv6 Campus Deployment Panel
IPv6 Campus Deployment Panel
 
.EDU DNSSEC Testbed
.EDU DNSSEC Testbed.EDU DNSSEC Testbed
.EDU DNSSEC Testbed
 
PennNet and MAGPI
PennNet and MAGPIPennNet and MAGPI
PennNet and MAGPI
 
Internet2 DNSSEC Pilot
Internet2 DNSSEC PilotInternet2 DNSSEC Pilot
Internet2 DNSSEC Pilot
 
Internet2 DNSSEC Pilot
Internet2 DNSSEC PilotInternet2 DNSSEC Pilot
Internet2 DNSSEC Pilot
 
MAGPI: Advanced Services: IPv6, Multicast, DNSSEC
MAGPI: Advanced Services: IPv6, Multicast, DNSSECMAGPI: Advanced Services: IPv6, Multicast, DNSSEC
MAGPI: Advanced Services: IPv6, Multicast, DNSSEC
 

Último

The Role of Taxonomy and Ontology in Semantic Layers - Heather Hedden.pdf
The Role of Taxonomy and Ontology in Semantic Layers - Heather Hedden.pdfThe Role of Taxonomy and Ontology in Semantic Layers - Heather Hedden.pdf
The Role of Taxonomy and Ontology in Semantic Layers - Heather Hedden.pdf
Enterprise Knowledge
 
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot TakeoffStrategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
sammart93
 
EIS-Webinar-Prompt-Knowledge-Eng-2024-04-08.pptx
EIS-Webinar-Prompt-Knowledge-Eng-2024-04-08.pptxEIS-Webinar-Prompt-Knowledge-Eng-2024-04-08.pptx
EIS-Webinar-Prompt-Knowledge-Eng-2024-04-08.pptx
Earley Information Science
 
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
Miguel Araújo
 
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
Understanding Discord NSFW Servers A Guide for Responsible Users.pdfUnderstanding Discord NSFW Servers A Guide for Responsible Users.pdf
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
UK Journal
 
Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...
Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...
Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...
Igalia
 
08448380779 Call Girls In Civil Lines Women Seeking Men
08448380779 Call Girls In Civil Lines Women Seeking Men08448380779 Call Girls In Civil Lines Women Seeking Men
08448380779 Call Girls In Civil Lines Women Seeking Men
Delhi Call girls
 

Último (20)

The Role of Taxonomy and Ontology in Semantic Layers - Heather Hedden.pdf
The Role of Taxonomy and Ontology in Semantic Layers - Heather Hedden.pdfThe Role of Taxonomy and Ontology in Semantic Layers - Heather Hedden.pdf
The Role of Taxonomy and Ontology in Semantic Layers - Heather Hedden.pdf
 
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot TakeoffStrategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
Strategize a Smooth Tenant-to-tenant Migration and Copilot Takeoff
 
Presentation on how to chat with PDF using ChatGPT code interpreter
Presentation on how to chat with PDF using ChatGPT code interpreterPresentation on how to chat with PDF using ChatGPT code interpreter
Presentation on how to chat with PDF using ChatGPT code interpreter
 
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
Bajaj Allianz Life Insurance Company - Insurer Innovation Award 2024
 
EIS-Webinar-Prompt-Knowledge-Eng-2024-04-08.pptx
EIS-Webinar-Prompt-Knowledge-Eng-2024-04-08.pptxEIS-Webinar-Prompt-Knowledge-Eng-2024-04-08.pptx
EIS-Webinar-Prompt-Knowledge-Eng-2024-04-08.pptx
 
Tech Trends Report 2024 Future Today Institute.pdf
Tech Trends Report 2024 Future Today Institute.pdfTech Trends Report 2024 Future Today Institute.pdf
Tech Trends Report 2024 Future Today Institute.pdf
 
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
Mastering MySQL Database Architecture: Deep Dive into MySQL Shell and MySQL R...
 
Workshop - Best of Both Worlds_ Combine KG and Vector search for enhanced R...
Workshop - Best of Both Worlds_ Combine KG and Vector search for enhanced R...Workshop - Best of Both Worlds_ Combine KG and Vector search for enhanced R...
Workshop - Best of Both Worlds_ Combine KG and Vector search for enhanced R...
 
How to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected WorkerHow to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected Worker
 
How to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected WorkerHow to Troubleshoot Apps for the Modern Connected Worker
How to Troubleshoot Apps for the Modern Connected Worker
 
Strategies for Landing an Oracle DBA Job as a Fresher
Strategies for Landing an Oracle DBA Job as a FresherStrategies for Landing an Oracle DBA Job as a Fresher
Strategies for Landing an Oracle DBA Job as a Fresher
 
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
Understanding Discord NSFW Servers A Guide for Responsible Users.pdfUnderstanding Discord NSFW Servers A Guide for Responsible Users.pdf
Understanding Discord NSFW Servers A Guide for Responsible Users.pdf
 
Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...
Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...
Raspberry Pi 5: Challenges and Solutions in Bringing up an OpenGL/Vulkan Driv...
 
GenCyber Cyber Security Day Presentation
GenCyber Cyber Security Day PresentationGenCyber Cyber Security Day Presentation
GenCyber Cyber Security Day Presentation
 
2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...2024: Domino Containers - The Next Step. News from the Domino Container commu...
2024: Domino Containers - The Next Step. News from the Domino Container commu...
 
08448380779 Call Girls In Civil Lines Women Seeking Men
08448380779 Call Girls In Civil Lines Women Seeking Men08448380779 Call Girls In Civil Lines Women Seeking Men
08448380779 Call Girls In Civil Lines Women Seeking Men
 
How to convert PDF to text with Nanonets
How to convert PDF to text with NanonetsHow to convert PDF to text with Nanonets
How to convert PDF to text with Nanonets
 
[2024]Digital Global Overview Report 2024 Meltwater.pdf
[2024]Digital Global Overview Report 2024 Meltwater.pdf[2024]Digital Global Overview Report 2024 Meltwater.pdf
[2024]Digital Global Overview Report 2024 Meltwater.pdf
 
Handwritten Text Recognition for manuscripts and early printed texts
Handwritten Text Recognition for manuscripts and early printed textsHandwritten Text Recognition for manuscripts and early printed texts
Handwritten Text Recognition for manuscripts and early printed texts
 
presentation ICT roal in 21st century education
presentation ICT roal in 21st century educationpresentation ICT roal in 21st century education
presentation ICT roal in 21st century education
 

DANE and Application Uses of DNSSEC

  • 1. DANE & Application Uses of DNSSEC! Shumon Huque, Verisign Labs! Internet2 Technology Exchange, Indianapolis, IN! October 29th, 2014!
  • 2. Verisign Public! 2! This session will give an overview of application uses of DNSSEC, available software tools, and application programmer interfaces. With the increasing deployment of DNSSEC, new, exciting uses are emerging that leverage the DNS to store and verify cryptographic keying material (like public keys, certificates, fingerprints, etc). The DANE (DNS-based Authentication of Named Entities) protocol and new DNS records like TLSA are among the principal enablers of these uses. This session will give an overview of DANE in the context of DNSSEC, use cases that it enables today and in the future, and available software tools. It will also talk about a new open DNS API called "getdns" that allows application programmers to more easily use DNS and DNSSEC enhanced responses without needing to be deep experts in the DNS protocol. The Research & Education community has long been a pioneer in deploying new technologies, including DNSSEC. Technologies like DANE are the next step in the evolution of DNSSEC, and we expect that DANE and new software APIs will be adopted and experimented with in this community.!
  • 4. 4! . (root)! .edu! upenn.edu!www.upenn.edu! recursive! resolver! endstation! (stub resolver)! 1! 2! 3! 4! 5! 6! 8! 7! answer 1.2.3.4! Recursive Resolver is prepopulated with root DNS server addresses! www.upenn.edu! referral to .edu! referral to upenn.edu!
  • 5. Verisign Public! DNSSEC at a glance! •  Original DNS protocol wasn’t built with security in mind! •  No way to verify the authenticity of DNS data other than trusting the connection to the DNS server! •  DNSSEC: “DNS Security Extensions”! •  A system to verify the authenticity of DNS data! •  Specifications: RFC 4033, 4034, 4035, 5155! •  Protects against DNS spoofing & cache poisoning! •  Secondary benefits:! •  Ability to store and verify cryptographic keying material in the DNS, which could be used by new & existing application protocols! •  SSHFP, IPSECKEY, CERT, DKIM, etc.! •  DANE family: TLSA, OPENPGPKEY, SMIMEA, etc.! 5!
  • 6. Verisign Public! DNSSEC at a glance! •  Uses public key cryptography! •  Each zone has a public and private key! •  Typically a 2-level hierarchy (KSK and ZSK) is used for each zone! •  Zone owner uses private key to sign the zone data, producing digital signatures for each resource record set! •  Public key is used by DNS resolvers to validate the signatures -> proof of authenticity! •  Public key is published in the zone! •  Zone public keys are organized in a chain of trust that follows the DNS delegation hierarchy! •  Resolvers authenticate signatures from the root down to the target zone containing the queried name! 6!
  • 7. 7! . (root)! .edu! upenn.edu!www.upenn.edu! recursive! resolver! endstation! (stub resolver)! 1! 2! 3! 4! 5! 6! 8! 7! answer 1.2.3.4! Recursive Resolver is prepopulated with root DNS server addresses! www.upenn.edu! referral to .edu! referral to upenn.edu!
  • 8. 8! . (root)! .edu! upenn.edu!www.upenn.edu! recursive! resolver! endstation! (stub resolver)! 1! 2! 3! 4! 5! 6! 8! 7! Recursive Resolver is prepopulated with root DNS server addresses and the root’s public key! referral to .edu! + DS,RRSIG! referral to upenn.edu! + DS, RRSIG! answer 1.2.3.4! + RRSIG! www.upenn.edu! set DO bit! (has root’s pubkey)! answer! + AD bit! root’s pubkey! edu pubkey! upenn pubkey! (Also queries for DNSKEY and DS records are performed as needed)!
  • 9. Verisign Public! DNSSEC: Additional DNS record types! 9! Record Name! Description! DNSKEY! Contains zone’s public key! RRSIG! Contains digital signature of record set! NSEC! Points to next name in the zone! (for authenticated denial of existence)! DS! Delegation signer! (signs/authenticates key for a child zone)! NSEC3! Enhanced version of NSEC! (provides zone enumeration defense & opt-out)! NSEC3PARAM! Parameters for NSEC3! (flags, hash, iterations, salt)!
  • 10. Verisign Public! Changes in a signed zone! •  One or more DNSKEY records at zone apex! •  One or more NSEC for each DNS name! •  One or more RRSIG (signature) for each RR Set! •  One or more DS records (in parent zone) for every secure delegation to a child zone! •  Exceptions: non-authoritative data like delegation NS record sets and glue records do not have signatures! 10!
  • 11. $ dig jabber.upenn.edu A! ! ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 337! ! ;; QUESTION SECTION:! ;jabber.upenn.edu.! !IN !A! ! ;; ANSWER SECTION:! jabber.upenn.edu. ! 86400 ! IN ! A! 128.91.2.172! ! ;; AUTHORITY SECTION:! upenn.edu. ! ! 86400 ! IN ! NS sns-pb.isc.org.! upenn.edu. ! ! 86400 ! IN NS ! adns3.upenn.edu.! upenn.edu. ! ! 86400 ! IN ! NS ! adns2.upenn.edu.! upenn.edu. ! ! 86400 ! IN ! NS ! adns1.upenn.edu.! upenn.edu. ! ! 86400 ! IN NS ! dns2.udel.edu.! upenn.edu. ! ! 86400 ! IN ! NS ! dns1.udel.edu.! ! ;; ADDITIONAL SECTION:! adns1.upenn.edu. ! 81904 ! IN ! A! 128.91.3.128! adns1.upenn.edu. ! 81904 ! IN ! AAAA ! 2607:f470:1001::1:a! adns2.upenn.edu. ! 81904 ! IN ! A! 128.91.254.22! adns2.upenn.edu. ! 81904 ! IN ! AAAA ! 2607:f470:1002::2:3! adns3.upenn.edu. ! 81904 ! IN ! A! 128.91.251.33! adns3.upenn.edu. ! 81904 ! IN ! AAAA ! 2607:f470:1003::3:c! 11! RRset without! signature!
  • 12. $ dig jabber.upenn.edu A +dnssec! ! ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 690! ;; flags: qr aa rd ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 7! ! ;; OPT PSEUDOSECTION:! ; EDNS: version: 0, flags: do; udp: 4096! ;; QUESTION SECTION:! ;jabber.upenn.edu. IN A! ! ;; ANSWER SECTION:! jabber.upenn.edu. ! 86400 IN A 128.91.2.172! jabber.upenn.edu. ! 86400 IN RRSIG A 5 3 86400 (! ! ! ! ! 20140909070510 20140810061231 50475 upenn.edu.! ! ! ! ! jFElfhdkNeWsIwEZcV/n2nt9T2KXKogYYtyemVEf3X4l! ! ! ! ! 4nbhyXGvFdGEtmDS9cVl3RgiwwUVaY78jaz7cQPX2lc3! ! ! ! ! raYDrLY3irRh1NSbt9v/esF4SI06KwRmhTv3Z2GBVP+C! ! ! ! ! jFkMLJnN1dFBEa2UHzFzIk7cKoQcdmEdbiDJ3Ag= )! ! ;; AUTHORITY SECTION:! upenn.edu. 86400 IN NS dns1.udel.edu.! upenn.edu. 86400 IN NS noc3.dccs.upenn.edu.! upenn.edu. 86400 IN NS dns2.udel.edu.! upenn.edu. 86400 IN NS noc2.dccs.upenn.edu.! upenn.edu. 86400 IN RRSIG NS 5 2 86400 20140919232217 (! 20140819223616 50475 upenn.edu.! WWpT4uD9p5zORM+2O7pRZ46+Qo3cHj9tnjxH62Xt9QBR! yu9V7+3ihlIM1HCd9kjsddskT8GJ+5hEzykB8fPIjSli! bqG6hCnCccGdTsGzmPoGdlz95H7Nf2yfrlGLAcSCix6I! EJb8Aj4+OW9Zq1dmeZrnJDXSzm8joQg5+IlkzR4= )! DNSSEC Ok flag! Authenticated Data! Answer &! Signature! (Algorithm 5: RSA-SHA1)!
  • 13. Verisign Public! DNSViz – Visual DNS Analysis! •  Online analysis (query/response) of DNS name, authoritative servers, and dependencies! •  Graphical representation of chain of trust! •  DNSKEY, DS, RRsets! •  Authenticated denial of existence! •  Web interface! 13! . com baz.com http://dnsviz.net/!
  • 14. Verisign Public! 14! RRset (authenticated)! Broken chain of trust! Trust anchor! RRSIG! DS digest! DNSKEY! RRset (bogus)!
  • 15. Verisign Public! DNSSEC Deployment overview! A very brief overview of DNSSEC deployment in the Internet! 15!
  • 16. Verisign Public! Brief DNSSEC Deployment status! •  DNS Root was signed in July 2010! •  TLDs signed [1]: .COM, .NET, .EDU, .ORG, .GOV, etc.:! •  All TLDs: 543 of 726 (74.8%), as of October 2014! •  ccTLDs: 102 of 286 (36%)! •  New gTLDs: all are signed (418 of 418)! •  Reverse trees (in-addr.arpa and ip6.arpa) are signed! •  Levels beneath TLDs are where more needs to be done! •  US .GOV federal: ~ 82% [3](Oct 2014) – FISMA OMB Mandate! •  Internet2 Higher Ed members [1]: 27 of ~ 266 (10.2%)! •  .NL (Netherlands) has over 1.8 million signed delegations [2]! •  .COM has 384,100 signed delegations (0.33%)! 16! [1] http://www.huque.com/app/dnsstat/! [2] https://xs.powerdns.com/dnssec-nl-graph/! [3] http://la51.icann.org/en/schedule/wed-dnssec/presentation-dnssec-deployment-gov-15oct14-en! [4] htttp://statdns.com/ & http://scoreboard.verisign.com/!
  • 17. Verisign Public! Signed zones at Internet2 full members! 17!http://www.huque.com/app/dnsstat/category/internet2/dnssec/!
  • 18. Verisign Public! Use of DNSSEC Validation by resolvers! •  US Gov FISMA IT security policy DNSSEC validation mandate (Spring 2014)! •  Some very large DNS resolver services are doing DNSSEC validation:! •  Google Public DNS (free; very widely used)! •  Comcast DNS [1]: ~ 18.1 million subscriber homes! •  A number of US R&E institutions and NRENs! •  Worldwide there is substantial amount of validation, as measured by APNIC! •  Roughly ¼ of DNS queries by resolvers in the US perform DNSSEC validation! 18! [1] http://la51.icann.org/en/schedule/wed-dnssec/presentation-dnssec-dns-15oct14-en!
  • 19. Verisign Public! DNSSEC Validation map (from APNIC)! 19!gronggrong.rand.apnic.net/cgi-bin/worldmap!
  • 21. Verisign Public! Application uses of DNSSEC! •  One of the more exciting prospects for DNSSEC! •  DNSSEC can be employed to store cryptographic keys in the DNS, and ..! •  Allow applications to securely obtain (authenticate) those keys and use them in application security protocols! •  Some possible applications: SSH, SSL/TLS, HTTPS, S/ MIME, PGP, SMTP, DKIM, and many others ..! •  Existing records:! •  SSHFP, IPSECKEY, DKIM TXT record, …! •  DANE records: TLSA, OPENPGPKEY! •  Upcoming:! •  SMIMEA, IPSECA, …! 21!
  • 22. Verisign Public! SSHFP record! 22! grodd.magpi.net.!86400!IN!SSHFP!(1 1! F60AE0994C0B02545D444F7996088E9EA7359CBA)! • SSH Host Key Fingerprint (RFC 4255)! • Allows you to validate SSH host keys using DNSSEC! algorithm! number! fingerprint ! type (1= SHA1)! fingerprint! In OpenSSH, you can use the client configuration directive “VerifyHostKeyDNS” to use this. Enabled by default in some newer operating systems like FreeBSD 10.!
  • 23. Verisign Public! IPSECKEY record! 23! 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2! 192.0.2.38! AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== )! • RFC 4025: method for storing IPsec keying material in DNS! • rdata format: precedence, gateway-type, algorithm, gateway address, public key! • Not much uptake of this record! • Will likely be superseded by newer proposals, like IPSECA!
  • 24. Verisign Public! TLS and the Internet PKI! •  A very large number of security protocols authenticate server names with SSL/TLS certificates! •  TLS, IPsec, HTTPS, SIPS, SMTP, IMAP, XMPP, …! •  These certificates are issued and signed by the Internet PKI, composed of a set of globally trusted public Certification Authorities (CAs)! ! 24!
  • 25. Verisign Public! Public CA model issues! •  Applications need to trust a large number of global Certification Authorities (CA)! •  No namespace constraints! Any CA can issue certificates for any entity on the Internet! •  Least common denominator security: our collective security is equal to the weakest one!! •  Furthermore, many of them issue subordinate CA certificates to their customers, again with no naming constraints! •  Most CAs aren’t capable of issuing certificates with any but the most basic capabilities (e.g. alternate name forms or other extensions)! 25!
  • 26. Verisign Public! Public CA model issues! •  “Analysis of the HTTPS Certificate Ecosystem”, UMich, October 2013, Internet Measurement Conference! •  http://conferences.sigcomm.org/imc/2013/papers/imc257- durumericAemb.pdf! •  Over 1,800 separate CAs are capable of issuing certificates for anyone! (Root CAs and intermediate CAs issued by them)! •  “The Shape & Size of Threats: Defining a Networked System’s Attack Surface”! •  Eric Osterweil (Verisign), Danny McPherson (Verisign), Lixia Zhang (UCLA), NPsec 2014 conference! ! 26!
  • 27. Verisign Public! Can DNSSEC help?! •  Can we leverage DNSSEC to address these deficiencies?! •  DNS has hierarchical, decentralized administration! •  Certificates and public keys placed in the DNS can be authenticated with DNSSEC signatures! •  Name constraints are inherent! •  Deployed infrastructure is becoming real! •  Root and many of the TLDs are signed, so most organizations can sign their zones and have an intact secure chain of trust to the root! •  Validation is also becoming more prevalent (see prior slides in deployment status)! 27!
  • 28. Verisign Public! DANE and the TLSA record! •  RFC 6698: The DNS-Based Authentication of Named Entities (DANE) Protocol for Transport Layer Security! •  http://tools.ietf.org/html/rfc6698! •  Defines a new DNS record type “TLSA”, that can be used for better & more secure ways to authenticate SSL/TLS certificates! •  By specifying constraints on which CA can vouch for a certificate, or which specific PKIX end-entity certificate is valid! •  By specifying that a service certificate or a CA can be directly authenticated in the DNS itself.! 28!
  • 29. 29! _443._tcp.www.example.com. IN TLSA (! 0 0 1 d2abde240d7cd3ee6b4b28c54df034b9! 7983a1d16e8a410e4561cb106618e971 )! port, transport proto & ! server domain name! TLSA rrtype! certificate association data! usage! selector! matching! type! TLSA record example!
  • 30. Verisign Public! TLSA configuration parameters! 30! Usage field:! 0 PKIX-TA: CA Constraint! 1 PKIX-EE: Service Certificate Constraint! 2 DANE-TA: Trust Anchor Assertion! 3 DANE-EE: Domain Issued Certificate! ! Selector field:! 0 Match full certificate! 1 Match only SubjectPublicKeyInfo! ! Matching type field:! 0 Exact match on selected content! 1 SHA-256 hash of selected content! 2 SHA-512 hash of selected content! ! ! Certificate Association Data: raw cert data in hex!
  • 31. Verisign Public! TLSA configuration parameters! 31! Usage field:! 0 PKIX-TA: CA Constraint! 1 PKIX-EE: Service Certificate Constraint! 2 DANE-TA: Trust Anchor Assertion! 3 DANE-EE: Domain Issued Certificate! ! Selector field:! 0 Match full certificate! 1 Match only SubjectPublicKeyInfo! ! Matching type field:! 0 Exact match on selected content! 1 SHA-256 hash of selected content! 2 SHA-512 hash of selected content! ! ! Certificate Association Data: raw cert data in hex! Co-exists with and ! Strengthens Public ! CA system! Operation without! Public CAs!
  • 32. Verisign Public! Usage types! 32! 0 PKIX-TA: CA Constraint! Specify which CA should be trusted to authenticate the! !certificate for the service. Full PKIX certificate! !chain validation needs to be performed.! ! 1 PKIX-EE: Service Certificate Constraint! !Define which specific service certificate (“EE cert”)! !should be trusted for the service. Full PKIX cert! !validation needs to be performed.! ! 2 DANE-TA: Trust Anchor Assertion! !Specify a domain operated CA which should be trusted! !independently to vouch for the service certificate.! ! 3 DANE-EE: Domain Issued Certificate! !Define a specific service certificate for the service! !at this domain name.!
  • 33. Verisign Public! Example TLSA record (for WWW)! 33! _443._tcp.fedoraproject.org. 263 IN TLSA 0 0 1 (! ! ! ! !19400BE5B7A31FB733917700789D2F0A2471C0C9D506! ! ! ! !C0E504C06C16D7CB17C0 )! ! _443._tcp.fedoraproject.org. 263 IN RRSIG TLSA 5 4 300 (! ! ! ! !20141114150617 20141015150617 7725 fedoraproject.org.! ! ! ! !hrk0si7I/BWTz0wEtMcFZNUCj/0o5796k5FVuZx6eXrc! ! ! ! !YOe/ChHA/Shu/WHr3iM1yNGi86+8t4wMq9GA+JZthWZC! ! ! ! !ZmENxf9OTNe/t/LBAc2EDW/fMBJq0JO2b4ZkJHXCEyX0! ! ! ! !CDsIYz8shZ20nPGlrsYqwLdQiCeravWcwcJiPuc= )! ! ! Usage 0 (“CA Constraint”) – this record says:! -  For service at fedoraproject.org tcp port 443! -  only the CA with the specified SHA-256 certificate fingerprint (19400BE5B…) should be trusted!
  • 35. Verisign Public! DANE/TLSA tools and software! •  TLSA Record Generation! •  Command line tools: “swede”, “hash-slinger”, “ldns-dane”! •  Web based tool: https://www.huque.com/bin/gen_tlsa! •  TLSA validators for web! •  Some 3rd party validator plugins are available (Firefox, Chrome, Opera, Safari):! •  https://www.dnssec-validator.cz/! •  http://blog.huque.com/2014/02/dnssec-dane-tlsa-browser- addons.html! •  Bloodhound Mozilla fork:! •  https://www.dnssec-tools.org/wiki/index.php/Bloodhound! ! 35!
  • 37. Verisign Public! DANE for SMTP! •  DANE in conjunction with SMTP over TLS, or SMTP + STARTTLS can be used to more fully secure email delivery! •  DANE can authenticate the certificate of the SMTP submission server that the user’s mail client (MUA) communicates with! •  DANE can authenticate TLS connections between SMTP servers (“MTA”s or Mail Transfer Agents)! •  This second use case is where DANE solves some important problems that are unaddressed today! 37!
  • 38. Verisign Public! DANE for SMTP! •  Most connections between SMTP servers today use encryption opportunistically (i.e. if both sides support and advertise it, it is used)! •  Even when encryption is used, it is vulnerable to attack:! •  Attackers can strip away the TLS capability advertisement and downgrade the connection to not use TLS! •  TLS connections are often unauthenticated (e.g. the use of self signed certificates as well as mismatched certificates is common)! •  DANE can address both these vulnerabilities! •  Authenticate the certificate using a DNSSEC signed TLSA record! •  Use the presence of the TLSA record as an indicator that encryption must be performed (prevent downgrade)! •  http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane! 38!
  • 39. Verisign Public! Example TLSA record (for SMTP)! 39! _25._tcp.mx1.freebsd.org. 2389 IN TLSA 3 0 1 (! ! ! ! !5EC0508C3F337D18509F41BFF9D8AB07FED588A132FA! ! ! ! !12FA1E223BA6B9403ACB )! ! _25._tcp.mx1.freebsd.org. 2389 IN RRSIG !TLSA 8 5 3600 (! ! ! ! !20141023072418 20141009105807 39939 freebsd.org.! ! ! ! !ll6DEQ7oP2lbEcOeJyPk+I8tYiGz4CzuDiqiMbr4Mzp3! ! ! ! !90UWdej3kdAz4t+1BT0dO3/o0nz0pp3HFsDu+gkwT6YH! ! ! ! !Jg4C6mi3STPciCP1tjbFuW/dv4lPkCUaN7kJt/qwPrR6! ! ! ! !0kQmyvcuUoYgUDPbNYbJNJXai+mFai5WqLS2MEP15ydU! ! ! ! !nt8KympnjHS5mVLVGXW0e7tLY1afQz1VrIeYsGW8YztM! ! ! ! !DYUpCXjWiq+YpCFv7rZ7ICejQR6ot1M35CDsfjk68eu0! ! ! ! !EAjx+HlqaTdGyilcMB+GduFwqkULDPIgiFu/3xb+srJR! ! ! ! !zuR89YpHga9OCnz6nXJgQ6cxvSImZWbKuw== )! ! This is a domain-issued certificate (usage 3), which can be authenticated without a trusted CA.!
  • 40. Verisign Public! Early large adopters of SMTP + DANE! •  posteo.de! •  mailbox.org! •  umbkw.de! •  bund.de! •  denic.de! •  freebsd.org! •  unitybox.de! •  debian.org, debian.net! •  ietf.org! •  nlnetlabs.nl! •  nic.cz! •  nic.ch! •  torproject.org! 40! Quite a few are large email systems in Germany. See a! larger list at https://www.tlsa.info/! !
  • 41. Verisign Public! SMTP servers that support DANE! •  Postfix MTA (works today, version 2.11 onwards)! •  Exim (currently under development)! ! 41!
  • 42. Verisign Public! XMPP servers! •  XMPP (Jabber) has seen some uptake of DANE.! •  To authenticate the c2s and/or s2s portion of the XMPP protocol! •  List of XMPP servers with DANE TLSA records:! •  https://xmpp.net/reports.php#dnssecdane! 42! Example:! ! _xmpp-server._tcp.mail.de. 3600!IN!SRV! 10 20 5269 jabber.mail.de.! ! _5269._tcp.jabber.mail.de. 600 !IN!TLSA !3 1 1 (! A0315F0CF61CAC787140833C2C608550476! 246DDA54122D66BB339D5 0FBB10E3 )! !
  • 43. Verisign Public! OpenPGPKEY! •  OPENPGPKEY record! •  Used to publish an OpenPGP public keys in the DNS! •  DNSSEC signature provides authentication! •  Spec under development, but RR code already assigned! •  http://tools.ietf.org/html/draft-wouters-dane-openpgp-02! ! ! 43!
  • 44. Verisign Public! Example OPENPGPKEY record! 44! For shuque@huque.com! ! 1st label: sha224 hash of “shuque” = ! 4f7c2705c0f139ede60573f8537a0790fb64df5d4a819af951d259bc! ! 2nd label: “_openpgpkey”! ! Remaining labels: domain name portion of the email addr:! Huque.com! ! ! Resulting record looks like this:! ! 4f7c2705c0f139ede60573f8537a0790fb64df5d4a819af951d259bc. _openpgpkey.huque.com.! IN OPENPGPKEY <base64 encoding of the openpgp key>! !
  • 45. Verisign Public! SMIMEA! •  Using DNSSEC to associate certificates with domain names for S/MIME! •  http://tools.ietf.org/html/draft-hoffman-dane-smime! •  S/MIME is a method of encrypting and signing MIME data used in e-mail messages! •  The SMIMEA DNS record proposes to associate S/MIME certificates with DNS domain names! •  Verisign DANE/SMIMEA early Mail User Agent Prototype! •  http://la51.icann.org/en/schedule/wed-dnssec/presentation- dnssec-dane-smime-15oct14-en! 45!
  • 46. Verisign Public! getdns: a brief introduction! A new application friendly interface to the DNS! 46!
  • 47. Verisign Public! Application access to any kind of DNS data! •  Today’s commonly used DNS application interfaces, like getaddrinfo(), getnameinfo() are designed to obtain the most common types of DNS data, e.g. name to IP address mappings, reverse DNS mappings, etc.! •  How do applications ask for other types of data, eg. TLSA, SSHFP records, or even SRV records?! •  How can we tell if a response was successfully authenticated with DNSSEC?! •  Some lower level, harder to use libraries exist (libresolv etc) that can do some of this, but application developers deserve something much better! 47!
  • 48. . (root)! .edu! upenn.edu!www.upenn.edu! referral to .edu! + DS, RRSIG! recursive! resolver! endstation! (uses DNS stub resolver)! 1! 2! 3! 4! 5! 6! 8! 7! referral to upenn.edu! + DS, RRSIG! answer 1.2.3.4! + RRSIG! www.upenn.edu! set DO bit! root’s pubkey! (has root’s pubkey)! edu pubkey! upenn pubkey! Stub to Recursive! Resolver channel! 48! Securing the first hop?!
  • 49. Verisign Public! DNS first hop protection! •  Applications normally query a DNS stub resolver! •  The stub resolver communicates over the network with a recursive resolver. How do we secure that path?! •  Complex solutions exist (but rarely used)! •  e.g. employ a channel security mechanism between the stub and the validating recursive resolver:! •  TSIG, SIG(0), IPsec! •  Run full-service validating resolver on endstation! •  There may be other solutions, like DNScrypt – not standards based, only supported by a few resolvers, not widely used! •  getdns can solve this problem! 49!
  • 50. Verisign Public! getdns: a new DNS library for applications! •  getdns: A new application-friendly interface to the DNS! •  Get and use arbitrary data in the DNS easily! •  Get this data securely, authenticated with DNSSEC if it’s available! •  Full iterative resolver mode with validation! •  Validating stub resolver mode! •  Designed by application developers. Most previous APIs have been developed by DNS protocol people with less concern for the needs of app developers.! 50!
  • 51. Verisign Public! getdns! •  API specification:! •  http://www.vpnc.org/getdns-api/! •  Latest revision: February 2014! •  Creative Commons Attribution 3.0 Unported license! •  An opensource implementation at http://getdnsapi.net/! •  A joint project of Verisign Labs and NLNet Labs! •  First release (0.1.0) in February 2014! •  Latest release (0.1.4) in August 2014! •  C library! •  Bindings in Python, and Node.js (upcoming: go, ruby, perl)! •  BSD 3 License! 51!
  • 52. Verisign Public! getdns features! •  Asynchronous and synchronous modes of operation! •  Sensible defaults suitable for consumption by most users! •  But behavior highly configurable for users with advanced knowledge of the DNS! •  DNS query results are returned in an easy to parse “response dictionary” data structure! •  Members of the data structure can be lists, dictionaries, integers, and binary strings! •  Can return DNSSEC status, and can be instructed to only return DNSSEC authenticated results! 52!
  • 53. Verisign Public! getdns functions! 53! Four main functions defined.! ! getdns_address() Obtain IPv4 and/or IPv6 addresses! ! getdns_hostname() Obtain reverse DNS mappings! ! getdns_service() Obtain SRV record answers! ! getdns_general() General purpose DNS record query! ! Read the API specification for full details:! ! http://www.vpnc.org/getdns-api/! !
  • 54. Verisign Public! getdns response dictionary (partial)! 54! {! "answer_type": GETDNS_NAMETYPE_DNS,! "canonical_name": <bindata of "www.internet2.edu.">,! "just_address_answers”: [! {! "address_data": <bindata for 207.75.164.248>,! "address_type": <bindata of "IPv4">! },! {! "address_data": <bindata for 2001:48a8:68fe::248>,! "address_type": <bindata of "IPv6">! }! ],! "replies_full":! [! <bindata of 0x000081a0000100040000000103777777...>,! <bindata of 0x000081a0000100040005000d03777777...>! ], …!
  • 55. Verisign Public! getdns response dictionary (partial)! 55! "dnssec_status": GETDNS_DNSSEC_SECURE,! ! "replies_tree":! [! {! "additional": [],! "answer":! [! {! "class": GETDNS_RRCLASS_IN,! "name": <bindata for www.internet2.edu.>,! "rdata":! {! "cname": <bindata for webprod2.internet2.edu.>,! "rdata_raw": <bindata for webprod2.internet2.edu.>! },! "ttl": 120,! "type": GETDNS_RRTYPE_CNAME! },! […]!
  • 56. Verisign Public! getdns: example code: hostname lookup! 56! # Example python code to query a domain name and! # return all associated IPv4 and IPv6 addresses.! ! hostname = sys.argv[1]! ! ctx = getdns.Context()! extensions = {"return_both_v4_and_v6”:getdns.GETDNS_EXTENSION_TRUE}! ! results = ctx.address(name=hostname, extensions=extensions)! status = results['status']! ! if status == getdns.GETDNS_RESPSTATUS_GOOD:! for addr in results['just_address_answers']:! print addr['address_data']! else:! print "%s: getdns.address() error: %d" % (hostname, status)! ! ! $ ./program.py www.internet2.edu! 207.75.164.248! 2001:48a8:68fe::248!
  • 57. Verisign Public! getdns: example code: TLSA record lookup! 57! # Example python code to lookup an authenticated TLSA! # record for a domain name, transport, & service port.! ! qname = “_443._tcp.fedoraproject.org”! qtype = getdns.GETDNS_RRTYPE_TLSA! ! ctx = getdns.Context()! extensions = {! "dnssec_return_only_secure”:getdns.GETDNS_EXTENSION_TRUE ! }! ! results = ctx.general(name=qname, request_type=qtype, ! extensions=extensions)! status = results['status']! ! if status == getdns.GETDNS_RESPSTATUS_GOOD:! # here we’d normally parse and do something useful with the! # result data. For now just pretty print the dict.! pprint.pprint(results)! else:! print "%s: getdns.address() error: %d" % (hostname, status)! !
  • 58. Verisign Public! Questions or comments?! Shumon Huque! shuque @ verisign.com! 58!
  • 59. © 2014 VeriSign, Inc. All rights reserved. VERISIGN and other trademarks, service marks, and designs are registered or unregistered trademarks of VeriSign, Inc. and its subsidiaries in the United States and in foreign countries. All other trademarks are property of their respective owners.!