These are on the -02 draft. Sorry they took so long for me to type up
(I read it quite a while ago). Sadly this also meant I'm trying to
understand my own notes ;-)
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'd be tempted to list motivation for the document a bit better.
IE, explicitly state "these are the goals of this document"
- 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.
- 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).
section 1, 3rd paragraph:
OLD:
The security extensions to DNS...
NEW:
The security extensions to DNS (commonly labeled "DNSSEC")...
^^^^^^^^^^^^^^^^^^^^^^^^^^^
OLD:
configured at the end resolver to the signed record
NEW:
configured at the end validating resolver to the signed record
^^^^^^^^^^
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.
last P of 2.1:
you should state something like "The diagrams in the
next section help document this architecture".
end of 2.1:
also might be worth mentioning that some name servers
don't provide decent configuration of view-boundaries and thus some of
these solutions are likely only implementable on certain
architectures.
section 2.2, second paragraph (at end):
you should mention where the externally authoritative server needs
to be located.
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.
Something like (this is not at all complete):
INTERNAL DMZ EXTERNAL
NETWORK BOUNDARY NETWORK
| |
+---------------+ | |
| Internal | | |
| Authoritative | | |
| Server | | |
+---------------+ | |
^ | |
| | |
| | |
+---------+ +---------------+ | +--------+ | +-------------+
| | | Internal | | | Second | | | |
| Clients | | Recursive | | | Level | | | External |
| | | Forwarder | | | Name | | | Nameservers |
| | --> | |--|->| Server | -------|-->| |
+---------+ +---------------+ | +--------+ | +-------------+
| | |
| | |
| | |
| | +---------------+ |
| | | External | |
-----------------|->| Authoritative | |
| | Server | |
| +---------------+ |
| |
I think that's just slightly more readable... I could tinker with
it more if you want to consider using it.
Section 2.3:
Add a reference for TSIG
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).
Section 3:
OLD:
Any data in any view that is likely to be spoofed has to be signed.
NEW:
Any data in any view that may be spoofed has to be signed.
^^^
(I didn't think the word "likely" is a good choice here. You want
to imply "important" and whether it's "possible" not the possibility
of whether it's going to be spoofed or not)
Section 3.2, first sentence:
OLD:
the external zone data.
NEW:
the external zone data (does not include sub-domains).
Section 3.4:
worth mentioning (last sentence) that the only data that can be
polluted is data from the other zone... I don't think it's clear
that's what you're talking about to newer readers.
section 3.6:
"All name servers listed below..."
listed where? I don't see a list... I suspect this section is
incomplete?
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.
Section 4.1, clients in the boundary network:
Might say that if there aren't any, you can just drop these?
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".
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.
--
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
