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

[Vernon Schryver]

> From: Anne Bennett <anne at encs.concordia.ca>

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

So you prefer replacing "smaller" and "larger" with something about
"earlier" and "later in the DNSSEC canonical order"?  And similarly
for "smallest" and "largest"?  To me "early" sounds fuzzy and a
little informal.  

What I mean by "smallest" is "first in the well order of all triggers
hit by this DNS request as defined by blah de blah" and similarly
for "largest", "smaller, and "larger"
https://www.google.com/search?q=well+order
https://en.wikipedia.org/wiki/Well-order
Perhaps the only relevant substance of "well order" is that you
can count all possible domains or any subset of domains by associating
each with an integer.


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

I might not understand, because the string "size" does not appear in 
the draft.  I know I don't get "opposite".  The RFC 4034 DNSSEC
order is merely:
    1. re-order the labels, eg. www.example.com -> com.example.www
    2. ASCII lexical order but with "." replaced by 0x00


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

That's the purpose of the precedence rules.  Given the set of of
all rules that triggered by a DSN response, consistently pick one.
The choice should 
  1. be easy to implement
  2. facilitate stopping early
      It's not a coincidence that prefering client-IP to qname to
      IP to NS to NSIP means that if you get a qname hit in the
      first policy zone, then you quit immediately and don't need
      to recurse to find the A RRs to check for IP triggers.
  3. make a little intuitive sense, even if only post hoc


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

In normal DNS matching, wildcards are ignored when there is a
specific match, and so the first 3 wildcard triggers are implicitly
excluded while ns4.aaa.dom.ain and ns3.bbb.dom.ain are being sought
in the policy zone database.

The DNSSEC canonical order puts
 ns4.aaa.dom.ain < ns3.bbb.dom.ain < ns2.dom.ain 
 ain.dom.aaa.ns4 < ain.dom.bbb.ns3 < ain.dom.ns2 
 ain.dom.aaa     < ain.dom.bbb     < ain.dom.ns2 
and so the winning rule is trigger by ns4.aaa.dom.ain


> * ... 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 agree that there should be text somewhare saying that the fundamental
trigger lookup scheme is the familiar DNS matching scheme including
the odd but unavoidable oddities of zone wildcards.  That is why
rules are usually doubled, as in having both example.com and
*.example.com to catch both example.com and any child of example.com.


vjs