Re: [DNSOP] comments on draft-vixie-dns-rpz-04
> From: =?UTF-8?B?56We5piO6YGU5ZOJ?=
> To: draft-vixie-dns-...@tools.ietf.org
> Cc: dnsop
> 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,
Yes, that's the remit.
>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.
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.
> - 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,
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?
> - 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 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
> suggest:
>
>As in [RFC5952], in order to make the representation unique,
>leading zeroes MUST be suppressed.
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"?
> - 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 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
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 kinds of trigger. Please recall
that that was before we came up with rpz-ip
[DNSOP] comments on draft-vixie-dns-rpz-04
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 2001:db8::1
then no policy will apply to a query for b.example.com./ or
c.a.b.example.com./ (or other query types than 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./). 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
and A RRsets, i.
