Criteria
1 Stability
1.1 Uptime
1.1.1 Reachability
1.1.1.1 At multiple ports
1.1.1.2 Unintended
1.1.1.3 Officially intentional
1.1.1.4 Malicious
1.1.2 Note -- WW CGI.hR, SIMET
1.2 Changes can be implemented with a predictable impact on services
1.3 Acceptable performance for all actors
1.4 DNS is (by definition) an End-to-End service -- not just the protocol between client and server, but has boundaries that go far beyond that
1.5 Availability
1.5.1 Availability of data/system
1.5.2 Availability of DNS as a service
1.5.2.1 Secondary servers
1.6 Data integrity
1.6.1 Integrity of data
1.6.1.1 Authenticity
1.6.1.2 Trustworthy
1.6.2 Types of data
1.6.2.1 Configuration
1.6.2.1.1 Accuracy (e.g. errors/typos in names/IPs/etc.
1.6.2.1.2 Correctness/accuracy
1.6.3 Scope -- not just registry data, registrars AND registries
1.7 Process integrity
1.7.1 Scope -- includes policy, political, protocol
1.7.1.1 Action: expand/clarify
1.7.2 Institutional confidence
1.7.3 Accountability and transparency
1.7.4 Availability to end user
1.7.4.1 "reachability"
1.7.4.2 Action -- Don B -- figure out a substitute for the word "availability"
1.7.5 Procedures
1.7.5.1 Roles and responsibilities
1.7.5.2 Physical/procedural/process
1.7.6 Incidence response
1.7.6.1 Threat warning and recommendations of mitigation based on the warning
1.7.6.2 Timely response
1.7.7 Expertise
1.7.7.1 DNS
1.7.7.2 Security
1.7.7.3 Networking
1.7.7.4 Skill
1.7.7.4.1 Design
1.7.7.4.2 Operation
1.7.8 Healthy DNS needs good incident management and good network operations
1.7.9 Diversity
1.7.9.1 Operator (people, location, funds, experience)
1.7.10 Protocol integrity
1.8 Sufficient provisioning of infrastructure building blocks
1.8.1 Hardware
1.8.2 Software
1.8.3 Capacity
1.8.4 Transit
1.8.5 Connection (minimums?)
1.8.5.1 Bandwidth
1.8.5.2 Connectivity
1.8.5.3 Latency
1.8.5.4 Resilience?
1.9 System integrity
1.9.1 Consistency
1.9.2 Infrastructure (brand, spec, location)
1.9.3 3rd party suppliers of services/SLA's
1.9.4 Works and continues to work in a highly predictable way
2 Action items
2.1 Ask Mark to clarify the "DNSSEC" part of that group's work
2.2 Scott -- expand on:
2.2.1 WHOIS problem?
2.2.2 Threats and defenses
2.2.2.1 Operational criteria
2.2.2.1.1 Roles and responsibilities
2.2.2.1.2 Physical/procedural/process
2.2.2.1.3 3rd party suppliers of services/SLA's
2.2.2.2 Institutional confidence
2.2.2.3 Accountability and transparency
3 From whose perspective???
3.1 Different issues, depending on point of view
3.2 Registrant <--> Registrar (1)
3.2.1 Availability - n/a
3.2.2 DNS data accuracy -- 100%
3.2.3 Data integrity
3.2.4 Process integrity
3.2.5 System integrity
3.3 Registry <--> Registrar AND Registry <--> Registrant (2)
3.3.1 Availability - 90%
3.3.2 DNS data accuracy -- 100%
3.3.3 Data integrity
3.3.4 Process integrity
3.3.5 System integrity
3.4 Registry <--> DNS (3)
3.4.1 Availability --
3.4.2 DNS data accuracy -- 100%
3.4.3 Data integrity
3.4.4 Process integrity
3.4.5 System integrity
3.5 DNS <--> End-user (4)
3.5.1 Availability -- 100%
3.5.2 DNS data accuracy -- 100%
3.5.3 Data integrity
3.5.4 Process integrity
3.5.5 System integrity
3.6 Picture
3.6.1
4 Security
4.1 Confidence
4.2 Resistant to attack
4.3 Manage threats effectively
4.4 Attribution/zone data?
4.5 WHOIS problem?
4.6 Physical Security
4.7 Data integrity
4.7.1 Submission/registration
4.8 DNSSEC
4.8.1 Recursive resolver
4.8.2 DNSSEC taxonomy
4.8.3 Hard to determine health of DNS based on unknown but exploited holes in DNS
4.8.4 Need of service level of DNS (dashboard)