[dnsop] abstract of split-view-03

[Edward Lewis <[e-mail]>]

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