Subject: DNSEXT future

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Mon, 26 Mar 2007 20:36:10 -0400

Dear Colleagues:

Last week in the WG meeting at IETF68 the chairs raised the issue that
the working group has basically concluded all of its working group items.
The chairs believe that there are no DNS protocol CHANGES that are being
developed.
With the conclusion of the NSEC3 work there seems to be consensus
that DNSSEC work is done.

All the remaining work in the group are close to completion,
with the exception of
	ECC DNSKEY specification.
	advancing RFC's up the standards track.
Both of these items have not had great interest or activity.
A potential new item for the working group is the provide input on the
processing of RFC2929bis templates while that process is stabilizing.

For this reason we asked the meeting and our AD for guidance on what to do
with the working group. The three options are
	A. keep the working group open
	B. Put the group to sleep/hibernate
	C. Close the working group

Options A and B require a new charter, the main reason for keeping the
working group alive is to have an official place to take DNS ideas
and have them processed (i.e. killed).
A living working group (case A) may keep attacking work which is
of limited value.
A group in hyphenation state still has a chair and official mailing
list it can process ID's as needed but does not meet.

The feedback that the chairs was that option A was not attractive to the
people in the room.

Option B had supporters and is advocated by our AD.
There are few people advocating option C as that sends the strongest
message that changes to DNS and DNSSEC are done and there is nothing more
to do.

The purpose of this message is to gauge the mailing list as to which option
they think is the most appropriate.

Draft charter for DNSEXT in hyphenated state:
     The DNSEXT WG group will actively maintain the DNS protocol and is
     available for advancing DNS protocol related RFCs on the standard
     track, while defending against further enhancements of questionable
     value.

	Olafur & Olaf 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: George Michaelson <[email-masked]>
Date: Tue, 27 Mar 2007 10:53:30 +1000

I am not a fan of WG living forever.

I think a WG in search of recharter after so long is a WG which needs to
be considered a strong candidate for closure, especially if docs in
review are now not there.

If there is a need for a DNS wg, it should come in "at the top".

I think this for two reasons:

	firstly, its better for IETF process its done this way.

	secondly, it will allow for a better charter/focus to emerge.

so you can add me +1 on the closure side.

-George

---

From: Paul Vixie <[email-masked]>
Date: Tue, 27 Mar 2007 01:13:57 +0000

i'd like to see roy's version of DLV standardized before we quit, that's all.

---

From: [email-masked]
Date: Tue, 27 Mar 2007 01:45:36 +0000

> message that changes to DNS and DNSSEC are done and there is nothing more

	good summary.
	B has the downside that a single person(s) (WG chair) is chartered 
	to judge the worthiness of any proposed new work.  Such a gatekeeper
	is prone to abuse, neglect, etc.

	C, imho, is more properly characterized as "nothing more to do at this
	time" - leaving the Mailing list open, but the WG itself in a 
	dormant state (e.g. less than the "hyphenated" version of "B"
	is my prefered outcome.

	fending off bad ideas can be done by the retained DNS directorate.
	new ideas should be the result of a group, forming a charter and 
	having a specific task list to accomplish.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 26 Mar 2007 21:55:59 -0400

Kill it.

The rest of the message says as much, so if you 
are into the "bottom line" you can stop reading 
already.

>that DNSSEC work is done.

Oh, the DNSSEC work is not done, but what remains 
does not need a WG to discuss the protocol.

There's plenty of DNS work out there - 
implementations, performance, etc.  But the 
protocol is cooked though and through.

Yes, DLV probably ought to be allowed to come to 
a conclusion first, but on the other hand, it's a 
shame we have to do it.

>	ECC DNSKEY specification.

I have nothing against this, but it has fallen so 
far off my radar, I can't see me wanting to 
volunteer any time to work on it.  Will this be 
what puts DNSSEC over the top and get interest in 
its deployment?  If not, I wouldn't keep a WG 
together for it.

>	advancing RFC's up the standards track.

Does anyone care about the latter?  I have seen 
that no one wants to bother.  This has become a 
strictly bureaucratic hurdle.

Draft Standards is supposed to mean that 
interoperability has been demonstrated by relying 
on the specifications.  That's a noble goal.  But 
the way things work in the DNS industry today we 
mostly just check to see if the new 
implementations work with BIND and that's enough. 
(At least one open source implementation touted 
that it's testing consisted of replaying queries 
and checking to see if the relies matched that of 
a BIND server's real responses to the same 
queries.)

As long as no one demands Draft Standard compliance, it's not worth the effort.

What about DNAME?  That's the only topic that 
caused any stir of engineering at the meeting 
last week.

>processing of RFC2929bis templates while that process is stabilizing.

I'll note that RFC 2929bis has nothing to do with 
engineering and is a (much needed) bureaucratic 
process.  It's not about engineering.

>     track, while defending against further enhancements of questionable

I really think it is a folly to maintain a 
dormant WG.  (For those who don't know, Olafur 
and I go back 25 years back before I had to help 
him with the English of his thesis - I say this 
because: "Olafur, *hyphenated*? Is the group 
getting married?  Like DNSOP-DNSEXT?  Sorry 
folks, sorry for the sarcasm - yes it doesn't 
scale.)  Oh, back to the cynical comment I *was* 
going to make...

A "hibernating" anything cannot "actively" do anything.

Returning to being serious...DNSEXT was formed to 
engineer specific extensions for DNS, not be a 
bit bucket for the DNS protocol changes.

The DNS protocol is something that should not be 
undergoing continuous measurable improvement. 
It's infrastructure, at some point it is done. 
People who aren't DNS experts ought to be able to 
see a stable platform.

Yes there are features we want out of a naming 
system that are not in DNS.  But there's no way 
we are going to get them features with what's 
running on port 53 today.  "Super wildcards" - 
hat's off to the idea, but it can't happen with 
this protocol, we've plum tweaked the protocol 
out.

Here's why we need to kill this outright:

1) Tell the ICANN folks we are done.  They can 
count on the DNS as the basis of much of the work 
going on there.  I'd be happy if we could 
engineer a better naming system (DNS2) that 
better fits the budding regulatory environment 
growing there.

2) Tell the folks that are not signing the root 
that we've done the best we can, it's in their 
hands now.  The extensions are done.

3) Let folks know that the IETF is still an 
engineering organization with dynamic components, 
not yet a crusty bureaucracy that can't seem to 
let go of bailiwicks.

4) Give the impression that new features for a 
naming system are going to need a major overhaul 
of the naming system.

Engineering is meant to solve other people's 
problems.  Fortunately for us, there are always 
problems somewhere.

PS - There's no reason to shut down the list. 
The PROVREG WG as shut down (effectively after 
the spring 03 IETF, officially about a year more 
as documents got passed through the 
gastro-editorial tract), the ietf-provreg list 
stayed open (and still is) and has seen the 
documents get to Draft Standard.  The latter 
thanks to there being a desire to see it happen 
by participants.  (And no WG as needed!)

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Sarcasm doesn't scale.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 26 Mar 2007 22:14:25 -0400

Hyphenation state?

Would it be fair to characterize (B) as "We'll continue to be open to standardize new RR Types that don't require changes to the base DNS protocol, but further changes in the protocol are neither contemplated nor desired [for a period of x years]." ?   I'd like to put a sunset clause on this - to wake up in say three years, do a 2-meeting evaluation of progress and either wake up fully (say, to address discovered problems in ??), go back to sleep or disband at that time.

With respect to Paul Vixie's note - I assume he meant passing the DLV document to Informational rather than as a standard? Not sure it needs a live WG for it to get to that state.  But useful to have the discussion take place on namedroppers.

I'd  vote for B with an identified stuckee as chair just to have a point of contact to advance the various stuck-at-proposed RFCs with the notes as above.

Mike

---

From: Mark Andrews <[email-masked]>
Date: Tue, 27 Mar 2007 12:27:51 +1000

If we need to defend against new DNS extentions then this
	has to be done in a open manner.  The DNS directorate is
	not the appropriate place.

	As for "BIND" is the standard.  Please don't.  We have many
	times needed to make implementation choices.  Sometimes
	those choices are wrong.  Sometimes we mis-read / overlook
	something.  Also we have been there as part of the development
	process.

	We really do need to see interop from new vendors that
	wern't around when a RFC is developed to be able to move
	forward RFCs on the standards track.  We had a perfect
	example of this in the weeks leading up to IETF 68.

	I still want to see the RFCs advanced.  I would however be
	happy with waiting a year or so before looking at them as
	I feel that most of the wg feel slightly burnout at this
	stage.  Recessing for a year or so would be a good idea.

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Roy Arends <[email-masked]>
Date: Tue, 27 Mar 2007 08:20:38 +0200

> i'd like to see roy's version of DLV standardized before we quit, that's 
all.

Me too. (well, ofcourse I would, wouldn't I). Jakob and I are writing this 
up in a draft that will soon hit the list.

As for DNSEXT, I don't think we're done at all. There is indeed DLV, and 
there is the last mile. There is also the transparency and the end-to-end 
paradigm I'd like to see written up, explicitly for the DNS. There is 
key-management, rollover, and once 2929-bis is done, I hope to see more 
record types hit the iana registry. Some of this can be wrapped up in 
DNSOP, but not all of it.

Just my .02 american lire.

Roy

---

From: Shane Kerr <[email-masked]>
Date: Tue, 27 Mar 2007 10:58:32 +0200

Ólafur,

>     track, while defending against further enhancements of questionable

I find the idea of changing the group to one explicitly chartered to stop work
to be a bit disturbing. Nobody else in the room seemed to mind, so maybe I'm crazy.

I understand that DNS is somewhat of a magnet for bad ideas, since it is so
successful. But "defending against further enhancements of questionable value"
implies a closed mindset.

What is the new DNSEXT group supposed to do when a good idea appears? With this
charter, the most important thing the group can do is criticize the idea, until
the people advocating it somehow manage to get work done anyway, or go away and
leave the IETF process completely.

For the record, I like the idea of a hibernating group of DNS experts to *help*
people with their DNS ideas and drafts.

- --
Shane

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 27 Mar 2007 11:18:06 +0200

On Mon, Mar 26, 2007 at 09:55:59PM -0400,
 Edward Lewis <[email-masked]> wrote 
 a message of 154 lines which said:

> I'd be happy if we could engineer a better naming system (DNS2) that
> better fits the budding regulatory environment growing there.

Expect a RFC on DNS2 requirments in four days, then a BoF in Chicago
and a new WG :-)

---

From: Niall O'Reilly <[email-masked]>
Date: Tue, 27 Mar 2007 10:32:36 +0100

On 27 Mar 2007, at 02:55, Edward Lewis wrote:

> What about DNAME?
> That's the only topic that caused any stir of engineering at the  
> meeting last week.

	As some of you know, I'm a fan of DNAME.
	Unfortunately, I wasn't able to listen in remotely to last week's  
meeting.
	Consequently, I have some catching up to do.

	Last time I read Wouter's draft, it seemed to me that any remaining  
DNAME issues
	were operational in nature, and thus out of scope for DNSEXT.  I  
_am_ wondering
	where best these can be followed up -- DNSOP?

	Best regards,

	Niall O'Reilly
	University College Dublin IT Services

	PGP key ID: AE995ED9 (see www.pgp.net)
	Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9

---

From: [email-masked]
Date: Tue, 27 Mar 2007 09:33:01 +0000

> Expect a RFC on DNS2 requirments in four days, then a BoF in Chicago

	RFC in four days!!!!  the new IESG/IAB have apparently cut 
	a fast-track deal w/ the RFC Editor.  How did you do it?

--bill

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 27 Mar 2007 12:01:06 +0200

On Tue, Mar 27, 2007 at 09:33:01AM +0000,
 [email-masked] <[email-masked]> wrote 
 a message of 20 lines which said:

> > Expect a RFC on DNS2 requirments in four days, 

>  How did you do it?

Do a bit of maths and you'll see :-)

---

From: bert hubert <[email-masked]>
Date: Tue, 27 Mar 2007 12:05:31 +0200

> people with their DNS ideas and drafts.

For me that is a very important point - 'namedroppers' serves as a central
gathering of DNS experts and knowledge.

Whatever happens to DNSEXT, I still need such a central place where people
know how things *should* work. As opposed to DNSOP which is a gathering of
people who know how things *do* work :-)

Both groups have their purposes.

-- 
http://www.PowerDNS.com      Open source, database driven DNS Software 
http://netherlabs.nl              Open and Closed source services

---

From: Mathieu Arnold <[email-masked]>
Date: Tue, 27 Mar 2007 12:09:55 +0200

+-Le 27/03/07 12:01 +0200, Stephane Bortzmeyer a dit :
| On Tue, Mar 27, 2007 at 09:33:01AM +0000,
|  [email-masked] <[email-masked]> wrote 
|  a message of 20 lines which said:
| 
|> > Expect a RFC on DNS2 requirments in four days, 
| 
|>  How did you do it?
| 
| Do a bit of maths and you'll see :-)

Shouldn't that be five days ?

-- 
Mathieu Arnold

---

From: David Conrad <[email-masked]>
Date: Tue, 27 Mar 2007 11:28:33 +0100

Hi,

> that DNSSEC work is done.

Key rollover?

> 	C. Close the working group

And create task specific working groups as necessary.

Rgds,
-drc
(Speaking for myself)

---

From: [email-masked]
Date: Tue, 27 Mar 2007 10:52:14 +0000

> Do a bit of maths and you'll see :-)
	2,880 hour days... works out just right.

--bill

---

From: Scott Rose <[email-masked]>
Date: Tue, 27 Mar 2007 07:23:01 -0400

Niall O'Reilly wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 

Well, there was some last protocol (mainly signals/TTL value) issues
left that were presented, but most of them seem settled.  Wouter and I 
don't know if any last minute issues will come up, but a mailing list 
can take care of that (I hope).

Most of the text is protocol, so DNSEXT makes more sense.  However, I 
don't think there needs to be any meeting time devoted to the draft 
anymore.  All the work can be completed on the mailing list in a short 
time frame (before Chicago, I hope :)  )

Scott

----------------------------------------
Scott Rose            Computer Scientist
NIST
ph: +1 301-975-8439
[email-masked]

http://www-x.antd.nist.gov/dnssec
http://www.dnssec-deployment.org/
-----------------------------------------

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Mar 2007 08:17:56 -0400

At 7:23 -0400 3/27/07, Scott Rose wrote:

>Most of the text is protocol, so DNSEXT makes more sense.  However, I don't
>think there needs to be any meeting time devoted to the draft anymore.  All
>the work can be completed on the mailing list in a short time frame (before
>Chicago, I hope :)  )

When I say there's no engineering left, I am talking about design 
work, work that needs a group to discuss.

What's left are mostly document processing steps, editing, etc.  I 
think that for the most part ideas have been hammered out, we need to 
express them.

OTOH - using the DO bit to signal understanding of DNAME is something 
I would "encourage my competitor to do."  Perhaps that needs to be 
discussed.  (If so, that should be on a new thread.)
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Sarcasm doesn't scale.

---

From: Matt Larson <[email-masked]>
Date: Tue, 27 Mar 2007 08:47:56 -0400

My vote is for:

> 	B. Put the group to sleep/hibernate

We can simultaneously respond to ideas--good or bad--that come up, as
well as complete the remaining work that others have mentioned in this
thread.  (I am especially concerned with key rollover.)  I don't agree
with the notion that all the engineering work is done and only paper
shuffling is left.

What's the hurry to close down and what's the harm in going dormant?
We can wait in the wings until the DNS bat signal is projected in the
clouds and can spring nimbly back to life, without the overhead of WG
formation.  I especially like that there's a precedent with the PPP
WG.

Matt

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Tue, 27 Mar 2007 09:51:12 -0400

At 21:55 26/03/2007, Edward Lewis wrote:

>What about DNAME?  That's the only topic that caused any stir of 
>engineering at the meeting last week.

I omitted from my summary that we have 2 active working group documents[A]
both of which the chairs intent to force the working group to
finish in the next few months, and advance them to IESG by Jun. 15'th.

There are also number of documents at the IESG that need to be processed.
Rechartering takes minimum 1-2 months so the WG, chairs and AD needs some
lead time on that one, thus the question now.

Each one of the options presented has different point of execution,
killing the WG is the one that will take longest (i.e. after IESG approves
the last document). Keep the group around is shortest, going sleep is in
the middle.

The purpose of this message is an open question to the WG are we done
mucking with DNS and DNSSEC?

         Olafur

[A] Read and comment on ASAP:
http://ietf.org/internet-drafts/draft-ietf-dnsext-rfc2672bis-dname-01.txt
http://ietf.org/internet-drafts/draft-ietf-dnsext-forgery-resilience-00.txt

---

From: Frederico A C Neves <[email-masked]>
Date: Tue, 27 Mar 2007 11:22:43 -0300

> that DNSSEC work is done.

Finish DNAME, get a better understanding/implementation/standard on
the Key Rollover problem, or does the informational trustupdate-timers
is our final call on that ?

then,

...
> 	C. Close the working group

Close the working group.

Fred

---

From: Ólafur Guðmundsson /DNSEXT co-chair <[email-masked]>
Date: Tue, 27 Mar 2007 10:37:42 -0400

>>that DNSSEC work is done.

WG advanced the -timers- draft as the protocol handling this issue.
The WG has not taken on "Initial TA trust configuration" work item
which is the open Key management issue.
The last mile problem still remains, some says run full validator at
end, others say wider channel from validating resolver to stub-resolver,
so far the WG has not seen any proposals to address this.

>And create task specific working groups as necessary.

Yes that would be the plan.

         Olafur

---

From: Dean Anderson <[email-masked]>
Date: Tue, 27 Mar 2007 11:14:06 -0400 (EDT)

I think the working group needs to properly resolve AXFR-clarify.
I will submit a draft to do this.

IXFR also needs work.

I think the working group should stay open to handle existing and new
DNS protocol issues and new record formats.

There are a number of new protocols that have been put forward, but for
which there is no implemenation or experience.  I rather expect that
some of these drafts will need to be tweaked.  The working group should 
stay open as a forum to discuss that work.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Paul Vixie <[email-masked]>
Date: Tue, 27 Mar 2007 15:24:06 +0000

there are three replies here, two about DLV, one about this mailing list.

> From: Michael StJohns <[email-masked]>
> 
> With respect to Paul Vixie's note - I assume he meant passing the DLV
> document to Informational rather than as a standard?  ...

no.  roy arends told me a dlv the other day that would scale.  steve crocker
asked his dnssec-deployment committee the other day whether dnssec was
deployable without "something like dlv" and the consensus was "no."  (steve
went further than i, saying that "something like dlv" would ALWAYS be needed,
not just as an early deployment aid.)  taking those two facts together means
that we need to put roy's dlv on the standards track, and for that we need a
WG.

given that this WG has created an undeployable secure-dns protocol, it seems
that disbanding would be a good way to signal our disgrace, but would not
serve any constructive purpose.  literally speaking, we're just not finished.

> From: Roy Arends <[email-masked]>
> 
> vixie> i'd like to see roy's version of DLV standardized
> vixie> before we quit, that's all.
> 

and there was great rejoicing.  i disagreed with steve, i thought secure dns
only needs "something like dlv" during early deployment.  but based on david
conrad's estimate of the costs and risks involved in holding the KSK, and the
unlikelihood of ICANN being able to assume those costs or willing to assume
those risks, i now agree with steve, "something like dlv" will *always* be
needed.

given that roy's proposed hack to dlv would allow each domain to choose its
own dlv registry, the scaling limit of "one single dlv registry" will be gone,
and with some care around both off-the-wire aggressive-negative-caching and
negative caching in general, dlv as part of the basic secure dns architecture
is not only necessary, but realistic and practical.

> From: bert hubert <[email-masked]>
> 
> kerr> For the record, I like the idea of a hibernating group of DNS
> kerr> experts to *help* people with their DNS ideas and drafts.
> 

the namedroppers@ mailing list predates this WG, and predates the old DNSIND
working group, and may predate IETF, having been part of NWG.  there is no
authority now living who can close this list, only choose whether to stop
hosting it, and i do not expect "ops.ietf.org" to stop hosting this list.

on the other hand, [email-masked] has been a success, more so
than the various other (closed, invitation only) lists hosted by OARC.  keith
would certainly create [email-masked] if someone asked him to.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 27 Mar 2007 09:40:59 -0700

One issue that keeps coming up is the desire to publish some form of policy indication through the DNS.

I don't think that the IETF can or should ignore this. If we do we will end up with the situation that most of us like least and is the reason that people tend to try to suppress such proposals - without success. In particular we end up with:

  * Protocols that perform 'tree walking' and other forms of heuristic policy discovery

  * DNS RRs being hijacked for other purposes (e.g. SPF use of the unprefixed TXT record)

  * A proliferation of unregistered, untracked TXT and SRV prefixes.

  * People sticking large chunks of XML text into the DNS infrastructure itself

  * People propose rival infrastructures (e.g. UDDI, XRI) that attempt to superceed the DNS.

  * It is not yet happening but if we make DNS RR assignments into the equivalent of IP port numbers we should expect to see unauthorized and uncontrolled RR assignments becoming common.

I don't like any of the above. But from an architecture perspective I fully expect that in the future we will see most new protocols specify some form of policy layer. And expect the number of protocols to start to proliferate very quickly as Web Services / Mashups / Semantic web take hold over the next ten years.

I fully expect that the number of protocols that define policy will be of the order of hundreds a year. I don't believe that this is compatible with the idea that each policy record should have its own RR. If we go that route we are committing to burn several hundred, possibly thousand RRs per year to keep up with something that is not core to the DNS protocol. That is something that we must also avoid.

Rather than wait for the problem to become serious I would prefer to solve the problem now, once by anticipating it.

The solution I want to propose makes use of either one new RR or possibly two new RRs. The objective here is to get ahead of the curve by anticipating a very large number of needs while sticking to the core principles of DNS. In particular:

AXIOM1     : The DNS infrastructure is the sole authortitative lookup scheme for DNS names
 
COROLARY1  : If a protocol policy is bound to a DNS name the mechanism for discovery of that policy must be mediated by the DNS.

AXIOM2     : The DNS supports lightweight queries and responses

COROLARY2  : If the policy does not fit onto a few lines of text the DNS should return a pointer (i.e. URI) to the results.

COROLARY3  : If the form of the query requires any parameters other than a DNS name the DNS result must be a pointer to a service that can handle the extended query (e.g. SIP, LDAP, etc.)

AXIOM3     : Adding a new protocol to the Internet should not require any change to the core Internet infrastructure, including the DNS, nor should this require consumption of any finite resource (IP ports, DNS RRs).

This analysis makes me believe that prefix records are the way to go. This creates a problem however since prefix records do not work with wildcards. In particular it is not possible to define a wildcard of the form:

    _prefix.*.example.com

Which is of course exactly the type of record that the DKIM people need and many others want. 

We can solve DKIM by issuing a new RR and getting round the restrictive DNS wildcard semantics by using an administrative wildcard of some form. We can solve GEOPRV. OK so that is two new RRs. And two sets of synthesized data to be created at every node in the DNS tree. That is arguably manageable.

What do we do if there are a hundred policy protocols to be dealt with, each of which require their own administrative wildcard expansion?

   **.example.com DIKMP       "DKIM"
   **.example.com GEOPRIVP    "..."
   **.example.com NEWPROT1    "..."
   **.example.com NEWPROT2    "..."
   ...
   **.example.com NEWPROT100  "..."

Each of those administrative wildcards require a record to be synthesized for every node in our zone. Say we have 200 nodes. That means we have 20,000 synthetic records sitting around. Plus another 20,000 signatures if we are doing DNSSEC. 

A much better way to solve this problem is to introduce a pointer record into the scheme. This allows us to create the 'midpoint wildcard' without changing or disrupting DNSSEC. The policy discovery process then becomes:

1) Look for TXT at _policy.node.example.com
	If found, return the result and terminate

2) Look for XPTR at node.example.com
	If not found then return 'NOPOLICY'

3) Look for _policy.<xptr-result>
	If found return the result
	Else return 'NOPOLICY'

Under this scheme we still need a single administrative wildcard for the XPTR record. But every policy scheme can make use of the same XPTR record. So in the previous example we would only require 200+200 additional records. The combinatorial explosion is avoided.

So far the chief objection I have received has been 'this is architecture, it might be wrong'. Which is of course right but completely unactionable. We can forsee a problem, we have a proposed solution. It is quite possible that the proposed solution might not anticipate every eventuiality but this does not seem to me to be a good argument for ignoring the problem we can forsee.

What objective criteria can be defined for the correctness of an architectural proposal? From my point of view the approach that I take is pretty minimal, very clean and I think it through at both the protocol level (bits on the wire) and the API level (is it possible to encapsulate this in a fashion that makes sense).

With this addition I believe I can support the features required in DKIM, SPF, and anything built on WS-Policy. That may not cover everything but it does at least get us ahead of the fire.

If I am right we avoid what could become a serious problem within a few years. Growth in the number of Internet protocols has largely been constrained by the fact that they have been mostly targetting human-human and human-machine interaction. 

Once we get into the detailed area of machine-machine interaction the problem space becomes huge, much larger than OASIS, W3C, ITU and IETF combined. Worse still expect that most of those protocols are going to be designed by people who have no real concept of the DNS except what they learn through administering protocols such as DKIM. For every standards track proposal there will be tens of proposals that never make it there.

Anyway, since we are told that it is easy to get a new RR assigned I am going to propose the XPTR RR as a standards track proposal. It has to be STANDARD, not EXPERIMENTAL or else the DKIM working group will be unable to make use of it.

The question then is should this be a proposal made to DNSEXT or a personal submission or what?

---

From: Suresh Krishnaswamy <[email-masked]>
Date: Tue, 27 Mar 2007 11:48:22 -0400

> so far the WG has not seen any proposals to address this.

Well, running a full validator at the end does not solve the last- 
mile problem. Not unless we have a standardized mechanism for  
applications to specify their validating policies to the validating  
stub resolver, and not unless we have a standardized way for  
applications to get the results of validation from the validating  
stub resolver (may I now refer you to draft-hayatnagarkar-dnsext- 
validator-api :) ).

Even without a full validator at the end, we  (as a working group)  
have yet to decide what level of validation information and policy  
must be extruded on-the-wire. Whatever information we do choose to  
carry on-the-wire, it still needs to be consistent with the results  
returned by a validating stub resolver since the API will for  
applications has to be the same.

The last time I asked informally, the answer that I got was that API  
work was not within the scope of this working group, and extruding  
detailed validation policy and authentication chain information on- 
the-wire, even though within scope, was a bad idea. Is this still the  
working groups sentiment? If draft-hayatnagarkar-dnsext-validator-api  
is not within scope for DNSEXT, which working group is better suited  
to standardize last-mile issues/solutions?

Suresh

---

From: Shane Kerr <[email-masked]>
Date: Wed, 28 Mar 2007 14:55:48 +0200

Hallam-Baker, Phillip wrote:
> I don't think that the IETF can or should ignore this.

I totally agree!

I'll go further. I think this is a good example of the type of thing that the
IETF has failed to provide good engineering solutions for "ideological" reasons
in the past. By this I mean technologies that are compelling to engineers
dealing with day-to-day problems, but don't fit well with the architecture and
design philosophies of the Internet. (As an example, consider how poorly VoIP
worked behind NAT before STUN was adopted.)

<snip/>

> Anyway, since we are told that it is easy to get a new RR assigned I am going to propose the XPTR RR as a standards track proposal. It has to be STANDARD, not EXPERIMENTAL or else the DKIM working…

Agreed - experimental is "an interesting idea, but don't use it".

> The question then is should this be a proposal made to DNSEXT or a personal submission or what? 

Could it be a test case for the "dnsext as a group to help provide input on
other DNS drafts"?

- --
Shane

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 29 Mar 2007 11:07:25 -0400

Dear colleagues,

> 	C. Close the working group

I do not have a strong preference between B or C.  In the absence of
drafts that the WG is willing to take up as new work, I can't see an
argument for A.

If the consensus is to follow approach B, I would like to suggest a
relatively short (18 months?) deadline after which, if no work has
emerged to "awaken" the group, the WG be formally closed.  (That would
be 18 months after recharter, which gives us a practical period of
something in the area of two years.  That ought to be plenty of time
for evaluation, I would say.)  As others have suggested, there is no
reason the mailing list cannot remain active in such circumstances,
and to the extent it continues to attract experts in the protocol, I
think it can remain a useful resource to the wider IETF community
without a working group behind it.

A

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

---

From: "Edward Lewis Jr." <[email-masked]>
Date: Wed, 28 Mar 2007 10:47:16 -0400 (EDT)

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

I'm aware that I'm answering comments from two different folks here.

> I'll go further. I think this is a good example of the type of thing that
> the IETF has failed to provide good engineering solutions for "ideological"
> reasons in the past. By this I mean technologies that are compelling to
> engineers dealing with day-to-day problems, but don't fit well with the
> architecture and design philosophies of the Internet. (As an example,
> consider how poorly VoIP worked behind NAT before STUN was adopted.)

There are a couple of things I want to respond to in this.  The IETF 
doesn't promise to provide anything, volunteers do this.  If no one 
volunteers a solution to this, nothing is going to come out.

I completely understand the comment that the IETF seems to stomp on
technologies for ideological reasons.  I can think of some rumored 
situations myself, mostly in areas in which I am not an expert, i.e., I 
bet if I knew more I'd "buy in" to the ideology.

There's something in your words that I want to debate.  "Technologies that 
are compelling to engineers dealing with day-to-day problems."  One should 
not want a technology to deal with a problem, rather there should be a 
solution to the problem that uses the right technology.

What I am lining up to say is that there are needs by other parts of the 
Internet architecture, like what Phillip Halem-Baker is requesting.  And, 
yes, it's  reasonable to expect that the functionality would be part of 
the naming  system.  But, and this is the point of contention, is that the 
DNS  protocol as we know it today is quite possibly unable to accomodate 
the  need.  And that is why I am balking at wanting to work on this.

No amount of continued justification for the problem would change the 
opinion of mine - not because I don't want to hear it, but because I 
already buy into what is desired.  Really, I have no problem with the 
requirement.  The problem is that I don't see how I can squeeze any more 
support for the need from the bits available in the packet format or the 
cycles of the algorithms already implemented and deployed.

VoIP and STUN to work over NATs is a good example of being able to pull in 
another technology to get over a hump.  Is that possible here, is there a 
helper technology that can be easily integrated between DKIM and DNS to 
get the need met?  I would like there to be one, I can't think of it. 
Maybe it's LDAP?

Calling for DNS2 isn't an acceptible response either, that would take a 
long time.  However, we should be looking long range at some point and 
bring on, maybe DNSv6, to handle what DNS can't accomodate today.

The point isn't ideological, it's based on technical issues - like being 
able to maintain backwards compatibility with deployed code and retaining 
the quick and lightweight nature of the protocol which is probably it's 
greatest asset (more so that scaling).  I know that it sounds like me 
supporting protocol purity, but the alternative is to create a complex and 
amorphous mass that will take a small army of dedicated soldiers to 
operate.

When looking forward, we can't disregard the past in a protocol like DNS. 
We can't say "well wildcards are evil so let's just pave over any 
compatibility because I don't need them."  If that runs rampant, you'll 
wind up with tens of extensions, each for a niche segment of the network, 
that are potentially incompatible with each other.  That's why I resist 
freely extending the DNS in this manner.

>> Anyway, since we are told that it is easy to get a new RR assigned I
>>am going to propose the XPTR RR as a standards track proposal. It has
>>to be STANDARD, not EXPERIMENTAL or else the DKIM working group will
>>be unable to make use of it.

Where did "easy" come into play? ;)  New RR type codes ought to be readily
assigned to extensions that are compatible with the DNS, extensions that
do not "endanger" it's stability.

I do agree about the difference between experimental and standard.  The 
rationale in DNS is that it makes somethings easier to write in name 
server code.  The tradeoff is a burden to application code.  I personally 
have disagreed with reserving ranges of RR type codes for special 
purposes, although a "permanently private" band is useful.

>> or a personal submission or what?

The way the group has operated it starts as an individual submission 
anyway.  That says nothing of whether the work fits into the charter or 
not.

If I were to agree that this is a group item (and I'm just supposing for 
now) I would bet that the group would not be able to come to a successful 
solution.  No matter how well crafted the problem statement is, I have 
doubts that the protocol can be extended to accomodate this.  Of course, 
the doubts I have are not founded in fact as I haven't seen a detailed 
description of the proposed solution -  I just have hazy doubts based on 
my knowledge of the DNS architecture and what the general desire of DKIM 
is.

> Could it be a test case for the "dnsext as a group to help provide input on

I think we already have had plenty of such test cases.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 29 Mar 2007 22:40:18 -0700

On Mar 27, 2007, at 9:40 AM, Hallam-Baker, Phillip wrote:

> I don't think that the IETF can or should ignore this. If we do we  
> will end up with the situation that most of us like least and is  
> the reason that people tend to try to suppress such proposals -  
> without success. In particular we end up with:
>
>   * It is not yet happening but if we make DNS RR assignments into  
> the equivalent of IP port numbers we should expect to see  
> unauthorized and uncontrolled RR assignments becoming common.

These contortions of DNS overcome impediments imposed by messaging  
protocols that fail to offer client identification and a corporate  
environment lacking provisions for DNS.  What new DNS feature will  
allow DNS to evolve when DNS development appears stagnant within the  
corporate environment?  PRNP and Teredo is the change being offered,  
for good or bad.

> I don't like any of the above. But from an architecture perspective  
> I fully expect that in the future we will see most new protocols  
> specify some form of policy layer. And expect the number of  
> protocols to start to proliferate very quickly as Web Services /  
> Mashups / Semantic web take hold over the next ten years.

While true, motivation appears related to messaging providers wishing  
to remain nameless.  After being affected by various DoS attacks, one  
grows wary of a plan that has DNS servers synthesize large answers  
for a label anywhere within their bailiwick.  Initiatives such as  
OpenID could be a cue HTTP is an appropriate repository for such  
extensions.

> I fully expect that the number of protocols that define policy will  
> be of the order of hundreds a year. I don't believe that this is  
> compatible with the idea that each policy record should have its  
> own RR. If we go that route we are committing to burn several  
> hundred, possibly thousand RRs per year to keep up with something  
> that is not core to the DNS protocol. That is something that we  
> must also avoid.

HTTP is shifted to the edge of the network by various strategies  
which also makes it a compelling alternative.  Efficiencies found in  
simple messaging protocols have been countered by abuse permitted  
through a lack of name based identifications.  It is hard to know  
whether an IP address normally carries messages for some named  
entity.  When such message traffic is amassed behind address  
translation gateways, such will become increasingly difficult.  HTTP  
OpenID solves client identification issues in a manner independent of  
the IP address.

> Rather than wait for the problem to become serious I would prefer  
> to solve the problem now, once by anticipating it.

An attempt to repair a deficient messaging protocol with DNS  
wildcards can produce even greater harm.  Can client identification  
be established without scanning domain hierarchies?  Yes, especially  
when authentication and authorization is a component of the  
protocol.  A scheme of synthesizing a DNS answer facilitates  
publishing information regarding protocol repairs, but over a vast  
name space.  Often what is often needed is a means to associating one  
name with another.  Name associations can be done without use of  
wildcards.  Much of the authorization quandary can be resolved by  
associating two disparate names.  Publishing a name as a base32 hash  
below the authorizing name allows a large array of associations using  
small DNS answers.  DNS supports this today without searches or use  
of wildcards.  Rate limits offer a solution for all unauthorized  
messages within an adoption phase.

> The solution I want to propose makes use of either one new RR or  
> possibly two new RRs. The objective here is to get ahead of the  
> curve by anticipating a very large number of needs while sticking  
> to the core principles of DNS. In particular:
>
> COROLARY1  : If a protocol policy is bound to a DNS name the  
> mechanism for discovery of that policy must be mediated by the DNS.

The relationship between names can be established as a component of  
the protocol without requiring a modification to DNS.

> COROLARY2  : If the policy does not fit onto a few lines of text  
> the DNS should return a pointer (i.e. URI) to the results.

Cue HTTP.

> COROLARY3  : If the form of the query requires any parameters other  
> than a DNS name the DNS result must be a pointer to a service that  
> can handle the extended query (e.g. SIP, LDAP, etc.)

It would be better to have this pushed to the edge of the network  
when possible.  There is a fair amount of infrastructure in place to  
do this with HTTP as well.

> AXIOM3     : Adding a new protocol to the Internet should not  
> require any change to the core Internet infrastructure, including  
> the DNS, nor should this require consumption of any finite resource  
> (IP ports, DNS RRs).

It would be better to design authorization and authentication within  
the protocol initially, rather than adding these feature later.  You  
describe a mechanism to publish SPF record sets across a vast name  
space.  Whatever problem you see this as resolving creates a hazard  
many orders of magnitude worse.  You are in a good position to know  
controlling a domain or even millions of domains means very little.   
When a domain wishes to be white listed, they will ensure all the  
pieces needed in this new puzzle are in the right place.

Much is still possible by defining new RRs without changing how they  
operate.  Security demands simplicity.

-Doug

---

From: Dean Anderson <[email-masked]>
Date: Fri, 30 Mar 2007 12:30:24 -0400 (EDT)

On Tue, 27 Mar 2007, Paul Vixie wrote:

> there is no authority now living who can close this list, only choose
> whether to stop hosting it, and i do not expect "ops.ietf.org" to stop
> hosting this list.

This is not true. The namedroppers mailing list is now under control of
the IETF Trust. Any one of the IETF Trust trustees can, unilaterally,
close the namedroppers list. Or give it away.  A Trustee of a Trust is
allowed to act unilaterally with trust assets.  The IETF Trust Agreement
also explicitly states that the IETF Trust trustees are exempt from any
fiduciary duties to the maximum extent permitted by law.  This means
they can do things that are financially disastous to the IETF Trust
Assets, and not in the interests of the ISOC or the IETF Trust.  This is
a recipe for exploitation and disaster.

There is no legitimate business purpose to the IETF Trust, much less
with no fiduciary responsibilities, and so I assert it is a fraudulent
transaction to avoid financial responsiblity for torts accrued by the
ISOC and IETF management since 2003.  I am preparing a derivative
lawsuit on behalf the ISOC membership to have the trust declared
invalid, and will be seeking additional signers from the ISOC membership
soon.  Look to http://www.av8.net/IETF-watch/IETF-Trust.html for more
information.

> would certainly create [email-masked] if someone asked him to.

How does one judge that a closed, proprietary list has been a success?  
The ordinary measure of proprietary success is the financial benefits it
brings to the proprietor.

		--Dean