Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

SSAC Report on

DNS Zone Risk Assessment and Management

Domain Name WHOIS Terminology and Structure (R1)


Date IssuedDocumentReference IDCurrent Phase

  

SSAC Report on Domain Name WHOIS Terminology and Structure (R1)SAC051

Status
colourGreen
titleClosed




Progress Bar Container
step6
Progress Bar - Hyperlink Step
titlePhase 1 Receive
urlAdvice Process
Progress Bar - Hyperlink Step
titlePhase 2 Understand

Description:

Blocking or altering responses to Domain Name System (DNS) queries is increasingly prominent. Domain name or Internet Protocol (IP) address filtering (or otherwise preventing access to web content as a matter of security policy) may be viewed by some organizations as a natural extension of historical telephony controls that aimed to block people within an organizations from incurring toll charges.

Technical approaches to DNS blocking are intended to affect users within a given administrative domain, such as a privately or publicly operated network. Preventing resolution of the domain name into an IP address will prevent immediate connection to the named host, although circumvention techniques may enable connectivity to the intended system anyway (this includes simply accessing the site via IP address rather than via a Fully Qualified Domain Name (FQDN)). A DNS resolver or network operator could also rewrite a DNS response to contain an IP address mapping the operator chooses, whether rewriting a Non-Existent Domain (NXDOMAIN) response or rewriting the DNS response for an existing FQDN, with potentially harmful effects on DNS Security Extension (DNSSEC)-supporting name servers and their users. A particularly coarse-grained approach is for an operator to silently discard DNS responses, although this results in non-deterministic behavior and may itself be problematic. Regardless of the mechanism used, organizations that implement blocking should apply these principles:

  1. The organization imposes a policy on a network and its users over which it exercises administrative control (i.e., it is the administrator of a policy domain).
  2. The organization determines that the policy is beneficial to its objectives and/or the interests of its users.
  3. The organization implements the policy using a technique that is least disruptive to its network operations and users, unless laws or regulations specify certain techniques.
  4. The organization makes a concerted effort to do no harm to networks or users outside its policy domain as a consequence of implementing the policy.
urlAdvice Process
Progress Bar - Hyperlink Step
titlePhase 3 Evaluate
urlAdvice Process
Progress Bar - Hyperlink Step
titlePhase 4 Implement
urlAdvice Process
Progress Bar - Hyperlink Step
titlePhase 5 Close
urlAdvice Process
Progress Bar - Hyperlink Step
titleClosed
urlAdvice Process



Description:

The ICANN community should adopt the terminology outlined in this report in documents and discussions, in particular:

Domain Name Registration Data (DNRD). The data that domain name registrants provide when registering a domain name and that registrars or registries collects.

Domain Name Registration Data Access Protocol (DNRD-AP). The components of a (standard) communications exchange - queries and responses - that specify the access to DNRD.

Domain Name Registration Data Directory Service (DNRD-DS). The service(s) offered by domain name registries and registrars to implement the DNRD-AP and to provide access to DNRD-DSD.

Additional terminology includes "DNRDe," "DNRD Policy," "DNRD-DS Policy," "Internationalized DNRD," and "Localized DNRD." The term "WHOIS" should only be used when referring to the protocol as currently specified in RFC 3912.


STATUS UPDATES

DatePhaseTypeStatus Updates

 

ClosedPhase ChangeThis Advice Item is now Closed

 

Phase 5Board Update

This item has been processed as much as is relevant and is considered complete; no work is outstanding from the perspective of Board Advice (note that related implementation work may have been integrated into ICANN’s ongoing operations or other initiatives).

Status provided in 19 October 2016 letter from ICANN Board Chair to SSAC Chair (https://www.icann.org/en/system/files/correspondence/crocker-to-faltstrom-19oct16-en.pdf).

On 8 November 2012, the ICANN Board approved resolution directing that work begin related to the development of new directory service policy and that it incorporate the language used by the SSAC: https://www.icann.org/resources/boardmaterial/resolutions-2011-10-28-en#5. Both the New gTLD Base Registry Agreement and the 2013 Registrar Accreditation Agreement incorporate the SSAC's terminology: https://www.icann.org/resources/pages/registries/registriesagreements-en, https://www.icann.org/resources/pages/approved-withspecs-2013-09-17-en.

 

Phase 5Phase ChangeNow in Phase 5: Close Request

 

Phase 1Phase UpdateSSAC published SAC051: SSAC Report on WHOIS Terminology and Structure: https://www.icann.org/en/system/files/files/sac-051-en.pdf.

STATUS UPDATES

DatePhaseTypeStatus Updates