On Jun 23, 2006, at 5:56 PM, Wes Hardaker wrote:
General comments:
- overall I think it's an important document to have. If people
are
going to do split views (and they will) then we should at least
describe how to do it correctly.
I agree.
- I'd be tempted to list motivation for the document a bit better.
IE, explicitly state "these are the goals of this document"
The introduction section discusses this somewhat. I can make the
relevant portions a new section if that'd help.
- the problem with the solution, however, is easily noticed from
the
number of hosts in figure 1. If it takes so many hosts it's
unlikely people will be highly motivated to do split-view the way
you're hoping they will.
Part of the reason is the desire to separate authoritative name
servers from recursive name servers. There are ways in which you
could reduce the number of elements in the figure by combining
functionalities but that would assume special capabilities in name
servers which I've tried to avoid.
- I'd actually make a recommendation somewhere in the document with
a bit more strength. Yes, it outlines choices but I'd be really
tempted to say what you should do instead of using split-views if
you can (eg, use internal.example.com for internal data and thus
it only exposes the existence of the internal NS record and
nothing else if the name server can't be reached. but if you're
unwilling to do that, this document is for you).
I like this suggestion. One way to implement this is to have a
specific "When must this approach (not) be used" sub-section for each
of the different options listed in section 3.
I've added my comments to your note below in cases where they were
not specifically nits.
Thanks!
Suresh
Section 2.1, 4th paragraph:
Re:
split-views is not recommended for hiding ... names can be
leaked out.
I suggest you explain how things are leaked (NSEC) rather than just
say things are leaked.
Email headers was the example I was really thinking of here.
Figure 1:
I think this diagram is functional, but it took me a bit of
study to
understand all the components of it. I do wonder if we could make
it more clear. One of the biggest questions I had that wasn't
intuitively clear is why there is a CLIENTS listed inbetween the
inner and outer packet filters. Possibly more of a block diagram
might be helpful.
The "clients" mentioned here are devices such as MTAs. Will make
this clear in the next iteration of the document.
Something like (this is not at all complete):
<block diagram>
I think that's just slightly more readable... I could tinker with
it more if you want to consider using it.
It does indeed make it look cleaner. Thanks!
Section 2.4.1, 2.4.2:
Implies TSIG is only used in one direction... Needs to be used for
both? I'm not a TSIG expert (to say the least. Though I've used it
I haven't studied the docs), but I'd think if you received a TSIG
request you need to send the response protected as well? Or is it
independent (in which case, unidirectional is fine since you only
care that the 2nd level server only handles requests from
authorized
hosts).
I'll need to correct this to reflect how TSIG is actually applied.
section 3.6:
"All name servers listed below..."
listed where? I don't see a list... I suspect this section is
incomplete?
I should have referenced section 2.4 here instead of creating the
impression that the requirements would be listed again. The section
should otherwise be complete.
rule sections 4.1-4.2:
I'd explicitly list the drop rules as well... You're only listing
the accept rules and I'd hate to see someone just put in the accept
rules without the drop counterparts.
Will add this in the next revision.
section 5, paragraph 3:
This is a fairly negative sounding paragraph... I'd either say
"don't do it unless absolutely possible" or "if you, these methods
are the only way to avoid the pitfalls".
Here's an alternative suggestion:
Split-view DNSSEC involves significant effort: for configuring the
various name servers, for setting up zone forwarding, for configuring
and distributing shared keys for TSIG, and, depending on the
configuration, for performing DS (or keyset) exchanges for every view
of a split zone. Some configurations may also require multiple trust
anchors in end resolvers which may change between views. If name-
hiding is the objective, split-views can (and must) be avoided and
the alternative scheme of using different names for internal and
external domains must be used instead. For other scenarios, the
recommendations provided in this document must be followed to avoid
some of the common pitfalls in this set-up.
section 7: last sentence:
this needs to be stated much earlier in the document as well. This
is what I kept expecting to see earlier but didn't.
It is, at various places. But it wouldn't hurt to make it stand out
more clear.
--
Wes Hardaker
Sparta, Inc.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
