[DNSOP] BULK RR Myth[2] - BULK RRs are only for reverse IPv6
JW <jw@pcthink.com> Mon, 24 April 2017 17:19 UTC
Return-Path: <jw@pcthink.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76AD81318B4 for <dnsop@ietfa.amsl.com>; Mon, 24 Apr 2017 10:19:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O37wzzZonLY5 for <dnsop@ietfa.amsl.com>; Mon, 24 Apr 2017 10:19:17 -0700 (PDT)
Received: from atl4mhob22.registeredsite.com (atl4mhob22.registeredsite.com [209.17.115.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF921318BE for <dnsop@ietf.org>; Mon, 24 Apr 2017 10:19:17 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.205]) by atl4mhob22.registeredsite.com (8.14.4/8.14.4) with ESMTP id v3OHJGHd022166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dnsop@ietf.org>; Mon, 24 Apr 2017 13:19:16 -0400
Received: (qmail 2683 invoked by uid 0); 24 Apr 2017 17:19:16 -0000
X-TCPREMOTEIP: 73.251.233.169
X-Authenticated-UID: jw@pcthink.com
Received: from unknown (HELO ?10.2.1.116?) (jw@pcthink.com@73.251.233.169) by 0 with ESMTPA; 24 Apr 2017 17:19:16 -0000
Date: Mon, 24 Apr 2017 13:19:13 -0400
Message-ID: <ieqih9kvfdmhsmgv0ib3ju1r.1493054353014@email.android.com>
Importance: normal
From: JW <jw@pcthink.com>
To: dnsop@ietf.org
Cc: jw@pcthink.com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_268754493290160"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/2R6typ9eu4uY0da_8RAt0TQTXTA>
Subject: [DNSOP] BULK RR Myth[2] - BULK RRs are only for reverse IPv6
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Mon, 24 Apr 2017 17:19:19 -0000
BULK has many uses and is not limited to IPv6 namespace. BULK RRs are intended to both: - Simplify management of pattern-based RRs (e.g. $GENERATE) - Allow transfer of RR "intention" rather than verbatim RRs While BULK RRs offer a much greater range of pattern-based RRs allowing use to multiple quintillions (even a few undecillions) of IPv6 reverse, their usefulness doesn't stop there. One example of this might be cloud based environments where literally hundreds of resources (iSCSI, compute nodes, etc.) may need hostnames assigned for easy management and functional structuring. Additionally, since BULK RRs can be easily transferred between nameservers without expansion much smaller zone transfers are possible. The draft's authors have seen zones with more than 50MB worth of data (based on $GENERATEs) fail to reliably transfer between nameservers. BULK RRs could make a zone like this much more manageable and reliable across the network and ensure all copies of the zone remain intact. Thanks,John