<?xml version="1.0" encoding="us-ascii"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.9 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC1034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml">
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml">
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2181 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml">
<!ENTITY RFC2308 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2308.xml">
<!ENTITY RFC2317 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2317.xml">
<!ENTITY RFC3597 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.3597.xml">
<!ENTITY RFC4033 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml">
<!ENTITY RFC4034 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml">
<!ENTITY RFC4035 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml">
<!ENTITY RFC5234 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC7719 SYSTEM "https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7719.xml">
]>

<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>

<rfc ipr="trust200902" docName="draft-woodworth-bulk-rr-09" category="info" updates="2308, 4033, 4034, 4035">

  <front>
    <title abbrev="BULK RR">BULK DNS Resource Records</title>

    <author initials="J." surname="Woodworth" fullname="John Woodworth">
      <organization>CenturyLink, Inc.</organization>
      <address>
        <postal>
          <street>4250 N Fairfax Dr</street>
          <city>Arlington</city>
          <code>VA 22203</code>
          <country>USA</country>
        </postal>
        <email>John.Woodworth@CenturyLink.com</email>
      </address>
    </author>
    <author initials="D." surname="Ballew" fullname="Dean Ballew">
      <organization>CenturyLink, Inc.</organization>
      <address>
        <postal>
          <street>2355 Dulles Corner Blvd, Ste 200 300</street>
          <city>Herndon</city>
          <code>VA 20171</code>
          <country>USA</country>
        </postal>
        <email>Dean.Ballew@CenturyLink.com</email>
      </address>
    </author>
    <author initials="S." surname="Bindinganaveli Raghavan" fullname="Shashwath Bindinganaveli Raghavan">
      <organization>Hughes Network Systems</organization>
      <address>
        <postal>
          <street>11717 Exploration Lane</street>
          <city>Germantown</city>
          <code>MD 20876</code>
          <country>USA</country>
        </postal>
        <email>shashwath.bindinganaveliraghavan@hughes.com</email>
      </address>
    </author>
    <author initials="D.C." surname="Lawrence" fullname="David C Lawrence">
      <organization>Oracle</organization>
      <address>
        <email>tale@dd.org</email>
      </address>
    </author>

    <date year="2019" month="July"/>

    <area>Internet</area>
    <workgroup>DNSOP Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<t>The BULK DNS resource record type defines a method of pattern-based
creation of DNS resource records based on numeric substrings of query
names.  The intent of BULK is to simplify generic assignments in a
memory-efficient way that can be easily shared between the primary and
secondary nameservers for a zone.</t>



    </abstract>


    <note title="Ed note">


<t>Text inside square brackets ([]) is additional background
information, answers to frequently asked questions, general musings,
etc.  They will be removed before publication.  This document is being
collaborated on in GitHub at
&lt;https://github.com/ioneyez/bulk-rr&gt;.  The most recent
version of the document, open issues, etc should all be available
here.  The authors gratefully accept pull requests.</t>


    </note>


  </front>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The BULK DNS resource record defines a pattern-based method for
on-the-fly resource record generation.  It is essentially an enhanced
wildcard mechanism, constraining generated resource record owner names
to those that match a pattern of variable numeric substrings.  It is
also akin to the $GENERATE master file directive <xref target="bind-arm"/> without
being limited to numeric values and without creating all possible
records in the zone data.</t>

<t>For example, consider the following record:</t>

<figure><artwork><![CDATA[
example.com. 86400 IN BULK A (
                      pool-A-[0-255]-[0-255].example.com.
                      10.55.${1}.${2}
                   )
]]></artwork></figure>

<t>It will answer requests for pool-A-0-0.example.com through
pool-A-255-255.example.com with the IPv4 addresses 10.55.0.0 through
10.55.255.255.</t>

<t>Much larger record sets can be defined while minimizing the associated
requirements for server memory and zone transfer network bandwidth.</t>

<t>This record addresses a number of real-world operational problems that
authoritative DNS service providers experience.  For example,
operators who host many large reverse lookup zones, even for only IPv4
space in in-addr.arpa, would benefit from the disk space, memory size,
and zone transfer efficiencies that are gained by encapsulating a
simple record-generating algorithm versus enumerating all of the
individual records to cover the same space.</t>

<t>Production zones of tens of thousands of pattern-generated records
currently exist, that could be reduced to just one BULK RR.  These
zones can look deceptively small on the primary nameserver and balloon
to 100MB or more when expanded,</t>

<t>BULK also allows administrators to more easily deal with singletons,
records in the pattern space that are an exception to the normal data
generation rules.  Whereas a mechanism like $GENERATE may need to be
adjusted to account for these individual records, the processing rules
for BULK have explicit records more naturally override the dynamically
generated ones.  This collision problem is not just a theoretical
concern, but a real source of support calls for providers.</t>

<t>Pattern-generated records are also not only for the reverse DNS
space.  Forward zones also occasionally have entries that follow
patterns that would be well-addressed by the BULK RR.</t>

<section anchor="background-and-terminology" title="Background and Terminology">

<t>The reader is assumed to be familiar with the basic DNS and DNSSEC
concepts described in <xref target="RFC1034"/>, <xref target="RFC1035"/>, <xref target="RFC4033"/>,
<xref target="RFC4034"/>, and <xref target="RFC4035"/>; subsequent RFCs that update them in
<xref target="RFC2181"/> and <xref target="RFC2308"/>; and DNS terms in <xref target="RFC7719"/>.</t>

<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119"/> when, and only when, they appear in all capitals, as shown
here.</t>

</section>
</section>
<section anchor="the-bulk-resource-record" title="The BULK Resource Record">

<t>The BULK resource record enables an authoritative nameserver to
generate RRs for other types based upon the query received.</t>

<t>The Type value for the BULK RR type is TBD.</t>

<t>The BULK RR is class-independent.</t>

<section anchor="bulk-rdata-wire-format" title="BULK RDATA Wire Format">

<t>The RDATA for a BULK RR is as follows:</t>

<figure><artwork><![CDATA[
                     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                      /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>

<t>Match Type identifies the type of the RRset to be generated by this
BULK record.  It is two octets corresponding to an RR TYPE code as
specified in <xref target="RFC1035"/>, Section 3.2.1.</t>

<t>Domain Name Pattern consists of a pattern encoded as a wire-format
fully qualified domain name.  The full name is used so that numeric
substrings above the zone cut can be captured in addition to those in
the zone.  It needs no length indicator for the entire field because
the root label marks its end.</t>

<t>Special characters are interpreted as per the following Augmented
Backus-Naur Form (ABNF) notation from <xref target="RFC5234"/>.</t>

<figure><artwork><![CDATA[
match         =  1*(range / string)

range         =  "[" [decnum "-" decnum] "]" /
                  "<" [hexnum "-" hexnum] ">"
                      ; create references for substitution
                      ; limit of 32 references
                      ; [] is syntactic sugar for 0-255
                      ; <> is syntactic sugar for 00-ff

string        =  1*(ctext / quoted-char)

decnum        =  1*decdigit
                      ; constrained to 65535 maximum.

hexnum        =  1*hexdigit
                      ; constrained to ffff maximum.

octet         =  %x00-FF

decdigit      =  %x30-39
                      ; 0-9
hexdigit      =  decdigit / 0x41-0x46 / 0x61-66
                      ; 0-9, A-F, a-f

ctext         =  <any octet excepting "\">

quoted-char   = "\" octet
                       ; to allow special characters as literals
]]></artwork></figure>

<t>Interpretation of the Domain Name Pattern is described in detail in
the "BULK Replacement" section.  Note that quoted-char must be stored
in the wire format to preserve its semantics when the BULK RR is
interpreted by nameservers.</t>

<t>The limit of 32 references is meant to simplify implementation
details.  It is largely but not entirely arbitrary, as it could
capture every individual character of the text representation of a
full IPv6 address.</t>

<t>Replacement Pattern describes how the answer RRset MUST be generated
for the matching query.  It needs no length indicator because its end
can be derived from the RDATA length minus Match Type and Domain Name
Pattern lengths.  It uses the following additional ABNF elements:</t>

<figure><artwork><![CDATA[
replace       =   1*(reference / string)

reference     =   "$" "{" (positions / "*") [options] "}"

positions     =   (position / posrange) 0*("," (position / posrange))

posrange      =   position "-" position

position      =   1*decnum

options       =   delimiter [interval [padding]]

delimiter     =   "|" 0*(ctext | quoted-char)
                        ; "\|" to use "|" as delimiter
                        ; "\\" to use "\" as delimiter

interval      =   "|" *2decdigit

padding       =   "|" *2decdigit

]]></artwork></figure>

<t>[ Is the formatting complexity beyond simple ${1}, ${2}, etc, really
worth it?  I definitely see how it could make for shorter replacement
patterns, but does it enhance their clarity and usability, adding a
feature someone really wants? ]</t>

<t>The Replacement Pattern MUST end in the root label if it is intended
to represent a fully qualified domain name.</t>

</section>
<section anchor="the-bulk-rr-presentation-format" title="The BULK RR Presentation Format">

<t>Match Type is represented as an RR type mnemonic or with <xref target="RFC3597"/>'s
generic TYPE mechanism.</t>

<t>Domain Name Pattern is represented as a fully qualified domain name as
per <xref target="RFC1035"/> Section 5.1 rules for encoding whitespace and
other special characters.</t>

<t>Replacement Pattern is represented by the standard &lt;character-string&gt;
text rules for master files as per <xref target="RFC1035"/> section 5.1.</t>

<t>It is suggested that lines longer than 80 characters be wrapped with
parenthetical line continuation, per <xref target="RFC1035"/> Section 5.1, starting
after Match Type and ending after Replacement Pattern.</t>

</section>
</section>
<section anchor="bulk-replacement" title="BULK Replacement">

<t>When a BULK-aware authoritative nameserver receives a query for which
it does not have a matching name or a covering wildcard, it MUST then
look for BULK RRs at the zone apex, selecting all BULK RRs with a
Match Type that matches the query type and a Domain Name Pattern that
matches the query name.  Note that query type ANY will select all
Match Types, and all query types match a CNAME or DNAME Match Type.
One or more answer RRs will be generated per the replacement rules
below.  Examples are provided in an appendix.</t>

<t>By only triggering the BULK algorithm when the query name does not
exist, administrators are given the flexibility to explicitly override
the behaviour of specific names that would otherwise match the BULK
record's Domain Name Pattern.  This is unlike BIND's $GENERATE
directive, which adds the generated RRs to any existing names.</t>

<section anchor="matching-the-domain-name-pattern" title="Matching the Domain Name Pattern">

<t>A query name matches the Domain Name Pattern if the characters that
appear outside the numeric ranges match exactly and those within
numeric ranges have values that fall within the range.  Numeric
matches MUST be of the appropriate decimal or hexadecimal type as
specified by the delimiters in the pattern.  For example, if a range
is given as [0-255], then FF does not match even though its value as
a hexadecimal number is within the range.  Leading zeros in the
numeric part(s) of the qname MUST be ignored; for example,
001.example.com, 01.example.com and 1.example.com would all match
[].example.com.</t>

<t>When a query name matches a Domain Name Pattern, the value in each
numeric range is stored for use by the Replacement Pattern, with
reference numbers starting at 1 and counting from the left.  For
example, matching the query name host-24-156 against
host-[0-255]-[0-255] assigns 24 to ${1} and 156 to ${2}.</t>

</section>
<section anchor="record-generation-using-replacement-pattern" title="Record Generation using Replacement Pattern">

<t>The Replacement Pattern generates the record data by replacing the
${&#8230;} references with data captured from the query name, and copying
all other characters literally.</t>

<t>The simplest form of reference uses only the reference number between
the braces, "{" and "}".  The value of the reference is simply
copied directly from the matching position of the query name.</t>

<t>The next form of reference notation uses the asterisk, "*".  With
${*}, all captured values in order of ascending position, delimited by
its default delimiter (described below), are placed in the answer.
The commercial-at, "@" symbol captures in the same way only in
order of descending position.</t>

<t>Numeric range references, such as ${1-4}, replaces all values captured
by those references, in order, delimited by the default delimiter
described below.  To reverse the order in which they are copied,
reverse the upper and lower values, such as ${4-1}.  This is useful
for generating PTR records from query names in which the address is
encoded in network order.</t>

<t>Similar to range references, separating positions by commas creates
sets for replacement. For example, ${1,4} would be replaced by the
first and fourth captured values, delimited its default delimiter.
This notation may be combined with the numeric range form, such as 
${3,2,1,8-4}.</t>

<section anchor="delimiters" title="Delimiters">

<t>A reference can specify a delimiter to use by following a vertical
bar, "|", with zero or more characters.  Zero characters, such as in
${1-3|}, means no delimiter is used, while other characters up to an
unescaped vertical bar or closing brace are copied between position
values in the replacement.  The default delimiter is the hyphen, "-".</t>

</section>
<section anchor="delimiter-intervals" title="Delimiter intervals">

<t>A second vertical bar in the reference options introduces a delimiter
interval.  The default behavior of a multi-position reference is to
combine each captured value specified with a delimiter between each.
With a delimiter interval the delimiters are only added between every
Nth value.  For example, ${*|-|4} adds a hyphen between every group of
four captured positions.  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 0
value for the delimiter interval MUST be interpreted as the default
value of 1.</t>

</section>
<section anchor="padding-length" title="Padding length">

<t>The fourth and final reference option determines the field width of
the copied value.  Shorter values MUST be padded with leading zeroes
("0") and longer values MUST be truncated to the width.</t>

<t>The default behavior, and that of an explicit empty padding length, is
that the captured query name substring is copied exactly.  A width of
zero "0" is a signal to "unpad", and any leading zeros MUST be
removed. [ Unnecessary complexity? ]</t>

<t>If a delimiter interval greater than 1 is used, captured values
between the intervals will be concatenated and the padding or
unpadding applied as a unit and not individually.  An example of this
would be ${*||4|4} which would combine each range of 4 captured values
and pad or truncate them to a width of 4 characters.</t>

<t>[ If this is kept, the element/feature should probably be renamed
from "padding" since it is just as likely to truncate. ]</t>

</section>
<section anchor="final-processing" title="Final processing">

<t>The string that results from all replacements is converted to the
appropriate RDATA format for the record type.  If the conversion
fails, the SERVFAIL rcode MUST be set on the response, representing a
misconfiguration that the server was unable to perform. [
The EDNS extended-error code would be useful here. ]</t>

<t>The TTL of each RR generated by a BULK RR is the TTL of the
corresponding BULK record itself.  [ BULK should probably have its
own TTL field because using that of the record itself feels like bad
design.  On the other hand, if BULK is never meant to be queried for
directly and only appears in authoritative data, its own TTL is pretty
useless normally. ]</t>

<t>The class for the RRSet is the class of the BULK RR.</t>

<t>If the generated record type is one that uses domain names in its
resource record data, such as CNAME, a relative domain names MUST be
fully qualified with the origin domain of the BULK RR.</t>

</section>
</section>
</section>
<section anchor="known-limitations" title="Known Limitations">

<t>This section defines known limitations of the BULK resource type.</t>

<section anchor="unsupported-nameservers" title="Unsupported Nameservers">

<t>Authoritative nameservers that do not understand the semantics of the
new record type will not be able to deliver the intended answers even
when the type appears in their zone data This significantly affects
the interoperability of primary versus secondary authorities that are
not all running the same software.  Adding new RRs which affect
handling by authoritative servers, or being unable to add them, is an
issue that needs to be explored more thoroughly within dnsop.</t>

</section>
</section>
<section anchor="security-considerations" title="Security Considerations">

<t>Two known security considerations exist for the BULK resource record,
DNSSEC and DDOS attack vectors.</t>

<section anchor="dnssec-signature-strategies" title="DNSSEC Signature Strategies">

<t>DNSSEC was designed to provide validation for DNS resource records,
requiring each tuple of owner, class, and type 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.</t>

<t>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 <xref target="npn-draft"/> provides the most flexible.</t>

<section anchor="on-the-fly-signatures" title="On-the-fly Signatures">

<t>A significant design goal of DNSSEC was to be able to do offline
cryptographic signing of zone contents, keeping the key material more
secure.</t>

<t>On-the-fly processing requires authoritative nameservers to sign
generated records as they are created.  Not all authoritative
nameserver implementations offer on-the-fly signatures, and even with
those that do not all operators will want to keep signing keys online.
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.</t>

<t>One possibly mitigation for addressing the risk of keeping the zone
signing key online would be to continue to keep the key for signing
positive answers offline and introduce a second key for online signing
of negative answers.</t>

<t>No changes to validating resolvers is required to support this
solution.</t>

</section>
<section anchor="alternative-signature-scheme" title="Alternative Signature Scheme">

<t>Previous versions of this draft proposed a new signature scheme using
a Numeric Pattern Normalization (NPN) RR.  It was a method to support
offline signatures for BULK records, with the drawback that is
required updates to DNSSEC-aware resolvers.</t>

<t>That mechanism is not specific to BULK and has been removed from the
current draft.  If there is further interest in pursuing it, it can be
reopened as a separate draft.</t>

</section>
<section anchor="non-dnssec-zone-support-only" title="Non-DNSSEC Zone Support Only">

<t>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 resolvers.</t>

</section>
</section>
<section anchor="ddos-attack-vectors-and-mitigation" title="DDOS Attack Vectors and Mitigation">

<t>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 seconds) in its
examples, values between 300 to 900 seconds are likely more
appropriate and is RECOMMENDED.  What is ultimately deemed appropriate
may differ from zone to zone and administrator to administrator.</t>

<t>[ I am unclear how this helps DDOS mitigation against anyone at all,
and suspect this section should be removed.. ]</t>

</section>
<section anchor="implications-of-large-scale-dns-records" title="Implications of Large-Scale DNS Records">

<t>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, implementers 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.</t>

<t>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.</t>

<t>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.</t>

</section>
</section>
<section anchor="privacy-considerations" title="Privacy Considerations">

<t>The BULK record does not introduce any new privacy concerns to DNS
data.</t>

</section>
<section anchor="iana-considerations" title="IANA Considerations">

<t>IANA is requested to assign numbers for the BULK RR.</t>

</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>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.</t>

<t>A special thanks is extended for the kindness, wisdom and technical
advice of Robert Whelton (CenturyLink, Inc.) and Gary O'Brien
(Secure64 Software Corp).</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>

&RFC1034;
&RFC1035;
&RFC2119;
&RFC2181;
&RFC2308;
&RFC2317;
&RFC3597;
&RFC4033;
&RFC4034;
&RFC4035;
&RFC5234;


    </references>

    <references title='Informative References'>

&RFC7719;
<reference anchor="bind-arm" target="https://ftp.isc.org/isc/bind9/cur/9.9/doc/arm/Bv9ARM.html">
  <front>
    <title>BIND 9 Configuration Reference</title>
    <author >
      <organization>Internet Systems Consortium</organization>
    </author>
    <date year="2016"/>
  </front>
</reference>
<reference anchor="npn-draft" target="https://github.com/ioneyez/npn">
  <front>
    <title>Numeric Pattern Normalization (NPN)</title>
    <author >
      <organization>Internet Systems Consortium</organization>
    </author>
    <date year="2019"/>
  </front>
</reference>


    </references>


<section anchor="bulk-examples" title="BULK Examples">

<section anchor="example-1" title="Example 1">

<figure><artwork><![CDATA[
$ORIGIN 2.10.in-addr.arpa.
@ 86400 IN BULK PTR (
          [0-255].[0-255].[0-255].[0-255].in-addr.arpa.
          pool-${4-1}.example.com.
        )
]]></artwork></figure>

<t>A query received for the PTR of 4.3.2.10.in-addr.arpa will create the
references ${1} through ${4} with the first four labels of the query
name.  The ${4-1} reference in the replacement pattern will then
substitute them in reverse with the default delimiter of hyphen
between every character and no special field width modifications.  The
TTL of the BULK RR is used for the generated record, making the
response:</t>

<figure><artwork><![CDATA[
4.3.2.10.in-addr.arpa 86400 IN PTR pool-10-2-3-4.example.com.
]]></artwork></figure>

</section>
<section anchor="example-2" title="Example 2">

<figure><artwork><![CDATA[
$ORIGIN 2.10.in-addr.arpa.
@ 86400 IN BULK PTR (
          [0-255].[0-255].[0-255].[0-255].in-addr.arpa.
          pool-${2,1|||3}.example.com.
        )
]]></artwork></figure>

<t>Example 2 is similar to Example 1, except that it modifies the
replacement pattern.  The empty option after the first
vertical bar causes no delimiters to be inserted, while the second
empty option that would keep the delimiter interval as 1.  The latter
is relevant because the final value, padding of 3, is applied over
each delimiter interval even when no delimiter is used.  Not all
captures from the substring are required to be used in the response.</t>

<t>The result is that a query for the PTR of 4.3.2.10.in-addr.arpa
generates this response:</t>

<figure><artwork><![CDATA[
4.3.2.10.in-addr.arpa 86400 IN PTR pool-003004.example.com.
]]></artwork></figure>

<t>[ Admittedly you can't do this very effectively without the field
width complexity. Is this sort of name common?  Does it need support?
Admittedly $GENERATE had the feature, but is that reason enough? ]</t>

<t>[ Change this to a hex matching example? ]</t>

</section>
<section anchor="example-3" title="Example 3">

<figure><artwork><![CDATA[
$ORIGIN 0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
@ 86400 IN BULK PTR (
          <>.<>.<>.<>.<>.<>.<>.<>.<>.<>.<>.<>.<>.<>.<>.<>
          poolAA-${16-8|-|4}.example.com.
        )
]]></artwork></figure>

<t>This example introduces IPv6 where 16 individual nibbles are captured
and the last 8 are combined into 2 blocks of 4, separated by a hyphen.</t>

<t>A query for the IP of 2001:db8::dead:beef results in a PTR RR with
the value of poolAA-dead-beef.example.com.</t>

</section>
<section anchor="example-4" title="Example 4">

<figure><artwork><![CDATA[
$ORIGIN example.com.
@ 86400 IN BULK AAAA (
          poolAA-<0-ffff>-<0-ffff>.example.com.
          ${@|.|1}.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.
        )
]]></artwork></figure>

<t>This example performs the reverse of example 3, where a query of
poolAA-dead-beef.example.com captures "dead" and "beef", reversing
the nibbles and using a dot (.) as the delimiter to form a valid
AAAA record.</t>

</section>
<section anchor="example-5" title="Example 5">

<t>This example contains a classless IPv4 delegation on the /22 CIDR
boundary as defined by <xref target="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:</t>

<figure><artwork><![CDATA[
$ORIGIN 2.10.in-addr.arpa.
@    7200 IN BULK CNAME [0-255].[0-3] ${*|.}.0-3
0-3 86400 IN NS ns1.sub.example.com.
]]></artwork></figure>

<t>A query for the PTR of 25.2.2.10.in-addr.arpa is received and the BULK
record with the CNAME Match Type matches all query types.  25 and 2
are captured as references, and joined in the answer by the period
(".") character as a delimiter, with ".0-3" then appended literally
and fully qualified by the origin domain.  The final synthesized
record is:</t>

<figure><artwork><![CDATA[
25.2.2.10.in-addr.arpa 7200 IN CNAME 25.2.0-3.2.10.in-addr.arpa.
]]></artwork></figure>

<t>[ Without $* and options complexity, the pattern to get the same
result is just ${1}.{$2}.0-3 which is not really significantly onerous
to enter, and slightly less arcane looking to comprehend. ]</t>

</section>
</section>


  </back>

<!-- ##markdown-source:
H4sIAF7VMl0AA8V86XcbN7bnd/wVOGzPaTtD0tTmrTPpyJad9nu27JGczukX
5/QpkqBYT8UqplAlmbE1f/vc370XKBRFOenpDyMv4oICLu6+AaPRyDR5U7hn
9vmPb/7Tnpye2zPnq7aeOXoxq+q5N9l0WrsrHXF2ZubVrMxW9Mi8zhbN6Lqq
5tdV3SxH07a4HNX1aPLUzLOGBuxP9p6OJo+Nydf1M9vUrW/2J5Onk32T1S57
Zl+XjatL15jri2dY+917+1NVX+blhf2hrtq1ubzuBo1OsJyZZc0zm5eLypp2
jWU8rXMweTK0h5ODA/7/kP8/MmZWzWmuZ7b1o8zP8tys82fG2pFtqhn/9ptV
7RZeXtMe+I3J2mZZ1TyS/llajdb4jzHBpjvlTwUH/1Ety60vqpqWfOHKpq03
b/LyckhbmI35K08rOIL/cP9oYk/tqyyvF9kne1Lzt7O82Tyzx3VBQDdVKZ9V
c1rl78d2f39/cqAftWVT08gfz4/5A7fK8kJAGUdQvk8gGM+qlelv52Rsn2dF
4a6TvZy4rEw//QMb2T84OrInLT3i7YuKyFTb58XVfGjPG0fkn9iDySTZ29+I
kvNbO5vsPd776s4A2FgA+51tndO28hJUz8rsyhW5PcsultlVVib7PF9mfnmd
NcuvjuXd/629WNLWTl1DSL205xvfuJXvoWCPoH9sX35aF1WdNXlV2jdZ6ZJN
/+DqVVY21XW677cntO8njx99dd8+ADqe9gCtFc7vlwzeTvK+GBMc17UrZy4l
cXaVz+2L/le803d1NitcunqTFe77+XxMXxtTVrSJJr9yEIt6MdsjMeteHunL
/b29p/Hlk73wksQzvtx7rC8Pjp6Gl5Dc7uVh9zLMe7SPTw3Evg/G48eyIPAz
yurVM95AUGmvT0/sU+LLcpFftEqcM7dw3dY7UY+ICPomEBvPQzfk7YqHRdUm
tGuy+gJssGyatX/28OGiWY9zPwPWHtLvh4Ds6cNZWz98On76kHTnQwLz4fOr
p8dnb8fLZlXQLOW6HLEy7YF/2q5cnc/s+6wBRPYUey/y32Qf90/fnz74t/fw
dOceLvJm2U7BVg9pKbdxvz0kEI0ZjUY2mxLjZ7PGmA9L11mNOliNmq2GbTZr
Z+dukZckPpldOYJxbquFXctuRtPMu7mZkR3g7dA3O6bxlodZGlAqNnwLAEgW
PJ75tXX1xoC3/dhaQJTT1ssG3zFsuSdlb32+Whf5YmMvXMmzZN7nF+WKRnp6
wmZm5VZVvRm5xSKf5ZjgOtvYZpk1dkZKceqsy3xebCCSNQE0JYXgXEkjnF3X
+SqrNzYr58YT2OUc7xgmV1+52lviWsLBb4RK1p6Mx7Jq3D9fzv+J34RL96mB
5OZzZ/2vLa1hp4TlS0fw3f/488dfHmAn2XyeA1tZQXiZXV6QjaQ1o1RU5ZCA
8NdYkja9qB2hp2wI6sxfEtD0zmOUHwoeaJpV64HKoXHNTBC4sdd5UWDHNaHk
ivdK89M222mRz3gZHknwEDe3wCFgmzqaiCxuUWRTKEKhGuH2h7z5Wzu1WWM+
fvsVBlPn4eN3SsdV5RtwAU1vgERlEiA8LDu01ZpokHtPGxta2gKRp2qLuc1k
B6QjcwKH1NqSZF4nFnHx9gJALsh0EXpmM7duaIf0GCPNN34s7L7K53N63vwJ
MlVX83YGBPwO83d83+P2IAWETlOVI9rKaEGrbz8ttFE8v2bkOu9pv3nGwJbW
lcuMNNjcEKnms6zGzDP6KPerIRmTEhKal3CjdC5ae3sVMkdkrJlLDTELAead
MDyx0mzZwQ6sX2V1DjzukMIAo8kKX9mMnDfL0zl774eXpy/Pjj+8pBlJC9V2
kdMM85wAgAa3nz8HrX1zQ0xHELSNYTayRb7KATTNFFa8yooWKC3nYawV5UHD
Qe51RSINUgfNkYt0Quqg7zIi6CuSQ/cpI13gBE8kbjWPWhDfVteYSx4nY/N/
6MfoaHDq2D55dEgezetTIfyxva8qd/tnXVXF6Hj082S0f3T0S/g9Tue648m9
yfjoaHzv894N/bd/s2vUAwHMENJZUEXgI9uyrlEAJqNJuihtlBTGxdLo1wQU
/vWGALWMkNfvrw6hb2qwnlfAJuNJnEQ+2dd/xrxtiWkKGJI6sJiH9lL1KSJB
tFuCCVbEnav8N+Abi5E2rmY52NRgH8QhopmxF9GhVvQzk58pShxe+gU4WF2z
KX11nc/JV4JwkswoEN0eMvDSlB4hhibOKShyqUlXkA4RaSN1uK4rYiGylxAE
jQPyhh0OFnQAk8+g8qsr8A5J5id6PIc/QYKQ8peReaFprpeVXUKdkRu4ERwR
AFBqzhZVddmueU9QYVekz7DrqiRJBw2MX2czWDX6O8Jexlm9zob2mvXclMR7
kTek6pm8kC5/afmRYUCZz38jaG4jLpg6+if7tbA6FxmTabohJTPL1r4tVMQM
29CgPkZBSbH0XQBLy5XFllrCCctsJ5qitg1cWMJamxXRupN8z6orlUFPukhg
JxK+j7pWcMOTuFJ+k/R72pBP/YlU00ncSj5XLebPfco9WQsx54o4GkYLiI75
bwpMLZCjIa5YCu+MLA0WBp2IiWEniBngCKx4a30XoDP6zKlTGlKRtaAl9iaT
t8/JOSO7Rli+XhKdiXVokJsPjeF1RYFCD8HSQ0Sgx5mDaAJ+Tp2QOXGviCqs
d+Ea2PRtxRfUtzBQJDDMxyfeRhU1NTv3BWtJ01kfW7cFu1U/wXpm4sapmSEN
fdnX8LR5J9icOpPNgVJ5S8YV4Q2zdQOs2tuMMFQsVjMSVdbCWNrgEUYNRTsO
+CIHJG8i9zBKyozCQTaMYKQaDhQLwoZoQe4KfWE61gA5g/MCVyVnt0KlHoaW
vDHhhgyz0PwN5iC3hgS8Jvdq2uIraA+r5pRY0LfrNTnXFqupAg76AZx8F4MK
OUB0rMoSrziK2oF0jigAUS7XMPXCk/xcNZtlnjUXPSs4IiclyrMYNaOMoB8G
xWGvXVGMgnZkiW+WnQSQx/Mn+zw6mczOHyiQzcuqqC424gARHmBA4ZmSD7YK
5LcLQn2RZ3VnTsj/IRsOFYqJ6Pf5yxeC1TXp+bnzszqf0vPEu58/n716gfDy
5mYY3xzFN4gV6Y0Jb3gYJg0f0NC/sH8i3q+lT3Xrki8CPETrUmZAmEruR5wA
sSomUDBJ59QrH8FCuHlzM5bdX8JXZkIO3v54/mEwlN/29B2/Pnv5v398ffby
BK/P/3b85k18ISMMvXn34xv9Hq+6J1+8e/v25emJPEyf2q2P3h7/Y8C7NoN3
7z+8fnd6/GYgcp965eAvIQiConpN3Ewozvr4DmjAxlgvCTaZHeVtg6AgW68d
ERSxEqk9sgxkFguSW5qNfO7rUjxs+MnRM95KJCY+87Yv6ko4l3DubN/mJvq0
qaIcE3+KmFUEWs2hZggU27VqZA4MOX6geeZKsQ8IStmRjJKm/C7xKiHvw/OT
cQIpfQNVURB/j0htOYo35oRaFQ8ecXL84dj+RD4LJJR8Z3laPpbAL5kp8yqV
PniYu/3AHX/2d/w5sAfGTvjLA3toj+wj+9g+sU//lc/M/xz9m3/MlwT0txw9
MKbjz5dbG+z/PPx9GHTkSbUiB8WewlUIeRGZ4eHvrPF7P38Aht/Fw78Pwx0z
nLl1QVaApTrd9h+f4V+A4d/Hg0QoCSfkEJp8IZbJibBpME+y7BpVU52JZGtE
QaWqC2iJGAyTv0+Wr+HgoiIXz5PMzzmUqKBBSNA+/OP9S86zkryR/XQzLN0z
LmxPzp04mAfj/fEeifQu5uIoEXEVgduFxOQb0+ysSzMycjUF8iL7kk/4lVwb
WXIuU0KPafoBI/g9ttJCZ/lKzJNGuibJcGVTcmq6MHbWxnQUaWDye2RTIS1k
YxxPaj08JGiDbwbvxhauvCCbDBdsBt8yKkIQiHQYQc3uwSwj2HiSuiLvpMim
riAvr74kY9jAxYdOPQdqyRUipxApQcRDsDlb1mZ9K8Y+bi/AyhTuwcNo/eg0
a2tWn/b+8fPTVw/gEYkPypENUw05YLa9zF2SpAg//4tU5jf3KbKhyOqhFew9
MEY+SAYNfh7Yn8mLJ1TbwWhg5eUvdvDLgBj/tjAMvqXxS/cpjJeXNP67wR0R
/F8kKwHTpnlmDWNB1LxpOXt016Oc9gCnHewnz985/OdfwEN+UzaEfE7KXGRC
UM443Pnct9/d+dxktFgYIwjsI5fI+6kh5P7aVkS4EUhOGFZcpiPpo3l+kTd3
IygkqMRffHR0dHBErPUpX7UrIq+iO52SPvqXplzQTzIjKwubzPg/PtFGX71i
8Hni5JuDyejg6Z0LTUZPTYAmPhRneWgnnw73RvTfI379aG/06NHX5hra49Er
cqJGhHRBcALlt8gWCOwasRFNBh8H3xmTEIHH0qcy8o7FaLVGY0vrdwitJ9Zr
kBD2IbsURDhm5yHBuxRkvuW+z+mZvAgaaKCeYDRfA+tF65JeOq0aDUzT/awQ
fpGG86SdHLLbvPQ1KydWstgKgcZ+ISsj71Bfy2de4uqm57yZVBtNe3l5dfR2
Sx02tnI0b69+wDkQ7IPxYmSzMQcquR0yAAgTEdSJUkXStp7mxKD1hj3mXNMQ
RrU48j7krSZxcSROQD0zR+1432VHlYwtDjJFj0Kmi3a1y10IRPKW3HXJuknm
UAwwRy6pCTbBMLCmBeuxS/175kQtRzASJqb/avjhXaJK/GN9nKLK1qeeI0df
HbOFGFrHK75br+5EZ1iSAgnsiHVCrOhs14KYTsbYbASa90xH/DCMHNwb2MHn
gb2/rjwv4mn84JvBA/tzxdkUT3bhZmBM9314ND5CT9BLNksP7OSb+4PhYPeX
D3iaxH5hmjgQpii86dZLNyV6mVTfuoNEvps7Sa7X9meWDAqH7M9rIK68+OUX
qMTwfdz4lwFgFf30pW8A7lA3pG8GH+kxEh0wA2bgsFOn/upjH7vHPm49ZiLE
PeC+2Y82x+hO7N0jRMF9/Nm+DtwDpcLKdVZBvD/lDUmw25BXaTXpiYz80CIl
z2WmIWeAio3hTgvi9b8SQ0qKm+BEctA5FrMg6CRElxJzUrBcN5wijyIaEzSS
XppXjjWEFnkAY14jBK0BFySj9dk0J4UNZSK7JTXgMtYkvlo5uIoCoL0mBeb/
aj/+olHpDsXAkk+iGvKGib+XLwBI7qWoSg4vMplRCZHr+zV3l0PkNJB+n+qu
ECunQYLv5lbfuoyh+ap0q6okZ6XSrBL7hOghuLn5szehrsuef8xS3uHT71jo
aztBEAEfNokdYuhwNN6TXCUTl8MC0ON6SXwgiVckaSRPcdvw3qGqt+DTzJxv
MlSW5/bjt3GGkeir74yYhwhIUnDzwQVPwfcd+GMuJcEfbC8unCRtYZILrmAW
VXnB7juR4skk9RmQQayRFZJ6HDExku1LSZjy0/DKSKxarUx/BYVDbK6GCJps
AcC3TIGT+E6+24ExzjttexrG/ARvQNIvo+yas613ZZc0UQROkMwRsEhUnC1N
riIJe8451qwzicwenOPhMgaTXkuyQ4gOyxYhpTRcP4j5bCSw4MiEwC5bu0+E
BDJXs1g1iQOZ3bNUUroyrVpAgbkJ+Mp2empc07r9lMamqTMWJzs+/YdUGQU0
wJXA4SVVCGC7Z3ysH784PX77Etg54Rfdc2PzrnSxFtK5IbHzoMsDhNgxUZda
GyD9VF0T3C+l3iaRp+bdJSouOWlJrPOJ+OP5RlKaJC/E5nWoPGrhJRSwov/Y
oSYS32gVaas0w0Wz/EqfW8B8iHKGFQsli6Q6wW7x1BEn5VXL7p0mKGbCj2mW
nvXGde7VCYsQa6nnz34XnUN9A+mFkss06IOisbFaY2INfig8DjMiLNFhHvTg
hIqWzwK7e1Hsb4MI3BEXGHOcIjFlu50qWbzcRL9IBVayzlXb+FDYCf0A7BsF
ZnOf6KlCrKNkQCA0FINsjWb51U4CKZGAeWWs8BnGQRo0FxPgDu6xeuMEV12t
a5SsEf3lqJ4RP1NkmIW3Ioxp+kn1eHRntit1WwVk4CQTgAzRUniMdPlH7Sfg
xDwZ0ledelJkCDOiSs9uuCS8CZSsB6AWw3O/a/9vXMYq9zdXVwHOiExS9c19
/yAg41emcMBQflEibvuLGMRQDJ9M9tI+g6Htv2fC9T+5jo08vCty2LY6KIJ6
38FlO/Wf1BgFGfSVy2jSHnuwEeSgk2GHB6ok22FyhmL1ujBB0OmjJYN+3+N9
cfkTn8Tgp3CLRqhtIrVXqUAle0LjwGj/cLR3RBEeqvO+MfxZ4IP4QpvavN0/
hOTCZxW80pP8fv9GZFfqMfaHrtLLXWC7tnm32xg0hVf9LI1PWZMBaaKudTfm
3ufxeHyTxtZs0nhwzGNG5HR7Hyr61hv2DFBuZ0cq0RKatig2GsuLv+652ryS
Ro9AIA4XxQYsk/RckAPt6BP1TNPDuiHcAwgU1mn2VthHGb+bA5yDlTeGoGX3
kTUsKrphW5G+MVwL4tNZYdlDCV/uNvwxJRrjXnbycn9JgH78BhD+BJa89/nj
NyiJSplOkKsqj9ieqCRJhczP1K0KAA2jaoKuMjkXZhdZWzRJ0Hi/S/awBX4w
FMML/oghhJj0Me+GZJVkDI7vKCPrOfh+gK77aRWhi2qQ+z/QdslEIuUdYcWa
W8ASrk57wttxFzlS6EUiVUkiMDq8GQbvwTNSFBcBN4ZlHCYjnSFgqo8T1d9b
ODFbKAGrVLGEj0dkIzSnWFspqNbADZgFnRvd2Ha91u4RmopeCbjpnkgX3KRG
3qOLkdM1SVPO+w9nsc+AebBjM9+DJKSNkCoLZQ0EPtpWxaAj1U97pRAUimQH
vh2ZBFm3S34QukB7Alky4mQKnfZ0Jd7cuG/ziGLDw5uuSUFHBuSbRV6jOaOE
im4Re2+xeEqvnQw8luawKExoXJkyl06lPy10LPRNA8SxowHJ2MFwf7g3fELs
xTr1T/YkmnW4Pp3YIgEmPgDRPBEkzXFMN2n6Ch1U0nEyzYj3Bl8GYmfYDkeP
OQkgrf0vfNN90gFJAgT+P/hyM+REJufruvW1+jTUjrxbmrVdi/tnWooDCctA
sQJnp/DJkJOo2G6wukwYOnZHxxxVp3+2nHlVq7f1TC4qbrlZcw/CYDTYxrMN
ySBGuDRe90GMywVahGxYrq287Cp0chwm3AJKnXXRmnZFH+WjqMR7NqCpjDIS
uxdbzGk7V1BCumS7AWN4bGx+2v465r22HEjgnLUlCXGCd04nm1OahBfedizv
ff7my+gLiRm7/Zkiuf+0Rd/PmrZsIGjdTqJ8xzYqSfDSLCSVxMyah1LcIzEd
1RsrH06KXKNbRBcq8yk6i/NOJUtGRpWK2lxuYOyiE3hAQZfNihZd806KtIc6
IQA8ps2s1hSKobRl+o0fO5AbXdh+/TJR+iba/z1lx/eagZPMtBhwVU2spfKS
u9z6HIgiCfdShQQ2F125exUY50hIJCnQ71zThipIAdK10J3ZqUhcdlK29weT
wQO1I5zD2Xq0qdtylmmPnlRYQvPsbdYfamSVcZ2EWwi1F0/wu+5hYQhbwoN5
J4GqiVMbS9xMdtmqxnAgW4cK1nu0E+6dsXBvIQT0UVvSmgNNQKCrthew6CaN
HmEYU9BkfyxLh/ZC9Gl2iV7Jjb5e7Ba3C7Zcmv/a63TmltUx6XGQqJZiOgN9
bjRNydgWRLqIMooBeC+S4VoTWoMAtGUupg6hXVcbEhSVQZzFjSSER5sJ8f5y
CPkWIy9f9BSTGDWWlu2tYEECByITWEQ65mANImHwYGKFJJ8ugABLl27dSLyl
FZiHMT8tBzTQcplNi43YePDE3LCbMlBUDNDaCq3KuUlpyfTcdVpwZiXANmb6
QRJf5drBrT2kGhA0muvJUD7zxNTqD2V81iMaIi+cWMKARJkwaZwfO7pWWZM0
asbTTihKaRaDp0FjplmgPCiYOH959vdXx6/f2Jo7U4IcovhWBUOFVhbvhl36
V5L7q9zPeofYonBp+vI6Q7KHT2igOOpqgAmuZxy8RCMjBRWcwh+5uobtBgyR
ZcSHtHJKRmsFHz68AaGZX87O+r05vZ62phsMnPV7cpIGHjhkrlgQnohZ+PNt
ZuD0DI0y1XXJU/a6UTRKDVooQb9MTLbHFcIjZP7ncMtJX9By7wS94uLATHFu
JRwPK52cL9BS71QislyyACYGcrEpUnJScmysl05GPDtkrzOAT7PDjDQb0yKB
6r12WkOEQ0mGewsjP52dnbsmIFW+0q12jbnKZdv9xLGFkbv8ud8VgWJSyGCY
gd5b55UY8uA4ct52yG3Ohe4snSPo1u2KSfScCSMXaASQh26B/yf7nyUQ9AbK
ltnZ64mNUJUIx6cueVzRjetNFjfBwseJjR9LbcUmcE67Oj/5h3fk/TULOJcW
7LZEy3YTNHTXVqCcXbrrHq5Zv+NB+D8qezAi4UBDqJrFQ3nIzJmYY5YMYcdN
UuiL55XEvQILIzmcyTm+xYJw5E20M3zIRPPNOAyh5xD0IEZ3GjFwanrWwwB0
VoNtWYbMkxzCqBYN6iUwNGKYsHXO0Eu6mMEwEKWCA4DNligodoeWOwIwpNNO
pN/ZoAzZppeGj+9pBxy3FYgQOj5QjUNzCHkwORKaKGlKtnJe+mrN7HTuZi3X
Rl/oia7IVNeV8pAPQ2a9IZLZ7vcCb8nG0EizurQknLw7t1nTZLNLQvEM+X9h
PB1zDv+Ezdw5ygPugtBtwgTX0nhNQ8S+aK0Cdjefa7MbF0tun4Id6rEoIJL1
cdOq5edTfEPRFOqkcYGoiroUQ4wPgAWvPT1QSOJGxllUzrqt18iFMC8BPvbq
0NWSnKKYFtXskqUCLAE9qOdQYBBolwxiWkkQQxPOdkUVWRCCGmJY7ug+f/1D
aPRE+9FWY4eqBrD0FR9cDaEcIqA5mceWDzEIeyGdYdQV8ew+vxO9oQ8RW3an
L5UMsn0+dMrM4oyvCu7WY6yevj+1nz/Hc9o3Nzuek9pP4TQyeNetEflCQtVO
pJUh7EWVFXoEOrCKSEFUKxT9LxaoqppZvVk31UWdrZfo3cNkcCMX2iJa8fln
2uOlc+sg1TiqADzXqD9DoIxskkB910NFPH8jpPJ3Vkz1WPVFaXaca/FJios9
6LkUGFnb9GY0SQ2231sF/sIxtYRUkYuV1bnQwWn45PSq6nLOFncn8KCpr9XC
AzERb4QZzgrnOJstGjfQXbwjl7PbEHgX824DCkyI3TFb0IqDn5RFoCq3Hxed
ijiazwHVJtoVDlM2TCQXDrgSIUloLjqFoQwfSI2EMLghJT84wyQ71g13/h+f
w+NivYsYCnzDXSvyrLYaXblo0ZQpmRwxq8LBO6djwvO6XpiGwCvdRZbOhHwu
57G4TkcwBLXIzEg0YZ7jzggmxDzBusQ/gW4qfscFyhSyRqKXZ2R5HI4XOtRf
vVVH3YcwSi61gShAD6KUDtMXOc96nkBcUZP9kTsa5DwhjutmyU0IKc8oDjv2
7hoF4vm46F0RfNc4/C/cnnsTEaLX4WBq0SPa9BDRR2DA00LvQDzHp2feYg2a
HpaaOFFvmaHNw5XxJoBQzAhHKwVZMfCp2f1cIPkRgmiUYshAkFnxLYf7DfdF
SNKIQMcB/lsJH5lVyHhKEqVa8b+g386V5O/IFSdlyq07HPhpZkVOx2ngm/sl
J6wde6KxGTOcH9djaIGLkAqWplL2hHUmHatqINR/uS8/cByfSo/HLxM7Ge6u
SFo59IYBqBLObYTFgVpMQYgCx3Y0E/8CjsexOB5/F8eDKfQ2qgLBRZl2QMKu
UzQZqob2BE0L+bQFaCeuhCkgu3iuR5rvY40HRrwbHx/qQLovMKE9smcHJEJf
5nDOGAmrlXi9odWNIiGvQea83wLDaRUOy+SYaV44Crg8GT3uxsukYKbJUkaX
RlVg2WSpoZgclLLZ0eA4TaJ9dU+W+SIGjerAyaUniHOmWcGddqJ3u1OsC5x8
DIDZ/tk6jq32Dy0xB+HgvlwNIFrPPwhxlqZoSHw1+RbyRAc0mNZ42j3DxlLT
G2yg09QDa1efHgJkqFj+LfLRsO3syTkcwkweNWDqec6WlKVXzoBX2naE5Fna
ziIOVPLBWDI7NluRBz8r0Iwh7cMguSvWXlgzMUmBcbJyw0uwKZbz5xSSrNFF
1KTBnuYAuvtGxiGlY1+j6XrWhX5vQLHR+SwrnN5UJge9OY5edwfG+UhuuI1g
5Hn81uFodGmxwLObjKZJ05YxXkOIgKtgEGuFs+C9D7tT5LSWHg6G5UZs05a4
E2AGKWP7HXcgelm1QoxI2MuR62xqFPFIZHE/Dac1m3zk14T6lcs87ELkxbQh
xs+qdZcF7O5GiW6G2GnbkM6Xw7sI7DfsmpQ7ww2uJc4QLc5YjczkmPQq45vZ
uD+/QT8r4avqR1Sht1x6pSTjrcTI7BWpy5WTorYe4Cal0QDQjLkC4W8HJYqO
UcFqjnqVkQPRIN0fzmxHfdLvXII0BTKYKfcFcPkyX0g2lc+jzSSXHBJKsc0p
3qqSnk5HXsupKPHGJK7VvB0JIbxLyRGGvC9x1K9aceBuE72jw/V620M8ywcZ
QEpNwYdraqJfkp7q5Wwg9iDAo9RKH6MM3CPHMLpZ/+xxr8jKljcaujU0U7t1
rKMPQ7gTCbkZSWtLTrXcMLFNuCdDjsJDLjlSf1/nV9lsR6DeBd+SjwoNTYlL
WW7YE1vrFCp0QaqM3vBCSuP49PjWAvyhOo8uXkzA7TKxcWfrRDBPdjxD/qBw
cz6vFvJUEQ3Xsbgd2pU5y+qTqxUAW14u6owUKqGBQ/Bjz1gayn0ga3KCINIh
a7ThfBDrJfjkarHReQ0WiRdmhSxV4BNubyXFjx5jdnrRfohAXKzeSpJPyv8w
vLgRirYcj2bO+zUGjlS1Y5mHs/cdssgRW6QS5uQnsYfq59rJxULMZexsLnyw
sGcVYbnBXRJFA9f41r2CUqz6Admqd39+jjtVzH1O7bhHh/ZcM1K4ZHD9QO9m
ghscO39DHyhbDn1j97Td/967s9c/vD61++O9yTi9SGVsvt+61geNE+nFPuH2
nrt+92frnuNLdrRZY+fNP+Ein+Ots+oRtYAElZYxn0/twy06Ro8aQmqT5ipu
/NJretAuctMFD9I+wRVd7vCPGdXuHjUtfgvkaXn7Vu0+noZlWBp0OcdTjvGW
hdgH0wUwt2r9BIOUoE2/BN0dgpIqWOTHtF66quacTOmK0s501Yi0ThH9z13Z
82Ewb4JMKcSEY0O7SRD5BoRicu8RT4wORod9gguZE67c///OlfvDvS9fvhz8
DmdGeLW/LTQAReka6sFEjUUbJYYkxcwOVlHm0qK8RGzS1R+50/RaOLjw0+9c
Cakx8jK5Vhc6WCRlD2fa9OZP+qljXmNHqZf0956CVzCwhu1F4a5g2EMJSsBE
dMUe/bAr4y7sgWS0tYQLfW5YAe9YTDJXKATs6snpkmUm9sjFPsKudC6xfZcN
CSFW3q8mjsNdLRIOhfx/cs7h95SNSXs9GSv/b+IxmVDcs1M4KMY4prCD0D6n
MGZTtfAw/szJPF6R1YF4L3L7UgjLY/eEEW3QFfbHcr6LE3o1+3fceYCYsSr/
ipsk5JgVx3sahf/VJFB0lxstMzG16hnJMa2ASNyMVCG5AHUr3QS0mxecyJL1
uXC+dJ+6FlDFwF9Rak0Vw8GWYpiM+3+ejKfjOf3e43f743z96A/qi2+/G/8r
f7c0xvEx6Yy9R6Mn3Db0daUh5QXdUNJoxUdUpe9n71F61FXbdcSvDU2Zwbsp
yG+yT9Tn1RY9Djv2kyrEYexADNVpMSfjzrgGNn/9Hg/sTyZ7z+bTJ8+ezV02
fzZ1bhGbAzhfAPShbCG55aTtV7GBx0Z4bKslPaHl4RYtewO3yXVMPz166Trf
4jz+YvFdfHHXJYL3Pn//ZfyFXI0/zjJfJZy2EITmbjHhHCMppw6VlkGPVAvz
Ndx0zb4DfK9t1Rg1GOr8SKhy42XgBz7pKG2Rc1KH9+Eh+i31jcP+6JTOJF9s
GJGxjJSQ42hrg3CtkajA0S0Uz7g6z5ce0uROcxnal/Fwf9++eH1yZqZICHE5
1ccLDYnf9OKovcc3N2pBQvessF0qEN4M9kCHCU06CGtpPJIeSBuUfm9Mur5H
8ME4XH1kerNyEUzhyeJh56+6F/TzeD/hQDmslbgRB79wI9GYWGp0YOhfx7Kn
53YXdFv+7JZl2T+iXd+2EnJRozi+QeiTI06d2/hi6xBZd9ijf/yMKLB/xFPx
LfO9psK0Zxkj/rtShSKRlBxE0zZvXOtYzc39wXjwIPVEey2jmpcfAEcDdoH1
zBnNGo8msDLb7pbQVXq9EuGGGPYvcD0HbS//zYXUMuEqkPYOZAaKCq54EAF2
e2Bidn9SQ3rvG+lw0bJqZ0f1ar5whrAiz7mJnQKm8yq4RYtvLv18b5+ZRrPw
MV3LxeZ+P0NFfkXV8gW0nKgSsvgCeaECTX0edoEGy0WZeskPgKvdEnfQwN7+
XxvM3R7FYAAA

-->

</rfc>

