> From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jin...@wide.ad.jp>
> To: draft-vixie-dns-...@tools.ietf.org
> Cc: dnsop <dnsop@ietf.org>
> 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
<something else> 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 <something else> kinds of trigger. Please recall
that that was before we came up with rpz-ip and other subdomains.
I also agree that using the DNS to define and distribute DNS policy
data is a kludge.
But to the point, I don't understand your suggested change to the
draft. This draft is intended to describe RPZ as it is and not what
it should have been in hindsight or what it might become in the future.
> - 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? ...
It's nothing to do with RPZ but what DNS implementations do. I assume
that one or more of the documents that came after RFC 1035 mandate
that behavior. If I knew of a normative reference, I'd add 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.
There are these words in the draft:
] 6. Application of the Policy
]
] To enable the use of RPZs, the recursive name server's control plane
] is connected to the DNS RPZ data plane by supplying an ordered list
] of RPZs in the name server's configuration.
I think the draft should avoid words about individual resolver
configuration languages, and so the draft does not mention the BIND9
implementation of those words.
> - 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.
I could blather about the difficulties of relating IPv4 prefixes to
IPv6. I won't defend the preference for IPv4 in the current RPZ. If
pressed, I might suggest a possibly hard to implement scheme such as
giving one IPv4 prefix bit the same weight as four IPv6 prefix bits.
But again, whether the current RPZ preference for IPv4 is ideal or
even just reasonable is irrelevant to this document. It is intended
to describe RPZ as it is and not what it should have been or might
become.
I think the current version of the draft makes that aspect of the
current notion of RPZ clear. If it is not clear, do you have an
explicit suggestion?
> - 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?
I'm sorry, but I don't understand that question or questions.
But please note again that whether whatever the current RPZ protocol
does is okay is irrelevant to this document.
> - 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.
I don't know to make it more clear. Could you suggest some words?
> 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.
This overriding is required for most 'walled garden' RPZ schemes. A
policy zone vendor cannot provide rules that rewrite to the domain
names all of its customers' walled gardens, because each customer is
likely to want to use its own local walled garden. Moreover, in
practice RPZ zone vendors use "CNAME ." or NXDOMAIN rules, perhaps
because those require the least storage on authoritative policy
zone servers and the least bandwidth for AXFR/IXFR zone transfers.
If you think that should be stated explicitly, could you suggest
some words?
> - 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.
I think NSDNAME and NSIP triggers should be used more than they are.
If you don't trust the A and AAAA RRs for example.com, then you shouldn't
trust any domains hosted or controlled by example.com
However, whether NSDNAME and NSIP are useful, unwise, or hard to
implement seems irrelevant to this document. They are present in more
than one RPZ implementation and so present in the RPZ protocol as it
exists today.
Vernon Schryver v...@rhyolite.com
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
