Subject: [dnsop] draft-krishnaswamy-dnsop-dnssec-split-view-03

From: Suresh Krishnaswamy <[email-masked]>
Date: Wed, 23 Aug 2006 18:24:03 -0400

The latest version of the DNSSEC split-views draft addresses a whole  
buch of comments that were either sent to the list or directly  
communicated to me.

Major changes in the the draft are that it now actually makes  
recommendations about which scenario(s) a particular option is best  
suited to; an improved network architecture figure (with thanks to  
all those who contributed); reorganization of text with new sections  
added and portions moved to the appendix. I've also added some text  
to suggest that this document is more a "DNSSEC" split-views  
recommendation rather than a "DNS" split-views recommendation.

I personally think that there is enough agreement within the working  
group that this topic, in general, is important. Does the group also  
feel that we have enough of a start in draft-krishnaswamy-dnsop- 
dnssec-split-view-03 to form the basis of a Working Group document?

Suresh

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Split-View DNSSEC Operational Practices
> 	Author(s)	: S. Krishnaswamy
> 	Filename	: draft-krishnaswamy-dnsop-dnssec-split-view-03.txt
> 	Pages		: 23
> 	Date		: 2006-8-23
> 	
> The security extensions to the Domain Name System (DNSSEC) allow for
>    integrity protection, whereby it is possible to make a  
> determination
>    of the verity of data returned from the Domain Name System in
>    response to a query.  Current operation of the Domain Name System
>    also allows for the creation of multiple views of data, where the
>    answer returned in response to a query is dependent on the  
> origin of
>    the query.  Data integrity and the ability to return possibly
>    conflicting values as in split-views may be construed to be  
> mutually
>    conflicting goals; but this apparent dichotomy is resolvable in
>    practice through careful configuration.  This document provides
>    recommendations for configuring a manageable split-view DNSSEC
>    environment in a representative enterprise network.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-krishnaswamy-dnsop-dnssec- 
> split-view-03.txt
>

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

---

From: Edward Lewis <[email-masked]>
Date: Thu, 24 Aug 2006 10:40:21 -0400

Referring to:

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

# Abstract
#
#   The security extensions to the Domain Name System (DNSSEC) allow for
#   integrity protection, whereby it is possible to make a determination
#   of the verity of data returned from the Domain Name System in
#   response to a query.  Current operation of the Domain Name System
#   also allows for the creation of multiple views of data, where the
#   answer returned in response to a query is dependent on the origin of
#   the query.  Data integrity and the ability to return possibly
#   conflicting values as in split-views may be construed to be mutually
#   conflicting goals; but this apparent dichotomy is resolvable in
#   practice through careful configuration.  This document provides
#   recommendations for configuring a manageable split-view DNSSEC
#   environment in a representative enterprise network.

(This is just a comment on the abstract.)

View- (I am not sure if that concept is still just a BINDism or is 
about to become a DNSism) based results are not just based on the 
origin of the query, they can also be based on the key signing the 
query (e.g., TSIG).  The more general point is that the response to a 
query can be based on more data related to the query than just the 
QNAME, QTYPE, and QCLASS contained in the question section.

There should also be a distinction between the concept of views (as 
the BINDism) and other answer synthesis approaches.  For example, 
answers may be synthesized based on server load or geographical 
location of the query source IP address.  Synthesis of this type is 
not part of the draft.  It will be important to highlight that "out 
of scope" boundary lest there be arguments over whether any 
recommendation, etc., in this document will impact answer synthesis.

So, my recommendation is that the abstract states that this document 
defines "split-views", both in term and in concept, principally to 
distinguish the practice from answer synthesis.  Once there is an 
understanding of what it is, the reason that DNSSEC seems to be at 
odds with it will appear to have merit.  Looking at the solutions we 
will see that DNSSEC is not at odds with the concept of 
"split-views."  (Because DNSSEC allows data to be traced back to the 
administrator, and it is the administration that is making the split. 
All is cool.)

My prediction is that the outcome of this document will be a new 
feature in DNS implementations (not the protocol) that will allow one 
view of a zone to be unsigned while another is.  Or differently 
signed, etc.

BTW, I am neutral on split-view as the name of the practice.  I've 
heard split-DNS, split-namespace, split-brain, etc., over the years. 
The final document ought to cover these colloquialisms if they are 
found to be in the archives (so as not to confuse future generations).

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 24 Aug 2006 11:15:08 -0400

> recommendation rather than a "DNS" split-views recommendation.

I continue to have a deep reservation about this document: the whole
thing depends on something like a reasonable set of practices around
split-view DNS.  Indeed, it seems to me that all of section 3 amounts
to a way to sneak that in through the back door.

Don't get me wrong: I'm not opposed, at least at first blush, to
anything in section 3, and it seems to me to be a nice outline of what
is needed.  But the simple fact that the only reference in that
section, in my quick reading, is to TSIG suggests to me that there is
a set of practices that are either undocumented or else uncited, but
which form the necessary condition for the practices outlined later
in this document.

The above is the reason that I suggested just before the Montreal
meeting that there are, in fact, two documents here.  I appreciate
that there is a certain vitriol that seeps out every time split-view
DNS is discussed.  But if we are not willing to come to some sort of
consensus on what an "ordinary" split-view DNS operator ought to
consider, I don't think we can seriously recommend anything for a
split-view DNS operator to consider in the presence of DNSSEC.  I
don't know of any document that outlines what a split-view DNS
operator ought to consider, and there isn't one listed in the
references of this draft.

The alternative, of course, is to make this into a document about
split-view generally, with a section that covers how it interacts
with DNSSEC.  (That seems to me to be a possibility, although it will
of course make the document a little more complex.)

That said,

> group that this topic, in general, is important. 

I agree.  I also think the draft is in general a good one.  I just
think that it either needs to be straightforwardly about split-view,
or that it should depend on another document that is about "vanilla"
split-view.

A

-- 
----
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
                                        +1 416 646 3304 x4110

.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 24 Aug 2006 12:32:30 -0400

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

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Thu, 24 Aug 2006 18:53:03 -0400

> source address that are not related to split-view.

Point taken.

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

I think it's a pretty good straw"person". Thanks for the text!

> authenticity" tying the data to the administrator, you eliminate the

Will add this in as well.

> with the statement of "especially problematic" too.

Agree with the first part; the text should be changed if it creates  
that impression that DNSSEC is what causes cache contamination. For  
the "especially problematic" portion, I believe that this is indeed  
the case -- the NS and DS should point to the correct delegation  
point in order that the authentication chain be properly constructed  
in both views. However, troubleshooting faults in this setup is what  
causes the overhead and not construction of the chain itself. So,  
point taken.

> range or the club of holders of TSIG keys for instance), then internal

  I think you can most certainly combine the roles of two name  
servers given in the document, and I've mentioned this in section 2.3:
   "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."

You'd still want to control errant queries though, since the fiat of  
a single internal recursive name server may not always be  
enforceable. Also, the presence of the boundary recursive name server  
gives us the nice property that queries to the outside world are not  
directly made from within the internal network segment.

> 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  

This can be easily corrected by deleting the first sentence. The  
intent is to remain neutral on the topic of whether split-views is a  
good thing or a bad thing. The fact that it is in widespread use  
cannot be denied, which is why the draft exists in the first place.

.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 24 Aug 2006 20:53:09 -0400

>directly made from within the internal network segment.

Errant queries?  I don't believe in them.  Every thing happens by 
design or fat-fingering.  Tannenbaum does not roll dice with the 
network.

This is why we need to have a definition of split-view.

A "fiat of a single internal recursive name server" is certainly 
enforceable.  What happens if someone runs a server counter to local 
policy.  If noticed, it'll be debugged and fixed.  If someone doesn't 
fix it and is supposed to, they will be fired.  That's enforcement.

Split-view is run within a management domain, ergo, there's enforcement.

This is why we need a definition of split-view.  And operational 
assumptions.  It's possible to screw up a split-view configuration 
and this is why the IETF seems to want to sweep this issue under a 
rug.  But the fact is that many do use it successfully despite a lack 
of guidance from the IETF, and no one is running around screaming 
that the sky is falling.

I currently operate in an environment that uses split-view.  (And at 
every place I've worked for the past decade.)  Occasionally I do send 
queries directly to the outside world.  I do this by running a local 
non-policy-compliant server when I am debugging something or checking 
out a problem I hear about on a mailing list.  When I break policy 
the world does not come to an end.  "Border recursive servers" aren't 
needed (but can be), aren't always there (but can be) in split-view 
environments.[0]

Note, however, if I told others in my environment to use my Mac's 
recursive server behind the firewalls and managed to cause a great 
financial loss to the company, you bet I'd experience "enforcement."

[0] I've worked in places with firewalls that "hijack" DNS traffic 
and enforce split-view there.  I"ve also worked in places where the 
firewalls do not proxy DNS.  In both kinds of places, split-view 
works.  This is what I mean by separating layer 7 splits and layer 3 
splits.

Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html