ICANN/GNSO GNSO Email List Archives

[ispcp]


<<< Chronological Index >>>    <<< Thread Index >>>

[ispcp] proposal to mitigate name-collision risks -- ISPs will do the heavy lifting

  • To: "ispcp@xxxxxxxxx" <ispcp@xxxxxxxxx>
  • Subject: [ispcp] proposal to mitigate name-collision risks -- ISPs will do the heavy lifting
  • From: "Mike O'Connor" <mike@xxxxxxxxxx>
  • Date: Wed, 7 Aug 2013 11:35:03 -0500
  • List-id: ispcp@xxxxxxxxxxxxxx
  • Sender: owner-ispcp@xxxxxxxxxxxxxx

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br>hi all,<br><br>ICANN has just posted a proposal to mitigate the "name collision" problem. &nbsp;their proposal creates unfunded customer-service obligations for ISPs worldwide. &nbsp;i've attached&nbsp;ICANN's proposal to this note.&nbsp; i've excerpted some of the interesting pieces within the text of this note. &nbsp;<div><br></div><div>ISPs will be on the front lines of this process, since we are in many cases the only organizations that know which customer is using a given IP address. &nbsp;so if a Registry detects name-collision traffic on their newly-delegated gTLD, they will have to send these notifications to ISPs who will in turn have to reach out to their customers.</div><div><br></div><div>my immediate question is "who funds all this?" &nbsp;who provides the educational material, the mitigation techniques, the trouble-shooting when things go wrong? &nbsp;who bears the liability if the repair-efforts cause harm to ISP customers? &nbsp;who puts together the global outreach effort to let ISPs know that this is coming? &nbsp;</div><div><br></div><div>i think we need to start thinking *hard* about this, and offer our thoughts during this public-comment period. &nbsp;</div><div><br></div><div>mikey</div><div><br></div><div><br></div><div>here's what's supposed to happen in the "low-risk" namespaces (proposed to be 80% of applied-for gTLDs):<br><br><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;">...once a TLD is first delegated within the public DNS root to name servers designated by the&nbsp;registry operator, the registry operator will not activate any names&nbsp;under the TLD in the DNS for a&nbsp;period of no less than 30 days. During this 30-day period, the registry operator will <b>notify the point of&nbsp;contacts of the IP addresses&nbsp;that issue DNS requests</b> for an un-delegated TLD or names under it. The&nbsp;minimum set of requirements for the notification is described in Appendix A of this&nbsp;paper. This&nbsp;measure will help mitigate the namespace collision issues in general. Note that both no-activate-name periods can overlap.<div><br></div><div>The TLD name servers may see DNS queries for an un-delegated name from recursive resolvers – for&nbsp;example, a resolver operated by a subscriber’s ISP or&nbsp;hosting provider, a resolver operated by or for&nbsp;a private (e.g., corporate) network, or a global public name resolution service. These queries will not&nbsp;include the&nbsp;IP address of the original requesting host, i.e., the source IP address that will be visible to&nbsp;the TLD is the source address of the recursive resolver. In the event&nbsp;that the TLD operator sees a&nbsp;request for a non-delegated name, <b>it must request the assistance of these recursive resolver&nbsp;operators in the notification process as&nbsp;described in Appendix A.</b></div></blockquote><div><br>APPENDIX&nbsp;A – NOTIFICATION&nbsp;REQUIREMENTS<br><br>Registry operator will notify the point of contact of each IP address block that issue any type of DNS&nbsp;requests (the Requestors) for names under the TLD or its&nbsp;apex. The point of contact(s) will be&nbsp;derived from the respective Regional Internet Registry (RIR) database. Registry operator will offer&nbsp;customer support for the&nbsp;Requestors or their clients (origin of the queries) in, at least, the same&nbsp;languages and mechanisms the registry plans to offer customer support for registry&nbsp;services.&nbsp;Registry operator will avoid sending unnecessary duplicate notifications (e.g. one notification per&nbsp;point of contact).<br><br>The notification should be sent, at least, over email and must include, at least the following elements:&nbsp;1) the TLD string; 2) why the IP address holder is receiving&nbsp;this email; 3) the potential problems the&nbsp;Requestor or its clients could encounter (e.g., those described in section 6 of the Study report); 4) the&nbsp;date when the&nbsp;gTLD signed the registry agreement with ICANN, and the date of gTLD delegation; 5)&nbsp;when the domain names under the gTLD will first become active in DNS; 6)&nbsp;multiple points of contact&nbsp;(e.g. email address, phone number) should people have questions; 7) will be in English and may be in&nbsp;other languages the point of&nbsp;contact is presumed to know; 8) ask the Requestors to pass the&nbsp;notification to their clients in case the Requestors are not the origin of the queries, e.g., if they are&nbsp;providers of DNS resolution services; 9) a sample of timestamps of DNS request in UTC to help&nbsp;identify the origin of queries; 10) email digitally signed with&nbsp;valid S/MIME certificate from well-&nbsp;known public CA.<br><br><br><br><br>PHONE: 651-647-6109, FAX: 866-280-2356, WEB: <a href="http://www.haven2.com";>www.haven2.com</a>, HANDLE: OConnorStP (ID for Twitter, Facebook, LinkedIn, etc.)</div><div><br></div><div><br></div></div></body></html>

Attachment: new-gtld-collision-mitigation-05aug13-en.pdf
Description: Adobe PDF document

<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div></div></div></body></html>


<<< Chronological Index >>>    <<< Thread Index >>>