All,
I fully understand we are scheduled to hold an interim meeting tomorrow and
have a Iot to think about but am hoping at least a handful of you may have a
cycle or two left in you to look at our updated draft (-05).
We welcome _any_ feedback on the draft as we are hoping to have it (or some
incarnation) adopted by the WG soon and look to rally more interest around it.
We've seen a lot of recent need to address the issues this draft attempts to
solve and hope others on this list have as well. We've also provided a short
Mini-FAQ to help determine if you feel it may be of interest and worth a look.
Many thanks,
John
----------------------------------------------------------
** I-D "BULK DNS Resource Records" Mini-FAQ 01-31-17 **
----------------------------------------------------------
Q) Why do we need BULK RRs?
A) BULK is a tool like many others.
It was designed to help simplify the management of
pattern based "generic" records and scale to fit the
growing demand of IPv6 support. It builds on popular
technology currently used today while providing a
number of modern enhancements. The authors feel BULK
is the next logical progression of what is already
field-proven and accepted in the industry today.
Q) Does BULK cover all RR types?
A) No. The draft only covers A, AAAA, PTR and CNAME RR types.
Q) What happens if there are other RRs which fall inside
a BULK pattern range?
A) BULK records can only exist where other records do not,
a concept referred to as "Record Superimposition" [5.1]
Q) Can BULK generated RRs be DNSSEC validated.
A) The draft offers two DNSSEC solutions, on-the-fly
generated signatures and a pattern based solution in
the form of a support NPN RR type (included in the draft).
Q) Is BULK only for IPv6 namespace?
A) No, BULK is intended to simplify management of both IPv4
and IPv6 "generic" records.
Q) Why not just script these ranges, use $GENERATE or
simply forbid the larger ones?
A) Two fundamental goals behind BULK are to be able to
provide the same capability behind scripting and
$GENERATEs without the memory requirements and
be able to transfer the zone maintainer's "intent".
For example, when you transfer RRs managed by a script
or $GENERATE the receiver gets "all" records and not
the shorthand used to create them. BULK transfers
this intent so the copy looks just like the original.
Several DNS Software Vendors are already providing
this capability in a proprietary manner, BULK offers
an open "standard" way to exchange these records
which scales to fit any size.
Q) BULK syntax looks like regular expression, isn't that
a bit too complicated?
A) BULK does offer advanced regular-expression-esque
backreferences but in a simplified manner. In fact,
the "star" backreference will work fine in most
scenarios (e.g. "member-${*}.example.com."). NAPTR
RRs currently provide client-assisted regular-
expression pattern substitution so BULK leverages
a familiar "feel" while also providing some of the
heavy lifting.
--
-----Original Message-----
Subject: New Version Notification for draft-woodworth-bulk-rr-05.txt
From: [email protected] [mailto:[email protected]]
A new version of I-D, draft-woodworth-bulk-rr-05.txt has been successfully
submitted by John Woodworth and posted to the IETF repository.
Name: draft-woodworth-bulk-rr
Revision: 05
Title: BULK DNS Resource Records
Document date: 2017-02-15
Group: Individual Submission
Pages: 32
URL:
https://www.ietf.org/internet-drafts/draft-woodworth-bulk-rr-05.txt
Status: https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/
Htmlized: https://tools.ietf.org/html/draft-woodworth-bulk-rr-05
Diff: https://www.ietf.org/rfcdiff?url2=draft-woodworth-bulk-rr-05
Abstract:
The BULK DNS resource record type defines a method of pattern based
creation of DNS resource records to be used in place of NXDOMAIN
errors which would normally be returned. These records are currently
restricted to registered DNS resource record types A, AAAA, PTR and
CNAME. The key benefit of the BULK resource record type is the
simplification of maintaining "generic" record assignments which
would otherwise be too many to manage or require scripts or
proprietary methods as bind's $GENERATE.
This document updates RFCs 2308, 4033, 4034 and 4035.
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
The IETF Secretariat
-- THESE ARE THE DROIDS TO WHOM I REFER:
This communication is the property of CenturyLink and may contain confidential
or privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful. If you have received this communication in
error, please immediately notify the sender by reply e-mail and destroy all
copies of the communication and any attachments.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
