[DNSOP] comments on draft-vixie-dns-rpz-04

[神明達哉 <[e-mail]>]

This is my technical comments on draft-vixie-dns-rpz-04 that I
promised to submit when I responded to the wg adoption call.  Some of
the points may be considered "out of scope" if the draft really
intends to just describe what's currently deployed, but I nevertheless
made these points for the reasons I said in my response to the
adoption call.

- Abstract

   This document describes a method for expressing DNS response policy
   inside a specially constructed DNS zone, and for recursive name
   servers to use such policy to return modified results to DNS clients.

  I don't think this document limits its scope to recursive servers as
  it talks about the "recursive-only" option in Section 6.  The same
  sense of comment applies to some other use of "recursive servers"
  throughout the document.

- Section 4.1.1

  The BIND 9 RPZ implementation rejects a prefix length of 0:

      if (prefix_num < 1U || prefix_num > 128U) {
        badname(log_level, src_name,
            "; invalid prefix length of ", prefix_str);
        return (ISC_R_FAILURE);
    }

  I don't know the rationale behind it, but since /0 is not a
  syntactically invalid prefix it's probably better to describe it
  explicitly, if the restriction is intentional and especially if this
  document seeks for wider interoperability among multiple
  implementations.  Furthermore, if the intent is to avoid
  accidentally apply a policy to too broad addresses, some other
  shorter prefixes (e.g., /1) may also need a similar consideration.

- Section 4.1.1

   As in [RFC5952], in order to avoid confusion with octal notation,
   leading zeroes MUST be suppressed.

  This reads awkward or confusing to me.  First, it could read as if
  RFC5942 suppresses leading zeros to avoid confusion with octal
  notation, but as far as I understand it that's not the reason (it's
  basically just to provide unique and consistent representations.)
  Second, unlike the case of IPv4 addresses, not all hex block can
  this confusion; if avoiding the confusion were the reason, there
  should be no reason for banning '0db8' instead of 'db8'.  So I
  suggest:

   As in [RFC5952], in order to make the representation unique,
   leading zeroes MUST be suppressed.

- Section 4.2

   To control the policy for both a name and its
   subdomains, two policy RRsets must be used, one for the domain itself
   and another for a wildcard subdomain.

  IMO this part of the spec is one of the reasons why abusing zone
  data to represent filtering policies is not good.  I guess (and I
  know that's actually the case in some real world deployments) in
  many cases we want to apply the same policy to both 'example.com'
  and '*.example.com'.  So this spec can easily lead to wasting memory
  for straightforward implementations.  Although an implementation could
  employ an internal compression scheme to save memory, it seems to me
  to make much more sense to design the spec so a straightforward
  implementation would just work without a waste in the first place.

  Following the standard DNS protocol can also result in
  counter-intuitive results.  For example, if you have the following
  policy records:

  example.com CNAME .
  *.example.com CNAME .
  a.b.example.com AAAA 2001:db8::1

  then no policy will apply to a query for b.example.com./AAAA or
  c.a.b.example.com./AAAA (or other query types than AAAA for that
  matter).  That would be quite likely to be different from what the
  admin of this config intends to implement (the most likely intended
  policy would be to return NXDOMAIN for everything on and under
  example.com except for a.b.example.com./AAAA).  We might say an
  admin of RPZ should be very familiar with all the subtlety of the
  DNS protocol details like this one, but to me this seems to be
  another case for designing a better spec at this opportunity.

- Section 4.4

   Recall also that the target of a CNAME is not added to the
   response if the QTYPE is ANY

  Is this guaranteed by a protocol standard?  Or is this a requirement
  to RPZ implementations?  (If it's the latter while the former isn't
  explicitly guaranteed, then I think the current draft should be
  clearer about it).

- Section 5.2

   Matches on rules in an RPZ specified earlier in the ordered list of
   RPZs take precedence over matches on rules in an RPZ specified later.

  I may miss something, but the concept of "ordered list of RPZs"
  isn't explicitly described elsewhere (at least earlier) in the
  draft.  I think it should be explicitly documented as part of
  assumptions.

- Section 5.6

   When comparing two Response IP Address matches or two NSIP matches on
   rules within a single RPZ, choose the match whose rule trigger has
   the longest "internal prefix length".  [...]
   For an IPv4 address trigger, the
   internal prefix length is the numeric value of its first label plus
   96 (that is, 128-32).

  Does this apply when a response to type ANY query contains both AAAA
  and A RRsets, i.e., choose the IPv6 or IPv4 address that has the
  longest internal prefix length among all AAAA and A RRsets?  If so,
  (I think it's better to clarify that explicitly and) it means IPv4
  prefixes would tend to be preferred even if they are effectively
  very short.  For example, a /8 (whose internal plen is 104) IPv4
  prefix will be preferred over a /64 IPv6 prefix.  Depending on the
  rationale of this precedence it may or may not be ideal (if it's
  just for making it deterministic it's okay, but if it tries to
  prefer more specific prefixes then it's probably not).

- Section 5.7

   The three addresses above are compared as these 128-bit hexadecimal
   numbers, respectively:

      0x000000000000000000000000c0000200,
      0x000000000000000000000000c0000280, and
      0x20010db80000000000000000c0000280.

   Thus, the first IPv4 address is most preferred and the IPv6 address
   is least preferred.

  The latter part of the previous comment applies here; with this
  logic IPv4 prefixes will be generally preferred over IPv6 prefixes
  (when the internal plen is identical) since in practice most IPv6
  addresses contain non-0 bits in the first 96-bit part.

- Section 6

   RPZ rules do not apply to synthetic data generated by using RPZ
   rules.  For example, if RPZ supplies a CNAME pointing to a walled
   garden, RPZ policies will not be used while following that CNAME.

  Consider the following policy record:

    a.example.com CNAME garden.example.org.

  and assume following the CNAME target results in the chain as follows:
    garden.example.org. CNAME a.example.com.
    a.example.com. AAAA 2001:db8::1

  Then should this server includes these two RRs as well as the first
  CNAME in the answer?  If so, it would result in "CNAME and other
  type for the same name" and violate the protocol standard
  (forgetting RPZ violates the standard anyway).  Is it okay?

- Section 6.1

   For each DNS RPZ configured for use by a recursive name server, it
   SHOULD be possible to specify a single, OPTIONAL overriding policy
   action to be used for all policy triggers found in that RPZ.

  I'd suggest explaining what "override" means in a bit more detail.
  I know what it means from the actual behavior of existing
  implementations, but I'm not sure if this is clear enough just from
  this text.

  Also, I'm not really sure for what this overriding is useful except
  DISABLED (for which the draft explains its possible purpose).  Some
  more background motivation would be helpful for readers and for
  implementers who will end up supporting these SHOULDs.

- Section 7

   Because minimal data latency is
   critical both to the prevention of crime and abuse and to the
   withdrawal of erroneous or outdated policy, a DNS RPZ producer SHOULD
   also make every effort to minimize data latency, including ensuring
   that NOTIFY messages are sent in a timely manner after each change of
   the DNS RPZ on the master server.

  I'd note that this is another case why abusing DNS zone data
  wouldn't be a good choice: notifies are unreliable and often delayed
  (if for a short period).

- Section 9 (or regarding NSDNAME and NSIP in general)

   RPZ checks can add significant processing and network costs to the
   processing of recursive DNS requests.  This is particularly true of
   rules with NSDNAME and NSIP triggers. [...]

  I wonder how widely these triggers are used.  My personal
  experiences are of course very limited, but none of the large scale
  RPZ deployments I know of uses these triggers.  On the other hand
  the implementation of these would be quite complicated and error
  prone in addition to the performance overhead described in the draft
  text, and, in fact, the support for these triggers certainly makes
  the BIND 9's RPZ implementation even more unreadable.  So, depending
  on the actual deployment status, we might want to make these
  triggers optional or even excluded from a spec aiming to be a base
  of broader interoperability.

--
JINMEI, Tatuya