Subject: [dnsop] split view comments

From: Wes Hardaker <[email-masked]>
Date: Fri, 23 Jun 2006 14:56:42 -0700

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