[dnsop] Chapter 1 of split-view-03

[Edward Lewis <[e-mail]>]

>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
#

...

# 1.  Introduction
#
#    Split-view DNS is the term used to describe the behavior where the
#    DNS returns different responses to the same query based upon the
#    query source address.  It is also a network management technique that
#    can be used to restrict DNS names to only those segments or views of
#    the network that need to see these names.
#

It is okay to say that the response will differ based on the query's source,
but not on the source *address.*  OTOH, there are techniques that alter
responses based on the recorded (estimated?) physical location of the
source address that are not related to split-view.

See: http://www.ecsl.cs.sunysb.edu/~chiueh/cse646/cn8/cn8.html, section 3.1,
for example..

This is why the document needs to more clearly define split-view and then
scope the discussion appropriately.

So what is "split-view"?

I'll try a definition -

The practice of simultaneously loading different contents for the same
zone on active and available servers, with the intent that some queries
will see one version of the zone and others another version.  The
distinguishing features between split-view and a situation in which a
zone transfer has failed to happen (resulting in different versions of
a zone) are first that split-view is intentional and not a fault, and
that for any single query the zone appears to be coherent.  Two queries
may ge different answers, but to each individually, the zone is coherent.

What split-view does not address is the dynamic synthesis of responses
based on data other than the question section contents of the query.  Such
synthesis may be the result of target application server load reports.

The purpose of this document is to address DNSSEC with in the established
administrative practice that has become to be known as split-view.  Other
forms of customizing DNS responses are possible and will interact with DNSSEC
in other ways than what is described in this document.  The recommendations
contained herein are only defined for the observed practice of split-view.

--okay, that's wordy, run-on, etc., but I'll leave it as a straw"person."

#    The security extensions to DNS (commonly labeled "DNSSEC") [1]
#    provide for origin authenticity and data integrity.  These properties
#    are determined by validating the authentication chain from some trust
#    anchor configured at the validating resolver to a signed record.

Emphasize that the RRset can be tied to the administrator of the zone, with
the DNSSEC "chain" establishing the authority of the signing administrator.

Once you put together that the split is intentional and a decision on the
part of the administrator (somewhere in the chain) plus the "origin
authenticity" tying the data to the administrator, you eliminate the
apparent conflict.

#    The combination of DNSSEC with split-views raises some potential
#    issues and concerns.  In the case of split-view DNS every
#    authentication chain in every view must validate properly.  Names
#    that are common in different views may contain different data for the
#    same resource record type in each of these views.  Cache
#    contamination is a possibility when data from the wrong view is
#    returned in response to a query.  For "private" views, or views of
#    the DNS that contain data not available through the public DNS,
#    building an authentication chain from a public trust anchor to data
#    in the private view of a zone can be especially problematic, caching
#    problems notwithstanding.

Any "cache contamination" does not come from DNSSEC being used, but by
improper construction of the split-view arrangement.  I strongly disagree
with the statement of "especially problematic" too.

The thought of cache contamination is what prompted me to switch to a
different strategy for split-view.  All of the internally recursive
servers are also authoritative for all internal versions of split zones.
As long as there are no other recursive servers in the, in this instance,
enterprise's network (something that can be controlled by fiat) then the
internal data is never in a cache.  External data conflicting with internal
data is never seen given the algorithm in RFC 1034, 4.3.2.

So long as no query from the outside (whether this is outside an address
range or the club of holders of TSIG keys for instance), then internal
data won't leak.

#    Although closely tied to it, this document must not be viewed as an
#    endorsement of split-views technique in itself; this document only
#    provides recommendations for DNSSEC in such environments while
#    avoiding some of the common pitfalls that are possible in this setup.
#    The approach given in this document is adjustable for various
#    operational and security consideration levels.  Network architects
#    may implement other mechanisms for DNSSEC split-views however they
#    must carefully consider the ramifications of any changes with respect
#    to the base architecture given in this document.

I don't like the sound of this paragraph.  Split-views does not need an
endorsement, it is an established practice in the field.  If the IETF wants
or thinks it can blithely ignore what may seem heretical to the textbooks
on networking technologies, the IETF will continue on it's road to being
irrelevant.

This doesn't mean that everyone should do split-view.  But excusing 
it's existence isn't appropriate.  Why does RFC 1918 exist and is 
accepted (it creates a split-number space) but we have this fear of a 
split-name space?  Not everyone has to use RFC 1918 space (just 
because it's in an RFC), so don't expect any document coming from 
this to be a direction to do split-view.

I would expect, in an operations area group, more awareness and acceptance
of solving the real world needs of the Internet than trying to pretend
that the theoretical models of the ...80's... are the be-all and end-all.

If this document does not endorse split-view, it ought to exist at all.
Why talk about the solution to a "dirty little secret?"  If you don't endorse
and define it - how can you reasonably be able to offer a solution?

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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