You Need More Than Just SSL: Locking Down Interop With DNSSEC
Upcoming SlideShare
Loading in...5
×
 

You Need More Than Just SSL: Locking Down Interop With DNSSEC

on

  • 1,695 views

This presentation from Interop 2011 in Las Vegas is a high and low-level discussion on how Dyn providing DNSSEC to Interop, why DNSSEC is as important (if not more) than HTTPS and the technical ...

This presentation from Interop 2011 in Las Vegas is a high and low-level discussion on how Dyn providing DNSSEC to Interop, why DNSSEC is as important (if not more) than HTTPS and the technical details of DNSSEC as done by Dyn, aka the DNS experts.

To see the video version as a companion, enjoy Kevin Gray's chat here: http://www.youtube.com/watch?v=R1i2Z_8ENRQ&hd=1

Statistics

Views

Total Views
1,695
Views on SlideShare
1,695
Embed Views
0

Actions

Likes
0
Downloads
9
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

You Need More Than Just SSL: Locking Down Interop With DNSSEC You Need More Than Just SSL: Locking Down Interop With DNSSEC Presentation Transcript

  • The need for more than just SSL, locking down Interop with DNSSEC
  • Who is Dyn? The DNS and Email Experts Powering the biggest and fastest growing brands on the Internet Providing DNS to InteropNET with our Enterprise Managed DNS service: Dynect Platform
  • First there was unsecured http....
  • To verify the correct domain name, https....
  • Add in DNSSEC to secure the entire lookup.
  • Quick reminder about the basics of DNS...
    • DNS maps names to numbers. You and I understand www.local.mybank.com but your computer only knows how to get to IP addresses. DNS bridges the two.
    • 2 Types of DNS servers
      • Authoritative – Answers specific DNS queries: ie: What is the A record for www.local.mybank.com
      • Recursive – Query Authoritative servers for DNS information and store it (Cache it) for a period of time
    • DNS recursion is the process of a recursive server iteratively asking authoritative servers questions until it finds out a definitive answer.
  • DNS Recursion – Query the recursive server
  • DNS Recursion – Recursive server queries root...
  • DNS Recursion – Recursive server queries com
  • DNS Recursion – Recursive server queries mybank.com
  • DNS Recursion – Recursive server queries local.mybank.com
  • DNS Recursion – Recursive server responds to original request
  • I'm doing my online banking, I see the https lock is green but you're saying I'm not safe!?
    • Only Partly!
      • As we saw the name of the site you are going to is trusted
      • The ip address you are being brought to is at the mercy of DNS
        • Think about what would happen if someone changed your /etc/hosts file to point www.local.mybank.com to a fake site.... would your computer know?
        • This is basically what DNS cache poisoning or DNS man in the middle attacks are but on a larger scale
  • What types of security breaches occur at the DNS level?
    • Man in the middle attack
      • Malicious machine intercepts every packet going from one machine to another
      • When returning information changes DNS records to point to bad site
    • DNS cache poisoning Attack
      • Malicious machine continuously re-sends response for a site to the recursive DNS server
      • When recursive server eventually asks for the information the first reply that it sees is from the malicious machine
  • DNS Cache Poisoning
  • You would be securely connected... but to the wrong computer!
  • Need a way to do SSL like verification in DNS... Enter DNSSEC!
    • DNSSEC is a way for the recursive server to validate each of the replies it gets to make sure the correct response is given.
  • DNSSEC Secured
  • Interop and DNS … and DNSSEC
    • First the DNS layout
    • Providing both Authoritative and Recursive DNS to interop
  • The starting point...
  • Cisco providing DHCP service through their CNR
  • CNR pushes updates to Dynect show floor hidden master
  • It's good to have redundancy plus redundancy is good to have
  • Sign the update and propagate it to Dynect
  • Need to handle DNS requests too!
  • Handle it by show floor anycast recursive servers.... and here is the complete DNS picture
  • So the authoritative zones are signed, how do you actually sign a zone...
    • The BIND way (for each and every zone...)
      • Generate the keys using dnssec-keygen twice, once for the ZSK and once for the KSK
      • Store the private keys someplace safe (since anyone with the private keys can sign as you)
      • Include the correct keys in the zone file
      • Actually sign the zone using dnssec-signzone
    • The Dynect way...
  • Click “Add DNSSEC”!
  • Just one more step...
    • After the zone is signed, just publish the DS record to your registrar and you are trusted!
    • This isn't always the fastest thing. At the moment we are waiting for the interop.net registrar to update their DS record – being a newer technology this sometimes takes a while, particularly if it isn't something the registrar does all the time
  • DNSSEC tools
    • Being the DNS Experts we aren't going to leave you hanging in regards to a DNSSEC tool!
      • DNSCog: http://www.dnscog.com/ - Lets you verify the DNSSEC chain
      • Notice that interop.net is signed up to the registrar
  • Some other cool DNSSEC related stuff to check out
    • This is a site with a purposely broken DNSSEC chain that can be used to check untrusted handling: http://www.dnssec-failed.org/
    • FireFox DNSSEC plugin: http://www.dnssec-validator.cz/ - Adds a simple graphical interface for sites to let you know their DNSSEC status
    • Tools/patches for adding DNSSEC awareness into some common applications like postfix and sendmail: https://www.dnssec-tools.org/wiki/index.php/DNSSEC_Applications
    • A one stop shop for all your DNSSEC needs: http://www.dnssec.net/
  • Booth #715 in Cloud and Virtualization Zone Get a free Dynect Platform trial and get started with DNSSEC Dyn On the web: http://dyn.com/ Twitter: @DynInc Kevin Gray Tech Integrator Email: kgray@dyn.com Twitter: @tuftsmoose Interested in hearing the DNSSEC details... keep going!
  • How does DNSSEC work?
    • Implemented as a pair (2) of public key/private key pairs
      • A zone signing key pair (ZSK) used to sign every record type except for DNSKEY records
      • A key signing key pair (KSK) used to sign DNSKEY records
    • A zone uses it's ZSK private key to sign each of it's record sets, the signature is stored in an RRSIG record type which is a DNSSEC specific DNS record type
    • A zone stores the public ZSK in a DNSKEY record which is another DNSSEC specific DNS record type, this record is then signed with the private KSK
    • The zone administrator then sends a DS record to the parent zone owner. The DS record is the public KSK. This DS record exists only on the parent zone and is signed by the parent zone to verify it's validity.
    • Now to validate a zone one takes the validated DS record from the parent zone to get the zone's public KSK, uses this KSK to validate the DNSKEY record of the zone then uses the public ZSK stored in the validated DNSKEY record to validate every other record set in the zone.
  • The DNSSEC Chain of Trust
    • In the manner just described each validated parent is able to give the validated public KSK for it's signed children. This linking is called the DNSSEC Chain of Trust
    • Basics of the Chain (where is www.local.mybank.com?):
      • root KSK validates root DNSKEY with ZSK -> ZSK validates .com DS record which contains .com KSK
      • .com KSK validates .com DNSKEY with ZSK -> ZSK validates mybank.com DS record which contains mybank.com KSK
      • mybank.com KSK validates mybank.com DNSKEY with ZSK -> ZSK validates local.mybank.com DS record which contains local.mybank.com KSK
      • local.mybank.com KSK validates local.mybank.com DNSKEY with ZSK -> ZSK validates www.local.mybank.com A record
  • Wait! What about root?
    • Need a trust starting point just like you need a DNS look up starting point
    • Validators maintain list of KSKs for trusted zones. These are updated either by hand, through some secure method or through Automated Updates of DNSSEC Trust Anchors (RFC 5011)
    • RFC 5011, in a nutshell is using current trust anchors to validate new ones. Software implementing this is just starting to gain traction but many lists are still maintain using other methods.
    • As of July 2010 root is signed (Yeah!)
  • What if a domain doesn't exist?
    • NXDOMAIN is returned, how do you sign it?
      • NSEC records fill this void
      • NSEC is a signed negative response. It spans a gap between two consecutive existing zones and includes the types of records the first of of the zones has
      • In this way the NXDOMAIN or NOERROR with no records can be signed too
      • Consecutive zones... so there is an order? Yes!
        • Domain names in a zone are sorted rightmost label then the next label to the left and so on. Sorting is done case insensitive in dictionary order.
        • Order local.mybank.com, mybank.com, mybank.net, local.mybank.net, national.mybank.net and national.mybank.com:
          • mybank.com
          • national.mybank.com
          • local.mybank.com
          • mybank.net
          • national.mybank.net
          • local.mybank.net
  • Yes, there is another option to NSEC...
    • More recently NSEC3 records have begun being used instead of NSEC
      • NSEC3 is a signed record with a hash of the name
      • Intent is to thwart automatic walking of all the names in a zone in an attack attempt.
      • RFC 5155
  • If this is still relatively new, what happens if someone in my chain isn’t signed?
    • A good number of zones are still unsigned and don't support DNSSEC, if one of those is above you in the trust chain you need to follow a slightly different method to DNSSEC secure yourself
    • To get a pseudo trust chain you can use DNSSEC Lookaside Validation (DLV)
      • DLV essentially uses a DLV service like the ISC (Internet Systems Consortium) as the trusted source for your DS records thus allowing the security aware resolver to “look aside” to the ISC server for the DS verification of the next step in the trust chain.
      • This requires you to trust the DLV service ahead of time and then upload your DS record for a signed zone to the DLV service
  • Since everyone in the world isn't using this there must be a reason or two...
    • It is still relatively new and takes a while to propagate
    • Root was just recently signed... It took a while politically, think about it, the trusted root signature is done by organizations strongly tied to the US and believe it or not the US isn't the favorite country of some nations.
    • It is more work to maintain -> need to roll over the KSK roughly every 30 days and the ZSK about once a year which requires generating and storing the keys, resigning the zones then propagating the new DS records.
    • Many people think HTTPS is good enough.
    • Many end user tools don't have native support for DNSSEC checking. For example, no browser monitors it natively and a search revealed only FireFox has a free production level plugin supporting it.
    • Truthfully, DNSSEC isn't the most intuitive to setup/maintain which makes the barrier to entry on setting it up not worth it to many (which Dyn is trying to fix!)