Subject: [DNSOP] Kindly review draft-woodworth-bulk-rr-05.txt

From: "Woodworth, John R" <[email-masked]>
Date: Wed, 15 Feb 2017 10:33:50 +0000

All,

I fully understand we are scheduled to hold an interim meeting tomorrow and have a Iot to think about but am hoping at least a handful of you may have a cycle or two left in you to look at our updated draft (-05).

We welcome _any_ feedback on the draft as we are hoping to have it (or some incarnation) adopted by the WG soon and look to rally more interest around it.

We've seen a lot of recent need to address the issues this draft attempts to solve and hope others on this list have as well.  We've also provided a short Mini-FAQ to help determine if you feel it may be of interest and worth a look.

Many thanks,
John
----------------------------------------------------------
**  I-D "BULK DNS Resource Records" Mini-FAQ   01-31-17 **
----------------------------------------------------------

Q) Why do we need BULK RRs?
A) BULK is a tool like many others.
   It was designed to help simplify the management of
   pattern based "generic" records and scale to fit the
   growing demand of IPv6 support. It builds on popular
   technology currently used today while providing a
   number of modern enhancements. The authors feel BULK
   is the next logical progression of what is already
   field-proven and accepted in the industry today.

Q) Does BULK cover all RR types?
A) No. The draft only covers A, AAAA, PTR and CNAME RR types.

Q) What happens if there are other RRs which fall inside
   a BULK pattern range?
A) BULK records can only exist where other records do not,
   a concept referred to as "Record Superimposition" [5.1]

Q) Can BULK generated RRs be DNSSEC validated.
A) The draft offers two DNSSEC solutions, on-the-fly
   generated signatures and a pattern based solution in
   the form of a support NPN RR type (included in the draft).

Q) Is BULK only for IPv6 namespace?
A) No, BULK is intended to simplify management of both IPv4
   and IPv6 "generic" records.

Q) Why not just script these ranges, use $GENERATE or
   simply forbid the larger ones?
A) Two fundamental goals behind BULK are to be able to
   provide the same capability behind scripting and
   $GENERATEs without the memory requirements and
   be able to transfer the zone maintainer's "intent".
   For example, when you transfer RRs managed by a script
   or $GENERATE the receiver gets "all" records and not
   the shorthand used to create them.  BULK transfers
   this intent so the copy looks just like the original.
   Several DNS Software Vendors are already providing
   this capability in a proprietary manner, BULK offers
   an open "standard" way to exchange these records
   which scales to fit any size.

Q) BULK syntax looks like regular expression, isn't that
   a bit too complicated?
A) BULK does offer advanced regular-expression-esque
   backreferences but in a simplified manner. In fact,
   the "star" backreference will work fine in most
   scenarios (e.g. "member-${*}.example.com."). NAPTR
   RRs currently provide client-assisted regular-
   expression pattern substitution so BULK leverages
   a familiar "feel" while also providing some of the
   heavy lifting.

--

-----Original Message-----
Subject: New Version Notification for draft-woodworth-bulk-rr-05.txt
From: [email-masked] [mailto:[email-masked]]

A new version of I-D, draft-woodworth-bulk-rr-05.txt has been successfully submitted by John Woodworth and posted to the IETF repository.

Name:           draft-woodworth-bulk-rr
Revision:       05
Title:          BULK DNS Resource Records
Document date:  2017-02-15
Group:          Individual Submission
Pages:          32
URL:            https://www.ietf.org/internet-drafts/draft-woodworth-bulk-rr-05.txt
Status:         https://datatracker.ietf.org/doc/draft-woodworth-bulk-rr/
Htmlized:       https://tools.ietf.org/html/draft-woodworth-bulk-rr-05
Diff:           https://www.ietf.org/rfcdiff?url2=draft-woodworth-bulk-rr-05

Abstract:
   The BULK DNS resource record type defines a method of pattern based
   creation of DNS resource records to be used in place of NXDOMAIN
   errors which would normally be returned.  These records are currently
   restricted to registered DNS resource record types A, AAAA, PTR and
   CNAME.  The key benefit of the BULK resource record type is the
   simplification of maintaining "generic" record assignments which
   would otherwise be too many to manage or require scripts or
   proprietary methods as bind's $GENERATE.

   This document updates RFCs 2308, 4033, 4034 and 4035.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

-- THESE ARE THE DROIDS TO WHOM I REFER:
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.

---

From: Shane Kerr <[email-masked]>
Date: Wed, 15 Feb 2017 17:05:32 +0100

John,

At 2017-02-15 10:33:50 +0000
"Woodworth, John R" <[email-masked]> wrote:

> I fully understand we are scheduled to hold an interim meeting
> tomorrow and have a Iot to think about but am hoping at least a
> handful of you may have a cycle or two left in you to look at our
> updated draft (-05).
> 
> We welcome _any_ feedback on the draft as we are hoping to have it
> (or some incarnation) adopted by the WG soon and look to rally more
> interest around it.
> 
> We've seen a lot of recent need to address the issues this draft
> attempts to solve and hope others on this list have as well.  We've
> also provided a short Mini-FAQ to help determine if you feel it may
> be of interest and worth a look.

Full disclosure: I hate reverse DNS, which seems to be a strong
motivator for things like $GENERATE and the BULK proposal. :)

The benefit of the BULK proposal is that it performs a nice
compression compared to $GENERATE when sending via AXFR, and also
enables on-the-fly generation of answers for things like IPv6 reverse
DNS which cannot be done with $GENERATE.

I have a few mostly minor comments, feel free to ignore any and all of
them. My main concern is with the proposal for NPN. That's at the end
of this e-mail.

--------

I'd move section 2.4 to the top of section 2. Looking at the examples
first can make understanding the rest clearer.

--------

It might be nice if the examples could be re-worked to use the
documentation IP addresses from RFC 3330 (192.0.2.0/24) or RFC 3849
(2001:DB8::/32). I realize that for IPv4 this might be unworkable,
because of the limited size of the prefix.

-------

In 2.2.2. The Domain Name Pattern Field, we see:

      number              =   1*DIGIT / 1*HEXDIG

However a HEXDIG already includes DIGIT in RFC 5234. (This is also true
in 2.2.3. The Replacement Pattern Field.)

In fact, I don't see any way to disambiguate. Does [9-11] mean "9, 10,
11" or "9, 10, 11, 12, 13, 14, 15, 16, 17"? 

While the server will eventually figure this out based on the record
type, to me it seems better to define the grammar completely separately
for IPv4 (decimal) versus IPv6 (hex). Or perhaps use the "0x" prefix for
hex, although I can see why that might be too clumsy. This might even
get rid of the need for the rules in 3.3.2. Manual Domain Name Pattern
Matching.

-------

In 2.2.2. The Domain Name Pattern Field, we see:

      range               =   number [ "-" number ]
      
I don't understand the motivation here. If you are just using a single
number then why include it in a range? It seems like it complicates
parsing (and possibly automatic generation) for no real gain.

I propose making range:

      range               =   number "-" number

This would apply when used in 2.2.3. The Replacement Pattern Field also.

--------

In 2.2.3. The Replacement Pattern Field, the term "stage" is introduced
in a bit of a haphazard way. I am pretty sure I understand the intent,
but for example the phrase "stage one" is never used.

I think that I would say something like:

    This field MUST be evaluated for proper syntax for resource records
    of its Match Type, as defined above. This validation MAY be done
    when a new version of the zone is received, such as through a zone
    transfer or when loaded from a file. In this case, the version of
    the zone containing the invalid RR is not used. If validation is not
    done then, then validation MUST be done prior to returning generated
    replacement answers.

--------

In 3.4.1.1.8. Backreference Position, it makes me nervous to have
context-based rules about reversed order or not. As the text indicates,
this was done to make the syntax intuitive. Since I have been working
on computers for many years, I have no intuition any more, but it still
seems like a source of potential mistakes to specify some rules operate
in reverse and others not. I don't strongly oppose this, but it does
make me nervous. :)

--------

In 5.1 Record Superimposition, "SWIP" is an ARIN-ism (I think). Perhaps
this should be replaced with some text describing what is meant by the
term instead of using it.

--------

Now... for DNSSEC and the NPN record.

My own preference here would be for on-the-fly signing, but this is of
course not always possible. Certainly if you are using a commercial
secondary service you don't want to hand the provider your DNSSEC keys
in many cases. :)

So I understand the motivation for NPN, but if I understand the NPN
record itself, then it can allow certain types of spoofed data.
Basically, we are saying that we are going to ignore part of the answer
when we do our checks.

In the case of a typical IPv6 setup with a /64 network, that would
allow an attacker to provide an AAAA record anywhere in the network.
This might allow an attacker to direct traffic to anything in the
network to any hacked device.

I wonder if a better approach might be to simply supply the BULK record
itself to a resolver, and have it perform the rewriting itself. We
could add an EDNS0 option where a resolver indicates that it
understands the BULK format. If the zone is signed and the flag is
used, then the authoritative server can include the BULK record and
its RRSIG in the answer.

This also makes me think of complications with NXDOMAIN results.

* In the case where there is an error that is not caught on load (the
  "stage two" checking in the text), the NXDOMAIN will not have a
  signed NSEC or NSEC3 record to return, and a validating resolver will
  not accept the response. Possibly it is better to return SERVFAIL if
  an error is discovered when sending a reply.

* In the case where there is no error but no patterns match, probably
  it is better to return an empty answer (what BIND 9 calls NODATA, I
  think) rather than NXDOMAIN, since we don't have a signed NSEC or
  NSEC3 record. This will work with the EDNS0 hack that I described,
  but I do not think it will work with NPN. 

I think that's about it. I spent way more time on this than I expected,
hopefully it is helpful. :)

Cheers,

--
Shane

---

From: "Woodworth, John R" <[email-masked]>
Date: Wed, 15 Feb 2017 22:57:11 +0000

Shane,

Thanks so much for the review, it is very detailed and your
comments are fantastic!

> motivator for things like $GENERATE and the BULK proposal. :)

:)

> compression compared to $GENERATE when sending via AXFR, and
> also enables on-the-fly generation of answers for things like
> IPv6 reverse DNS which cannot be done with $GENERATE.
>
> I have a few mostly minor comments, feel free to ignore any
> and all of them. My main concern is with the proposal for
> NPN. That's at the end of this e-mail.
>
> --------
>
> I'd move section 2.4 to the top of section 2. Looking at
> the examples first can make understanding the rest clearer.

Good idea.  We struggled a bit with this as we didn't want to
throw too much at the reader too soon.  It is a rather long
draft to get through.

> --------
>
> It might be nice if the examples could be re-worked to use
> the documentation IP addresses from RFC 3330 (192.0.2.0/24)
> or RFC 3849 (2001:DB8::/32). I realize that for IPv4 this
> might be unworkable, because of the limited size of the
> prefix.
>

We can rework the IPv6 as you suggest but we wanted to point
out the significance of the larger ranges even in IPv4.

> However a HEXDIG already includes DIGIT in RFC 5234.
> (This is also true in 2.2.3. The Replacement Pattern Field.)
>

Good point.  This was done more for readability, if it is
confusing we can try to find another way.

> In fact, I don't see any way to disambiguate. Does [9-11]
> mean "9, 10, 11" or "9, 10, 11, 12, 13, 14, 15, 16, 17"?
>
> While the server will eventually figure this out based on
> the record type, to me it seems better to define the
> grammar completely separately for IPv4 (decimal) versus
> IPv6 (hex). Or perhaps use the "0x" prefix for hex,
> although I can see why that might be too clumsy. This
> might even get rid of the need for the rules in 3.3.2.
> Manual Domain Name Pattern Matching.
>

We will take a close look at this section to see where we can
tune it a bit and maybe provide better clarity.

> I don't understand the motivation here. If you are just using
> a single number then why include it in a range? It seems like
> it complicates parsing (and possibly automatic generation)
> for no real gain.

The main motivation behind this is only ranges are captured and
if you want to use all octets/nibbles in the backreference
even a single number should be able to work.

Guess it depends on how the zone maintainer wants to segment
their rules.

> This would apply when used in 2.2.3. The Replacement Pattern

The replacement pattern accepts something like ${1,3,4,6} to
allow more control over the backreferences.  This feature
requires single digits to maintain a clean look.

> --------
>
> In 2.2.3. The Replacement Pattern Field, the term "stage" is
> introduced in a bit of a haphazard way. I am pretty sure I
> understand the intent, but for example the phrase "stage one"
> is never used.
>
>     This field MUST be evaluated for proper syntax for resource
>     records of its Match Type, as defined above. This validation
>     MAY be done when a new version of the zone is received,
>     such as through a zone transfer or when loaded from a file.
>     In this case, the version of the zone containing the invalid
>     RR is not used. If validation is not done then, then
>     validation MUST be done prior to returning generated
>     replacement answers.
>

Good suggestion, we will reevaluate the wording here.  We don't
want a "1st, B, and finally" scenario :) .

> context-based rules about reversed order or not. As the text
> indicates, this was done to make the syntax intuitive. Since I
> have been working on computers for many years, I have no
> intuition any more, but it still seems like a source of potential
> mistakes to specify some rules operate in reverse and others not.
> I don't strongly oppose this, but it does make me nervous. :)
>

I am personally torn on this point as well.  On one hand, it "feels"
nicer to have the numbers automatically reversed (it is a computer
after all); but on the other hand, giving up control in the matter
is difficult.

Overall, I tend to lean toward the automatic assignment but maybe
there could be a parameter to control this behavior.

> --------
>
> In 5.1 Record Superimposition, "SWIP" is an ARIN-ism (I think).
> Perhaps this should be replaced with some text describing what
> is meant by the term instead of using it.
>

The main point of this section is to show how non BULK RRs
inserted within the range of a BULK RR are automatically
"superimposed" where they belong.  For too long, we have had
to break up $GENERATES into multiple $GENERATES (especially for
singletons) to support a new customer assignment.  While this
feature piggybacks on wildcard logic, we find it to be worth
pointing out its utility and novelty.  Perhaps it would be
worthwhile to expand this section with an example to make
this feature more apparent.

> My own preference here would be for on-the-fly signing, but
> this is of course not always possible. Certainly if you are
> using a commercial secondary service you don't want to hand
> the provider your DNSSEC keys in many cases. :)
>
> So I understand the motivation for NPN, but if I understand
> the NPN record itself, then it can allow certain types of
> spoofed data.
> Basically, we are saying that we are going to ignore part
> of the answer when we do our checks.

This is where we expected the biggest concern.  DNSSEC was
a hard nut to crack so we had to stroll down a very seedy
road to get there :) .

To be clear, the "ignore" fields control which part of the
RR would remain completely untouched by the "normalization"
process.  The normalization then collapses hexadecimal and
decimal ranges into a fixed single digit allowing for
the number "65535" to become "9" for evaluation purposes.

> In the case of a typical IPv6 setup with a /64 network,
> that would allow an attacker to provide an AAAA record
> anywhere in the network.
> This might allow an attacker to direct traffic to anything
> in the network to any hacked device.
>

We had great concerns about this as well initially but
after further experimentation realized the scope was a lot
smaller than the hair on the back of our necks had led us
to suspect.

> I wonder if a better approach might be to simply supply
> the BULK record itself to a resolver, and have it perform
> the rewriting itself. We could add an EDNS0 option where
> a resolver indicates that it understands the BULK format.
> If the zone is signed and the flag is used, then the
> authoritative server can include the BULK record and its
> RRSIG in the answer.
>
> * In the case where there is an error that is not caught
>   on load (the "stage two" checking in the text), the
>   NXDOMAIN will not have a signed NSEC or NSEC3 record
>   to return, and a validating resolver will not accept
>   the response. Possibly it is better to return SERVFAIL
>   if an error is discovered when sending a reply.

Good point.  We will comb through this section as well.
Our instinct here was to leave the system the same way
we found it (i.e. NXDOMAIN) if we were unable to
synthesize RRs but DNSSEC greatly complicates this.

> * In the case where there is no error but no patterns
>   match, probably it is better to return an empty answer
>   (what BIND 9 calls NODATA, I think) rather than NXDOMAIN,
>   since we don't have a signed NSEC or NSEC3 record. This
>   will work with the EDNS0 hack that I described, but I
>   do not think it will work with NPN.
>
> I think that's about it. I spent way more time on this
> than I expected, hopefully it is helpful. :)
>

Thanks again for your thoughtful and thorough review, it has
given us much to think about.

Thanks,
John