[DNSfirewalls] Fwd: New Version Notification for draft-vixie-dns-rpz-01.txt
vjs at rhyolite.com
Fri Oct 21 20:58:43 UTC 2016
> 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
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"
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.
More information about the DNSfirewalls