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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
