On 10/5/16 2:30 PM, 神明達哉 wrote:
At Tue, 4 Oct 2016 17:39:55 -0400,
Warren Kumari <war...@kumari.net> wrote:
- Section 3: this section also has an issue of "recursive resolver".
Although it may not be as critical as other part of the draft since
it's only used as an example scenario, it's probably better to not
limit the role of resolver to avoid misleading. Maybe "recursive
resolver" is just changed to "validating resolver", and
"authoritative server" is changed to, e.g., "external servers"
(meaning either authoritative or or other recursive servers).
DONE.
I did some fix up - how do you like:
"If a validating resolver gets a query for cat.example.com, it will
query the example.com servers and will get back an NSEC (or NSEC3)
record starting that there are no records between apple and elephant.
The resolver then knows that cat.example.com does not exist; however,
it does not use the fact that the proof covers a range (apple to
elephant) to suppress queries for other labels that fall within this
range. This means that if the validating resolver gets a query for
ball.example.com (or dog.example.com) it will once again go off and
query the example.com servers for these names."
Does that cover it sufficiently? (and I think I now better understand
your concern).
To be perfectly generic, "it will query the example.com servers" is
not always the case. It (= validating resolver) might query another
intermediate resolver (often called a "forwarder") that performs
recursion. By "external server" I tried to generalize the concept.
Maybe this?
"If a validating resolver receives a query for cat.example.com, it
contacts its resolver (which may be itself) to query the example.com
servers and will get back an NSEC (or NSEC3) record starting that there
are no records between apple and elephant."
I'm not sure how we address the subtlety without being overly
verbose. Perhaps we can note in the terminology section that this
draft generally describes (validating) resolvers as those performing
recursive resolution, but the proposal will also work for resolvers
that rely on other recursive (or "full service" if you love to use
this term) resolvers. And then we can keep Section 3 as is (as of ver
02).
I'm now understanding the distinction you're trying to make. I've spent
some time staring at 7719 and 4035 with no better suggestion.
How is:
"Aggressive use of NSEC / NSEC3 resource records without DNSSEC
validation may create serious security issues, and so this technique
requires DNSSEC validation."? I don't love it, additional suggestions
or text welcomed.
To me the main point isn't address with this text. I might be able to
offer alternative text, but can't we perhaps just remove these 2
sentences? In a sense these talk about the obvious, and in other
sense it could be even harmful as it can be misleading.
I think you could drop the "Aggressive" and discussing NSEC/NSEC3
records w/out validation. 4035 is pretty clear on that
tim
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
