Content-Transfer-Encoding: base64
User-Agent: Microsoft-MacOutlook/f.23.0.170610
Content-Language: en-US
Spamdiagnosticmetadata: NSPM
Content-ID: <882640C385028441A2433D8E70880B06@namprd04.prod.outlook.com>
Message-ID: <E42BF11A-864A-4D35-A9A2-EDAE564779E7@cornell.edu>
To: "bind-bugs@isc.org" <bind-bugs@isc.org>
X-MS-Exchange-Crosstenant-Fromentityheader: Hosted
From: "Jim Yang" <zy33@cornell.edu>
X-MS-Traffictypediagnostic: DM5PR04MB0571:
content-type: text/plain; charset="utf-8"
Thread-Index: AQHS8Q9iO1lX1oxYgkSSWp/3SVVIeg==
X-MS-Has-Attach: 
X-Forefront-PRVS: 0353563E2B
Spamdiagnosticoutput: 1:99
CC: "Mukund Sivaraman" <muks@isc.org>
From zy33@cornell.edu  Thu Jun 29 19:39:29 2017
X-MS-Exchange-Crosstenant-Originalarrivaltime: 29 Jun 2017 19:39:12.3704 (UTC)
X-Cornellrouted: This message has been Routed already.
X-Org-Msgsource: exchange
Thread-Topic: BIND bug report
Subject: BIND bug report
Return-Path: <zy33@cornell.edu>
X-RT-Incoming-Encryption: Not encrypted
X-Org-Routeonprem: False
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.pao1.isc.org", Issuer "COMODO RSA Organization Validation Secure Server CA" (not verified)) by bugs.isc.org (Postfix) with ESMTPS id 36E93D78A9D for <bind9-bugs@bugs.isc.org>; Thu, 29 Jun 2017 19:39:29 +0000 (UTC)
Received: from limerock01.mail.cornell.edu (limerock01.mail.cornell.edu [128.84.13.241]) by mx.pao1.isc.org (Postfix) with ESMTP id C0733349315; Thu, 29 Jun 2017 19:39:25 +0000 (UTC)
Received: from exchange.cornell.edu (sf-e2013-08.exchange.cornell.edu [10.22.40.55]) by limerock01.mail.cornell.edu (8.14.4/8.14.4_cu) with ESMTP id v5TJdFoD020948; Thu, 29 Jun 2017 15:39:24 -0400
Received: from sf-e2013-07.exchange.cornell.edu (10.22.40.54) by sf-e2013-08.exchange.cornell.edu (10.22.40.55) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 29 Jun 2017 15:39:14 -0400
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (216.32.181.18) by sf-e2013-07.exchange.cornell.edu (10.22.40.54) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Thu, 29 Jun 2017 15:39:13 -0400
Received: from DM5PR04MB0571.namprd04.prod.outlook.com (10.173.170.140) by DM5PR04MB0571.namprd04.prod.outlook.com (10.173.170.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.11; Thu, 29 Jun 2017 19:39:12 +0000
Received: from DM5PR04MB0571.namprd04.prod.outlook.com ([10.173.170.140]) by DM5PR04MB0571.namprd04.prod.outlook.com ([10.173.170.140]) with mapi id 15.01.1220.014; Thu, 29 Jun 2017 19:39:12 +0000
X-MS-Publictraffictype: Email
Authentication-Results: isc.org; dkim=none (message not signed) header.d=none;isc.org; dmarc=none action=none header.from=cornell.edu;
X-MS-Exchange-Crosstenant-ID: 5d7e4366-1b9b-45cf-8e79-b14b27df46e1
Accept-Language: en-US
X-MS-Exchange-Transport-Crosstenantheadersstamped: DM5PR04MB0571
X-MS-Tnef-Correlator: 
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org
X-Original-To: bind9-bugs@bugs.isc.org
X-Originating-Ip: [2620:110:d000:1:5e2:4e43:8cde:53ac]
X-Microsoft-Antispam-PRVS: <DM5PR04MB0571F272FB44895076E60945D6D20@DM5PR04MB0571.namprd04.prod.outlook.com>
X-PMX-Cornell-Auth-Results: dkim-out=pass;
Date: Thu, 29 Jun 2017 19:39:12 +0000
MIME-Version: 1.0
X-RT-Original-Encoding: utf-8
X-RT-Interface: Email
Content-Length: 3516

Hi,

As per Mukund Sivaraman’s suggestion, I am reporting a bug in BIND. This name “sign.encoding.information.uzmzudseodc2fjpyi6mjcxndiymtuzmzufazdseyi6swh58fmodc2fjqxoc2fjp.chinaboca.com” was successfully loaded into a RPZ zone. 
The label “uzmzudseodc2fjpyi6mjcxndiymtuzmzufazdseyi6swh58fmodc2fjqxoc2fjp” is 64 bytes long (> label limit 63 bytes RFC 1035)

The sample RPZ zone is listed below.

$ORIGIN rpz.example.com.
      $TTL 1H
      @               SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h)
                      NS  LOCALHOST.
 
      ; QNAME policy records.
      ; Note: There are no periods (.) after the (relativised) owner names.
 
sign.encoding.information.uzmzudseodc2fjpyi6mjcxndiymtuzmzufazdseyi6swh58fmodc2fjqxoc2fjp.chinaboca.com      A       10.0.0.1      ; redirect to walled garden
                          AAAA    2001:2::1


named-checkconf does not report any error about this name.


I tested the name using 8.8.8.8 on both Centos 7 and Macbook Pro macOS Sierra.
The dig version on Centos 7 is 9.9.4-RedHat-9.9.4-38.el7_3.2 and it always gives ‘NXDOMAIN’ no matter how long the label I changes (I tested 64, 65, 80 bytes long).



The results from my Macbook Pro are listed below:
The length of uzmzudseodc2fjpyi6mjcxndiymtuzmzufazdseyi6swh58fmodc2fjqxoc2fjp is 64 bytes.

$ dig @8.8.8.8 sign.encoding.information.uzmzudseodc2fjpyi6mjcxndiymtuzmzufazdseyi6swh58fmodc2fjqxoc2fjp.chinaboca.com

; <<>> DiG 9.8.3-P1 <<>> @8.8.8.8 sign.encoding.information.uzmzudseodc2fjpyi6mjcxndiymtuzmzufazdseyi6swh58fmodc2fjqxoc2fjp.chinaboca.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 59096
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;sign.encoding.information.uzmzudseodc2fjpyi6mjcxndiymtuzmzufazdseyi6swh58fmodc2fjqxoc2fjp.chinaboca.com. IN A

;; AUTHORITY SECTION:
chinaboca.com.		1799	IN	SOA	ns9.sinohosting.net. admin.cycomsupport.com. 2017020401 3600 7200 1209600 86400

;; Query time: 108 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Jun 29 15:16:33 2017
;; MSG SIZE  rcvd: 195


The length of uzmzudseodc2fjpyi6mjcxndiymtuzmzufazdseyi6swh58fmodc2fjqxoc2fjp66 is 66 bytes
OIT-ZY33-ML2:~ zy33$ dig sign.encoding.information.uzmzudseodc2fjpyi6mjcxndiymtuzmzufazdseyi6swh58fmodc2fjqxoc2fjp66.chinaboca.com
dig: 'sign.encoding.information.uzmzudseodc2fjpyi6mjcxndiymtuzmzufazdseyi6swh58fmodc2fjqxoc2fjp66.chinaboca.com' is not a legal name (label too long)

dig should report the name is not a legal name when the label length is 64(>63 bytes), but it reports the issue when the label length is 65.


Thanks,
Jim


On 6/29/17, 2:40 PM, "Mukund Sivaraman" <muks@isc.org> wrote:

    Hi Jim
    
    On Thu, Jun 29, 2017 at 01:57:16PM +0000, Jim Yang wrote:
    > Hi,
    > 
    > What is the DNS name label length limit? As per RFC 1035, it is 63
    > characters.  I tested a few DNS names that contains a label that is
    > longer than 63 characters, and found that these records were
    > successfully loaded in RPZ zone. I wonder if this is a BIND RPZ
    > feature or bug (it allows DNS name label that is longer than 63
    > characters)?
    > 
    > When I dig these DNS records using 8.8.8.8, which reports them as
    > ‘NXDOMAIN’.
    
    Can you send us a bug report with a sample RPZ zone that contains such a
    name?
    
    		Mukund