[NCAP-Discuss] Fwd: AGENDA: 24 April 2019

James Galvin jgalvin at afilias.info
Wed Apr 24 19:58:14 UTC 2019


I’m forwarding this on behalf of Steve Crocker for consideration by 
the discussion group.



Forwarded message:

> From: Steve Crocker <steve at shinkuro.com>
> Date: Tue, 23 Apr 2019 19:11:00 -0400


>
> Jim,
>
> Thanks for the agenda and thanks to you and Jay for chairing this 
> group.
>
> I've spent time on this topic over the years, so I'll offer some 
> thoughts
> right away.
>
> It should be possible to define name collisions and explain them 
> clearly
> for those who are not familiar with the phenomenon fairly quickly.  I
> recommend this be done right away, prior to the three goals listed.  
> This
> will be a qualitative, not quantitative, description and hence would 
> not
> include any statement or measure of how much damage is caused by
> collisions.  Instead it would provide a straightforward framework to 
> build
> on.  This should not take six months and should not take a lot of 
> money.
>
> Let me go a bit further and attempt a very short description.
>
> Over the years, several strings have appeared as if they were top 
> level
> names and have shown up in queries to the root even though these 
> strings
> have never been delegated.  The most common examples are corp, home, 
> mail,
> local, localhost, example, belkin <<edit this list as needed.>>  
> Queries to
> the root that end with one of these names are responded with the DNS
> protocol NXDOMAIN, i.e. this domain does not exist.
>
> The reasons these names occur so frequently are somewhat varied and 
> are
> mentioned below, but the reason these require attention is because 
> they
> have been requested as official top level domains.  That is, there are
> business interests that wish to have some of these strings delegated 
> to
> them so they can run a registry.
>
> As mentioned queries ending with these  strings are already occurring. 
>  If
> these strings were to be delegated, such queries would be directed to 
> the
> registry, thus changing behavior seen by the systems that generate 
> those
> queries.  It would also provide a channel for the delegated registry 
> to
> respond to the systems generating the queries, with potentially 
> negative
> effects.  Finally, but probably less important, it would impose a load 
> on
> the registry.
>
> As mentioned, the reasons for such queries are a bit varied, but 
> what's
> common in all cases is the queries are the result of some form of
> configuration error in the querying systems.  In the case of belkin, 
> some
> of their products were sold with .belkin configured into their 
> software in
> a way that caused erroneous queries to leak onto the public Internet.  
> In
> the case of .corp, the configuration manuals for the products from 
> major
> companies instructed system administrators to use .corp as an 
> enterprise
> level internal top level domain, and these systems also leaked queries 
> onto
> the public Internet.
>
> An added complication is many systems have scripts that try a sequence 
> of
> queries.  When the NXDOMAIN is received in response to an erroneous 
> query
> sent over the public Internet, the querying system moves along to the 
> next
> query in its script.
>
> Delegation of strings that are appearing in numerous erroneous queries 
> has
> the potential of causing harm to the system that are generating these
> queries.  There are roughly four courses of action:
>
>
>    1. Refuse to delegate the string and leave things as they are.
>
>    2. Reduce or eliminate the erroneous queries by changing the
>    configurations of the systems that generate these queries.
>
>    3. Make a determination that although delegation would change the 
> status
>    quo, the resulting harm would be acceptable.
>
>    4. Determine if there is a way to configure the registry to process
>    erroneous requests so as to avoid harming the offending systems.
>
> Combinations of 2, 3 and 4 might be possible, and the course of action
> might be different for each string.  Significant study and possible
> experimentation is required, although there have been previous studies 
> of
> some of these.
>
> In addition to the technical issues involved, this work requires 
> exploring
> a policy question that has never been dealt with directly.  In prior
> delegation of new top level domains, there was an implicit 
> understanding
> that these names were fresh, i.e. had not been in use.  With requests
> pending for names that have not been delegated but are nonetheless in 
> use,
> ICANN is faced will have to develop a policy.  This group may be able 
> to
> assemble the facts related to the causes of erroneous queries for each
> string and the potential methods of mitigation, i.e. actions 2 or 4, 
> but
> unless there is a way to reduce the level and causes of erroneous 
> queries
> for these strings to the same level as for delegated TLD strings, 
> ICANN Org
> and the community will have to developed a policy that balances 
> competing
> interests.
>
> Cheers,
>
> Steve
>
>
> On Tue, Apr 23, 2019 at 6:10 PM James Galvin <jgalvin at afilias.info> 
> wrote:
>
>> Hello and welcome from one of your co-chairs.  Jay Daley is the 
>> other.
>> We’ll introduce ourselves tomorrow during our first meeting.
>>
>> Here is the agenda:
>>
>> 1.  Introduction from the co-chairs and staff
>> - who we are
>> - how this discussion group will be managed
>> - SOIs
>>
>> 2.  Introduction from discussion group members
>>
>> 3.  Introduction to NCAP
>> - three studies
>> - roles of OCTO / SSAC / Discussion Group
>> - defining a name collision
>>
>> 4.  Current work
>> - RFP being drafted
>> - required output of study 1
>>
>> Attached to this document is the text we need to review and will be
>> discussion in item 4 above.  I’ve also attached it as a PDF to make
>> sure everyone can read it.
>>
>> See you all on Wednesday, 24 April, 2000 UTC.
>>
>> Jim
>> _______________________________________________
>> NCAP-Discuss mailing list
>> NCAP-Discuss at icann.org
>> https://mm.icann.org/mailman/listinfo/ncap-discuss
>>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ncap-discuss/attachments/20190424/d6d2ffb1/attachment.html>


More information about the NCAP-Discuss mailing list