[dnsop] Chapter 2 of split-view-03

[Edward Lewis <[e-mail]>]

Another installment on the split-view document.

>Referring to:
>
>http://www.ietf.org/internet-drafts/draft-krishnaswamy-dnsop-dnssec-split-view-03.txt
>

#                 Split-View DNSSEC Operational Practices
#            draft-krishnaswamy-dnsop-dnssec-split-view-03.txt

# 2.  Considerations for split-views
#
# 2.1.  Split-Views and Name Hiding
#
#    Although primarily meant to be a network management technique, the
#    use of split-views is also seen by some as an approach for improving
#    an organization's security posture - by preventing the exposure of
#    internal host names, knowledge of whose existence is deemed to be
#    sensitive.

Again, there ought to be a positive-slant defining description of what
split-view is here.  I don't mean "positive-slant" as in something that
glorifies the spirit of splitting the name space, but I mean it in
contrast as the soon-to-be negative tone of split-view being support for
security.

#
#    Relying solely on split-view DNS to protect sensitive hosts from
#    attacks has proven to be insufficiently adequate in the past and is
#    not recommended.  Attack vectors in Internet exploits have been able
#    to successfully infect hosts with or without their IP addresses being
#    published in the DNS.  Conversely, publishing the IP addresses of
#    hosts that are otherwise secured does not necessarily increase their
#    vulnerability to these attacks.

I think jumping headlong into this discussion sidetracks the meanfulness
of the document.  First, split-view is in essence not about security and
is about network asset management.  Present that first, give it the solid
definition it needs.  When it comes to split-view as being an element of
security, begin with what does offer and then get into limitations.

This is just a basic document formatting suggestion.  Engineers usually
want to get to the point, which is usually the weakness in a situation that
they want to solve.  If you lead with the build up you first justify why
the problem is worthy of a solution.  In this instance, I don't think that
the failure of security-by-obscurity will prove to be germane to the
discussion on DNSSEC, so it may be that this is a distraction.  OTOH, in
a document on split-view alone, it's a needed discussion.

What's getting lost here too is that there's a disconnect between layer 7
name space cohesiveness/splitting and layer 3 packet end-to-endness/filtering
at firewalls.

#    Name hiding through split-view DNS is primarily useful as part of a
#    more comprehensive defense-in-depth strategy to provide one line of
#    defense against name-based attacks.  Split-views are not recommended
#    by themselves as a name-hiding approach.  A better alternative for
#    protecting a namespace of sensitive hosts is to have that entire
#    namespace reside within a private delegation.  By doing so, it is
#    possible to have the protection given to the name server that serves
#    these names commensurate with the protection given to the hosts
#    themselves.  Since hosts in the private branch are explicitly marked
#    as such by virtue of their domain name, this method also allows the
#    network administrator to better classify hosts as being public or
#    private and lessens the opportunity for sensitive hosts to be
#    inadvertantly placed in public domains.  Private delegations are
#    useful when name hiding is the only reason for namespace separation.
#    They do not, however, allow for transparency during name resolution;
#    queries have to be made for specific names in specific views.

I would think that a "private delegation" is a less desirable option than
split-view.  Again, as we don't have a definition on the table, this comment
is subjective.

My assumption about a private delegation is that it is a zone only available
to some queriers.  To other (unprivilieged) queriers, the zone would appear
to be non-responsive, down, or otherwise malformed.

Split-view is an overlay, meaning that the private delegation that is the
private view is transparent to the others.  There is a view that is public,
satisfying the needs of the Internet's "health."

Split-view isn't only about name hiding, name hiding is a side effect of
"scoping" names.  In coding, scoping of variables is a well-understood and
sometimes tricky concept (lot's of newbie's have problems when the "x" they
assign 0 to is not the same "x" the linker picks).  Split-view is the
doing the same here.  Names are hidden, but treat that as a side effect.

# 2.2.  Representative Network Structure
#
#    The architecture for split-views in this document is modeled around a
#    representative enterprise structure as described below.

That's a valid approach.  It would be better if we did have a more
comprehensive description (to repeat a theme).

#    The two views are for the internal and external segments of the
#    network, with the external segment residing within the boundary
#    network.  The external view of the DNS is also the "global" view of
#    the enterprise to the outside world.  The two networks are separated
#    by a packet filtering firewall.  A packet filtering firewall also
#    separates the boundary network from the external Internet.  Name
#    hiding is not an objective of this split-view setup, but avoiding
#    cache contamination is.  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 (through email headers,
#    for example).  Again, if name hiding is the main objective, the
#    approach of using a private delegation for sensitive names is
#    strongly encouraged.

The point that names can be "leaked out" via mail headers deserves mention
as one reason for split-views.

I once had the experience of explaining that if you filter all incoming
traffic to a certain host but allow the same host to initiate connections
to the outside world, the machine's IP address will appear in packets on
the Internet.  (NAT was not in use, some will be happy to hear.)

 From this I was able to justify a split view of the reverse map, with
the Internet view being something like "lan-138.example.org." and the
internal view being "central-processor.example.org." (the RDATA of the
PTR record for the IP address).

Of course, mail headers leaking names is a problem with the SMTP
rewrite header configuration.  You can't so anything in DNS to fix that.

# 2.3.  Special Capabilities in Network Devices
#
#    Some name server implementations directly support split-view DNS as a
#    configuration feature.  However, the options for placement of such
#    devices in the representative architecture suggested above are rarely
#    optimal.

Without defining "optimal" you really can't support such a statement.  In
fact, I disagree with the notion - that it is "rarely" optimal.  For
instance, as a LAN admin, having one box do all the DNS things you need
is better than having two boxes, each doing 1/2 the job.  Just the hassle
of managing the support agreements for the hardware.

The point I'm reinforcing - "optimal" is relative.

#    Split views can also be constructed using a single multi-homed device
#    in lieu of the multiple machines suggested in this document -- an
#    approach typically used in a proxy-firewall setting.  The device is
#    configured as the authoritative name server for both views of data by
#    running multiple instances of the name server process and answering
#    differently based on the query source.

You get too specific here.  You don't need multiple instances of "the
name server process" to do this, e.g., BIND's views tool runs in one
process and can be multithreaded.  BIND isn't DNS, but the example is the
exception to rule as stated.

#    This document describes a generic architecture for split-view DNS
#    without relying on any of the above special capablities from any
#    network device or name server implementation.  Ergo, the number of
#    distinct devices that provide the name resolution function is
#    increased.  Networks that use a reduced set of network devices for
#    providing the split-view functionality may still draw from
#    recommendations given in this document, provided that the
#    ramifications of any change (if any) with respect to the base
#    architecture given in this document are well understood.

What this says to me is that the document "conjurs up a theoretical
environment and solves for that case; realistic environments can season
to taste."

It's not that you refer to "reduced set of network devices" so much as the
presumption that the layer 3 topology is innately tied to the DNS name
space.  Ok, I'm getting theoretical here, DNS is better done pragmatically.
Most do refer to public-facing and private-facing views, and for the most
part, that's what we see.  But we need to recall that sometimes a public-
facing application server will want to resolve names using the private
view of the enterprise's DNS.

To tell you the truth, I think this document will be easier to write if you
drop the talk about firewalls, etc., and layer 3 issues.  You want to show
how DNSSEC can be done in a split-view environment and you can arrange that
by sticking to a discussion on zones, zone signing, and validation.  You don't
need to get into how servers behave - if there was a generic document on
split view.  All of the concerns about name hiding are not germane to DNSSEC,
they belong to the base split view document.

If you want to do this all in one document, it can work.  You'd have to have
the first part be non-DNSSEC split-view text, the second DNSSEC specific
discussion that moves away from the layer 3 things and the security things.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                [phone]
NeuStar

Soccer/Futbol. IPv6.  Both have lots of 1's and 0's and have a hard time
catching on in North America.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html