You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 7 Next »

Reports from other days:

Saturday, 18 June 2011 Meetings
Sunday, 19 June 2011 Meetings
Tuesday, 21 June 2011 Meetings
Wednesday, 22 June 2011 Meetings
Thursday, 23 June 2011 Meetings
Friday, 24 June 2011 Meetings

Welcome Ceremony

Time: 09:00 - 10:30
Location: Canning/Padang
Author:

Please add your report here

ccNSO Tech Day

Time: 09:00 - 16:00
Location: Olivia
Author:

Please add your report here

Board Session - New gTLD Program

Time: 11:00 - 12:30
Location: Canning/Padang
Author:

Please add your report here

Joint ccNSO/GNSO Council Meeting

Time: 12:30 - 14:00
Location: Sophia
Author:

Please add your report here

Forum on DNS Abuse

Time: 13:00 - 14:30
Location: Canning/Padang
Author:

Please add your report here

FY12 Draft Operating Plan and Budget

Time: 13:30 - 14:30
Location: Orchard A/B
Author:

Please add your report here

New gTLD Update

Time: 14:30 - 16:00
Location: Canning/Padang
Author:

Please add your report here

GAC Meeting with SSAC

Time: 15:00 - 16:00
Location: Collyer
Author:

Please add your report here

DNSSEC for Everybody - A Beginners Guide

Time: 16:00 - 17:30
Location: Olivia
Author:  Darlene Thompson

DNSSEC for Everybody:  A Beginners Guide

DNSSEC continues to be deployed around the world at an ever accelerating pace. From the Root, to both Generic Top Level Domains (gTLDs) and Country Code Top Level Domains (ccTLDs), the push is on to deploy DNSSEC to every corner of the internet. Businesses and ISPs are building their deployment plans too and interesting opportunities are opening up for all as the rollout continues.

In the beginning of this presentation, DNSSEC was cleverly illustrated through simple cartoons of cavemen.  Later, a series of (low budget but hilarious) scits were put on to illustrate DNSSEC and how and how it prevents malicious attacks.  This session really made DNSSEC easily understood.  Points that were raised:

DNS Security
• DNS has no security
• One packet for query, one packet for response
• Must rely on source IP‐based authentication
• Easily spoofed
• Clever resolvers help a lot
• But we need something better

What DNSSEC Does
• DNSSEC uses public key cryptography and digital signatures to provide:

  • Data origin authentication
    • “Did this DNS response really come from the .com zone?”
  • Data integrity
    • “Did an attacker (e.g., a man-in-the-middle) modify the data in this response since it was signed?”
    • Bottom line: DNSSEC offers protection against spoofing of DNS data

    What DNSSEC Doesn’t Do
    • DNSSEC does not:
  • Provide any confidentiality for DNS data
    • I.e., no encryption
    • The data in the DNS is public, after all
  • Address attacks against the name server itself
    • Denial of service,
    • Packets of death,
    • etc.

    Key Pairs
    • In DNSSEC, each zone has a public/private key pair
    • The zone’s public key is stored in the new DNSKEY record
    • The zone’s private key is kept safe
  • Stored offline (ideally)
  • Perhaps held in an HSM (Hardware Security Module)

    Digital Signatures
    • A zone’s private key signs each piece of DNS data in a zone
    • Each digital signature is stored in an RRSIG record

    Chain of Trust
    • There are no certificates in DNSSEC
    • The trust model is rigid
    • The chain of trust flows from parent zone to child zone
    • Only a zone’s parent can vouch for its keys’ identity

    Types of Keys
    • Signed zone has DNSKEY records at its apex* Usually multiple keys* One or more key-signing keys (KSKs)
  • One or more zone-signing keys (ZSKs)• KSK
  • Signs only the DNSKEY records• ZSK
  • Signs the rest of the zone

    Delegation Signer (DS) Records
    • The Delegation Signer (DS) record specifies a child zone’s key
    • A zone’s DS records only appear in its parent zone
    • DS records are signed by the parent zone

    Trust Anchors
    • You have to trust somebody
    • DNSSEC validators need a list of trust anchors
    • A trust anchor is a key that is implicitly trusted
    • Analogous to list of certificate authorities (CAs) in web browsers

    DNSSEC Implementation Samples
    • DNSSEC implementation depends upon & is mostly driven by an activity’s DNS
    functions
  • DNS is made up of many parts, e.g., name server operators, applications users, name holders (“owners”), DNS provisioning
  • Activities with large, complex DNS functions are more likely to have more complex DNSSEC implementation activities• Also more likely to have ‘DNS knowledgeable’ staff
    • DNS size and complexity examples:
  • Registry responsible for a large TLD operation, e.g., .com
  • Substantial enterprise with many components with many geographic locations, e.g., hp.com
  • Internet-based businesses with a number of business critical zones, e.g., www.verisign.com
  • Activities with non-critical DNS zones, e.g., net-snmp.org
  • Proverbial Internet end users (all of us here)

    General Principle:
    • If an activity does a lot with their DNS functions and operations then they probably will want to do a lot with the associated DNSSEC pieces;
    • If an activity does little or nothing with their DNS functions and operations then they probably will want to do little or nothing with the associated DNSSEC pieces.

    DNS Basic Functions
    • DNS provides the translation from names to network addresses
    • Get the right DNS content to Internet users
    -->IT’S DNS CONTENT THAT MATTERS!

    How Does DNSSEC Fit?
    • DNSSEC is required to thwart attacks on DNS CONTENT
    • DNS attacks used to attack Internet users applications
      -->Protect DNS CONTENT as much as (or more than) any DNSSEC information
      -->Including DNSSEC private keys!!

IDN Varaint TLD

Time: 16:00 - 17:30
Location: Canning/Padang
Author:

Please add your report here

Joint ccNSO/GNSO IDN Working Group (JIG)

Time: 17:30 - 18:30
Location: Moor
Author:

Please add your report here

  • No labels