Your SlideShare is downloading. ×
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.


Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply



Published on

Published in: Technology

  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Secure Naming Infrastructure Pilot (SNIP) A .gov Community Pilot for DNSSEC Deployment JointTechs Workshop July 18, 2007 Scott Rose NIST [email_address]
  • 2. SNIP Goals
    • DNSSEC is now a FISMA Requirement.
      • NIST SP-800-53-r1 (Dec 2006) “ Recommended Security Controls for Federal Information Systems ” mandates the incremental deployment of DNSSEC technologies in Moderate and High Impact IT systems.
        • Moderate Impact – must sign zones.
        • High Impact – must be prepared to validate signatures.
    • Need to facilitate technology insertion and adoption.
      • Standards, implementations and policies don’t guarantee success.
      • Need for technical community resources and activities to foster early deployments, refine policies and plans, share information and expertise.
  • 3. SNIP Basics
    • SNIP will build a USG DNS Ops community and shared pilot
      • Provide “distributed training ground” for .gov operators deploying DNSSEC
      • Ability to pilot agency specific scenarios either locally or in SNIP-provided resources.
      • Create a community resource for DNS admins in the USG to share knowledge and to refine specifications, policies and plans.
    • SNIP basis is a signed shadow zone under .gov (
      • Will offer delegations and secure chaining to subzones
        • example – NIST would participate as
      • May offer limited hosting service as well
        • Goal isn't to be a hosting service, but help bootstrap others to host their own zones.
  • 4. SNIP as a Testbed
    • Use SNIP tree to exercise DNSSEC operations
      • Test deployment DNSSEC scenarios.
        • Multi-vendor platforms for authoritative / caching servers, resolvers.
        • Zone structure / contents / distribution.
      • Test DNSSEC operations described in SP800-81
        • Zone signing, key rollovers, zone transfers.
      • Test DNSSEC administration tools (From NIST, Sparta and Shinkuro)
      • Test performance – in agency specific scenarios.
    • Community hands-on participation
      • Agency DNS operators can participate in NIST/SPARTA led exercise.
      • Results will be published for community
  • 5. What SNIP is Not
    • Mandatory
    • Permanent
      • Expected lifetime: 2-3 years
      • The community tools and email lists will remain after the testbed activities conclude..
    • 100% Uptime
      • This is a experimental testbed in which we will conduct disruptive experiments, load/stress test servers, etc.
  • 6. Levels of Participation
    • Delegation only
      • Participants use own testbed systems and perform all administration associated with setup / experimentation.
    • Remote administration
      • Participants use SNIP testbed equipment, but perform all administration.
    • Hosted experiments
      • NIST/SPARTA set up mirror of agency specific infrastructure, but using SNIP equipment and administration, for specific experiment.
      • For limited use in investigating specific deployment / technology issues.
  • 7. The Big Picture – DNSSEC in .gov Internet2 DNSSEC Pilot zoneedit SNIP Core Infrastructure DREN DNSSEC Pilot
  • 8. Testbed Technical Details
    • Multiple authoritative server implementations
    • Internet2 connection (IPv6 testing)
    • May have alternate hosting capabilities (multiple servers)
      • secondaries in other locations?
    • Ability to host other zones (or servers) for delegations lacking equipment to participate fully.
      • Zone data can be real (servers), or anonymized
    • Will maintain and publish trust anchor for tree
  • 9. SNIP Infrastructure Resources
    • Primary Site – NIST / Gaithersburg MD.
      • Authoritative DNS servers
    • Secondary Site – Sparta / Columbia MD
      • Geographic and network dispersion (sort of)
      • Zone transfers using TSIG for message authentication
    • Reconfigurable Emulated wide area topology.
      • 20+ node Emulab being deployed at NIST.
  • 10. Additional NIST Resources
    • Other SNIP infrastructure
      • Web server and mail host for mailing lists
      • Test and measurement systems
    • Signing Infrastructure – apex.
      • Done behind firewall
      • Private keys not stored on servers
      • Scheduled resigning done every month
        • Also after updates as necessary
  • 11. Emulab Network Signing system SNIP Secondary Auth Server Internet /UUNet SNIP Topology NIST Network Internet2 /MAX Test and Measurement Systems SNIP Primary Auth Server
  • 12. SNIP Operational Overview
    • Will use procedures outlined in SP800-81
      • 1024 bit RSA ZSK
        • Rolled over every month
      • 2048 bit RSA KSK
        • Rolled over during experimentation
        • published as pilot trust anchor
    • ZSK rollover every 30 days
      • KSK on a less formal basis (experiment in trust anchor rollover)
    • Using NSEC initially, may experiment signing with NSEC3
  • 13. DNS Administrator Resources
    • Will remain active after SNIP zone shuts down
    • Project Website
      • Links to guides, tools, and performance stats
    • Mailing list
      • Useful for announcements and security bulletins
    • Revision of NIST SP800-81
      • using knowledge gained during SNIP operational lifetime
      • More examples of different server implementations
      • Information on how to interact with parent zones (GSA)
  • 14. SNIP Impact
    • Stepping stone for operational use
      • USG DNS operators get experience running delegation under before deploying in own agency
    • Tool testing
      • Tech transfer / training on existing tool suites (NIST, SPARTA, Shinkuro, ISC, et al).
    • Platform Testing
      • Multi-vendor environment
        • Servers - ISC/BIND, NSD, Microsoft, Nominum(?) and more surprises
        • Resolvers – Linux, BSD, Microsoft, OS X
        • Applications – TBD.
    • Procedure Testing
      • Refinement of procedure/policy guidance and reporting requirements
  • 15. Participation
    • Will try to accommodate all
      • Non USG entities:
        • May try to get a presence in other TLD’s a well
      • Don’t want a delegation?
        • How about a DNAME?
      • Tool developers
        • Can run locally or have delegation/secondary/etc as necessary.
  • 16. Resources
    • NIST Special Publications page
    • DNSSEC Project Page
    • DNSSEC-Deployment Web page
      • Informal working group