dnsop J. Woodworth
Internet-Draft D. Ballew
Updates: 2308, 4033, 4034, 4035 S. Bindinganaveli Raghavan
(if approved) CenturyLink, Inc.
Intended status: Standards Track
Expires: August 15, 2017 February 15, 2017
BULK DNS Resource Records
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF). Note that
other groups may also distribute working documents as Internet-
Drafts. The list of current Internet-Drafts is at
http://datatracker.ietf.org/drafts/current.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
Woodworth, et al. Expires: August 15, 2017 [Page 1]
Internet-Draft BULK DNS Resource Records February 2017
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Woodworth, et al. Expires: August 15, 2017 [Page 2]
Internet-Draft BULK DNS Resource Records February 2017
Table of Contents:
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Background and Related Documents . . . . . . . . . . . 5
1.2. Reserved Words . . . . . . . . . . . . . . . . . . . . 5
2. The BULK Resource Record . . . . . . . . . . . . . . . . . 5
2.1. BULK OPTIONAL Hidden Wildcards . . . . . . . . . . . . 5
2.2. BULK RDATA Wire Format . . . . . . . . . . . . . . . . 5
2.2.1. The Match Type Field . . . . . . . . . . . . . . 6
2.2.2. The Domain Name Pattern Field . . . . . . . . . . 6
2.2.2.1. Single hyphen . . . . . . . . . . . . . . . 7
2.2.2.2. Numeric ranges . . . . . . . . . . . . . . . 7
2.2.2.3. String values . . . . . . . . . . . . . . . 7
2.2.3. The Replacement Pattern Field . . . . . . . . . . 7
2.3. The BULK RR Presentation Format . . . . . . . . . . . 8
2.4. BULK RR Examples . . . . . . . . . . . . . . . . . . . 9
3. BULK Replacement . . . . . . . . . . . . . . . . . . . . . 9
3.1. Matching BULK "owner" field . . . . . . . . . . . . . 10
3.2. Matching the BULK "Match Type" field . . . . . . . . . 10
3.3. Matching the BULK "Domain Name Pattern" field . . . . 10
3.3.1. Automatic Domain Name Pattern matching . . . . . 11
3.3.2. Manual Domain Name Pattern matching . . . . . . . 11
3.3.2.1. Manual Domain Name Pattern matching
examples . . . . . . . . . . . . . . . 11
3.4. Record Generation using the BULK "Replacement
Pattern" field . . . . . . . . . . . . 14
3.4.1. Replacement Pattern Backreferences . . . . . . . 14
3.4.1.1. Backreference Notation . . . . . . . . . . . 15
3.4.1.1.1. Simple numeric backreference
replacement . . . . . . . . . . . . . 15
3.4.1.1.2. Star backreference replacement . . . . 15
3.4.1.1.3. Numeric range backreference
replacement . . . . . . . . . . . . . 15
3.4.1.1.4. Numeric set backreference
replacement . . . . . . . . . . . . . 15
3.4.1.1.5. Backreference delimiter . . . . . . . . 16
3.4.1.1.6. Backreference delimiter interval . . . 16
3.4.1.1.7. Backreference padding length . . . . . 16
3.4.1.1.8. Backreference Position . . . . . . . . 17
3.4.1.1.9. Backreference Position Negation . . . . 17
3.4.2. Replacement Pattern examples . . . . . . . . . . 17
4. The NPN Resource Record . . . . . . . . . . . . . . . . . . 19
4.1. NPN RDATA Wire Format . . . . . . . . . . . . . . . . 19
4.1.1. The Match Type field . . . . . . . . . . . . . . 19
4.1.2. The Flags field . . . . . . . . . . . . . . . . . 20
4.1.3. The Owner Ignore field . . . . . . . . . . . . . 20
4.1.4. The Left Ignore field . . . . . . . . . . . . . . 20
4.1.5. The Right Ignore field . . . . . . . . . . . . . 20
4.2. The NPN RR Presentation Format . . . . . . . . . . . . 21
4.3. Normalization Processing of NPN RRs . . . . . . . . . 21
Woodworth, et al. Expires: August 15, 2017 [Page 3]
Internet-Draft BULK DNS Resource Records February 2017
4.3.1. Pseudocode for NPN Normalization Processing . . . 22
4.3.2. NPN Normalization Processing examples . . . . . . 23
5. Positive Side-Effects . . . . . . . . . . . . . . . . . . . 26
5.1. Record Superimposition . . . . . . . . . . . . . . . . 26
5.2. Pattern Based DNSSEC support . . . . . . . . . . . . . 27
6. Known Limitations . . . . . . . . . . . . . . . . . . . . . 27
6.1. Increased CPU utilization for NXDOMAIN RRs . . . . . . 27
6.2. Pre-Adoption Nameserver Implications . . . . . . . . . 27
7. Security Considerations . . . . . . . . . . . . . . . . . . 28
7.1. DNSSEC Signature Strategies . . . . . . . . . . . . . 28
7.1.1. On-the-fly (Live) Signatures . . . . . . . . . . 28
7.1.2. Normalized (NPN Based) Signatures . . . . . . . . 28
7.1.3. Non-DNSSEC Zone Support Only . . . . . . . . . . 29
7.2. DNSSEC Verifier Details . . . . . . . . . . . . . . . 29
7.3. DDOS Attack Vectors and Mitigation . . . . . . . . . . 29
7.4. Implications of Large Scale DNS Records . . . . . . . 30
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 30
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Normative References . . . . . . . . . . . . . . . . 30
10.2. Informative References . . . . . . . . . . . . . . . 31
1. Introduction
The BULK DNS Resource Record (BULK) defines a maskable pattern based
method for real-time on-the-fly resource record generation.
Specifically, it allows one to manage large blocks of DNS records
based entirely on record owner data in the RR query and patterns (or
templates) designed by knowledgeable zone administrators. Existing
DNS resource records covered by this document are Address (A), IPv6
Address (AAAA), Pointer (PTR) and Canonical Name (CNAME). Although
other RR types are not explicitly forbidden from use with BULK logic
they fall outside of scope and will not be discussed in this
document. This document defines the purpose of this new resource
record (BULK), its RDATA format, its presentation format (ASCII
representation) as well as generated responses to matched DNS
queries.
Two Key benefits of this record type are; a) the ability to transfer
BULK RR intentions from primary to secondary nameservers with minimal
bandwidth and memory requirements; and b) the ability to manage large
volumes of pattern based records such as an IPv6 /64 CIDR or larger
in a single entry.
Support options for DNSSEC related complications resulting from
dynamically generated records are also provided in this document.
One such option is in the form of the Numeric Pattern Normalization
(NPN) resource record type also described in this document. NPN
resource records provide a way of generating pattern based DNSSEC
signatures and securely performing DNSSEC validation on such
Woodworth, et al. Expires: August 15, 2017 [Page 4]
Internet-Draft BULK DNS Resource Records February 2017
signatures.
1.1. Background and Related Documents
This document assumes the reader is familiar with the basic DNS
concepts described in [RFC1034], [RFC1035], and the subsequent
documents that update them, particularly [RFC2181] and [RFC2308].
The reader is also assumed to be familiar with DNSSEC basics as
described in [RFC4033], [RFC4034] and [RFC4035] as well as the DNS
cryptographic signature generation process described in [RFC4033],
[RFC4034], [RFC4035], [RFC2536], [RFC2931] and [RFC3110].
1.2. Reserved Words
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. The BULK Resource Record
The BULK resource record consists of details which enable a DNS
nameserver to generate RRs of other types based upon query received
and patterns provided. Unless otherwise stated the letters used in
hexadecimal numbers (a-f) MUST be case insensitive and are assumed to
be lowercase. All examples in this document using hexadecimal are
provided in lowercase.
The Type value for the BULK RR type is XX.
The BULK RR is class independent.
The BULK RR has no special TTL requirements but some security
guidelines are offered in a later section.
2.1. BULK OPTIONAL Hidden Wildcards
The BULK RR extends current wildcard substitution logic as defined in
[RFC1034] by allowing a single hyphen "-" in the leftmost label to
represent the intent of leveraging a modified wildcard matching
mechanism. If this condition exists wildcard logic SHALL be used for
generated replacement records but not for the BULK resource records
themselves. This will become clearer in the "BULK Replacement"
section of this document. If an asterisk "*" (the standard wildcard
character) is used default wildcard behavior MUST be used.
2.2. BULK RDATA Wire Format
The RDATA for a BULK RR consists of a 2 octet Match Type Field, a
Domain Name Pattern Field and a Replacement Pattern Field.
Woodworth, et al. Expires: August 15, 2017 [Page 5]
Internet-Draft BULK DNS Resource Records February 2017
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Match Type | /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Domain Name Pattern /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
/ Replacement Pattern /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2.2.1. The Match Type Field
The Match Type field identifies the type of the RRset identified by
this BULK record. This field consists of two octets corresponding to
an RR TYPE code as specified in [RFC1035], Section 3.2.1.
2.2.2. The Domain Name Pattern Field
The Domain Name Pattern Field consists of a text string which may be
evaluated by the sections below. The character encoding for this
field is [US-ASCII] and may not contain whitespace unless enclosed
within double-quote characters. The value of a single hyphen "-" has
special implications and will be discussed in greater detail below.
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC5234].
DIGIT = <as defined in RFC 5234 Appendix B.1>
HEXDIG = <as defined in RFC 5234 Appendix B.1>
DQUOTE = <as defined in RFC 5234 Appendix B.1>
pattern = "-" / 1*part / DQUOTE 1*part DQUOTE
part = "[" range "]" / string
range = number [ "-" number ]
number = 1*DIGIT / 1*HEXDIG
string = 1*( %x01-5A / %x5C / %x5E-7F )
; Any [US-ASCII] character excluding
; NUL and square bracket characters
; "[" or "]"
Although allowed by [RFC2181]; the square bracket characters, "[" and
"]", are reserved to enclose a range specification and MUST NOT
appear anywhere outside of a range specification.
Woodworth, et al. Expires: August 15, 2017 [Page 6]
Internet-Draft BULK DNS Resource Records February 2017
2.2.2.1. Single hyphen
If the domain name pattern field consists of a single hyphen it is
not necessary to evaluate for numeric ranges or strings.
Implementors SHOULD simply set a flag indicating all ranges matching
the query's label are true and backreferences (described in further
detail in the "BULK Replacement" section) will be automatically set.
2.2.2.2. Numeric ranges
Numeric ranges include decimal or hexadecimal ranges depending on
which record type was used in the query. This logic will be
described in further detail in the "Replacement Logic" section.
The numeric range pattern will be a range of allowed numbers lower
and upper values separated by a single hyphen "-". If upper and
lower values are identical a single numeric value (without hyphen)
will suffice. To easily distinguish numeric range patterns from
string values they MUST be enclosed within square brackets "[" and
"]".
2.2.2.3. String values
All values found before or after Numeric ranges (excluding single-
hyphen rule) are considered to be string values. These values will
be taken literally when evaluating for pattern matches in the "BULK
Replacement" section below.
2.2.3. The Replacement Pattern Field
The Replacement Pattern field describes how the answer RRset SHOULD
be generated for the matching query. It can either be a single
hyphen "-" or a string containing backreferences (described in
further detail in the "BULK Replacement" section). This field MUST
be evaluated for proper syntax for resource records of its Match Type
defined above. A "read" evaluation MAY be performed when a zone is
first committed to memory either while converting from Text to Wire
format (from stored zone files) or when a RR transfer is received
(raw Wire format). Stage two "write" evaluations MUST be performed
prior to returning generated replacement answers. Since logic to
perform a stage two evaluation is already a requirement for DNS
nameservers it may be easier for implementors to perform just stage
two evaluations. Stage-two-only evaluation may be also preferred for
performance purposes and is acceptable behavior. Any stage two
evaluation errors MUST be processed as if the record did not exist
and if all BULK generated records for a query answer-set evaluate to
errors the original condition of an NXDOMAIN error state MUST be
restored.
Woodworth, et al. Expires: August 15, 2017 [Page 7]
Internet-Draft BULK DNS Resource Records February 2017
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC5234].
DIGIT = <as defined in RFC 5234 Appendix B.1>
HEXDIG = <as defined in RFC 5234 Appendix B.1>
DQUOTE = <as defined in RFC 5234 Appendix B.1>
pattern = "-" / 1*part / DQUOTE 1*part DQUOTE
part = backreference / string
backreference = "$" "{" substitution "}"
substitution = range 0*( "," range ) [ options ]
substitution =/ "*" [ options ]
options = delimiter [ interval [ padding ] ]
delimiter = "|" 0*1( %x01-23 / %x25-7A / %7E-7F )
; Any single [US-ASCII] character
; excluding NUL, dollar sign "$",
; pipe "|" and curly brace characters
; "{" or "}"
interval = "|" *2DIGIT
padding = "|" *2DIGIT
range = number [ "-" number ]
number = 1*DIGIT / 1*HEXDIG
string = 1*( %x01-23 / %x25-7A / %x7C / %7E-7F )
; Any [US-ASCII] character excluding
; NUL, dollar sign "$" and curly brace
; characters "{" or "}"
The dollar sign, "$", and curly brace characters, "{" and "}", are
reserved to enclose regular-expression-esque backreferences and MUST
NOT appear anywhere outside of such a backreference specification.
This rigidity is necessary to simplify implementation of this
document and may relax once adoption reaches an acceptable level and
demand for such an exception exists. The authors feel this
limitation is a reasonable limitation for the flexibility offered by
this document.
2.3. The BULK RR Presentation Format
The Match Type field is represented as an RR type mnemonic. When the
Woodworth, et al. Expires: August 15, 2017 [Page 8]
Internet-Draft BULK DNS Resource Records February 2017
mnemonic is not known, the TYPE representation as described in
[RFC3597], Section 5, MUST be used.
The Domain Name Pattern and Replacement Pattern fields MUST be
presented as the TXT RR type described in [RFC1035], Section 3.3.14.
2.4. BULK RR Examples
EXAMPLE 1
The following BULK RR stores a block of A RRs for example.com.
*.example.com. 86400 IN BULK A (
pool-A-[0-255]-[0-255].example.com.
10.55.${1}.${2}
)
The first four fields specify the owner name, TTL, Class, and RR type
(BULK). Value "A" indicates that this BULK RR defines the A record
type (Address). Value "pool-A-[0-255]-[0-255].example.com."
indicates the Domain Name Pattern. Value "10.55.${1}.${2}" indicates
the Replacement Pattern. The owner in this example is a wildcard and
matches any query ending with the string right of the asterisk.
EXAMPLE 2
The following BULK RR stores the reverse block of PTR records for the
first example.
*.55.10.in-addr.arpa. 86400 IN BULK PTR (
[0-255].[0-255].55.10.in-addr.arpa.
pool-A-${1}-${2}.example.com.
)
The first four fields specify the owner name, TTL, Class, and RR type
(BULK). Value "PTR" indicates that this BULK RR defines the PTR
record type (Pointer). Value "[0-255].[0-255].55.10.in-addr.arpa."
indicates the Domain Name Pattern. Value "pool-A-${1}-
${2}.example.com." indicates the Replacement Pattern. The owner in
this example is a wildcard and matches any query ending with the
string right of the asterisk.
Additional examples can be found in the "BULK Replacement" section.
3. BULK Replacement
The BULK Record is designed to enable DNS zone maintainers to manage
large blocks of DNS RRs which all conform to a common pattern. The
Domain Name Pattern field provides both a tertiary filter (after
owner and type) and a definition of all numeric pattern ranges.
When a query is first received by a DNS nameserver it begins its job
Woodworth, et al. Expires: August 15, 2017 [Page 9]
Internet-Draft BULK DNS Resource Records February 2017
of locating an answer-set. In its simplest form this begins by
locating the query owner (or wildcard suffix), class and type then
returning any matching RR RDATA (or errors).
In the event no matches for the query are found the nameserver of
authority will return an error type defined as NXDOMAIN. In the case
of a "BULK" enabled authoritative nameserver an additional step MUST
be performed. The nameserver MUST query its local RR database for
any "BULK" RRs with a matching owner, class and compatible Match
Type. If any such RRs are found the query's owner MUST then be
matched against the Domain Name Pattern and all matching BULK records
MUST be placed into a temporary processing answer-set. This
temporary processing answer-set MUST then follow the Replacement
Pattern for each matched record and provided no errors are found
SHALL then write this new answer-set to the query's complete answer
set. Matching replacements will be of the type specified in the
Match Type field of the corresponding BULK RR. Additional detail is
provided in the following sections.
3.1. Matching BULK "owner" field
The owner field of all BULK records MUST be that of either a wildcard
or hidden wildcard as defined in previous sections. While a hidden
wildcard will not be searched for BULK records it will be added to
the database for use with the corresponding type field of each BULK
RR. This allows location of BULK records to be less conspicuous to
the public while still leveraging logic already included in the
nameserver thus minimizing the complexity of implementation.
A query SHALL pass the first filter stage (owner match) ONLY IF: (1)
an NXDOMAIN is set as the query's current answer set AND (2) the
query's owner ends with the BULK record's owner field past the
leading hyphen "-" or asterisk "*".
3.2. Matching the BULK "Match Type" field
The RR type of the received query must be compatible with that of the
Match Type of owners matched in the section above. That is to say a
query for an "A" record will only match BULK records with matching
owner and Match Types of "A" (or "CNAME"). All other BULK records
matching the query's owner are incompatible and MUST be ignored as
part of the selected answer set.
3.3. Matching the BULK "Domain Name Pattern" field
Assuming the RR owner and Match Type fields match the next step is to
find compatible Domain Name Patterns. The logic for this falls into
two categories; automatic and manual which are described in greater
detail in the following sections.
Woodworth, et al. Expires: August 15, 2017 [Page 10]
Internet-Draft BULK DNS Resource Records February 2017
3.3.1. Automatic Domain Name Pattern matching
Automatic Domain Name Pattern matching is determined by use of a
single hyphen "-" as the value for Domain Name Pattern field. This
assumes everything matches and all hexadecimal or decimal fields will
be captured for use as backreferences in the Replacement Pattern
(described below). Automatic Domain Name Pattern matching is often
preferred for large blocks such as the reverse IPv6 address space for
the simplicity of record management.
3.3.2. Manual Domain Name Pattern matching
Manual Domain Name Pattern matching, while more complex is designed
to be both simple to implement and simple to use. Below is an
example implementation for label matching using a combination of
parsing by regular expression and matching of numeric ranges.
Domain Name Patterns evaluate to current zone ORIGIN as defined in
[RFC1034], Section 3. In short this means all Manual Domain Name
Patterns must be terminated with a period "." or are assumed relative
to the RR's origin.
Numeric Ranges are either decimal or hexadecimal as determined by
conditions of query.
If query type is "A" ranges are set to decimal.
If query type is "AAAA" ranges are set to hexadecimal.
If query type is PTR or CNAME the RR owner is used to determine
decimal or hexadecimal.
If RR owner ends in ".ip6.arpa." ranges are set to hexadecimal.
If RR owner does _not_ end in ".ip6.arpa." ranges are set to
decimal.
The square bracket characters, "[" and "]", are reserved to enclose a
range specification and MUST NOT appear anywhere outside of a range
specification.
3.3.2.1. Manual Domain Name Pattern matching examples
EXAMPLE 1
For this example the query is defined as a PTR record for "10.2.3.4"
with an origin of "2.10.in-addr.arpa." and the evaluating BULK RR as:
Woodworth, et al. Expires: August 15, 2017 [Page 11]
Internet-Draft BULK DNS Resource Records February 2017
-.2.10.in-addr.arpa. 86400 IN BULK PTR (
[0-255].[0-10]
pool-A-${1}-${2}.example.com.
)
STEP 1
Ensure "Domain Name Pattern" is Fully Qualified
[0-255].[0-10] == [0-255].[0-10].2.10.in-addr.arpa.
STEP 2
Determine whether range is decimal or hexadecimal
Query type == "PTR" AND RR owner != "*.ip6.arpa." so range is
decimal.
STEP 3
Build regular expression based on fully qualified domain name
pattern.
[0-255].[0-10].2.10.in-addr.arpa. ==
/^([0-9]{1,3})\.([0-9]{1,2})\.2\.10\.in-addr\.arpa\.$/
The above regular expression simply matches numeric ranges based on
decimal or hexadecimal and length. Numeric range validation occurs
in the next step.
STEP 4
Compare captured numbers and validate ranges
4.3.2.10.in-addr.arpa.
=~ /^([0-9]{1,3})\.([0-9]{1,2})\.2\.10\.in-addr\.arpa\.$/
"4" is captured and within range 0-255 (decimal)
"3" is captured and within range 0-10 (decimal)
EXAMPLE 2
For this example the query is defined as a PTR record for "fc00::55"
with an origin of "0.0.c.f.ip6.arpa." and the evaluating BULK RR as:
-.0.0.c.f.ip6.arpa. 86400 IN BULK PTR (
-
pool-${1-16|}-${17-
28|}.example.com.
)
STEP 1
Ensure "Domain Name Pattern" is Fully Qualified
Woodworth, et al. Expires: August 15, 2017 [Page 12]
Internet-Draft BULK DNS Resource Records February 2017
- == [0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f]. ~~
[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f]. ~~
[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f]. ~~
[0-f].[0-f].[0-f].[0-f].0.0.c.f.ip6.arpa.
NOTE: Data above is shown in multiple lines for clarity.
Since Hyphen invokes "Automatic Domain Name Pattern" matching, all
fields are captured for future use as backreferences.
STEP 2
Determine whether range is decimal or hexadecimal
Query type == "PTR" AND RR owner == "*.ip6.arpa." so range is
hexadecimal.
STEP 3
Build regular expression based on fully qualified domain name
pattern.
[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f]. ~~
[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f]. ~~
[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f].[0-f]. ~~
[0-f].[0-f].[0-f].[0-f].0.0.c.f.ip6.arpa. ==
/^([0-9a-f]{1}\.){28}\.0\.0\.c\.f\.ip6\.arpa\.$/
NOTE: Data above is shown in multiple lines for clarity.
The above regular expression simply matches numeric ranges based on
decimal or hexadecimal and length. Numeric range validation occurs
in the next step.
STEP 4
Compare captured numbers and validate ranges
5.5.0.0.0.0.0.0.0.0.0.0.0.0.0.0. ~~
0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.f.ip6.arpa.
=~ /^([0-9a-f]{1}\.){28}\.0\.0\.c\.f\.ip6\.arpa\.$/
NOTE: Data above is shown in multiple lines for clarity.
"5" is captured and within range 0-f (hexadecimal)
"5" is captured and within range 0-f (hexadecimal)
...
"0" is captured and within range 0-f (hexadecimal)
"0" is captured and within range 0-f (hexadecimal)
EXAMPLE 3
For this example the query is defined as an "AAAA" record for "pool-
A-ff-aa.example.com." with an origin of "example.com." and the
Woodworth, et al. Expires: August 15, 2017 [Page 13]
Internet-Draft BULK DNS Resource Records February 2017
evaluating BULK RR as:
-.example.com. 86400 IN BULK AAAA (
pool-A-[0-ffff]-[0-ffff]
fc00::${1}:${2}
)
STEP 1
Ensure "Domain Name Pattern" is Fully Qualified
pool-A-[0-ffff]-[0-ffff] == pool-A-[0-ffff]-[0-ffff].example.com.
STEP 2
Determine whether range is decimal or hexadecimal
Query type == "AAAA" so range is hexadecimal.
STEP 3
Build regular expression based on fully qualified domain name
pattern.
pool-A-[0-ffff]-[0-ffff].example.com. ==
/^pool-A-([0-9a-fA-F]{1,4})-([0-9a-fA-F]{1,4})\.example\.com\.$/
The above regular expression simply matches numeric ranges based on
decimal or hexadecimal and length. Numeric range validation occurs
in the next step.
STEP 4
Compare captured numbers and validate ranges
pool-A-ff-aa.example.com.
=~ /^pool-A-([0-9a-fA-F]{1,4})-([0-9a-fA-F]{1,4})\.example\.com\.$/
"ff" is captured and within range 0-ffff (hexadecimal)
"aa" is captured and within range 0-ffff (hexadecimal)
3.4. Record Generation using the BULK "Replacement Pattern" field
Once it has been determined a query meets all criteria for a BULK
record generation the below rules are followed to process captured
numeric data and Replacement Pattern into RRs to apply to the answer-
set.
3.4.1. Replacement Pattern Backreferences
Before a record may be generated data must be captured in the Domain
Name Pattern comparison step above. Each provided numeric range is
assigned to a temporary buffer to be used in this step. To make the
Woodworth, et al. Expires: August 15, 2017 [Page 14]
Internet-Draft BULK DNS Resource Records February 2017
jobs' of zone administrators easier the order of these buffers will
change based on the Match Type and owner so they will default to feel
more natural or intuitive. Captured patterns and backreferences are
in the same vein as regular expressions and are intended to feel
"familiar". This is described in further detail (with examples) in
the sections below.
3.4.1.1. Backreference Notation
BULK RRs use a dollar-sign "$" and curly braces "{" and "}" to
enclose backreferences within the Replacement Pattern. The following
rules are used to determine the final replacement string.
3.4.1.1.1. Simple numeric backreference replacement
The simplest form of backreference notation is its numeric form. In
this form only the backreference number falls between the curly
braces "{" and "}". An example is "${1}" which would be replaced by
the value in the first capture position. Position is described in
detail in a later section.
Numeric backreference replacement indices start with one "1" to
maintain consistency with regular expression backreferences.
3.4.1.1.2. Star backreference replacement
The next form of backreference notation is its star (or asterisk "*")
form. In this form only an asterisk falls between the curly braces
"{" and "}". This form "${*}" would be replaced by all captured
values in order of ascending position delimited by its default
delimiter (described below). Position is described in detail in a
later section.
3.4.1.1.3. Numeric range backreference replacement
The next form of backreference notation is the numeric range form. In
this form a range of numbers falls between the curly braces "{" and
"}". An example of this is "${1-4}" which would be replaced by all
captured values within this range (1-4) in order of positions
provided delimited its default delimiter (described below). To
reverse the order of positions in this example one could simply
reverse the upper and lower values to look like "${4-1}". Position
is described in detail in a later section.
3.4.1.1.4. Numeric set backreference replacement
The next form of backreference notation is the numeric set form. In
this form a set of numbers falls between the curly braces "{" and "}"
separated by commas. An example of this is "${1,4}" which would be
replaced by the first and fourth captured values in the order of
Woodworth, et al. Expires: August 15, 2017 [Page 15]
Internet-Draft BULK DNS Resource Records February 2017
position provided delimited its default delimiter (described
below). Position is described in detail in a later section.
This notation may be combined with the numeric range form allowing
specific positions or position ranges to be used. Examples would be
"${3,2,1,4-8}" and "${8-12,1-4}".
3.4.1.1.5. Backreference delimiter
The above sections reference a default delimiter. In an effort to
provide an intuitive zone management experience the default delimiter
will be based on the BULK RR's Match Type. For Match Type "A" the
default delimiter SHALL be a period ".", for Match Type "AAAA" the
default delimiter SHALL be a colon ":" and for Match Types "PTR" and
"CNAME" the default delimiter SHALL be a hyphen "-". In any case the
default delimiter MAY be overridden by including it in the
backreference braces after the set selectors and a backreference
field separator character, the pipe "|". An example would be "${*|-
}" which would force a hyphen "-" delimiter. An empty or null
delimiter is allowed by not specifying a delimiter character, for
example "${*|}", which would simply concatenate all captured values
in order of capture position. Position is described in detail in a
later section.
3.4.1.1.6. Backreference delimiter interval
The default behavior of a backreference set is to combine each
captured value specified with a delimiter between each. To allow
captured backreferences to be delimited at another interval a third
backreference field is provided. An example would be "${*|-|4}"
which would concatenate all captured values but delimiting only every
fourth value with hyphens "-". This can be a handy feature in the
IPv6 reverse namespace where every nibble is captured as a separate
value and generated hostnames include sets of 4 nibbles. An empty or
null value MUST be interpreted as "1" or every captured value.
3.4.1.1.7. Backreference padding length
When generating BULK based records a common requirement is to convert
from one numeric format to another, padding is among the most common
of these. The fourth and final backreference field determines what
width to pad to. An example would be "${*|||4}" which would set the
width of all captured values to 4 by inserting leading zeros to fill
the void. The default is empty or null which MUST be interpreted as
NO modification. A width of zero "0" has a special interpretation
referred to as "unpad" meaning all leading zeros MUST be removed. If
a value is provided captured values longer than this width MUST be
truncated to fit the specified width. In the case where a delimiter
interval is provided captured values between the intervals will be
concatenated and the padding or unpadding applied as a unit and not
Woodworth, et al. Expires: August 15, 2017 [Page 16]
Internet-Draft BULK DNS Resource Records February 2017
individually. An example of this would be "${*||4|4}" which would
combine each range of 4 captured values and pad them to a width of 4
characters by inserting leading zeros where necessary.
3.4.1.1.8. Backreference Position
Great effort has gone into providing zone maintainers an intuitive
syntax. As part of this effort, the captured values will reverse
direction depending on several factors.
As a general rule of thumb, if it makes sense the numeric ranges are
in reverse order from query to answer then they will be reversed.
Otherwise they will be in the same order.
Take for example a simple reverse DNS lookup, from "10.2.3.4" to
"pool-A-3-4.example.com.". Since DNS zones are arranged according to
management authority the records appear reversed numerically. In this
example "10.2.3.4" becomes "4.3.2.10.in-addr.arpa.". One would
intuitively expect this reversal to be reversed so positional indices
of captured values would increment toward the right of the
Replacement Pattern. This expectation is especially important when
using range based replacements.
Formally, the rules for position reversal are as follows:
Match Type RRs for "PTR" are reversed for zone owners ending in
either ".in-addr.arpa." or "ip6.arpa.". All other Match Type RRs for
"PTR" are forward.
Match Type RRs for "A" (Address), "AAAA" (IPv6 Address) and "CNAME"
(Canonical Name) are forward.
3.4.1.1.9. Backreference Position Negation
To allow simple reversal of any backreference notation a single
exclamation point character "!" MAY be used as the first character of
a backreference set. Examples would be "${!*}" and "${!1-4,7}". In
both of the examples the backreference positions SHALL be the exact
mirror equivalent as those without the leading exclamation point "!".
This can be very important if the BULK generated replacements have
values in positions opposite to what is required or expected.
3.4.2. Replacement Pattern examples
This section provides examples of several BULK RR Replacement
Patterns. Each example is intended to further understanding for
implementors and DNS administrators alike.
EXAMPLE 1
For this example the query is defined as a PTR record for "10.2.3.4"
Woodworth, et al. Expires: August 15, 2017 [Page 17]
Internet-Draft BULK DNS Resource Records February 2017
with an origin of "2.10.in-addr.arpa." and the evaluating BULK RR as:
- 86400 IN BULK PTR - pool-${*}.example.com.
This example contains several of the features described above.
First, the record owner is simply a single hyphen "-" denoting it is
a "hidden wildcard" (wildcard for generated records but not for
BULK).
Second, the Domain Name Pattern is also a single hyphen "-" denoting
all queries matching the owner's wildcard pattern for the "PTR" Match
Type are accepted and will be captured for use in the Replacement
Pattern.
Third, the Replacement Pattern contains a single "star" backreference
denoting all captured numeric (decimal) backreferences will be
combined with its default delimiter of hyphen "-" (for PTR) and
placed into the backreference's position in the answer-set. Should
this generate an invalid hostname the response will be NXDOMAIN
unless other BULK records match and are successfully generated
without error.
The owner for "10.2.3.4" is "4.3.2.10.in-addr.arpa." and creates
matching backreferences for "4", "3", "2" and "10" then reverses
their indices so "${1}" resolves to "10", "${2}" to "2", "${3}" to
"3" and "${4}" to "4" respectively. When applied to the Replacement
Pattern the answer becomes "pool-10-2-3-4.example.com.".
EXAMPLE 2
For this example the query is defined as a PTR record for "10.2.3.4"
with an origin of "2.10.in-addr.arpa." and the evaluating BULK RR as:
- 86400 IN BULK PTR - pool-${*|||3}.example.com.
This example expands on EXAMPLE 1 with the differences outlined
below.
The only change to the BULK RR is the Replacement Pattern includes
additional fields, specifically null values for delimiter and
interval and a padding width of 3.
The owner for "10.2.3.4" is "4.3.2.10.in-addr.arpa." and creates
matching backreferences for "4", "3", "2" and "10" and reverses their
indices so "${1}" resolves to "10", "${2}" to "2", "${3}" to "3" and
"${4}" to "4" respectively. When applied to the Replacement Pattern
the answer becomes "pool-010002003004.example.com.".
EXAMPLE 3
This example contains a classless IPv4 delegation on the /22 CIDR
Woodworth, et al. Expires: August 15, 2017 [Page 18]
Internet-Draft BULK DNS Resource Records February 2017
boundary as defined by [RFC2317]. The network for this example is
"10.2.0/22" delegated to a nameserver "ns1.sub.example.com.". RRs for
this example are defined as:
$ORIGIN 2.10.in-addr.arpa.
0-3 86400 IN NS ns1.sub.example.com.
- 86400 IN BULK CNAME [0-255].[0-3] ${*|.}.0-3
For this example, the query would come in for "25.2.2.10.in-
addr.arpa.". After matching the owner filter (ending in ".2.10.in-
addr.arpa.") and the fully qualified domain name pattern of "[0-
255].[0-3].2.10.in-addr.arpa." the answer-set would include a
generated RR consisting of captured values "25" and "2" joined by the
custom delimiter of period "." then joined by ".0-3" and made fully
qualified. The resulting RR would be a "CNAME" with RDATA of
"25.2.0-3.2.10.in-addr.arpa.". This record is now one delegated to
"ns1.sub.example.com." as its authority and the answer-set is
complete.
4. The NPN Resource Record
The NPN resource record provides pre-processing directives for
Numeric Pattern Normalization (NPN) based RR signature generation.
The Type value for the NPN RR type is XX.
The NPN RR is class independent.
The NPN RR has no special TTL requirements.
4.1. NPN RDATA Wire Format
The RDATA for a NPN RR consists of a 2 octet Match Type field, a 1
octet Flags field, a 1 octet Owner Ignore field, a 1 octet Left
Ignore field and a 1 octet Right Ignore field.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Match Type | Flags | Owner Ignore |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Left Ignore | Right Ignore |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.1.1. The Match Type field
The Match Type field identifies the type of the RRset identified by
this NPN record.
Woodworth, et al. Expires: August 15, 2017 [Page 19]
Internet-Draft BULK DNS Resource Records February 2017
4.1.2. The Flags field
The Flags field defines additional processing parameters for data
normalization. This document defines only the Period-As-Number flag
"." (position 5), the Hyphen-As-Number "-" (position 6) and the
hexadecimal flag "X" (position 7). All other flags are reserved for
future use.
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|Reserved |.|-|X|
+-+-+-+-+-+-+-+-+
Bits 0-4: Reserved for future
These flags have no default value if set to false (0).
Bit 5: Period As Number (.) Flag
This flag indicates the period (dot) will be processed as a
number. This flag has no default value if set to false (0).
Bit 6: Hyphen As Number (-) Flag
This flag indicates the hyphen (dash) will be processed as a
number. This flag has no default value if set to false (0).
Bit 7: Hexadecimal (X) Flag
This flag indicates the highest value for Normalization Processing
is "f". Normalization Processing will be described in a later
section. This flag has a default value of "9" if set to false
(0).
4.1.3. The Owner Ignore field
The Owner Ignore field defines the length of characters as counted
from the left-hand side of the owner which MUST be ignored by the
normalization process. This field offers additional security to
pattern based signatures which may not be immediately apparent. By
restricting the leftmost characters defined by this value, ultimately
the length of the generated portion of the accompanying BULK RR will
be confined accordingly. Normalization Processing will be described
further in a later section.
4.1.4. The Left Ignore field
The Left Ignore field defines the length of characters as counted
from the left-hand side of the generated RDATA which MUST be ignored
by the normalization process. Normalization Processing will be
described further in a later section.
4.1.5. The Right Ignore field
The Right Ignore field defines the length of characters as counted
from the right-hand side of the generated RDATA which MUST be ignored
by the normalization process. Normalization Processing will be
Woodworth, et al. Expires: August 15, 2017 [Page 20]
Internet-Draft BULK DNS Resource Records February 2017
described further in a later section.
4.2. The NPN RR Presentation Format
The Match Type field is represented as an RR type mnemonic. When the
mnemonic is not known, the TYPE representation as described in
[RFC3597], Section 5, MUST be used.
The Flags field MUST be presented as a string of characters
representing each flag bit. This document defines only the period
".", hyphen "-" and hexadecimal "X" flags. Flags MAY appear in any
order. For example; all three flags could appear as "-9." or ".f-"
(without the quotes). If all bits are zero all default values (if
defined) would be presented ("9" as currently defined).
All Ignore fields MUST be presented as an unsigned decimal integers
and fall within the 0-255 range available to a single octet.
4.3. Normalization Processing of NPN RRs
This document provides a minor yet significant modification to DNSSEC
regarding how RRsets will be signed or verified. Specifically the
Signature Field of [RFC4034], Section 3.1.8. Prior to processing
into canonical form, signed zones may contain associated RRs where;
owner, class and type of a non NPN RR directly corresponds with an
NPN RR matching owner, class and Match Type. If this condition
exists the NPN RR's RDATA defines details for processing the
associated RDATA into a "Normalized" format. Normalized data is
based on pre-canonical formatting and zero padded for "A" and "AAAA"
RR types for acceptable precision during the process. This concept
will become clearer in the NPN pseudocode and examples provided in
the sections to follow.
The rules for this transformation are simple:
For RR's Owner field, characters from the beginning to the index
of the Owner Ignore value or the final string of characters
belonging to the zone's ORIGIN MUST NOT be modified by this
algorithm. While the Owner Ignore value is not used for BULK
records but is included with the expectation other pattern-based
resource records may emerge and leverage NPN records for their
DNSSEC support requirements.
For RR's RDATA field, character from beginning to the index of
Left Ignore value or characters with index of Right Ignore value
to the end MUST NOT be modified by this algorithm.
In the remaining portion of both Owner and RDATA strings of
numeric data, defined as character "0" through "f" or "0" through
"9" depending on whether or not the Hexadecimal flag is set or
Woodworth, et al. Expires: August 15, 2017 [Page 21]
Internet-Draft BULK DNS Resource Records February 2017
not, MUST be consolidated to a single character and set to the
highest value defined by the Hexadecimal flag. Examples may be
found in the following section. If period-as-number or hyphen-as-
number flags are set whichever are used ("." or "-") would be
treated as part of the number and consolidated where appropriate.
Once the normalization has been performed the signature will continue
processing into canonical form using the normalized RRs in the place
of original ones.
One thing to keep in mind when calculating values for the Ignore
fields is the Domain Name Pattern and Replacement Pattern fields are
considered relative unless terminated by a period. When processing
NPN records the fully-qualified Patterns will be used for determining
which characters should be ignored.
NPN RRs MAY be included in the "Additional" section to provide a hint
for NPN processing required for verification path.
It is important to note, properly sizing the Ignore fields is
critical to minimizing the risk of spoofed signatures. Never
intentionally set all Ignore values to zero in order to make
validation easier as it places the validity of zone data at risk.
Only accompany RRs which are pattern derived (such as BULK) with NPN
records as doing so may unnecessarily reduce the confidence level of
generated signatures.
4.3.1. Pseudocode for NPN Normalization Processing
This section provides a simple demonstration of process flow for NPN
rdata normalization and DNSSEC signatures.
The pseudocode provided below assumes all associated RRs are valid
members of a DNSSEC compatible RRset (including BULK generated ones).
for rr in rrset
if (has_NPN<rr.owner, rr.class, rr.type>)
rr.rdata_normal = NPN_normalize<rr.rdata>
add_to_sigrrset<NPN.owner, rr.class, rr.type,
rr.rdata_normal>
next
else
add_to_sigrrset<rr.owner, rr.class, rr.type, rr.rdata>
next
process_canonical_form<sigrrset>
dnssec_sign<sigrrset>
Similar logic MUST be used for determining DNSSEC validity of RRsets
Woodworth, et al. Expires: August 15, 2017 [Page 22]
Internet-Draft BULK DNS Resource Records February 2017
in verification (validation) nameservers for signatures generated
based on NPN normalization.
4.3.2. NPN Normalization Processing examples
EXAMPLE 1
For this example the query is defined as a PTR record for "10.2.3.44"
with an origin of "2.10.in-addr.arpa." and the evaluating BULK and
NPN RR as:
-.2.10.in-addr.arpa. 86400 IN BULK PTR (
[0-255].[0-10]
pool-A-${1}-${2}.example.com.
)
*.2.10.in-addr.arpa. 86400 IN NPN PTR 9 0 7 13
As shown previously in BULK RR examples the query would enter the
nameserver with an owner of "44.3.2.10.in-addr.arpa." and a "PTR" RR
with the RDATA of "pool-A-3-44.example.com." would be generated.
By protecting the "Ignore" characters from the generated RR's RDATA
the focus for normalization becomes "3-44" as illustrated below.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
v---------
p o o l - A - 3 - 4 4 . e x a m p l e . c o m .
---------^
2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
Everything to the left of "3-44" will remain intact as will
everything to its right. The remaining characters will be processed
for numbers between "0" and "9" as indicated by the NPN record's
hexadecimal flag "9" and each run replaced by the single character
"9". The final Normalized RDATA would therefore become "pool-A-9-
9.example.com." and its signature would be based on this "normalized"
RDATA field. This new "normalized" string would be used as an RDATA
for the wildcard label of "*.2.10.in-addr.arpa." now encompassing all
possible permutations of the "pool-A-${1}-${2}.example.com." pattern.
Since the verification (validation) nameserver would use the
identical NPN record for processing and comparison, all RRs generated
by the BULK record can now be verified with a single wildcard
signature.
EXAMPLE 2
This example contains a classless IPv4 delegation on the /22 CIDR
boundary as defined by [RFC2317]. The network for this example is
"10.2.0/22" delegated to a nameserver "ns1.sub.example.com.". RRs
Woodworth, et al. Expires: August 15, 2017 [Page 23]
Internet-Draft BULK DNS Resource Records February 2017
for this example are defined as:
$ORIGIN 2.10.in-addr.arpa.
0-3 86400 IN NS ns1.sub.example.com.
- 86400 IN BULK CNAME [0-255].[0-3] ${*|.}.0-3
* 86400 IN NPN CNAME 9 0 0 23
For this example, a query of "10.2.2.65" would enter the nameserver
as "65.2.2.10.in-addr.arpa." and a "CNAME" RR with the RDATA of
"65.2.0-3.2.10.in-addr.arpa." would be generated.
By protecting the "Ignore" characters from the generated RR's RDATA
the focus for normalization becomes "65.2" as illustrated below.
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
v---------
6 5 . 2 . 0 - 3 . 2 . 1 0 . i n - a d d r . a r p a .
---------^
2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
Everything to the left of "65.2" will remain intact as will
everything to its right. The remaining characters will be processed
for numbers between "0" and "9" as indicated by the NPN record's
hexadecimal flag "9" and each run replaced by the single character
"9". The final Normalized RDATA would therefore become "9.9.0-
3.2.10.in-addr.arpa." and its signature would be based on this
"normalized" RDATA field. This new "normalized" string would be used
as an RDATA for the wildcard label of "*.2.10.in-addr.arpa." now
encompassing all possible permutations of the "${*|.}.0-3.2.10.in-
addr.arpa." pattern.
As in example 1, the verification (validation) nameserver would use
the same NPN record for comparison.
EXAMPLE 3
This example provides reverse logic for example 1 by providing an
IPv4 "A" record for a requested hostname. For this example the query
is defined as an "A" record for "pool-A-3-44.example.com." with an
origin of "example.com.". RRs for this example are defined as:
-.example.com. 86400 IN BULK A (
pool-A-[0-10]-[0-255]
10.2.${*}
)
*.example.com. 86400 IN NPN A 9 0 8 0
By protecting the "Ignore" characters from the generated RR's RDATA
the focus for normalization becomes "003.044" as illustrated below.
Woodworth, et al. Expires: August 15, 2017 [Page 24]
Internet-Draft BULK DNS Resource Records February 2017
1 1 1 1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
v--------------
0 1 0 . 0 0 2 . 0 0 3 . 0 4 4
---------------^
1 1 1 1 1 1 1 1 1
8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
This example illustrates a key point about NPN records; since they
are pre-canonical they MUST operate on a strict subset of WIRE
formatted data. For "A" and "AAAA" records this means the "Ignore"
fields are based on zero padded data. In this example our generated
record MUST be converted into "010.002.003.044" (shown above) prior
to processing. After processing, wire format would become
"0x0A02032C" (shown in hexadecimal). This format would be too
imprecise for normalization so padded decimal is used.
Everything to the left of "003.044" will remain intact as will
everything to its right. The remaining characters will be processed
for numbers between "0" and "9" as indicated by the NPN record's
hexadecimal flag "9" and each run replaced by the single character
"9". The final Normalized RDATA would therefore become "10.2.9.9"
and its signature would be based on this "normalized" RDATA field.
This new "normalized" "A" RR would be used as an RDATA for the
wildcard label of "*.example.com." now encompassing all possible
permutations of the "10.2.${*}" pattern.
EXAMPLE 4
This example provides similar logic for an IPv6 AAAA record. For
this example the query is defined as an "AAAA" record for "pool-A-ff-
aa.example.com." with an origin of "example.com.". RRs for this
example are defined as:
-.example.com. 86400 IN BULK AAAA (
pool-A-[0-ffff]-[0-ffff]
fc00::${1}:${2}
)
*.example.com. 86400 IN NPN AAAA X 0 30 0
By protecting the "Ignore" characters from the generated RR's RDATA
the focus for normalization becomes "00ff:00aa" as illustrated below.
Woodworth, et al. Expires: August 15, 2017 [Page 25]
Internet-Draft BULK DNS Resource Records February 2017
1 1 1 1 1 1 1 1 1 1 2 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
f c 0 0 : 0 0 0 0 : 0 0 0 0 : 0 0 0 0 : -/-/
4 3 3 3 3 3 3 3 3 3 3 2 2 2 2 2 2 2 2 2 2 1
0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9
/-/-/- . . . . . . . . . . . . . . . . . . . . . . . . -/-/-/
2 2 2 2 2 2 2 2 2 3 3 3 3 3 3 3 3 3 3 4
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
v------------------
/-/- 0 0 0 0 : 0 0 0 0 : 0 0 f f : 0 0 a a
-------------------^
2 1 1 1 1 1 1 1 1 1 1
0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
This example reinforces the point on pre-canonical processing of NPN
records; they MUST operate on a strict subset of WIRE formatted data.
For "A" and "AAAA" records this means the "Ignore" fields are based
on zero padded data. In this example our generated record MUST be
converted into "fc00:0000:0000:0000:0000:0000:00ff:00aa" (shown
above) prior to processing. After processing, wire format would
become "0xFC000000000000000000000000FF00AA" (shown in hexadecimal).
This format is slightly misleading as it is truly only 16 bytes of
WIRE data and would be too imprecise for normalization so padded
hexadecimal is used.
Everything to the left of "00ff:00aa" will remain intact as will
everything to its right. The remaining characters will be processed
for numbers between "0" and "f" as indicated by the NPN record's
hexadecimal flag "X" and each run replaced by the single character
"f". The final Normalized RDATA would therefore become "fc00::f:f"
and its signature would be based on this "normalized" RDATA field.
This new "normalized" "AAAA" RR would be used as an RDATA for the
wildcard label of "*.example.com." now encompassing all possible
permutations of the "fc00::${1}:${2}" pattern.
5. Positive Side-Effects
This section highlights positive side effects of some architectural
decisions regarding the BULK RR design.
5.1. Record Superimposition
The main side-effect of the BULK RR design is superimposition. RRs
created by the BULK generation process generally rely on the logic of
wildcard assignment. This logic only provides answers where no
others exist. This means in the reverse DNS world (network
assignment) HUGE blocks of addresses can be assigned a single BULK
record and where delegated to another customer or SWIP will be
Woodworth, et al. Expires: August 15, 2017 [Page 26]
Internet-Draft BULK DNS Resource Records February 2017
automatically overridden.
When compared with bind's $GENERATE statement, if a singleton record
such as CNAME appears within a $GENERATE range, either the CNAME or
$GENERATE becomes invalid. While a BULK record range would
automatically notch out the CNAME without user intervention or
creating a potential management problem for the future when two
$GENERATES create a hole where the CNAME no longer exists. BULK RRs
would again automatically reassign the missing record to one of its
own.
5.2. Pattern Based DNSSEC support
The NPN resource record can be used to support other dynamic RR types
which do not currently exist.
6. Known Limitations
This section defines known limitations of the BULK resource type.
6.1. Increased CPU utilization for NXDOMAIN RRs
Nameserver requirements to support BULK RRs will minimally increase
CPU utilization requirements compared to most RR types. However,
since the inception of DNSSEC more is expected of DNS servers at a
system resource level and it is the authors' belief the benefit
outweighs the sacrifice.
A quick comparison of BULK versus bind's $GENERATE expansion reveals
much more memory would be sacrificed with $GENERATES to save the CPU
cycles required to support BULK records. Additionally, $GENERATES
cannot be transferred (i.e. AXFR) without expansion and an IPv6 CIDR
even as small as /96 would be simply impossible. BULK on the other
hand can easily support IPv6 CIDRs of /64 and much larger with very
little effort.
6.2. Pre-Adoption Nameserver Implications
While there is an added demand on authoritative nameservers, there
are no new requirements to recursive (caching) resolvers for non-
DNSSEC record handling. Even authoritative nameservers are able to
transfer to and from supporting nameservers with no requirement
(although would be unable to return BULK generated records without
support).
Prior to widespread adoption on the authoritative side all generated
records would be invisible if served on nameservers lacking support.
Since generated records are generally NOT service impacting records
this should be understood but not of great concern.
Woodworth, et al. Expires: August 15, 2017 [Page 27]
Internet-Draft BULK DNS Resource Records February 2017
Once adoption has reached an appreciable level on the producer
(authoritative) side only DNSSEC requirements remain for the consumer
(resolver) side. This behavior is fully expected.
7. Security Considerations
Two known security considerations exist for the BULK resource record,
DNSSEC and DDOS attack vectors. Both are addressed in the following
sections.
7.1. DNSSEC Signature Strategies
DNSSEC was designed to provide verification (validation) for DNS
resource records. In a nutshell this requires each (owner, class,
type) tuple to have its own signature. This essentially defeats the
purpose of providing large generated blocks of RRs in a single RR as
each generated RR would require its own legitimate RRSIG record.
In the following sections several options are discussed to address
this issue. Of the options, on-the-fly provides the most secure
solution and NPN provides the most flexible.
7.1.1. On-the-fly (Live) Signatures
This solution requires authoritative nameservers to sign generated
records _as_they_are_generated_. Not all authoritative nameserver
implementations offer on-the-fly (realtime) signatures so this
solution would either require all implementations to support on-the-
fly signing or be ignored by implementations which can not or will
not comply.
No changes to recursive (resolving) nameservers is required to
support this solution.
7.1.2. Normalized (NPN Based) Signatures
This solution provides the most flexible solution as nameservers
without on-the-fly signing capabilities can still support signatures
for BULK records. The down side to this solution is it requires
DNSSEC aware recursive (resolving) nameserver support. Unless a
recursive nameserver can verify the signature it is _unverifiable_.
It has been pointed out due to this limitation creation of DNSSEC
signed BULK RRs requiring NPN support SHOULD be formally discouraged
until such time a respectable percentage (>80) of DNSSEC verification
(validation) nameservers "in-the-wild" possess NPN processing
capabilities. Until that time, on-the-fly signing and unsigned BULK
records offer the intended capabilities of this document while
requiring zero new features to support RR resolution. The authors
would like to encourage opening this door for pattern based
Woodworth, et al. Expires: August 15, 2017 [Page 28]
Internet-Draft BULK DNS Resource Records February 2017
technologies such as NPN records as a solution to BULK RRs as well as
other pattern based RRs to come. Given enough time, enough
nameservers will be patched and upgraded for unrelated reasons and by
means of simple attrition can supply a level of "inertia" and
eventually widespread adoption can be assumed.
NPN records are likely to be a topic of great debate as to their own
security limitations. It is, however, the authors' belief; while any
logic which limits the input of digital signatures, lessens the
validity of such signatures, the limitation is minimal and the gain
is significant. The main reason for this is as a general rule, RRs
used in a generic manner such as conventional $GENERATE RRs or
scripted mass pattern generated RRs have a lesser importance than
other RRs in managed zones. These therefore inherently pose less
risk by means of attack and have a much less reward by defeating
security measures.
This being said, care must still be taken to set the Ignore fields
appropriately to minimize exposure and only use NPN RRs to secure
pattern-based records such as BULK.
7.1.3. Non-DNSSEC Zone Support Only
As a final option zones which wish to remain entirely without DNSSEC
support may serve such zones without either of the above solutions
and records generated based on BULK RRs will require zero support
from recursive (resolving) nameservers.
7.2. DNSSEC Verifier Details
Verification of DNSSEC signed BULK generated RRs may be performed
against on-the-fly signatures with zero modification to their
behavior. However, verification against NPN records would require
changes to the logic to incorporate processing RDATA generated by
BULK logic as described above so the results will be compatible.
7.3. DDOS Attack Vectors and Mitigation
As an additional defense against Distributed Denial Of Service (DDOS)
attacks against recursive (resolving) nameservers it is highly
recommended shorter TTLs be used for BULK RRs than others. While
disabling caching with a zero TTL is not recommended (as this would
only result in a shift of the attack target) a balance will need to
be found. While this document uses 24 hours (86400) in its examples
values between 300 to 900 are likely more appropriate and is
RECOMMENDED. What is ultimately deemed appropriate may differ from
zone to zone and administrator to administrator.
Woodworth, et al. Expires: August 15, 2017 [Page 29]
Internet-Draft BULK DNS Resource Records February 2017
7.4. Implications of Large Scale DNS Records
The production of such large scale "records in the wild" may have
some unintended side-effects. These side-effects could be of concern
or add unexpected complications to DNS based security offerings or
forensic and anti-spam measures. While outside the scope of this
document, implementors of technology relying on DNS resource records
for critical decision making must take into consideration how the
existence of such a volume of records might impact their technology.
Solutions to the "magnitude" problem for BULK generated RRs are
expected be similar if not identical to that of existing wildcard
records, the core difference being the resultant RDATA will be unique
for each requested Domain Name within its scope.
The authors of this document are confident that by careful
consideration, _negative_side-effects_ produced by implementing the
features described in this document _can_be_eliminated_ from any such
service or product.
8. IANA Considerations
IANA is requested to assign numbers for two DNS resource record types
identified in this document; BULK and NPN.
9. Acknowledgments
This document was created as an extension to the DNS infrastructure.
As such, many people over the years have contributed to its creation
and the authors are appreciative to each of them even if not thanked
or identified individually.
A special thanks is extended for the kindness, wisdom and technical
advice of:
Robert Whelton (CenturyLink, Inc.)
10. References
10.1. Normative References
[US-ASCII] American National Standards Institute, "Coded Character
Set -- 7-bit American Standard Code for Information
Interchange", ANSI X3.4, 1986.
[RFC1034] Mockapetris, P., "Domain names - concepts and
facilities", STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
Woodworth, et al. Expires: August 15, 2017 [Page 30]
Internet-Draft BULK DNS Resource Records February 2017
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS
Specification", RFC 2181, July 1997.
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
NCACHE)", RFC 2308, March 1998.
[RFC2317] Eidnes, H., de Groot, G., Vixie, P. "Classless IN-
ADDR.ARPA delegation", RFC 2317, March 1998.
[RFC2536] Eastlake 3rd, D., "DSA KEYs and SIGs in the Domain Name
System (DNS)", RFC 2536, March 1999.
[RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures
( SIG(0)s )", RFC 2931, September 2000.
[RFC3110] Eastlake 3rd, D., "RSA/SHA-1 SIGs and RSA KEYs in the
Domain Name System (DNS)", RFC 3110, May 2001.
[RFC3597] A. Gustafsson, "Handling of Unknown DNS Resource Record
(RR) Types", RFC 3597, September 2003.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", RFC
4033, March 2005.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, March 2005.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, March 2005.
[RFC5234] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, January 2008.
10.2. Informative References
Authors' Addresses
John Woodworth
4250 North Fairfax Drive
Arlington, VA 22203
USA
EMail: John.Woodworth@CenturyLink.com
Woodworth, et al. Expires: August 15, 2017 [Page 31]
Internet-Draft BULK DNS Resource Records February 2017
Dean Ballew
2355 Dulles Corner Boulevard Suite 200 300
Herndon, VA 20171
USA
EMail: Dean.Ballew@CenturyLink.com
Shashwath Bindinganaveli Raghavan
2355 Dulles Corner Boulevard Suite 200 300
Herndon, VA 20171
USA
EMail: Shashwath.Bindinganaveliraghavan@CenturyLink.com
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Woodworth, et al. Expires: August 15, 2017 [Page 32]