Welcome to the DNS for LIRs RIPE NCC Training Course

1
Welcome to theDNS for LIRsRIPE NCC Training
Course
2
Course Outline

• Securing Host-to-Host Communication
• DNSSEC
• New RRs
• Signing a zone
• Building chains of trust
• Key rollovers
• Operational Concerns
• RIPE NCCs DNSSEC Set-up

• Introduction
• RIPE and RIPE NCC
• DNSMON
• K-root
• Hostcount
• RIPE Whois Database
• Reverse Delegations
• DNS Vulnerabilities

3
Who Are We?

• Trainers
• Know about RIPE NCC procedures
• Know about DNSSEC
• Not DNS server operators!
• We expect you to know about DNS.
• Please fill in your expectations in the
  questionnaire.

4
RIPE and RIPE NCC
5
RIPE and RIPE NCC

• Réseaux IP Européens (1989)
• Collaborative operators community for
  coordinating IP infrastructure development
• Open to all
• Developing policies input to the RIPE NCC
• RIPE Network Coordination Centre (1992)
• Independent not-for-profit membership
  organisation
• One of five Regional Internet Registries (RIRs)

6
RIR Service Regions
7
How RIPE Works

• Open forum
• Voluntary participation
• Decisions by consensus
• Working groups
• Not a legal entity
• Does not develop Internet standards
• RIPE chair chair_at_ripe.net
• ripe-list_at_ripe.net

8
Bottom-up Process
9
Policy Development Process

• Proposal (from anyone)
• Discussion in RIPE Working Group (WG)
• Review by WG
• Consensus? Chair announces decision
• Concluding phase
• Last call for comments

10
Your Participation is Needed!

• What can you do?
• Propose new policy
• we can help draft it
• Comment on other proposals
• Check the drafts and recent changes web page
• How to take part?
• Subscribe to mailing lists
• Come to the meetings
• or watch webcast and use Jabber / irc

11
Internet Registry System Goals
12
Hierarchical Distribution
13
RIPE NCC Services

• Public Services
• RIPE Whois Database
• Routing Registry
• RIPE support
• Spreading information
• ENUM (e164.arpa)
• K-root name server
• Test Traffic Measurements
• DNSMON
• E-learning

• Member Services
• IP resources
• IPv4
• IPv6
• AS Numbers
• Reverse DNS delegation
• Training courses
• LIR
• Routing Registry Tools
• DNS for LIRs

14
(No Transcript)
15
K-root

• One of 13 DNS root servers
• Operated by the RIPE NCC
• Runs NSD
• IPv4 anycasted
• 11 local nodes
• 5 global nodes
• http//k.root-servers.org/

16
K-root AS25152 Peering Policy

• We advertise only our own routes in AS25152
• We will update our aut-num object in the RIPE
  Whois Db
• We secure peerings with passwords
• We will not to enter into a formal peering
  contract
• We accept any routes offered including transit
• Only at our global mirror instances
• Aut-num object AS25152 has
• the authoritative list of locations at which
  AS25152 peers
• which of those locations is considered global or
  local
• k-peerings_at_ripe.net for more information

17
DNSMON

• Quality of service of DNS servers
• Currently TLD and root servers
• Uses Test Traffic probes
• Detailed information publicly available
• http//dnsmon.ripe.net/

18
Hostcount

• Data collected from TLDs in the RIPE region
• Every month
• First hostcount was in October 1990
• Involved 19 TLDs
• Now the hostcount includes around 100 TLDs
• Hostcount is provided as an informational service
• Currently undergoing overhaul
• http//www.ripe.net/info/stats/hostcount/

19
Summary

• The RIPE NCC is not RIPE
• Subscribe to Policy Announce mailing list
• Services E-Learning, K-root, DNSMON, hostcount

Questions?
20
RIPE Whois Database
21
RIPE Whois Database

• Public Network Management Database
• All LIRs must have
• person object
• maintainer (mntner) object
• organisation object
• role object is convenient

22
DB Object Syntax
Attribute name
Attribute value
Comment (after )
person John Smith address Singel
258 Amsterdam phone [phone]
9-17 CET nic-hdl JS1-RIPE changed
john_at_example.net 20030306 source RIPE
Continuation (line starts with white character)
23
Querying Whois DB

• Object types
• Resource info
• Contact info
• Protection
• Command-line client
• Web interface
• https//www.ripe.net/whois
• Glimpse full text search
• http//www.ripe.net/db/whois-free.html

24
Updating Objects

• Updating creating, modifying, deleting
• Web, sync, e-mail
• Mind the primary key!
• Use new for creating objects
• Add changed line
• Ack, error and warning messages returned

25
Protection of DB Objects

• mnt-by attribute refers to mntner object
• Checked at every update
• Password
• CRYPT-PW, MD5-PW,
• https//www.ripe.net/cgi-bin/cgicrypt.pl.cgi
• Private key/Public key
• PGPKEY-ltidgt key-cert object
• X.509-ltidgt key-cert object
• Multiple auth / mnt-by / mntner-s are OR-ed

26
Multiple Protection Illustrated
aut-num AS3003 mnt-by ONE-MNT mnt-by TWO-MNT
mntner TWO-MNT
mntner ONE-MNT
auth MD5-PW bla34bla.
auth CRYPT-PW bla34
auth PGPKEY-AE6FBBF7

• In order to update the object AS3003, need to
  have
• Either the (crypt) password
• Or the MD5 password
• Or the PGP key
• If you forget pwd write to ripe-dbm_at_ripe.net

27
Hierarchical Authorisation
inetnum 10.0.0.0 - 10.255.255.255 mnt-lower
MNT1 mnt-by MNT2
inetnum 10.10.0.0 - 10.10.255.255 mnt-by MNT3
inetnum 10.0.0.0 10.255.255.255 mnt-by
MNT1 mnt-by MNT4 mnt-domains MNT3
28
TEST Database

• Playground Database source TEST
• whois h test-whois.ripe.net
• mailto test-dbm_at_ripe.net
• http//www.ripe.net/db/syncupdates/syncupdate-test
  -minimal.html
• http//www.ripe.net/webupdates-test
• Differences from RIPE Database
• Can create ASN objects automatically
• Does not contain same info as operational RIPE
  Database

29
Summary

• RIPE Database
• Maintainers
• Hierarchical authorisation

Questions?
30
Reverse Delegations
31
Why Reverse DNS?

• Mapping IP numbers to domain names
• Needed for applications (mail, IRC, ftp)
• troubleshooting (traceroute)
• LIRs responsibility

32
inet(6)num and Domain Objects
inet6num 20010888/32 status
ALLOCATED-BY-RIR mnt-by RIPE-NCC-HM-MNT mnt-domai
ns LIR-MNT
domain 8.8.8.0.1.0.0.2.ip6.arpa mnt-by LIR-MNT
inetnum 81.3.10.0/24 status ASSIGNED PA mnt-by
LIR-MNT mnt-domains END-USER-MNT
domain 10.3.81.in-addr.arpa mnt-by END-USER-MNT
33
Preparations

• Decide on the address range
• Whole allocation? Assignment?
• IPv4 One or more /24, /16
• IPv6 One or more /36, /32
• Decide who will be responsible
• LIR?
• End User? (create mntner)
• Allow hierarchical authorisation
• add appropriate mntner in the mnt-domains of
  the inetnum object

34
Sizes Other Than /24

• Multiple /24 delegations
• can be requested as one domain object
• use shorthand notation for consecutive zones
• broken and registered as multiple objects
  
• Smaller than /24 delegation
• End User can run own primary name server
• LIR requests delegation for whole /24
• LIR uses CNAME (RFC 2317)

35
Setup and Request

• Configure DNS server for chosen zones
• ns.ripe.net mandatory for IPv4 /16
• To request delegation
• submit domain object to Whois Database
• Delegation checker starts checks
• Uses points system

36
Delegation Checker Points System

• DNS issues awarded points
• 20 points or more Error
• Delegation not accepted
• Some issues awarded 20 points
• Unreachable servers, etc.
• Some issues awarded 0 points
• May be misconfigurations, may be conscious
  choices
• Full list of issues
• http//www.ripe.net/rs/reverse/delcheck/delcheck_d
  escr.html

37
Delegation Checker Issues (score 2)

• Could not lookup MX records
• PROBLEM_MAILCHECK_MX_LOOKUP
• Could not lookup A records for MTA
• PROBLEM_MAILCHECK_A_LOOKUP
• A reverse domain found in the RNAME field
• PROBLEM_REVERSE_DOMAIN_IN_RNAME

38
Delegation Checker Issues (scores 45)

• TTL on NS set is too short
• PROBLEM_NS_TTL_TOO_SHORT
• DS records points to a DNSKEY without SEP flag
• PROBLEM_DS_POINTING_TO_NON_SEP_DNSKEY
• TTLs for the NS RRs in the NS RR set not equal
• PROBLEM_RRSET_TTLS_NOT_EQUAL

39
Delegation Checker Issues (scores 710)

• SOA expire parameter is too small
• PROBLEM_EXPIRE_LESS_THAN_REFRESH_RETRY_SUM
• Duplicated name in the SOA e-mail field
• PROBLEM_RNAME_DUPLICATE_ZONE
• SOA serial numbers differ between servers
• PROBLEM_SERIAL_NUMBERS_DIFFER

40
Other Checks

• Whois database syntax
• Authentication
• mnt-domains in corresponding inetnum
• and
• mnt-by in domain
• Errors / warnings ask ripe-dbm_at_ripe.net
• Success RIPE NCC updates parent zone

41
Summary

• Set-up servers
• Domain object is delegation request
• Zone delegation checker

Questions?
42
DNS Vulnerabilities
43
DNS Data Flow
Master
Caching forwarder
Dynamic updates
Resolver
44
DNS Vulnerabilities
Corrupting data
Impersonating master
Cache impersonation
Master
Caching forwarder
Dynamic updates
Resolver
Cache pollution by data spoofing
Unauthorised updates
Altered zone data
Server protection
Data protection
45
DNS Exploit Example

• Mail gets delivered to the MTA listed in the MX
  RR
• Man in the middle attack

Blackhat
MX RR
Resolver
MX RR
MX RR
Sending MTA
Receiving MTA
46
Other Possible DNS Targets

• SPF, DomainKey and family
• Technologies that use the DNS to mitigate spam
  and phishing value for the black hats
• StockTickers, RSS feeds
• Usually no source authentication but supplying
  false stock information through a stockticker and
  a news feed can have value
• ENUM
• Mapping telephone numbers to services in the DNS
• As soon as there is some incentive

47
Mitigate by Deploying SSL?

• Claim SSL is not the magic bullet
• (Neither is DNSSEC)
• Problem Users are offered a choice
• Far too often
• Users are annoyed
• Implementation and use make SSL vulnerable
• Not the technology

48
Confused?
49
Where Does DNSSEC Come In?

• DNSSEC secures the name to address mapping
• Before the certificates are needed
• DNSSEC provides an independent trust path
• The person administering https is most probably
  a different from person from the one that does
  DNSSEC
• The chains of trust are most probably different
• See acmqueue.org article Is Hierarchical
  Public-Key Certification the Next Target for
  Hackers?

50
DNSSEC Provides

• Data Origin Authentication
• Data Integrity
• Authenticating Name and Type Non-Existence
• DNSSEC
• Is not designed to provide confidentiality
• Provides no protection against denial of service
  attacks

51
DNSSEC Components

• TSIG/SIG(0) provides mechanisms to authenticate
  communication between machines
• DNSKEY/RRSIG/NSEC provides mechanisms to
  establish authenticity and integrity of data
• DS provides a mechanism to delegate trust to
  public keys of third parties
• A secure DNS will be used as an infrastructure
  with public keys
• However it is NOT a PKI

52
Summary

• DNS introduction
• DNS vulnerabilities
• SSL not the complete answer

Questions?
53
Securing Host-Host Communication
54
TSIG Protected Vulnerabilities
Impersonating master
Zone administrator
Zone file
Master
Caching forwarder
Dynamic updates
Slaves
Resolver
Unauthorised updates
55
Transaction Signature TSIG

• TSIG (RFC 2845)
• Authorising dynamic updates and zone transfers
• Authentication of caching forwarders
• Independent from other features of DNSSEC
• One-way hash function
• DNS question or answer and timestamp
• Traffic signed with shared secret key
• Used in configuration, NOT in zone file

56
TSIG Example
Query AXFR
Master
Slave
KEYsgs!f23f
KEYsgs!f23f
Response Zone
57
TSIG for Zone Transfers

• Generate secret
• Communicate secret
• Configure servers
• Test

58
Importance of the Time Stamp

• TSIG/SIG(0) signs a complete DNS request /
  response with time stamp
• To prevent replay attacks
• Currently hardcoded at five minutes
• Operational problems when comparing times
• Make sure your local time zone is properly
  defined
• date -u will give UTC time, easy to compare
  between the two systems
• Use NTP synchronisation!

59
Authenticating Servers Using SIG(0)

• Alternatively, it is possible to use SIG(0)
• Not yet widely used
• Works well in dynamic update environment
• Public key algorithm
• Authentication against a public key published in
  the DNS
• SIG(0) specified in RFC 2931

60
Summary

• TSIG/Sig(0)
• Generate secret
• Configure servers

Questions?
61
DNSSEC Mechanisms

• New Resource Records
• Setting Up a Secure Zone
• Delegating Signing Authority
• Key Rollovers

62
DNSSEC Protected Vulnerabilities
Cache impersonation
Zone administrator
Zone file
Master
Caching forwarder
Dynamic updates
Slaves
Resolver
Cache pollution by data spoofing
Altered zone data
63
DNSSEC hypersummary

• Data authenticity and integrity by signing the
  Resource Records Sets with private key
• Public DNSKEYs used to verify the RRSIGs
• Children sign their zones with their private key
• Authenticity of that key established by
  signature/checksum by the parent (DS)
• Ideal case one public DNSKEY distributed

64
The DNS is Not a PKI

• All key procedures are based on local policy
• A PKI is as strong as its weakest link
• Certificate Authorities control this through SLAs
• The DNS does not have Certificate Revocation
  Lists
• If the domain is under one administrative control
  you might be able to enforce policy

65
Public Key Crypto

• Key pair a private (secret) key and a
  corresponding public key
• Simplified
• If you know the public key, you can verify a
  signature created with the private key
• If you know the public key, you can encrypt data
  that can only be decrypted with the private key
• DNSSEC only uses signatures
• PGP uses both methods

66
Security Status of Data (RFC4035)

• Secure
• Resolver is able to build a chain of signed
  DNSKEY and DS RRs from a trusted security anchor
  to the RRset
• Insecure
• Resolver knows that it has no chain of signed
  DNSKEY and DS RRs from any trusted starting point
  to the RRset
• Bogus
• Resolver believes that it ought to be able to
  establish a chain of trust but for which it is
  unable to do so
• May indicate an attack but may also indicate a
  configuration error or some form of data
  corruption
• Indeterminate
• Resolver is not able to determine whether the
  RRset should be signed

67
New Resource Records
68
RRs and RRSets

• Resource Record
• name TTL class type rdata
• www.ripe.net. 7200 IN A 192.168.10.3
• RRset RRs with same name, class and type
• www.ripe.net. 7200 IN A 192.168.10.3
• A 10.0.0.3
• A 172.25.215.2
• RRSets are signed, not the individual RRs

69
New Resource Records

• Three Public key crypto related RRs
• RRSIG Signature over RRset made using private
  key
• DNSKEY Public key, needed for verifying a RRSIG
• DS Delegation Signer Pointer for building
  chains of authentication
• One RR for internal consistency
• NSEC Indicates which name is the next one in the
• zone and which typecodes are available for
  the current name
• authenticated non-existence of data

70
DNSKEY RDATA

• 16 bits FLAGS
• 8 bits protocol
• 8 bits algorithm
• N32 bits public key
• Example
• ripe.net. 3600 IN DNSKEY 256 3 5 (
• AQOvhvXXU61Pr8sCwELcqqq1g4JJ
• CALG4C9EtraBKVd vGIF/unwigfLOA
• O3nHp/cgGrG6gJYe8OWKYNgq3kDChN)

71
RRSIG RDATA

• 16 bits - type covered
• 8 bits - algorithm
• 8 bits - nr. labels covered
• 32 bits - original TTL

ripe.net. 3600 IN RRSIG A 5 2
3600 ( 20050611144523 20050511144523 3112
ripe.net. VJ8ijXvbrTLeoAiEk/q
MrdudRnYZM1VlqhN
vhYuAcYKe2X/jqYfMfjfSUrmhPo0/GOZjW
66DJubZPmNSYXw )
signature field

• 32 bit - signature expiration
• 32 bit - signature inception
• 16 bit - key tag
• signers name

72
Delegation Signer (DS)

• Delegation Signer (DS) RR indicates that
• delegated zone is digitally signed
• indicated key is used for the delegated zone
• Parent is authorative for the DS of the childs
  zone
• Not for the NS record delegating the childs
  zone!
• DS should not be in the childs zone

73
DS RDATA

• 16 bits key tag
• 8 bits algorithm
• 8 bits digest type
• 20 bytes SHA-1 Digest

ORIGIN ripe.net. disi.ripe.net. 3600 IN NS
ns.disi.ripe.net disi.ripe.net. 3600 IN DS
3112 5 1 (
239af98b923c023371b52
1g23b92da12f42162b1a9
)
74
NSEC RDATA

• Points to the next domain name in the zone
• also lists what are all the existing RRs for
  name
• NSEC record for last name wraps around to first
  name in zone
• N32 bit type bit map
• Used for authenticated denial-of-existence of
  data
• authenticated non-existence of TYPEs and labels
• Example
• www.ripe.net. 3600 IN NSEC ripe.net. A RRSIG
  NSEC

75
NSEC Records

• NSEC RR provides proof of non-existence
• If the servers response is NXDOMAIN
• One or more NSEC RRs indicate that the name or a
  wildcard expansion does not exist
• If the servers response is NOERROR
• And empty answer section
• The NSEC proves that the QTYPE did not exist
• More than one NSEC may be required in response
• Wildcards
• NSEC records are generated by tools
• Tools also order the zone

76
NSEC Walk

• NSEC records allow for zone enumeration
• Providing privacy was not a requirement
• Zone enumeration is a deployment barrier
• Work has started to study solutions
• Requirements are gathered
• If and when a solution is developed, it will
  co-exist with DNSSEC-BIS !

77
Current Developments

• NSEC3 being tested
• All RR names hashed
• Hashed names are ordered
• opt-in for unsecured delegations possibilities
• SHA1 to be deprecated
• New hash for DS records
• Overlap, no flag day

78
Other Keys in the DNS

• DNSKEY RR can only be used for DNSSEC
• Keys for other applications need to use other RR
  types
• CERT
• For X.509 certificates
• Application keys under discussion/development
• IPSECKEY
• SSHFP

79
Summary

• DNSSEC not a PKI
• Zone status
• New RRs DNSKEY, RRSIG, NSEC, DS

Questions?
80
Setting Up a secure Zone
81
Securing a Zone Step 1

• Generate keypair
• Include public key (DNSKEY) in zone file
• dnssec-keygen tool comes with BIND

82
Securing a Zone Step 2

• Sign your zone
• Signing will
• Sort the zone
• Insert
• NSEC records
• RRSIG records (signature over each RRset)
• DS records (optional)
• Generate key-set and ds-set files

83
Securing a Zone Step 3

• Publish signed zone
• Signed zone is regular zonefile format
• With extra resource records
• Make sure all your servers are DNSSEC capable!

84
Securing a Zone Step 4

• Configure forwarding resolver
• Test
• DNSSEC verification only done in resolver!

85
Securing a Zone Step 5

• Distribute your public key (DNSKEY)
• To parent zone (key-set or ds-set can be used)
• To everyone that wants/needs you as SEP
• Make sure to inform everyone of key rollovers!

86
Summary

• Generating keys
• Signing and publishing the zone
• Resolver configuration
• Testing the secure zone

Questions?
87
Delegating Signing Authority

• Chains of Trust

88
Locally Secured Zones

• Key distribution does not scale!

.
com.
net.
os.net.
money.net.
kids.net.
Secure entry points
corp
dop
unix
mac
nt
marnick
dev
market
dilbert
Out of band key-exchanges
89
Using the DNS to Distribute Keys

• Secured islands make key distribution problematic
• Distributing keys through DNS
• Use one trusted key to establish authenticity of
  other keys
• Building chains of trust from the root down
• Parents need to sign the keys of their children
• Only the root key needed in ideal world
• Parents always delegate security to child

90
Key Problem

• Interaction with parent administratively
  expensive
• Should only be done when needed
• Bigger keys are better
• Signing zones should be fast
• Memory restrictions
• Space and time concerns
• Smaller keys with short lifetimes are better

91
Key Functions

• Large keys are more secure
• Can be used longer ?
• Large signatures gt large zonefiles ?
• Signing and verifying computationally expensive ?
• Small keys are fast
• Small signatures ?
• Signing and verifying less expensive ?
• Short lifetime ?

92
Key solution More Than One Key

• RRsets are signed, not RRs
• DS points to specific key
• Signature from that key over DNSKEY RRset
  transfers trust to all keys in DNSKEY RRset
• Key that DS points to only signs DNSKEY RRset
• Key Signing Key (KSK)
• Other keys in DNSKEY RRset sign entire zone
• Zone Signing Key (ZSK)

93
Initial Key Exchange

• Child needs to
• Send key signing keyset to parent
• Parent needs to
• Check childs zone
• for DNSKEY RRSIGs
• Verify if key can be trusted
• Generate DS RR

94
Walking the Chain of Trust
2
95
Chain of Trust Verification, Summary

• Data in zone can be trusted if signed by a
  Zone-Signing-Key
• Zone-Signing-Keys can be trusted if signed by a
  Key-Signing-Key
• Key-Signing-Key can be trusted if pointed to by
  trusted DS record
• DS record can be trusted
• if signed by the parents Zone-Signing-Key
• or
• DS or DNSKEY records can be trusted if exchanged
  out-of-band and locally stored (Secure entry
  point)

96
Summary

• Scaling problem secure islands
• Zone signing key, key signing key
• Chain of trust

Questions?
97
Key Rollovers
98
Private Key Compromise

• You have to keep your private key secret
• Private key can be stolen
• Put the key on stand alone machines or on bastion
  hosts behind firewalls and strong access control
• Private key reconstruction (crypto analysis)
• Random number not random
• Leakage of key material (DSA)
• Brute force attacks

99
Key Rollovers

• Try to minimise impact
• Short validity of signatures
• Regular key rollover
• Remember DNSKEYs do not have timestamps
• the RRSIG over the DNSKEY has the timestamp
• Key rollover involves second party or parties
• State to be maintained during rollover
• Operationally expensive

100
Timing of the Scheduled Key Rollover

• Dont remove the old key while there servers are
  still handing out the old DS RR
• New DS needs to be distributed to the slaves
• Max time set by the SOA expiration time
• Old DS needs to have expired from caches
• Set by the TTL of the original DS RR
• You (or your tool) can check if the master and
  slave have picked up the change

101
Unscheduled Rollover Problems

• Needs out of band communication
• With parent and pre-configured resolvers
• The parent needs to establish your identity again
• How to protect child delegations?
• Unsecured?
• There will be a period that the stolen key can be
  used to generate seemingly secure data
• There is no revoke key mechanism
• Emergency procedure must be on the shelf

102
Key Rollover - Summary

• Generate new KSK
• Sign with old and new KSKs
• Wait for your servers TTL of old DNSKEY RRset
• Inform resolvers of the new key
• that have you as a trusted entry point
• Query for the parental DS and remember the TTL
• Upload the new KSK or DS to the parent
• Check if all parental servers have new DS
• Wait another TTL before removing the old key

103
Summary

• Key size and signature lifetimes
• Key rollovers
• Emergency procedure

Questions?
104
Operational Concerns
105
RIPE NCC Tests

• Traces from production servers
• k.root-servers.net
• ns-pri.ripe.net
• Test servers configured like production machines
• ns-pri.ripe.net
• Loaded with all 133 zones.
• k.root-servers.net
• Only loaded with the root zone.

106
Zone Signing

• 1 Key Signing Key 2048 bit RSASHA1
• 2 Zone Signing Keys of equal length
• Length varied between 512 and 2048
• Only one ZSK used for signing
• Pre-publish KSK to aid rollovers
• 3 DNSKEY RRs in each zone
• 1 RRSIG per RR set
• 2 RRSIGs over the DNSKEY RR set

107
Memory Usage

• On ns-pri.ripe.net factor four increase
• From ca. 30MB to 150MB
• No problem for a 1GB of memory machine
• On k.root-servers.net
• Increase by circa 150KB
• Total footprint 4.4 MB
• Memory usage can be calculated in advance
• For authoritative servers
• No surprises necessary

108
Serving the Zones Query Properties

• Clients set the DO flag to request DNSSEC data
• EDNS size determines maximum packet size
• DNSSEC requires EDNS
• EDNS/DO properties determine which fraction of
  the replies contain DNSSEC information

109
EDNS Properties
110
Serving the Zones

• Measured for different key sizes.
• Named for ns-pri.ripe.net
• NSD and named for ns-pri.ripe.net and
  k.root-servers.net
• We also wanted to study worst caseWhat if all
  queries have the DO bit set?
• Modified the servers to think that queries had
  EDNS 2048 octets size and DO bit set

111
CPU

• trace server ZSK size WCPU
• ns-pri BIND 9.3.1 0000 ca 14
• ns-pri BIND 9.3.1 2048 ca 18
• k.root BIND 9.3.1 0000 ca 38
• k.root BIND 9.3.1 2048 ca 42
• k.root BIND 9.3.1 mod 2048 ca 50
• k.root NSD 2.3.0 0000 ca 4
• k.root NSD 2.3.0 2048 ca 4
• k.root NSD 2.3.0 mod 2048 ca 5

112
Bandwidth Factors

• Fraction of queries with DO bit
• Seen in difference between ns-pri and k.root
  result
• Seen in difference between modified and
  unmodified servers
• Including DNSKEY RR in additional section.
• Seen in difference between k.root traces from
  modified nsd and modified named
• Difference in answer patterns
• Name errors vs positive answers
• Difficult to asses from our data

113
(No Transcript)
114
(No Transcript)
115
Upper Bound
116
Upper Bound
117
Notes On Bandwidth Usage

• DNSKEY RRset with RRSIG in additional section
• Fairly big chunk of data
• None of the clients today validate the data
• Clients that need the data will query for it
• Servers MAY include the DNSKEY RRset
• NSD does not include the DNSKEY RRset
• Named (BIND) does include the DNSKEY RRset

118
Bandwidth Increase

• Significant for ns-pri.ripe.net
• Well within provisioned specs
• Insignificant for for k.root-servers.net
• Upper bound well within provisioning specs
• Even when including DNSKEY RR set in additional
  section
• Key size influences bandwidth but bandwidth
  should not influence your key size!

119
Not Measured

• Our experiment was done in a closed environment
• What about the behavior of clients that do expect
  DNSSEC information, but do no not receive it?
• Firewalls dropping packets with DNSSEC
• BIND behavior is well understood
• What about implementations that set the DO bit,
  but cannot handle DNSSEC data that is returned?

120
Conclusion of These Measurements

• CPU, memory and bandwidth usage increase are not
  prohibitive for deployment of DNSSEC on
  k.root-servers.net and ns-pri.ripe.net
• Bandwidth increase is caused by many factors
• Fraction of DO bits in the queries is an
  important factor
• CPU impact is small
• Memory impact can be calculated

121
Signing the Root

• Three Organisations check root zone who signs?
• IANA/ICANN
• Department of Commerce
• Verisign
• How many keys?
• N of M system for trust?

122
Resolver Issues

• DNSSEC is not in POSIX yet
• e.g. gethostbyname()or getnameinfo()
• RRSIG verification only done by caching
  forwarders
• To test DNSSEC set-ups, you have to work with
  dig, or use the BIND lwresolver library
• Alternatively write some tools
• (for PERL NetDNS and NetDNSSEC)

123
End User Side

• Local verifying/recursive server trusted?
• TSIG for queries?
• IPSec?
• Enhance stub resolver functionality?
• How much information needed?
• AD bit enough?
• Verifier built in to programs?

124
Wish List

• Public and private key management tools
• Provisioning tools
• Secure Islands public keys distribution
• API and protocol to communicate validation
  results
• Killer app that relies on DNSSEC
• Documentation/training/tools in order to reduce
  costs

125
Summary

• Increased memory and bandwidth demands
• Political issues

Questions?
126
RIPE NCCs DNSSEC Deployment
127
Old Server Set-up

• ns.ripe.net
• - Primary for various zones such as ripe.net
• - Primary for /8 v4 and /16 v6 reverses
• - Secondary for /16 v4 and /32 v6 reverses
• - Secondary for around 70 ccTLD zones
• - Secondary for lots of other misc zones
• Machine had heavy load
• Provisioning was not optimal

128
New Servers - Status

• Most zones have moved to their new homes
• Currently zones are distributed as follows
• ns-pri 150 zones
• ns-sec 282 zones
• ns-tld 179 zones
• ns.ripe.net 3057 zones

129
RIPE NCC DNS Server Setup
130
DNSSEC Architecture Modifications
Zone signer
Primary DNS
ZoneGeneration
Whois
Secondary DNS
Customerinterfaces
DelChecker
131
DNSSEC Deployment Tasks

• Key maintenance policies and tools
• Private key use and protection
• Public key distribution
• Zone signing and integration into the
  provisioning chain
• DNS server infrastructure
• Secure delegation registry changes
• Interfacing with customers

132
Public Key Dissemination at RIPE NCC

• Until we have a signed parent zone
• Keys for all zones
• Published on a secured website
• https//www.ripe.net/projects/disi/keys/ripe-ncc-d
  nssec-keys.txt
• Are signed with the RIPE NCC public keys
• https//www.ripe.net/projects/disi/keys/ripe-ncc-d
  nssec-keys.txt.asc
• https//www.ripe.net/rs/pgp/ncc-pgpkey-2006.asc
• Will be rolled twice a year (initially)
• Announcements are always signed

133
Maintaining Keys and Signing Zones

• The KeyDB maintains the private keys
• It knows rollover scenarios
• UI that can create, delete, roll keys
• without access to the key material
• Physically secured
• The signer ties the Key DB to a zone
• Inserts the appropriate DNSKEYs
• Signs the the zone with appropriate keys

134
Private Key Maintenance Software

• Perl front-end to the BIND tools
• Key pairs are kept on disc in BIND format
• Files contain human readable information
• Possible to bail out and sign manually
• Works in the RIPE NCC environment
• No warranties
• Available https//www.ripe.net/projects/disi/dnss
  ec_maint_tool/

135
Securing the Delegations

• The DS exchange is the same process as the NS
  exchange
• Same authentication/authorisation model
• Integrate the key exchange into existing
  interfaces
• Customers are used to those
• Include checks on configuration errors
• DNSSEC is picky
• Provide tools
• To prevent errors and guide customers

136
Changes to the Delegation Procedure

• ds-rdata attribute was added
• Zone generation tool uses ds-rdata contents
• For unsigned zones ds-rdata is blocked
• Added a number of DelChecker checks
• Web-interface to create domain object
• Does all the delegation checker checks
• https//www.ripe.net/cgi-bin/delcheck/delcheck2.cg
  i

137
Summary

• Server changes
• Delegation changes
• Web interface for domain objects

Questions?
138
The End!
Finis
?????
K???
Sfârsit
Ki????
Konec
Ende
Kraj
The End
Son!
Fine
Lõpp
Kpaj
Vége
Fund
Fin
Einde
?????
Baigti
The End
Slutt
???????
Fim
Koniec
Loppu