Subject: Re: [dnsop] split view comments

From: Suresh Krishnaswamy <[email-masked]>
Date: Wed, 5 Jul 2006 12:25:35 -0400

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