[DNSOP] Unusual behavior (wildcarding) on .cn TLD

Nicholas Weaver <nweaver@ICSI.Berkeley.EDU> Fri, 30 October 2009 18:53 UTC

Return-Path: <nweaver@ICSI.Berkeley.EDU>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B34FE3A6823 for <dnsop@core3.amsl.com>; Fri, 30 Oct 2009 11:53:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.11
X-Spam-Level:
X-Spam-Status: No, score=-5.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mIbmo9K0y4qj for <dnsop@core3.amsl.com>; Fri, 30 Oct 2009 11:53:48 -0700 (PDT)
Received: from fruitcake.ICSI.Berkeley.EDU (fruitcake.ICSI.Berkeley.EDU [192.150.186.11]) by core3.amsl.com (Postfix) with ESMTP id B3BA93A6767 for <dnsop@ietf.org>; Fri, 30 Oct 2009 11:53:48 -0700 (PDT)
Received: from [IPv6:::1] (jack.ICSI.Berkeley.EDU [192.150.186.73]) by fruitcake.ICSI.Berkeley.EDU (8.12.11.20060614/8.12.11) with ESMTP id n9UIrMEO028017; Fri, 30 Oct 2009 11:54:05 -0700 (PDT)
Content-Transfer-Encoding: 7bit
From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Content-Type: text/plain; charset="us-ascii"; format="flowed"; delsp="yes"
Message-Id: <DDC29F8F-CD6F-4A1C-826D-FB5FE6733CCA@ICSI.Berkeley.EDU>
Date: Fri, 30 Oct 2009 11:54:06 -0700
To: dnsop@ietf.org
Mime-Version: 1.0 (Apple Message framework v1076)
X-Mailer: Apple Mail (2.1076)
Cc: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
Subject: [DNSOP] Unusual behavior (wildcarding) on .cn TLD
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Oct 2009 18:53:49 -0000

apologies if this isn't the correct list...


Has anyone else observed the following behavior for the .cn TLD, where  
one authoritative server (NS.CERNET.NET) wildcards invalid domains,  
but the others (a-e.dns.cn) do not?

Anyone know someone operationally involved with the .cn TLD to know if  
this is deliberate and, if so, why?

The authority for .cn (in this case, from g.root-servers.net) is:

(reordered for readability)
cn.                     172800  IN      NS      A.DNS.cn.
cn.                     172800  IN      NS      B.DNS.cn.
cn.                     172800  IN      NS      C.DNS.cn.
cn.                     172800  IN      NS      D.DNS.cn.
cn.                     172800  IN      NS      E.DNS.cn.
cn.                     172800  IN      NS      NS.CERNET.NET.

with IPs 203.119.{25-29}.1 for {a-e}.dns.cn and 202.112.0.44 for ns.cernet.net

A nice little foreach loop shows the behavior for me (from ICSI):

foreach foo ( 203.119.25.1 203.119.26.1 203.119.27.1 203.119.28.1  
203.119.29.1 202.112.0.44 )
  foreach? echo "Looking up a bad name at $foo"
  foreach? dig +short +norecurse www.aoeuantoheuntahoeutn.cn @$foo
  foreach? end

Looking up a bad name at 203.119.25.1
Looking up a bad name at 203.119.26.1
Looking up a bad name at 203.119.27.1
;; connection timed out; no servers could be reached
Looking up a bad name at 203.119.28.1
Looking up a bad name at 203.119.29.1
;; connection timed out; no servers could be reached
Looking up a bad name at 202.112.0.44
159.226.7.162


NS.CERNET.NET seems to be deliberately wildcarding items which are  
otherwise NXDOMAIN, and returning the a record of a server they  
control.  But it is ONLY this nameserver, not all nameserver for .cn.