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.
