Subject: 49'th IETF DNSEXT agenda

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 4 Dec 2000 13:34:45 -0500

Agenda (2000/12/13) (as of 2000/12/4)

	49'th IETF DNSEXT WG meeting
	Wednsday December 13'th 2000.
	9:00 -- 11:30
	Chairs: Randy Bush, Verio
		Olafur Gudmundsson, NAI

Working group items
03 min	Agenda bashing		Randy Bush
05 min	WG status		Olafur Gudmundsson
05 min	Interop testing results Bill Manning
05 min  Interop Status		Olafur Gudmundsson
 
Last call documents
02 min	IXFRbis + RSA/SHA	Olafur Gudmundsson
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ixfr-01.txt
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rsa-01.txt

05 min	APL 			Olafur Gudmundsson
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-apl-rr-01.txt

05 min	Message Size		Olafur Gudmundsson
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-message-size-01.txt

05 min	EDNS0.5			Harald Alvestrand
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns0dot5-02.txt

05 min	Zone Secure		Edward Lewis
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-zone-status-03.txt

05 min	DNSSEC OK		David Conrad
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-okbit-01.txt

Other working group documents
05 min	DNSSEC Roadmap		Glen Rose
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-roadmap-00.txt

05 min	NO record		Simon Josefsson
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-not-existing-rr-01.txt

05 min	AD is Secure		Brian Wellington
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ad-is-secure-00.txt

05 min	AXFR Clarify		Andreas Gustafsson
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-axfr-clarify-01.txt

05 min	Unkown RR types		Andreas Gustafsson
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-unknown-rrs-00.txt

05 min	SRVbis			Levon Esibov
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2782bis-00.txt

05 min	GSSAPI-TSIG		Levon Esibov
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-gss-tsig-01.txt

05 min	Local Multicast DNS	Levon Esibov
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-00.txt

05 min	Large site Multicast DNS Bill Manning/Bill Woodcock
   http://www.ietf.org/internet-drafts/draft-manning-dnsext-mdns-00.txt

05 min	DHCID RR		Mark Stapp
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-01.txt

New items:  DNS MIB's 
05 min	RFC161[12] retirement	Rob Austein
   http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnsmib-historical-00.txt

15 min	The case for DNS MIB	Richard Bar Hibbs

New non WG documents
05 min	DNSSEC opt IN 		Mark Kosters
   http://www.ietf.org/internet-drafts/draft-koosters-dnsext-dnssec-opt-in-00.txt

05 min	ENDS handling unknown	Michael Sawyer
   http://www.ietf.org/internet-drafts/draft-msawyer-dnsext-edns-attributes-00.tx

05 min	ZONE and View options	Michael Sawyer
   http://www.ietf.org/internet-drafts/draft-sawyer-dnsext-edns0-zone-option-00.tx

WG future: 
10 min	New charter discussion	Olafur Gudmundsson

Non-document slots:
07 min	Other items
03 min	Summary					     

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 04 Dec 2000 16:33:58 -0500

>http://www.ietf.org/internet-drafts/draft-sawyer-dnsext-edns0-zone-option-00.tx

Sorry these two URL's have error in them the correct ones are   (missing last
character both of them).

     http://www.ietf.org/internet-drafts/draft-msawyer-dnsext-edns-attributes-00.txt
and
    http://www.ietf.org/internet-drafts/draft-sawyer-dnsext-edns0-zone-option-00.txt

         Sorry

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 05 Dec 2000 13:10:54 +0100

>http://www.ietf.org/internet-drafts/draft-sawyer-dnsext-edns0-zone-option-00.txt

switching from agenda to content comments....
I am really confused by this draft.

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."

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.

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.

Mumble.

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: Michael Sawyer <[email-masked]>
Date: Tue, 5 Dec 2000 09:31:20 -0800 (PST)

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

> with ZONE options, the entire zone, including out-of-zone glue, should be 

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.

> 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

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 06 Dec 2000 08:29:06 +0100

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

oops....sorry.

>in hindsight that that clause is largely meaningless anyway.

dropping ZONE from the doc would make it stronger, IMNSHO.
But I guess I still don't understand what it's good for - adding a more 
fleshed-out use case is probably good for DNS amateurs such as me.

>use the option in the same way.

three, not two.....
global namespace was concerned with the situation where you have 3 
nameservers and 2 views:

   Server A
      view INT primary for .company
      view EXT primary for .company

   Server B
      view INT primary for .firm
      view EXT primary for .firm

   Server C
      view EXT secondary for .company
      view EXT secondary for .firm
      view INT secondary for .club

a client trying to check that the EXT view of .firm was consistent would have
to configure himself with two different names for the same view.
If views were globally named (say, with a domain name under the manager's 
DNS space), those names could not collide.
But this may not be a problem worth solving.

I'll accept your reasoning for the "no way to list views" - although it 
sticks in the craw from a management perspective, DNS isn't a management 
protocol.

The third (naming scheme - wrote that one badly) is an issue that arose 
once where 2 implementations of a protocol interpreted a certain field - 
one could only enter ASCII, and the other was configured with a binary 
value as (unchangeable) default. (TSAPs in X.400, if anyone cares).

This fun event left me with a permanent distaste for namespaces where the 
name is not specified to be either a specific charset or "pure binary".
Saying that "the name consists of ASCII characters", "UTF-8 characters" or 
"binary octets" will all leave me happy.

I understand and like the VIEW option, by now.

Have fun!

---

From: Michael Sawyer <[email-masked]>
Date: Wed, 6 Dec 2000 09:15:33 -0800 (PST)

> dropping ZONE from the doc would make it stronger, IMNSHO.

We have been discussing the possibility of doing just that.  There's a
good chance at the IETF, I'm just going to say, "even though the ZONE
option is in there, it will be removed from the next revision."  

> to configure himself with two different names for the same view.

Actually, in that case, you wouldn't really need the VIEW option.  Server
C, being a third-party server would be outside the network, would get the
EXT views by default.

Now, let's say that server C was internal to one of the other
networks.  The way we plan to add the option into bind is that there will
be an option in the zone along the lines of "remove-view EXT;" so that
you'll not be required to have the views matching between servers.  (Of
course, under a single administrative domain, having them be different
would be silly, but in the case you name, it make sense.)

> value as (unchangeable) default. (TSAPs in X.400, if anyone cares).

In honesty, I largely agree with this argument.  We're willing to change
to either "any legal DNS label" or "any legal UTF-8 string" in a revision,
probably leaning toward the first.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 07 Dec 2000 07:58:23 +0100

>C, being a third-party server would be outside the network, would get the

let's consider view EXT the view belonging to an extranet, rather than "the 
public view"; that makes it more interesting.

Apart from the name clash, the other interesting case is if the manager for 
B tries to look at his extranet's EXT view for .firm on C and gets returned 
the information for the EXT view for .company.
This shouldn't be a problem unless they have conflicting definitions of 
something (the root zone, for instance), but could get confusing.

Of course the paranoid among us see it as a security problem.....
if you want to make a hard problem harder, drop the word "security" in - I 
think you need an option to specify that views are visible on specific 
interfaces only, in order to satisfy the paranoid among us.
But you probably already have that, just not in this document.

Sigh.