[DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-01.txt

[Anne Bennett]

This turns out to be more complicated than I thought!

First, let me back up one subsection to "Within An RPZ",
and point out that only four of the five trigger types are
mentioned; we should add a sentence fragment to situate the
precedence of "Client IP address".  And "IP policies" should be
"Response IP address policies", I think, to differentiate them
from "Client IP address policies".


>> I still find the "Name Length" section confusing.  I looked at
>> section 6.1 of RFC 4034, which defines a "canonical ordering",
>> but doesn't use the terminology "smaller" or "bigger".

> I tried to say something shorter and less formal than section 6.1
> of RFC 4034, but that DNSSEC "Canonical DNS Name Order" is what is
> going on.  Would it be better say no more than "DNSSEC canonical
> name order; see section 6.1 of RFC 4034"?  Or copy the RFC 4034 text?

I don't think I'd copy the entire RFC 4034 text (it's rather
long), but since it's necessary to refer to that sort order,
then since RFC 4034 doesn't define "smaller", we might have
to resort to "the one that comes last" in that sort order.

(When I think of sort orders, numbers usually come to mind, and we
generally sort numbers "smallest first", which is the opposite,
I think, of what you mean by "smallest" in the above context,
which is why I'd avoid using "size" to refer to a position in
the Canonical DNS Name Order.)

>> Having proposed the above, though, I have two questions:
>>
>>   - Should "BLAH.y.z" not be considered more specific (and
>>     a better match) than the wildcard "*.y.z", regardless of
>>     whether the asterisk sorts lexicographically before or after
>>     "BLAH"?
>
> Those trigger precedence rules were less about specificity than
> making the rpz results well defined in the mathematical sense
> or deterministic in the computer science sense.

Sure, but the algorithm wasn't selected arbitrarily, and the
proposal of text which mentions a "prefix" (not to mention
the title "Name Length") very much suggested to me that in
general, specificity is what was wanted (which IMHO would only
make sense).  And if I understand RFC 4034 correctly, domain
names where one name is "prefix.another" will indeed sort
"most specific last".


Hmm, having gone over this several times now, I begin to
understand where some of my confusion comes from...

> The domain names from the triggering requests instead of the triggers
> themselve are what are being ordered.  There are no wildcards in
> request QNAMEs or among relevant NS domains.

Hang on, the text that introduces the list of precedence rules states:

  It is possible for more than one policy trigger among the
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  various DNS RPZs connected to the name server's control plane
  to match a given DNS query or DNS response.  The precedence
  ^^^^^^^^
  rules for multiple matches are as follows:
        ^^^^^^^^^^^^^^^^^^^^

... which I interpreted as: the "matches" that have to be
ordered by precedence are indeed the triggers (RRset owner
names).  But now that I re-re-re-read (!) more carefully,
the text above also mentions "a given DNS query" *or*
"DNS response".  In fact, *both* (triggers and responses)
can result in multiple matches.

That is, while a query or a client IP address is a single
entity, it can match multiple policies.  But for the other
three trigger types, we can have multiple responses, each of
which could in turn match multiple triggers.

So I think we need to clarify this somehow.

Perhaps if we worked through an example, I would understand more
clearly what is wanted, and might be able to suggest text which
would be clearer, at least to me.

Say we had these policies (all in the same RPZ), which I show
in Canonical DNS Name Order):

        *.dom.ain.rpz-nsdname   CNAME walled-garden-a.example.net.
  ns4.aaa.dom.ain.rpz-nsdname   CNAME walled-garden-b.example.net.
    *.bbb.dom.ain.rpz-nsdname   CNAME walled-garden-c.example.net.
  ns3.bbb.dom.ain.rpz-nsdname   CNAME walled-garden-d.example.net.

and we queried for the A record for "bad.example.com", where
"example.com" had NS records "ns1.example.com", "ns2.dom.ain",
"ns3.bbb.dom.ain", and "ns4.aaa.dom.ain".  In this case,
three of the four NS records match policy rules, and at least
one of them matches two policy rules (possibly two of them,
*see below).  Here I show the actual NS records (responses)
in Canonical DNS Name Order, then each group of matches itself
in Canonical DNS Name Order:

  ns4.aaa.dom.ain      matches *.dom.ain.rpz-nsdname (?)
  ns4.aaa.dom.ain  and matches ns4.aaa.dom.ain.rpz-nsdname

  ns3.bbb.dom.ain      matches *.dom.ain.rpz-nsdname (?)
  ns3.bbb.dom.ain  and matches *.bbb.dom.ain.rpz-nsdname
  ns3.bbb.dom.ain  and matches ns3.bbb.dom.ain.rpz-nsdname

      ns2.dom.ain      matches *.dom.ain.rpz-nsdname

  ns1.example.com   no match

So the last match among the responses is "ns2.dom.ain", but
the last match match among the triggers is "ns3.bbb.dom.ain";
which should take precedence?

* ... which brings up that (a) in the QNAME section, it could
  be clarified whether "*.DOMAIN.COM" triggers on queries to
  "foo.bar.domain.com" in addition to "bar.domain.com", and (b)
  I had assumed that wildcards would work for NSDNAME triggers
  if they work for QNAME triggers, but the text doesn't mention
  them, so I'm probably wrong to make that assumption.  I think
  it's a natural assumption to make, though, so if wildcards
  don't work for NSDNAME triggers, it might be worth mentioning
  that specifically.

I hope this is helping more than hindering....


Anne.
-- 
Ms. Anne Bennett, Senior Sysadmin, ENCS, Concordia University, Montreal H3G 1M8
anne at encs.concordia.ca                                    +1 514 848-2424 x2285