<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">hi all,<div><br></div><div>this is part of a continuing series of articles that Jeff is posting at DomainIncite. he’s looking for comments from people like us, and the organizations we represent. so circulate this to your organizations and encourage them to comment on the post over at DomainIncite.</div><div><br></div><div>my immediate reaction is…. cool idea. let’s think more on this one and figure out other similarly-cool ones. </div><div><br></div><div>mikey</div><div><br></div><div><h2><a href="http://domainincite.com/15512-controlled-interruption-as-a-means-to-prevent-name-collisions-guest-post">Controlled interruption as a means to prevent name collisions [Guest Post]</a></h2>
<div class="singleflanel">
<a href="http://domainincite.com/about">Jeff Schmidt</a>,
January 8, 2014,
<a href="http://domainincite.com/category/domain-technology" title="View all posts in Domain Tech" rel="category tag">Domain Tech</a>
</div><p><strong><em>This is a guest post written by Jeff Schmidt, CEO of
JAS Global Advisors LLC. JAS is currently authoring a “Name Collision
Occurrence Management Framework” for the new gTLD program under contract
with ICANN.</em></strong></p><p>One of JAS’ commitments during this process was to “float” ideas and
solicit feedback. This set of thoughts poses an alternative to the
“trial delegation” proposals in <a href="http://www.icann.org/en/groups/ssac/documents/sac-062-en.pdf" title="ICANN" target="_blank">SAC062</a>. The idea springs from past DNS-related experiences and has an effect we have named “controlled interruption.”</p><p><strong>Learning from the Expired Registration Recovery Policy</strong></p><p>Many are familiar with the infamous Microsoft Hotmail domain
expiration in 1999. In short, a Microsoft registration for <a href="http://passport.com">passport.com</a>
(Microsoft’s then-unified identity service) expired Christmas Eve 1999,
denying millions of users access to the Hotmail email service (and
several other Microsoft services) for roughly 20 hours. </p><p>Fortunately, a well-intended technology consultant recognized the
problem and renewed the registration on Microsoft’s behalf, yielding a
nice “thank you” from Microsoft and Network Solutions. Had a bad actor
realized the situation, the outcome could have been far different. </p><p>The Microsoft Hotmail case and others like it lead to the current <a href="http://www.icann.org/en/resources/registrars/consensus-policies/errp" title="ICANN" target="_blank">Expired Registration Recovery Policy</a>. </p><p>More recently, Regions Bank <a href="http://www.al.com/business/index.ssf/2013/04/regions_domain_issue_impacted.html" target="_blank">made news</a>
when its domains expired, and countless others go unreported. In the
case of Regions Bank, the Expired Registration Recovery Policy seemed to
work exactly as intended – the interruption inspired immediate action
and the problem was solved, resulting in only a bit of embarrassment. </p><p>Importantly, there was no opportunity for malicious activity.</p><p>For the most part, the Expired Registration Recovery Policy is
effective at preventing unintended expirations. Why? We call it the
application of “controlled interruption.” </p><p>The Expired Registration Recovery Policy calls for extensive
notification before the expiration, then a period when “the existing DNS
resolution path specified by the Registrant at Expiration (“RAE”) must
be interrupted” – as a last-ditch effort to inspire the registrant to
take action.</p><p>Nothing inspires urgent action more effectively than service interruption.</p><p>But critically, in the case of the Expired Registration Recovery
Policy, the interruption is immediately corrected if the registrant
takes the required action — renewing the registration. </p><p>It’s nothing more than another notification attempt – just a more
aggressive round after all of the passive notifications failed. In the
case of a registration in active use, the interruption will be
recognized immediately, inspiring urgent action. Problem solved.</p><p>What does this have to do with collisions?</p><p><strong>A Trial Delegation Implementing Controlled Interruption</strong></p><p>There has been a lot of talk about various “trial delegations” as a
technical mechanism to gather additional data regarding collisions
and/or attempt to notify offending parties and provide self-help
information. <a href="http://www.icann.org/en/groups/ssac/documents/sac-062-en.pdf" title="ICANN" target="_blank">SAC062</a> touched on the technical models for trial delegations and the related issues.</p><p>Ideally, the approach should achieve these objectives:</p>
<ul>
<li>Notifies systems administrators of possible improper use of the global DNS;</li>
<li>Protects these systems from malicious actors during a “cure period”;</li>
<li>Doesn’t direct potentially sensitive traffic to Registries, Registrars, or other third parties; </li>
<li>Inspires urgent remediation action; and</li>
<li>Is easy to implement and deterministic for all parties.</li>
</ul><p>Like unintended expirations, collisions are largely a notification
problem. The offending system administrator must be notified and take
action to preserve the security and stability of their system.</p><p>One approach to consider as an alternative trial delegation concept
would be an application of controlled interruption to help solve this
notification problem. The approach draws on the effectiveness of the
Expired Registration Recovery Policy with the implementation looking
like a modified “Application and Service Testing and Notification (Type
II)” trial delegation as proposed in SAC62.</p><p>But instead of responding with pointers to application layer
listeners, the authoritative nameserver would respond with an address
inside 127/8 — the range reserved for localhost. This approach could be
applied to A queries directly and MX queries via an intermediary A
record (the vast majority of collision behavior observed in DITL data
stems from A and MX queries).</p><p>Responding with an address inside 127/8 will likely break any
application depending on a NXDOMAIN or some other response, but
importantly also prevents traffic from leaving the requestor’s network
and blocks a malicious actor’s ability to intercede.</p><p>In the same way as the Expired Registration Recovery Policy calls for
“the existing DNS resolution path specified by the RAE [to] be
interrupted”, responding with localhost will hopefully inspire immediate
action by the offending party while not exposing them to new malicious
activity.</p><p>If legacy/unintended use of a DNS name is present, one could think of
controlled interruption as a “buffer” prior to use by a legitimate new
registrant. This is similar to the CA Revocation Period as proposed in
the New gTLD Collision Occurrence Management Plan which “buffers” the
legacy use of certificates in internal namespaces from new use in the
global DNS. Like the CA Revocation Period approach, a set period of
controlled interruption is deterministic for all parties.</p><p>Moreover, instead of using the typical 127.0.0.1 address for localhost, we could use a “flag” IP like 127.0.53.53. </p><p>Why? While troubleshooting the problem, the administrator will likely
at some point notice the strange IP address and search the Internet for
assistance. Making it known that new TLDs may behave in this fashion
and publicizing the “flag” IP (along with self-help materials) may help
administrators isolate the problem more quickly than just using the
common 127.0.0.1. </p><p>We could also suggest that systems administrators proactively search
their logs for this flag IP as a possible indicator of problems.</p><p>Why the repeated 53? Preserving the 127.0/16 seems prudent to make
sure the IP is treated as localhost by a wide range of systems; the
repeated 53 will hopefully draw attention to the IP and provide another
hint that the issue is DNS related.</p><p>Two controlled interruption periods could even be used — one phase
returning 127.0.53.53 for some period of time, and a second slightly
more aggressive phase returning 127.0.0.1. Such an approach may cover
more failure modes of a wide variety of requestors while still providing
helpful hints for troubleshooting. </p><p>A period of controlled interruption could be implemented before
individual registrations are activated, or for an entire TLD zone using a
wildcard. In the case of the latter, this could occur simultaneously
with the CA Revocation Period as described in the <a href="http://www.icann.org/en/groups/board/documents/resolutions-new-gtld-annex-1-07oct13-en.pdf" title="ICANN" target="_blank">New gTLD Collision Occurrence Management Plan</a>. </p><p>The ability to “schedule” the controlled interruption would further mitigate possible effects. </p><p>One concern in dealing with collisions is the reality that a
potentially harmful collision may not be identified until months or
years after a TLD goes live — when a particular second level string is
registered. </p><p>A key advantage to applying controlled interruption to all second
level strings in a given TLD in advance and at once via wildcard is that
most failure modes will be identified during a scheduled time and
before a registration takes place.</p><p>This has many positive features, including easier troubleshooting and
the ability to execute a far less intrusive rollback if a problem does
occur. From a practical perspective, avoiding a complex string-by-string
approach is also valuable.</p><p>If there were to be a catastrophic impact, a rollback could be
implemented relatively quickly, easily, and with low risk while the
impacted parties worked on a long-term solution. A new registrant and
associated new dependencies would likely not be adding complexity at
this point.</p><p><strong>Request for Feedback</strong></p><p>As stated above, one of JAS’ commitments during this process was to
“float” ideas and solicit feedback early in the process. Please
consider these questions:</p>
<ul>
<li>What unintended consequences may surface if localhost IPs are served in this fashion?</li>
<li>Will serving localhost IPs cause the kind of visibility required to inspire action?</li>
<li>What are the pros and cons of a “TLD-at-once” wildcard approach running simultaneously with the CA Revocation Period?</li>
<li>Is there a better IP (or set of IPs) to use?</li>
<li>Should the controlled interruption plan described here be included as part of the mitigation plan? Why or why not?
</li>
<li>To what extent would this methodology effectively address the perceived problem?</li>
<li>Other feedback?</li>
</ul><p>We anxiously await your feedback — in comments to this blog, on the
DNS-OARC Collisions list, or directly. Thank you and Happy New Year!</p><div apple-content-edited="true">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; display: inline !important; float: none; ">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.)</span>
</div>
<br></div></body></html>