Skip to main content

RSSAC Approves Advisories on Service Expectations of Root Servers and Measurements of the Root Server System

At its regular meeting on 20 November 2014, the RSSAC approved RSSAC001 and RSSAC002, the first two formal advisories produced by the RSSAC under its reorganized structure.

In RSSAC001, the RSSAC describes the best practice service to be provided by root servers, and defines the operational expectations that users might reasonably anticipate of both that service and the root server operators. This document highlights that a diversity of approach is desirable in the root server system, and replaces, together with an upcoming Request For Comments from the Internet Architecture Board (IAB) (see below), an earlier direction (RFC 2010, RFC2870) on implementation with a set of protocol and service expectations that root server operators must satisfy.

In RSSAC002, the RSSAC identifies and recommends an initial set of parameters that would be useful to monitor for establishing a baseline and trends for the root server system. The implementation of these measurements (and future refinements to them) by root server operators will form an early warning system that will assist in detecting and mitigating any effects (or the absence of such effects) associated with growing size of the root zone.  A common set of expectations for data collection will help identify any changes that might challenge the normal performance of the DNS root server system associated with growth of the root zone or other evolutionary changes in the DNS and the Internet.

RSSAC002 is published on the RSSAC publications webpage. RSSAC001 will be held for publication in tandem with a complementary RFC by the IAB, specifying the DNS Root Name Service Protocol and Deployment Requirements (current draft is available here).

These documents are general advice to the technical community, particularly the root server operators. In accordance with its charter, RSSAC is working with the root server operator organizations on deployment of the recommendations and plans a status report to the community.

More Announcements
Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as"""" is not an IDN."