Hi, Here is an ascii version of the proposed re-orgisation of the study topics that would fall within this area, as we discussed today. As you read this could you please bear in mind a few questions: Is this a useful structure to use to organise this activity? What is missing from this list? Is there anything here that is perhaps out of scope? Is this an achievable agenda for the study? thanks, Geoff ————————— Security and Stability of the DNS Topics The following are a set of general topic areas to underpin the study of this question. The question is predicated by scoping this topic to matters that fall with ICANN's remit. The broader consideration of the security and stability of the architecture of the DNS ecosystem, its technologies, aplicable standards, vendors, operating practices and actors doubtless intersect with ICANN's remit but the general topics are substantially larger matters and will not be considered as part of this review. The focus point here are those activities that are directed or coordinated by ICANN or the PTI, or where ICANN has a substantive presence by virtue of hosting the community-driven policy process.
1. Root Zone Management Practices 2. Change Management 3. Roles and Responsibilities 4. Abuse and Threats
-------------
1. Root Zone Management Practices
ICANN coordinates the contents of the root zone of the public DNS system, so consideration of the security aspects of the way in which this responsibility is fulfilled is relevant to this topic. POtential sub-topics incliude: 1.1 TLD Label management (what labels go in the root zone) What guidelines and constraints govern the labels that are placed into the root zone of the DNS? How are these constraints managed? How is change control exercised over these constraints? If a proposed TLD contains non-ascii unicode characters (IDN) what procedures are followed to ensure that the label is not inherently confusable? (see SSAC084 for background) 1.2 Name Server and DS record management When a name is delegated in the root zone, the delegation is made by virtue of entering NS (and DS) records into the root zone. These records change from time to time as the authoritative name servers change, and as DNSSEC Keys change, so the subject of the delegation. Are appropriate security practices used to ensure that changes are duly authorised by the correct party prior to inclusion onto the root zone? This includes considered of whether the content of the NS and DS records be validated prior to inclusion in the root zone, and whether these records should be regularly audited to ensure their contining accuracy? 1.3 Respective roles of RSSAC and ICANN The Root Server operators serve an authoritative copy of the current root zone contents from their secondary servers. They have considerable latitude as to how the root zone is served in terms of technical aspects of their service. Is this appropriate? The finer level of detail of how each root server actually delivers content are largely undocumented, and it is unclear if this opacity and diversity serves the security and resilience of the root service or detracts from this. 1.4 Respective roles of ICANN, PTI and Verisign over root zone contents The root zone is produced as the outcome of a multi-party process, where the zone file is the result of records provided by PTI and records provided by Verisign. Is this separation of roles appropriate? Does this multi-step process introduce vulnerabilities, or do they remove potential single points of failure by having multiple parties with oversight on the root zone as it is generated?
2. Change Management
2.1 Introduction of new TLDs Is the phased introduction of TLDs with the root zone in a state of constant flux better or worse than a single introduction of new names in a single well advertised event? Aside from ccTLDs (below) is there any consideration of the retirement of TLDs from the root zone? 2.2 Coordination with ISO3166 or both introduction and retirement of ccTLDs What is the nature of the interaction between ISO 3166 and the root zone? Are all two letter TLDs reserved? What about Exceptionally reserved, traditionally reserved and indeterminately reserved names? Does ISO3166 provide for CC name retirement in an acceptable manner? 2.3 Coordination with IETF over Special Use Names Registry There is none at the moment! See SSAC 090 2.4 Coordination between IETF and Unicode Consortium over IDNA standards and practice See SSAC 095 for the specific case with emojis, but the general observation holds true as well. 2.5 Evolution of the Root Service Does the future security of the DNS root service rely solely on the current root server operators and the infrastructure that they operate? Should the model of distribution of root zone data evolve to include consideration of the opportunities offerred by DNSSEC, such as local root secondary servers and recursive resolvers DNSSEC NSEC caching. How can ICANN assist in these measures to assist tin scaling the root and making it more resilient to known attack vectors? 2.6 Consistency of the Identifiers The DNS resolution protocol is not the only protocol that performs a mapping from a domain name to a IP address (or other 'attached' attribute. To what extent should the ICANN community take steps to ensure that a domain name has a consistent meaning irrespect of the method of name resolution? i.e. is ICANN's remit solely concerned with domain names as resolved by the DNS protocol. Or does it extent to domain names as resolved by any protocol in the context of the public Internet? Or domain names irrespective of the name's manner and context of use?
3. Roles and Responsibilities
3.1 How to balance community policies, applicable standards, and SSR concerns over DNS evolution Are there checks and balances in the process are do they have a voice? To what extent do registrar contracts take account of standards?
4. Abuse and Threats
4.1 What are ICANN's responsibilities in this space? Notes about DNSSEC DNSSEC is the chosen mechanism to support security in the DNS, in so far that the resolution process itself is not protected, but the result can be validated to assure the client that the resolution response is genuine and complete. Being such a central part of DNS Security in general, should it be a topic of study in this sub-topic? DNSSEC is largely under the control of the IETF as a piece of technology. If a party wants to alter the operation of DNSSEC or any other aspect of the way in which its operation if defined then the IETF is the place to undertake such a conversation. This implies that such technical aspects are beyond ICANN's remit. DNSSEC, as seen by ICANN, is firstly a set of DS delegation records, similar in almost every respect to NS records. There are some operational questions in this process, noted in section 1.2. Secondly, DNSSEC is a root zone signing operation. This area includes the management of the KSK key which appears to fall under the subtopic of ICANN operations as it not a generic DNS topic. The question of the choice of protocol and key length and the scheduling of periodic KSK rolls appears to also be an ICANN operational topic rather than a generic DNS stability issues.