[dnsop] Comments on draft-krishnaswamy-dnsop-dnssec-split-view-02.txt

["Howard J. Eland" <[e-mail]>]

All,

Here are my (also very late) comments on the split-view draft.

1) I agree with Andrew Sullivan that there's a case to separate out the
DNSSEC specific problems.  My only additional comment on this is that
_when_ RFC 403[3-5] are updated, we can tweak your DNSSEC draft, without
touching the non-DNSSEC split-view doc.

2) 1. Introduction, para 3 nit:

        "In the case of split-view DNS every authentication chain in
        every view must validate properly.  Some names may be common
        between multiple views but contain different data."
        
The last sentence here is a bit ambiguous: it's not clear if the data
you are are referring to is the different RR set returned (sans DNSSEC),
the different signatures, or both.

3) 1. Introduction, para 4 nit:
        "...but is also a well recognized security measure in DNS for
        protecting authoritative name servers against compromised
        caches."
        
Can you support this statement?  A reference to a BCP would be
sufficient I think.

4) Starting at 2.2. Query Channeling, throughout:

I like to suggest changing the name "second-level nameserver" to
"Boundary Network nameserver", so it matches the ASCII-art.

5) 2.1 Background, paras 1 and 2:
I don't care for the way this is worded.  To paraphrase:
        You run views with different servers.
        Unless you run it on one server, with different NICs.
        Unless your server code supports it directly.
        
I suggest moving things around a bit, or bullet them as examples of the
current ways that split-views are run.  I prefer the latter best, as the
former would seem to codify The Official Ways To Run Split Views, and I
don't believe this was the intent of the author.

6) 2.1 Background, para 3:
This seems out of place - it is a recommendation, but it's in the
Background section.
        
7) 2.1 Background, para 4: remove this:
        "Although the two concepts are related, split-views is not
        recommended for hiding sensitive names because of the ease with
        which names can be leaked out.  Again, if name hiding is the
        main objective, the approach of using a private delegation for
        sensitive names is strongly encouraged."
        
8) 2.2 Query Channeling:
It is not clear how other servers in the Boundary Net lookup names for
servers within the Boundary Net, or is that considered Internal Data as
well?

9) 2.3.  Controlling Errant Queries
        "Having these rules alternatively configured in the packet
        filter is also possible, but using TSIG for performing this
        authorization eases packet filter administration for DNS."

I'm a belt and suspenders kind of guy - I would do both.  I'd remove
everything after the comma.

10) 2.4.1.  Internal Recursive Forwarder, bullet 2:
        "Ability to control forwarding behaviour such that the recursive
        option is not tried, even if the name server that queries are
        normally forwarded to fails to respond."
        
This is confusing.  Is this what the author means?

        "No further attempt to resolve the query should be made if the
        name server(s) that queries are normally forwarded to fails to
        respond."
        
11) 3.  Split-View DNSSEC, para 2:
        "Often two views of a split zone are administered separately, so
        having different zone signing keys for the different views is
        also desirable."
        
This sounds like it forces the number of keys to always be >=2.  I
suggest:
        "... so the ability to configure different zone signing keys..."



Overall, I think it's very nice to have this spelled out.

Best,

-H

-- 
Howard J. Eland
Afilias USA
[phone]
http://www.afilias.info

.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html