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

["Woodworth, John R" <[e-mail]>]

Shane,

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


> John,
>
> 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.

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.


> -------
>
> 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.)
>

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.


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

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.

> I propose making range:
>
>       range               =   number "-" number
>
> This would apply when used in 2.2.3. The Replacement Pattern
> Field also.
>

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

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


> --------
>
> 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. :)
>

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.


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

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

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

> Cheers,
>
> --
> Shane
>

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