[PC-NCSG] NXdomains issue

Sun Aug 4 14:25:30 EEST 2013

I think this issue is a real one.
SSAC45 fairly indicates there is an issue, but not the solution. SSAC57 indicates that the implications of SSAC45 are significantly worse than we thought at the time.  There may not be a one size fits all solution. Some names that are going through to the root may well be effectively mitigated (for example, I believe there are a lot of queries for .ice, but these can probably be almost entirely traced to equipment configured by a single electricity provider). But for the major problematic ones, .home and .corp etc. I am gradually coming to the conclusion that there is not much that can be done. Compound it with the cert issue, and it is a big security problem that is juicy enough that exploitation is likely if they are ever delegated (and could be occurring already, for all we know, but could be far more exploitable if delegated as a new gTLD). 

I'm vaguely surprised that there aren't reserved names set aside for purely internal use, the DNS equivalents of 192.168 etc. Possibly that was what .local was originally intended for, but now it is used for mDNS. 

On 04/08/2013, at 4:35 PM, Avri Doria <avri at acm.org> wrote:

> 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.
> 

	My feeling is that we would get strong support from CSG on this one, who have already made a few comments. So I don't think we would be too near the centre of the storm. 

> 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.

I am finding myself in sympathy with Verisign on this one. 

> 
> 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.

	This issue needs some nuanced technical examination, and we certainly won't get it from the GAC. 
	I personally believe that non-delegation of .home and .corp would be a sensible outcome, disappointing as that would be for Donuts etc. But there could be effective mitigation strategies based on looking at the current 2TLD queries etc. I think delegation without a serious look at the problems identified by SSAC would be a policy failure. 

> 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'm not sure if I'd exactly say it is due to session layer stuff in the DNS (though I'll certainly yield to your far greater knowledge of protocol design), but certainly the close relationship between session layer protocols like TLS/SSL and the DNS is an important part of the problem. 

> 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.

	I've been thinking about how to deal with this issue myself. Thank you Avri for suggesting the appropriate process. I'd be happy to suggest an issues report. 
	Regards
		David

> 
> 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