Re: [DNSOP] DNSOP Digest, Vol 35, Issue 24

"keygold" <jinjian@cnnic.cn> Fri, 30 October 2009 19:46 UTC

Return-Path: <jinjian@cnnic.cn>
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 B2DFF3A68AE for <dnsop@core3.amsl.com>; Fri, 30 Oct 2009 12:46:34 -0700 (PDT)
X-Quarantine-ID: <ya+Hc5fbW4Hk>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID"
X-Spam-Flag: NO
X-Spam-Score: -1.195
X-Spam-Level:
X-Spam-Status: No, score=-1.195 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_53=0.6, MSGID_FROM_MTA_HEADER=0.803, STOX_REPLY_TYPE=0.001]
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 ya+Hc5fbW4Hk for <dnsop@core3.amsl.com>; Fri, 30 Oct 2009 12:46:33 -0700 (PDT)
Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 2555A3A6867 for <dnsop@ietf.org>; Fri, 30 Oct 2009 12:46:32 -0700 (PDT)
Received: (eyou send program); Sat, 31 Oct 2009 03:46:48 +0800
Message-ID: <456932008.28143@cnnic.cn>
X-EYOUMAIL-SMTPAUTH: jinjian@cnnic.cn
Received: from unknown (HELO jianjin) (127.0.0.1) by 127.0.0.1 with SMTP; Sat, 31 Oct 2009 03:46:48 +0800
Message-ID: <90A0CC71C45C4897A0571078201669A7@JianJin>
From: keygold <jinjian@cnnic.cn>
To: dnsop@ietf.org
References: <456929229.28143@cnnic.cn>
In-Reply-To: <456929229.28143@cnnic.cn>
Date: Sat, 31 Oct 2009 03:45:30 +0800
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="original"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Windows Mail 6.0.6001.18000
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18049
Subject: Re: [DNSOP] DNSOP Digest, Vol 35, Issue 24
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 19:46:34 -0000

good news and bad news.

I will check .cn TLD configuration and try to see what on earth happened.

NS.CERNET.NET as a node of .CN  is indeed located in a independent ISP 
network.

As far as I have known, it is not deliberate, I think.



>
> Today's Topics:
>
>   1.  Unusual behavior (wildcarding) on .cn TLD (Nicholas Weaver)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 30 Oct 2009 11:54:06 -0700
> From: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
> Subject: [DNSOP] Unusual behavior (wildcarding) on .cn TLD
> To: dnsop@ietf.org
> Cc: Nicholas Weaver <nweaver@ICSI.Berkeley.EDU>
> Message-ID: <DDC29F8F-CD6F-4A1C-826D-FB5FE6733CCA@ICSI.Berkeley.EDU>
> Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
>
> 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.
>
>
>
> ------------------------------
>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
> End of DNSOP Digest, Vol 35, Issue 24
> *************************************