hi all, here’s one of (at least) two new SSAC reports that have come out in time for Singapore — SAC064 - Search List Processing http://www.icann.org/en/groups/ssac/documents/sac-064-en.pdf i’ve extracted some of the report below, mostly with the intent of providing enough of it to give you a sense of what’s there. this report seems closely related to another of my favorite topics, Name Collision (i’ll give that thread a kick in a moment, the JAS report is out for comment). to start off the conversation, here’s an inflammatory question. we seem to be piling up an impressive group of recommendations that we should do more research, work with the IETF to come up with standards and communicate these issues to the worldwide operator community. but then what? let’s assume for a moment that the Board says “yes, thanks, we agree.” who does what after that? how do we evaluate success? who is accountable? this isn’t a problem just with SSR related stuff, i’m running into this broadly across the “implement GNSO policy” spectrum. it seems like a gap to me. this report could be another one we look back 5 years out and say “why didn’t anybody do anything way back in 2014?” is there something the GNSO (either the Council, by launching a PDP, or the broader GNSO stakeholder community) could do to help avoid that situation? mikey Executive Summary A Domain Name System (DNS) “search list” (hereafter, simply “search list”) is conceptually implemented as an ordered list of domain names. When the user enters a name, the domain names in the search list are used as suffixes to the user-supplied name, one by one, until a domain name with the desired associated data is found or the search list is exhausted. Processing search lists was weakly standardized in early Requests For Comments (RFCs) and implemented in most operating systems. However, as the Internet has grown, search list behavior has diversified. Applications (e.g., web browsers and mail clients) and DNS resolvers process search lists differently. In addition, some of these behaviors present security and privacy issues to end systems, can lead to performance problems for the Internet, and might cause collision with names provisioned under the newly delegated top-level domains. This advisory examines how current operating systems and applications process search lists. It outlines the issues related to the current search list behavior, and proposes both a strawman to improve search list processing in the long term and mitigation options for the Internet Corporation for Assigned Names and Numbers (ICANN) and the Internet community to consider in the short term. The purpose of these proposals is to help introduce new generic Top Level Domains (gTLDs) in a secure and stable manner with minimum disruptions to currently deployed systems. Specifically, the Security and Stability Advisory Committee (SSAC): Invites ICANN Supporting Organizations and Advisory Committees, and the DNS operations community to consider the proposed long term behavior for search list processing outlined in this advisory and comment on its correctness, completeness, utility and feasibility; Recommends ICANN to work with the DNS community to encourage the standardization of search list processing behavior; and Recommends ICANN, in the context of mitigating name collisions, to consider additional steps to address search list processing behavior. 6. Findings Finding 1: There is variance on how search lists are processed. The variation is large between applications and operating systems. Finding 2: RFC 1535 is ambiguous in how search list processing should take place. How to process a (specifically unqualified) domain name can be interpreted in multiple ways. Finding 3: Deployed operating systems and applications violate RFC 1535 today. Application developers and providers of operating systems today already have started to implement search list algorithms that differ from RFC 1535. This leads to incompatibilities and might contribute to a degraded user experience. Finding 4: Some search list algorithms deployed today will create problems when new TLDs are delegated. Search list processing according to RFC 1535 can today result in local resolution of a name if a TLD is not delegated. However after that TLD is delegated, global resolution will occur (see SAC06214). Given the variance in implementation of search lists, the use of shortened domain names is non-deterministic and, as a result, can result in negative consequences regardless of whether TLDs are delegated. Thus, the SSAC makes the following recommendations: 7. Recommendations Recommendation 1: The SSAC invites all ICANN Supporting Organizations and Advisory Committees, the Internet Engineering Task Force (IETF), and the DNS operations community to consider the following proposed behavior for search list processing and comment on its correctness, completeness, utility and feasibility. Administrators (including DHCP server administrators) should configure the search list explicitly, and must not rely on or use implicit search lists; Where DNS parameters such as the domain search list have been manually configured, these parameters should not be overridden by DHCP. When a user enters a single label name, that name may be subject to search list processing if a search list is specified, but must never be queried in the DNS in its original single-label form. c. When a user queries a hostname that contains two or more labels separated by dots, such as www.server, applications and resolvers must query the DNS directly. Search lists must not be applied even if such names do not resolve to an address (A/AAAA). Therefore www.server is always a FQDN. Recommendation 2: The SSAC recommends ICANN staff to work with the DNS community and the IETF to encourage the standardization of search list processing behavior. Such an effort should begin with ICANN staff submitting an Internet-Draft to the IETF, and advocating for its standardization within the IETF process. The effort should update RFC 1535 and other applicable RFCs to address the Findings and Recommendations in this document. Recommendation 3: In the context of mitigating name collisions, ICANN should consider the following steps to address search list processing behavior. a. Commission additional research studies to further understand the cause of invalid queries to the root zone and the significance of search list processing as a contributor to those queries. b. Communicate to system administrators that search list behaviors currently implemented in some operating systems will cause collision with names provisioned under the newly delegated top-level domains. Such communication should complement the current ICANN effort in this area with findings and recommendations from this report.15 PHONE: 651-647-6109, FAX: 866-280-2356, WEB: www.haven2.com, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)