[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