SAC 038: Registrar Abuse Contacts

In this document, SSAC examines some of the difficulties law enforcement, CERTs, online reputation protection services, and others may experience when they attempt to contact ICANN accredited registrars to make inquiries regarding the possible involvement of a domain name in a malicious, illegal or criminal activity. SSAC concludes that currently available registrar point of contact information does not meet the community's needs in two respects: first, point of contact information is not readily accessible for all registrars, and second, the contact information that can be accessed does not always identify a party at a registrar who can handle abuse claims or criminal complaints.

SSAC recommends that registrars and resellers assist in the investigation and mitigation of abuses and illegal activities in cases where attackers exploit domain name resolution and registration services. Specifically, SSAC recommends that each registrar should provide an abuse point of contact and that the staff handling abuses should be responsive, empowered to take effective action, and that abuse claims should be auditable by the claimant.

SSAC further recommends that registrars should publish abuse contact information, that the information a registrar publishes for the abuse point of contact should reach staff able to process an abuse claim, and that registrars make the information available in a uniform, machine readable format. Lastly, SSAC recommends that ICANN maintain a public repository for registrar abuse points of contact and should periodically verify that the contact information is accurate.

SAC 037: Executive Summary of SSAC Comments on Display and usage of Internationalized Registration Data: Support for characters from local languages or scripts

Many Internet applications today support characters from local languages, alphabets or scripts. Support for characters from local languages, alphabets or scripts affects how information is displayed to Internet users and how users submit information to applications via data entry methods including command lines and web forms.

This document examines how the use of characters from local scripts affects the Internet user experience with respect to domain name registration data submission, usage, and display. The paper presents examples of what users may encounter today when they access Registration Rata via WHOIS or via the web. The document examines the issues related to supporting characters from local scripts in the context of current and future applications that various parties (e.g., registrars, registries, third parties) provide for the submission, usage and display of domain names and Registration Data.

SAC 036: Executive Summary of SSAC Comments on the Draft ICANN Strategic Plan for 2009-2012

These documents make public SSAC's comments regarding the Draft ICANN Strategic Plan for 2009-2012.

SAC 035: Executive Summary of Test Report: DNSSEC Impact on Broadband Routers and Firewalls

During July and August 2008, Core Competence and Nominet UK, the registry for .UK, collaborated to assess the impact of DNSSEC on residential Internet router and SOHO firewall devices commonly used with broadband access services. Shinkuro, Inc., The Internet Society, ICANN, and Afilias, Ltd supported core Competence’s participation in this study.

Two dozen residential Internet router and SOHO firewall devices commonly used with broadband services were tested under closed controlled test beds to determine whether each unit correctly routes or proxies:

• DNS queries requiring TCP or EDNS0 to convey lengthy DNSSEC responses
• Non-DNSSEC queries on signed and unsigned domains
• Non-DNSSEC queries that set other DNSSEC-related request flags
• DNSSEC queries that request server-side validation
• DNSSEC queries that request no server-side validation

Published market research, broadband provider websites, and retail "best seller" lists were to identify the most widely deployed equipment supplied by broadband providers, or purchased by consumers and organizations for Small and Home Office networks.

The summary of findings is reproduced here:

• All 24 units could route DNSSEC queries addressed to upstream resolvers (referred to herein as route mode) without size limitations.
• 22 units could proxy DNS queries addressed directly to them (referred to herein as proxy mode), with varying degrees of success.
• 6 of 22 DNS proxies had difficulty with DNSSEC-related flags and/or validated responses that effectively prevented DNSSEC use in proxy mode.
• 16 of 22 DNS proxies could successfully pass DNSSEC queries and return validated responses of some size.
• 18 DNS proxies limited responses over UDP to either 512 bytes or a size constrained by the MTU. Only 4 could return responses over UDP up to 4096 bytes, while just 1 could proxy DNS over TCP (no size limit). Such limits can interfere with returning longer DNSSEC responses.
• When deployed with factory defaults, 15 units are likely to be used as DNS proxies, while 3 always route DNS queries. The rest (6) vary over time, preferring to route DNS after being connected to a WAN.

The report concludes that that only 6 units (25%) operate with full DNSSEC compatibility using the default or "out of the box" configuration. Nine (9) units (37%) can be reconfigured to bypass DNS proxy incompatibilities. The remaining percent of units (38%) lack reconfigurable DHCP DNS parameters, making it harder for LAN clients to bypass their interference with DNSSEC use.

The report offers several, additional, significant conclusions:

• domain signing will have no impact on broadband consumers that do not use DNSSEC
• consumers are encouraged to upgrade to the latest firmware for the products they operate to assure they become DNSSEC-ready at the earliest opportunity
• manufacturers are encouraged to avoid further implementation delay to ease the introduction of DNSSEC. (Note: Several technical recommendations accompany this conclusion and all merit the manufacturers’ attention.)
• manufacturers are also encouraged to consider additional DNS security measures; specific emphasis is placed on removing open resolver, cache poisoning and source spoofing vulnerabilities

Per unit test results have been made available along with the report.

Executive Summary: 033 Domain Name Registration Records and Directory Services

This paper is a companion document to SAC 027 Comment to GNSO regarding WHOIS studies http://www.icann.org/committees/security/sac027.pdf

The paper asserts that the WHOIS protocol and variability among WHOIS implementations contribute to the poor quality of domain name registration data currently available. The paper further asserts that the ICANN community would be served well if the accuracy and availability of domain registration information were improved.

The paper describes features and characteristics that are common to many proprietary and public directory service applications (a common data schema and authentication, authorization, auditing, accuracy and availability frameworks), and suggests a set of questions that the ICANN community could use as the basis for formulating a requirements statement for an Internet Directory Service.

This paper is informational and makes no specific recommendations. SSAC suggests that this informational paper could serve as the basis for discussions related to future WHOIS features and services.

Executive Summary: 032 DNS Response Modification

This preliminary report examines DNS response modification. The Advisory considers two cases of this practice. In the first case, the registrant tuns control of his domain zone file to a name server operator, who processes DNS name queries for the zone in the following manner. Thie agent receives a DNS query for a name. The agent determines that the name in the query does not exist in the zone file it hosts for the domain registrant. Instead of returning a DNS response indicating a non-existent name, the entrusted agent returns a response indicating the name exists and containing an IP address mapping for the queried name of the agent's choosing. This is called a synthesized response.

Modification of a DNS response can also be done "on the fly" by any third party operating an iterative resolver. In this case, the iterative resolver intercepts "name error" responses generated by an authoritative name server and silently alters the response. Specifically, the resolver is configured to change the non-existent name response to one that signals name exists and inserting an IP address mapping for the queried name of the third party operator's choosing. In both cases, the operators benefit in some manner from this "DNS rewrite", e.g., through advertising or services offered at the host identified in the response message.

SSAC notes with some concern that DNS response modification may be performed without notice to the registrant or user, and without consent.

Modifying content and redirecting users to hosts that may not be known to or authorized by the registrant sets a worrisome precedent for applications other than web, e.g., email, instant messaging, and Internet Telephony. SSAC further notes that in both cases, the address is associated with a web page containing some form of advertising, marketing, or customized search. This site is neither operated by the registrant, nor can the registrant take measures to ensure that it is operated as securely as it operates its own sites.

This initial report focuses on explaining the effects of and unintended consequences to users, domain registrants, and those who rely on non-existent domain responses for error reporting and administrative purposes. Some of the possible, unintended consequences of DNS response modification create security and operational stability issues for registrants, e.g., address mapping conflicts, vulnerability to attack from systems identified as subdomains of the registrant¹s domain (and thus conventionally viewed as trustworthy). SSAC also notes that DNS response modification does not merely suppress an error response but alters the contents the domain registrant published in his zone file.

Executive Summary: 030 Survey of DNSSEC Capable DNS Implementations

SSAC is conducting a survey to determine the extent to which DNSSEC features are available in commercial, open source, and privately developed name server software and hardware ("appliances"). The survey, conducted via email, asks developers to identify the capabilities of their product (e.g., resolver, authority server), whether they support the core DNSSEC standards, standards, including NSEC3 and whether they have performed interoperability testing. The survey also asks developers about the availability of administrative tools. In cases where developers indicate they do not support DNSSEC, the survey asks the developer to offer an approximate date when DNSSEC will be supported.

SSAC publishes survey results as they are received; thus, this survey is at this time a living document. Vendors and developers may request that SSAC update DNSSEC implementation availability by answering the survey questions and submitting these to ssac-fellow@icann.org.

Executive Summary: SAC 028 Registrar Impersonation

Phishers exploit many forms of email that merchants or financial businesses send to customers. The goal of such email messages is to lure a customer to a web site that appears to be the customer's bank or merchant and cause the customer to disclose his account information. The phisher uses this information to fraudulently use the customer's credit cards or financial account, or steal the customer's identity. Domain name registrars control domain name information of behalf of their customers (registrants), and mostly correspond with registrants by email. They are thus a particularly valuable phishing target, and a registrar-impersonating phisher tries to lure a registrar's customer to a bogus copy of the registrar's customer login page, where the customer may unwittingly disclose account credentials to the attacker who can then modify or assume ownership of the customer's domain names.

The Advisory recommends ways registrars can reduce phishing threats. For example, including only the information necessary to convey the desired message in customer correspondence, the registrar can reduce the opportunities for phishers to personalize messages and thus make them more convincing. Registrars can also avoid the use of hyperlink references in email messages, provide some form of non-repudiation of origin, and educate customers of the phishing threat and consequences registrars use to minimize the exposure of their registrants to phishing risk in email correspondence and at registrar web sites.

This Advisory also recommends ways for registrants to detect and avoid falling victim to this type of phishing attack. For example, customers should avoid clicking on hyperlinks in all email correspondence, be suspicious of email correspondence from a registrar that claims an urgent response is required, and should not trust an email simply because it is personalized. The Advisory also recommends services registrants should consider when choosing a registrar.

Executive Summary: SAC 025 Fast Flux Hosting and DNS

"Fast flux hosting" refers to the automated, rapid modification of IP addresses assigned to hosts in the DNS to hide the location of web sites supporting malicious, illegal, or criminal activities. This SSAC Advisory explains how fast flux hosting exploits domain name and name registration services to frustrate detection and prolong the lifetime of illegal web sites. It examines current and possible methods of detecting and mitigating fast flux hosting at various points in the Internet by private network operators, ISPs, domain name registrars and TLD registries; for example, the identification and removal of malicious code installed on compromised computers and IP address isolation. In the process, the Advisory explains why fast flux hosting defies many such "traditional" mitigation techniques.

The Advisory also considers measures that certain registrars and registries implement today: monitoring changes to DNS records that are indicative of fast flux hosting, restricting DNS change frequencies and value ranges, and monitoring registrant account access to prevent automation. It further considers how registrars can use apply such measures to expedite illegal web site and domain name suspension processes. The Advisory recommends that ICANN, registries and registrars to consider these practices, establish best practices to mitigate fast flux hosting, and consider whether such practices should be addressed in future agreements.

Executive Summary: SAC 023 Is the WHOIS Service a Source for email Addresses for Spammers?

This SSAC study on WHOIS considers whether the WHOIS service is a source of email addresses for spammers. For the study, SSAC registered and monitored email delivery to randomly composed strings as second-level labels in four Top Level Domains: COM, DE, INFO, and ORG. The domain names were registered in February 2007. The recipient chosen for the registrant email address for each of the registration records was also chosen randomly. These were neither used in correspondence nor published electronically in any form (web, IM user, online service...). Thus, the only practical vectors to obtain these specific email addresses other than brute force derivation (or guessing) was via a WHOIS service or through the registrar or reseller in whose database(s) the email address were stored.

SSAC collected and analyzed all email messages delivered to these addresses for a period of approximately three months. Based on the data collected, the Committee finds that the appearance of email addresses in response to WHOIS queries is indeed a contributor to the receipt of spam.The data SSAC analyzed illustrate that the appearance of email addresses in responses to WHOIS queries virtually assures spam will be delivered to these email addresses. The Committee members involved in the WHOIS study do not believe, however, that the WHOIS service is the dominant source of spam.

SSAC concludes from its study that registries and registrars that implement anti-abuse measures such as rate- limiting, CAPTCHA, non-publication of zone file data and similar measures can protect WHOIS data from automated collection. Further, SSAC noted that anti-spam measures provided with domain name registration services are effective in protecting email addresses not published anywhere other than the WHOIS from spam.

Executive Summary: SAC 022 Domain Name Front Running

A perception exists within the Internet community that monitoring or spying is taking place when would-be registrants check the availability of a domain name. In this Advisory, SSAC considers the possible financial incentives for parties to preemptively register domain names, including the acquisition of a seemingly desirable name for secondary market (auction, resale) and domain monetization (use of the domain to host paid advertising). SSAC also considers alternative explanations, including coincidence and domain tasting.

SSAC explains that a domain name availability check can be intercepted by a variety of parties, any of whom may preemptively register the queried name. SSAC observes that there does not appear to be a strong set of standards and practices to conclude whether monitoring domain name availability checks is an acceptable or unacceptable practice. Complaints presented to SSAC provided insufficient information to conclude that any party associated with the domain name registration process engages in domain name front running. SSAC concludes that checking the availability of a domain name can be a sensitive act which may disclose an interest in or a value ascribed to a domain name and calls for additional, more detailed information from registrants who suspect front running activity by parties who offer domain name availability checks.

Executive Summary SAC 018 Accommodating IP Version 6 Address Resource Records for the Root of the Domain Name System

This Report, issued jointly by the SSAC and RSSAC, examines the inclusion of

IPv6 addresses at the root level of the DNS, focusing on (1) the impact of including IPv6 addresses of root name servers in the configuration file commonly known as the "root hints", a file that recursive name servers initially rely on to provide recursive name service, and (2) the impact of including IPv6 addresses of root name servers in the response messages for a DNS protocol exchange ("priming") that operators use to ensure that a recursive name server always starts operation with the most up-to-date list of root name servers.

With respect to (1). including IPv6 addresses of root name servers in the root hints file will have little affect on deployed recursive name server implementations. Specifically, the RSSAC and SSAC find that the existing procedures for publishing root hints are adequate to support the addition of

IPv6 addresses of root name servers in the files made available at ftp://ftp.internic.net/domain/

With respect to (2), a number of resolvers commonly used in production networks today were tested and demonstrated capable of accepting IPv6 address records returned in response to type NS queries by TLD name servers without incident. Moreover, intermediate systems commonly used in production networks today allow DNS messages containing IPv6 addresses to pass without incident (either as a default policy or by user configuration).

The results of these tests are published companion documents SAC 016, Testing Firewalls for IPv6 and EDNS0 Support, and SAC 017, Testing Recursive Name Servers for IPv6 and EDNS0 Support.

The committees also found that DNS implementations used by all thirteen root name server operators are capable of including IPv6 records.

On the basis of the above findings, the committees conclude that adding IPv6 records for the root servers to both the hints file and the zone will have minimal impact on name server implementations and intermediate systems used in production networks.