Re: ZONE and VIEW options (Re: 49'th IETF DNSEXT agenda)

[Michael Sawyer <Michael.Sawyer@nominum.com>]

[Not sent to agenda@, since I think this is largely off topic there]

> In particular, the ZONE option says that "If the ZONE option is allowed, it 
> MUST return a normally formatted reply with a ZONE optional record, 
> containing the same zone as the one queried.  When replying to AXFR or IXFR 
> queries
> with ZONE options, the entire zone, including out-of-zone glue, should be 
> returned to the client."

I agree, on re-reading that is confusing.  I think I can remove the
"including out-of-zone glue" part and have it make more sense; I believe
in hindsight that that clause is largely meaningless anyway.

> The VIEW option "only" has the problem that there is no global namespace 
> for views, no ways of finding out which views are supported by a server, 
> and no specification of the naming scheme for views.

Both of those "problems" were intentional.  The primary goal of the VIEW
option (which, in my opinion, is the more important of the two) is to
provide two bits of functionality chich can't be done otherwise.  Both of
these are currently somewhat Bind9-specific, but I see no reason in the
way VIEW is defined other people who code similar functionality couldn't
use the option in the same way.

Assume you have two views in the server (let's call them "internal" and
"external"), where "internal" is the first one listed, and only members of
your internal network are encompassed by the view.  "External" is listed
second, and encompasses the entire world.  Your internal machines will
match the "internal" view, thus will see the data served by that view.

Problem one which VIEW was intended to address: You are the DNS
administrator, and want to make queries to your server which match the
"external" view to make sure it is serving the right data.  Your option
now is to log into a machine on the external wire and make the query from
there.  Personally, I consider this a Bad Thing, since either such
machines are actually external to the company, such as the administrator's
home machine, or are on both the internal and external wire, which should
have fairly high security requirements, and using them to make test
queries from isn's really a good idea.  With VIEW, you just add that
option to your query, and since you match the external view, just at a
lower level, you get that reply.

Problem two: You have two nameservers, say, for example, one on the west
coast and one one on the east coast.  These both serve internal and
external views, with the west coast server being the master and the east
coast being the slave, for zones in both views.  You also have your own
internal corporate, high-speed network between the two sites.  The AXFR of
zones from the west coast to the east coast is easy; it happens over the
corporate network.  However, transferring the external zone is
harder.  You either have to give the hosts addresses on the external wire
(if you even have "external" IP space to assign) and allow the zone to be
transferred over the public IP, assign external IP's as above and make
special routing rules which force just those external addresses to route
over the internal net, or try to setup the zone rules with enough keys
that you can fine-tune which zone you get that way (which all of the
authors agreed was more complex than we'd want to suggest to someone and
filled with potential for error).

With VIEW, you just have the server request the AXFR from a specified view
(just as the query above), and it should just work.

Regarding the lack of ability to get a list of views, that was intentional
(as was the fact that it returns the same error code for view not found
and you can't access that view).  We considered it a security issue for an
outsider to be able to get a list of views from a server, or even what
view they are currently looking at.  In our opinion, if you are using the
VIEW option, for whatever reason, you should know what the views in the
server are, a priori.

The naming scheme was not specified, specifically as not to make it
Bind9-specific.  Bind9 basically names views as ASCII strings, but there
is no reason some mythical server couldn't come along with views named as
properly formatted DNS names, or numbers, or anything else.  If there is a
strong objection to not specifying this, I'm more than happy to add in a
specification for the naming of views.

I'm not quite sure what you mean by a global namespace of views.  They
are, by their nature, site-specific, and an administrator generally won't
want to have someone outside the organization know what views they have
configured.  Views, at least as Bind9 understands them, aren't delegated
in any way, and this will be the first time the name of the view makes it
any further than the config and log files.

					   Mike Sawyer
				Nominum, Inc. -- www.nominum.com


On Tue, 5 Dec 2000, Harald Alvestrand wrote:

> At 16:33 04/12/2000 -0500, Olafur Gudmundsson wrote:
> 
> >and
> > 
> >http://www.ietf.org/internet-drafts/draft-sawyer-dnsext-edns0-zone-option-00.txt
> >
> >          Sorry
> 
> switching from agenda to content comments....
> I am really confused by this draft.
> 
> 
> now, is the glue out-of-zone or in-zone?
> I know that it's common practice to include glue in the same file as the 
> zone data - but is this an implementation requirement?
> 
> perhaps the author is looking for a "configured" option, where the server 
> replies only with data that are configured into it, no matter what its 
> status, and never with data learned from other sources? That would at least 
> make sense.
> 
> 
> Mumble.
> 
> 
> --
> Harald Tveit Alvestrand, alvestrand@cisco.com
> +47 41 44 29 94
> Personal email: Harald@Alvestrand.no
> 
> 
> 
> to unsubscribe send a message to namedroppers-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> 



to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.