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

From: 神明達哉 <[email-masked]>
Date: Tue, 31 Jan 2017 13:31:45 -0800

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

---

From: Vernon Schryver <[email-masked]>
Date: Wed, 1 Feb 2017 00:05:31 GMT

> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <[email-masked]>
> To: [email-masked]
> Cc: dnsop <[email-masked]>

> intends to just describe what's currently deployed,

Yes, that's the remit.

>   sense of comment applies to some other use of "recursive servers"

The  "recursive-only" option concerns bits in the headers of requests
from DNS clients.  When a DNS client sends a request with RD=0 to a
recursive server, that recursive server does not become other than a
recursive server.

In addition, it does not sound useful for an authoritative DNS server
to use RPZ to rewrite the DNS data for which it is authoritative.

If I were starting RPZ today, I'd fight harder to ignore the RD bit
and so not have the "recursive-only yes-no" option. 

But I think that's all irrrelevant to this document, which is supposed
to be about RPZ as it is instead of what it should have been.

>   I don't know the rationale behind it, 

That restriction intended to make the function that maps IP addresses
to RPZ triggers well defined and so the RPZ rewriting function well
defined in the mathematical sense.  Having two different triggers and
potentially differing rewrite rules that refer to the same IP address
could make particular instantiations of the RPZ rewriting function not
well defined.

I also don't know which IPv4 addresses an RPZ trigger of 0.0.0.0.0.rpz-ip
should match.  Should it match all IPv4 addresses or no IPv4 addresses?

If they are needed, could you suggest words to that effect for the
document?

>                                         but since /0 is not a
>   syntactically invalid prefix

Is there a normative reference that declares /0 valid or invalid?
It sounds like a nice thing to dump into the references section.

>                                it's probably better to describe it
>   explicitly,

The second sentence of 4.1.1. in the current draft is

               The prefix length ("prefix") is a decimal integer from 1
   to 32.  

Is not sufficiently explicit?

>   this confusion;

If the word "avoid" is missing there, as in "not all hex [blocks]
can [avoid] this confusion", then I half disagree.  The only hextet
with a leading 0 that cannot be suppressed is the zero hextet.

>                   if avoiding the confusion were the reason, there
>   should be no reason for banning '0db8' instead of 'db8'.  

"Unique and consistent representations" must be unique, and so there
can be only one.  If both 0db8 and db8 were allowed, then they could
have differing rules and so the RPZ rewriting function would not be
well defined.

>                                                           So I

I think there were objections to exactly those words in a previous
version of the draft.

Would you accept "unnecesary leading zeroes MUST be suppressed"?

>   data to represent filtering policies is not good. ...

I agree that requiring two rules in that case instead of some other
scheme involving 
   example.com       rewrite only example.com
   *.example.com     rewrite only children of example.com
   <something else>  rewrite both example.com and children of example.com
would save bandwidth.  But when I wrote that first RPZ implementation,
I could not see a sufficiently quick way to make BIND9 do the right
things for any obvious <something else> kinds of trigger.  Please recall
that that was before we came up with rpz-ip and other subdomains.

I also agree that using the DNS to define and distribute DNS policy
data is a kludge.

But to the point, I don't understand your suggested change to the
draft.  This draft is intended to describe RPZ as it is and not what
it should have been in hindsight or what it might become in the future.

>   to RPZ implementations? ...

It's nothing to do with RPZ but what DNS implementations do.  I assume
that one or more of the documents that came after RFC 1035 mandate
that behavior.  If I knew of a normative reference, I'd add it.

>   draft.  I think it should be explicitly documented as part of

There are these words in the draft:

] 6.  Application of the Policy
] 
]  To enable the use of RPZs, the recursive name server's control plane
]  is connected to the DNS RPZ data plane by supplying an ordered list
]  of RPZs in the name server's configuration.

I think the draft should avoid words about individual resolver
configuration languages, and so the draft does not mention the BIND9
implementation of those words.

>   very short.  

I could blather about the difficulties of relating IPv4 prefixes to
IPv6.  I won't defend the preference for IPv4 in the current RPZ.  If
pressed, I might suggest a possibly hard to implement scheme such as
giving one IPv4 prefix bit the same weight as four IPv6 prefix bits.

But again, whether the current RPZ preference for IPv4 is ideal or
even just reasonable is irrelevant to this document.  It is intended
to describe RPZ as it is and not what it should have been or might
become.

I think the current version of the draft makes that aspect of the
current notion of RPZ clear.  If it is not clear, do you have an
explicit suggestion?

>   (forgetting RPZ violates the standard anyway).  Is it okay?

I'm sorry, but I don't understand that question or questions.

But please note again that whether whatever the current RPZ protocol
does is okay is irrelevant to this document.

>   implementations, but I'm not sure if this is clear enough just from

I don't know to make it more clear.  Could you suggest some words?

>   implementers who will end up supporting these SHOULDs.

This overriding is required for most 'walled garden' RPZ schemes.  A
policy zone vendor cannot provide rules that rewrite to the domain
names all of its customers' walled gardens, because each customer is
likely to want to use its own local walled garden.  Moreover, in
practice RPZ zone vendors use "CNAME ." or NXDOMAIN rules, perhaps
because those require the least storage on authoritative policy
zone servers and the least bandwidth for AXFR/IXFR zone transfers.

If you think that should be stated explicitly, could you suggest
some words?

>   of broader interoperability.

I think NSDNAME and NSIP triggers should be used more than they are.
If you don't trust the A and AAAA RRs for example.com, then you shouldn't
trust any domains hosted or controlled by example.com

However, whether NSDNAME and NSIP are useful, unwise, or hard to
implement seems irrelevant to this document.  They are present in more
than one RPZ implementation and so present in the RPZ protocol as it
exists today.

Vernon Schryver    [email-masked]