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

[Shane Kerr <[e-mail]>]

John,

At 2017-02-15 10:33:50 +0000
"Woodworth, John R" <[e-mail]> 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