[PC-NCSG] NXdomains issue
Avri Doria
avri
Wed Aug 7 16:20:11 EEST 2013
Another interesting report:
http://techreports.verisignlabs.com/tr2/docs/tr-1130008-1.pdf
And I recommend the 5 part series:
http://www.circleid.com/posts/20130624_introduction_new_gtld_security_and_stability_considerations_part_1/
http://www.circleid.com/posts/20130626_internet_infrastructure_stability_at_core_innovation_edge_part_2/
http://www.circleid.com/posts/20130628_name_collisions_why_every_enterprise_should_care_part_3_of_5/
http://www.circleid.com/posts/20130731_nxdomains_ssacs_sac045_and_new_gtlds_part_4_of_5/
http://www.circleid.com/posts/20130806_new_gtld_ssr_2_exploratory_consumer_impact_analysis_part_5_of_5/
On 6 Aug 2013, at 14:07, Avri Doria wrote:
> Hi,
>
> This changes the call for an issues report. While ICANN is making recommendations, there may be call for the GNSO to do some policy as well.
>
> then again, maybe not.
>
> avri
>
> On 6 Aug 2013, at 12:12, Avri Doria wrote:
>
>>
>>
>>
>> The long awaited ICANN report on name colisions
>>
>> https://www.icann.org/en/news/announcements/announcement-3-05aug13-en.htm
>>
>> On 6 Aug 2013, at 10:27, Avri Doria wrote:
>>
>>> Hi,
>>>
>>> the issue to mention is probably:
>>>
>>> from SSAC 45
>>>
>>>
>>> Recommendation (2): The SSAC recommends that ICANN consider the following in
>>> the context of the new gTLD program.
>>>
>>> ? Prohibit the delegation of certain TLD strings. RFC 2606, ?Reserved Top Level
>>> Domain Names,? currently prohibits a list of strings, including test, example,
>>> invalid, and localhost.4 ICANN should coordinate with the community to
>>> Invalid Top Level Domain Queries at the Root Level of the Domain Name System
>>> identify a more complete set of principles than the amount of traffic observed at the
>>> root as invalid queries as the basis for prohibiting the delegation of additional strings
>>> to those already identified in RFC 2606.
>>>
>>> ? Alert the applicant during the string evaluation process about the pre-existence of
>>> invalid TLD queries to the applicant?s string. ICANN should coordinate with the
>>> community to identify a threshold of traffic observed at the root as the basis for such
>>> notification.
>>>
>>> ? Define circumstances where a previously delegated string may be re-used, or prohibit
>>> the practice.
>>>
>>>
>>> Now they are requesting that IETF do the work, but it is the GNSO that does recommendations to the reserved names list from a policy POV.
>>>
>>> We are already doing work on reserved names in the case of IOG-INGO. This seems like ti may be a bit more important.
>>>
>>> At least we need to understand the fulll extent of the situation so that GNSO can decide what, if anything, need to be done.
>>>
>>> avri
>>>
>>> On 4 Aug 2013, at 15:36, Rafik Dammak wrote:
>>>
>>>> Hi Avri,
>>>>
>>>> +1 for requesting issue report to start the process and to have some substantive information policy impact. and it will be great to have David with his tech knowledge to lead that within gnso council and to be able to respond to any kind of usual fallacious comments there. btw the ISPPC supposed looking for stability should be a natural allies about this question?
>>>> was there any discussion within IETF about that issue? I am not sure but I thought that IAB expressed concern before?
>>>> there was strong push and bypass for reserved names for IOC and RC to prevent the "fall of gnso" , lets help to prevent the "fall on the internet" ;)
>>>>
>>>> Best,
>>>>
>>>> Rafik
>>>>
>>>> 2013/8/4 Avri Doria <avri at acm.org>
>>>> Hi,
>>>>
>>>> Well it seems like it has to be a GNSO Policy issue to me.
>>>>
>>>> WG are open to all. the first step would be to request an issues report.
>>>>
>>>> Is the NCSG ready to be at the center of another storm? In this case, it really does not affect us, we are neither responsible for putting names in the root, nor are we applicants for these names. Yet this is another part of the reserved name policy issue.
>>>>
>>>> I have had conversations with both sides on this issue (Donut and Verisign). I do not beleive that Verisign is making noise just because of protecting incumbency - they are a backend to many names and stand to lose as much as any by delays.
>>>>
>>>>
>>>> On the other hand it is an issue, as you say that the GAC has grabbed hold of. I do not want to the see the board making preemptory policy decisions that run counter to previous GNSO policy issues.
>>>>
>>>> Personally, while I was skeptical about this issue at first, I have done some delving and now see it as an unfortunate consequence of early protocol development that put session layer type of functionality in DNS. This was compounded by microsoft (at least in the case of .corp) using .corp instead of .example (.yourcompanyname as an example in their setup instruction for servers and reinforced by the habit of people to follow examples as if they were recipes.
>>>>
>>>> I recommend that our council members look into this issue and consider putting together a motion for an issues request. Lets get beyondd the FUD and accusations and figure out whether there is something that needs to be done.
>>>>
>>>> avri
>>>>
>>>>
>>>> On 4 Aug 2013, at 09:35, Rafik Dammak wrote:
>>>>
>>>>> Hi Avri,
>>>>>
>>>>> did SSAC have updates about those issues to GNSO council in several meetings and asked for specific actions?
>>>>> my understanding that it brought the issue to GAC in durban, so it I definitely a political issue. SSAC also presented their coming report about name collision in durban (report not published yet)
>>>>> can be this initiated through a corss-community WG including GNSO, SSAC, ALAC even we know that will take time to act ?
>>>>>
>>>>> Best,
>>>>>
>>>>> Rafik
>>>>>
>>>>>
>>>>> 2013/8/3 Avri Doria <avri at acm.org>
>>>>> Hi
>>>>>
>>>>> The whole NXdomains colliding with new domain names issue seems to be begging as a policy issue.
>>>>>
>>>>> SSAC45 came out in 2010 and should have triggered a GNSO policy action. But I think we slept through the warning.
>>>>> We had finished the work of reserved names around 2006 and then never looked back except in terms of RCRC and IOC. Given the issues now coming up, perhaps something needs to be done.
>>>>>
>>>>> Now Verisign is raising the issue again and it is becoming a very political issue.
>>>>>
>>>>> When the issue first came up, i think even on the list, I was not sure what we should be doing. I am still not sure what we should be doing, but am sure we have to do something. Or the BoardStaff in it infinite wisdom will again make a decision none of us are comfortable with.
>>>>>
>>>>> avri
>>>>>
>>>>> Interesting article at: http://www.circleid.com/account/login/posts/20130731_nxdomains_ssacs_sac045_and_new_gtlds_part_4_of_5
>>>>>
>>>>> And an IETF note
>>>>>
>>>>> From RFC 6762
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Appendix G. Private DNS Namespaces
>>>>>
>>>>>
>>>>> The special treatment of names ending in ".local." has been
>>>>> implemented in Macintosh computers since the days of Mac OS 9, and
>>>>> continues today in Mac OS X and iOS. There are also implementations
>>>>> for Microsoft Windows [
>>>>> B4W
>>>>> ], Linux, and other platforms.
>>>>>
>>>>> Some network operators setting up private internal networks
>>>>> ("intranets") have used unregistered top-level domains, and some may
>>>>> have used the ".local" top-level domain. Using ".local" as a private
>>>>> top-level domain conflicts with Multicast DNS and may cause problems
>>>>> for users. Clients can be configured to send both Multicast and
>>>>> Unicast DNS queries in parallel for these names, and this does allow
>>>>> names to be looked up both ways, but this results in additional
>>>>> network traffic and additional delays in name resolution, as well as
>>>>> potentially creating user confusion when it is not clear whether any
>>>>> given result was received via link-local multicast from a peer on the
>>>>> same link, or from the configured unicast name server. Because of
>>>>> this, we recommend against using ".local" as a private Unicast DNS
>>>>> top-level domain. We do not recommend use of unregistered top-level
>>>>> domains at all, but should network operators decide to do this, the
>>>>> following top-level domains have been used on private internal
>>>>> networks without the problems caused by trying to reuse ".local." for
>>>>> this purpose:
>>>>>
>>>>> .intranet.
>>>>> .internal.
>>>>> .private.
>>>>> .corp.
>>>>> .home.
>>>>> .lan.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> PC-NCSG mailing list
>>>>> PC-NCSG at ipjustice.org
>>>>> http://mailman.ipjustice.org/listinfo/pc-ncsg
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> PC-NCSG mailing list
>>>>> PC-NCSG at ipjustice.org
>>>>> http://mailman.ipjustice.org/listinfo/pc-ncsg
>>>>
>>>>
>>>> _______________________________________________
>>>> PC-NCSG mailing list
>>>> PC-NCSG at ipjustice.org
>>>> http://mailman.ipjustice.org/listinfo/pc-ncsg
>>>>
>>>> _______________________________________________
>>>> PC-NCSG mailing list
>>>> PC-NCSG at ipjustice.org
>>>> http://mailman.ipjustice.org/listinfo/pc-ncsg
>>>
>>>
>>> _______________________________________________
>>> PC-NCSG mailing list
>>> PC-NCSG at ipjustice.org
>>> http://mailman.ipjustice.org/listinfo/pc-ncsg
>>
>>
>> _______________________________________________
>> PC-NCSG mailing list
>> PC-NCSG at ipjustice.org
>> http://mailman.ipjustice.org/listinfo/pc-ncsg
>
>
> _______________________________________________
> PC-NCSG mailing list
> PC-NCSG at ipjustice.org
> http://mailman.ipjustice.org/listinfo/pc-ncsg
More information about the NCSG-PC
mailing list