Subject: Re: DNSEXT WG Last Call: EDNS0.5

From: Kevin Darcy <[email-masked]>
Date: Thu, 30 Nov 2000 19:50:31 -0500

Harald Alvestrand wrote:

> At 22:02 29/11/2000 -0500, Kevin Darcy wrote:
> >I would prefer to see a more general mechanism in which both FEATURE codes and
> >OPTION codes, for boolean OPTIONs, are included in the same sorted list: it
> >seems a waste to have to specify such OPTIONs separately from FEATUREs when
> >they are so similar in form and function.
>
> do we have examples of boolean OPTIONs?

None that are drafted/RFC'ed, that I'm aware of. I have some ideas about a "don't
send me extraneous RR's" option (as I brought up several months ago -- see "To Be
Cached, ..."), but nothing concrete yet. It seems likely, though, that boolean
OPTIONs will be proposed in the future. If the codes for OPTIONs and FEATUREs need
to be co-ordinated, this is the time to do it. Otherwise, it may be difficult to
retrofit once we have collisions all over the place.

Note that sometimes there may be an affinity between a FEATURE and a boolean
OPTION. The FEATURE may establish a default -- "do X" or "don't do X" -- and the
corresponding boolean OPTION may establish a mutually-agreeable, per-transaction
override of that default behavior -- "let's do X just this once" or "let's not do
X right now". As FEATUREs get proposed, then, we may start to see boolean OPTIONs
proposed in parallel. I'm not saying this is inevitable, only likely.

> I would hesitate to jam them into the same mechanism if there is a chance
> that we might want to turn them off/on per query - the FEATURE mechanism
> was quite deliberately designed so that it was "relatively harmless" to
> signal a FEATURE you did not have any use for. This is a requirement in
> order to be able to subsume FEATURE lists into VERSIONs.

I don't think mixing boolean OPTIONs with FEATUREs would get in the way of
subsuming FEATURE lists into VERSIONs, especially if the OPTION codes and
FEATURE codes are assigned from distinct numeric ranges. Since the list is sorted
numerically, any reasonable algorithm can easily detect the demarcation between
the two types of extension, i.e. can easily tell that it is done parsing FEATUREs
or OPTIONs, depending on which direction it chooses to work through the list. The
FEATURE processing is thus easily segregable from the boolean OPTION processing.
The only thing it would hinder is if an implementation might want to do, say, a
non-linear (e.g. log) search for a specific FEATURE in a large, unparsed list. How
likely is that? My impression is that FEATURE lists would always be parsed into
internal data structures which would be consulted for any FEATURE-specific
decisions -- repeatedly searching the raw FEATURE list seems rather crude and
inefficient.

Admittedly, my suggestion ultimately only saves 4 bytes in the OPT RR (an
alternative would be to spec a "boolean options list" composite OPTION which would
exactly mirror EDNS0.5's FEATURE list, requiring an extra 2 bytes for the
OPTION-CODE and another 2 bytes for the OPTION-LENGTH), and possibly some parsing
resources, depending on implementation. In the grand scheme of things, 4 bytes is
not a whole lot. But every little bit helps, and I'm not sure that there would be
any significant downside (except of course the standards-process downsides of
having to a) reword the draft, and, potentially, b) to deal with IANA on the issue
of segmenting the range; I could perhaps assist with the rewording, but I'm
unfamiliar with IANA processes and procedures).

- Kevin

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

---

From: [email-masked] (Andreas Gustafsson)
Date: Tue, 12 Dec 2000 16:05:31 -0800 (PST)

> http://www.ietf.org/internet-drafts/draft-ietf-dnsext-edns0dot5-02.txt
> 
> This draft is on standards track, if you disagree with that please state why
> in your response.

I object to advancing the draft.  I do not think there is a genuine
need for this kind of feature indication mechanism, for a number of
reasons:

First of all, it seems to be the consensus of the DNSEXT working group
that the number of new DNS protocol features should be kept to an
absolute minimum.

Even if new features are introduced, it is not clear that a significant 
number of them will benefit from a mechanism to explicitly "determine
which extension features the other party understands".  Determining
the feature set of a server before using it requires an additional
round-trip, which causes considerable additional delays in a protocol
like the DNS which involves many simple transactions with a large
number of distinct servers.  Therefore, new extensions should be
designed to avoid such feature negotiation if at all possible.

For those cases where an explicit indication of support for a new
features is useful, there are existing mechanisms that can do the job
without introducing additional complexity in the form of mandatory
support for the FEATURE option.  The support for a feature can be
indicated by sending a feature-specific OPT RR, which may have an
empty data field if no information other than the mere presence of the
feature needs to be transmitted; with two or fewer features, this
takes no more space than using the FEATURE option.  Alternatively,
each feature may be allocated a flag from the 16-bit "Z" field of the
OPT RR header.
-- 
Andreas Gustafsson, [email-masked]

---

From: Paul A Vixie <[email-masked]>
Date: Tue, 12 Dec 2000 17:40:39 -0800

> > This draft is on standards track, if you disagree with that please state
> > why in your response.
> 

i tend to agree with andreas's reasoning here.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 13 Dec 2000 09:22:46 -0800

>need for this kind of feature indication mechanism, for a number of

I (obviously) disagree.

>that the number of new DNS protocol features should be kept to an

No argument from me here.

>number of distinct servers.

My reply: We introduced this mechanism when we introduced EDNS.
The problem with EDNS was that its mechanism is very coarse grained, so 
that we cannot do (for instance) negotiated tests with the next Binary 
Label-type extension without going through the heavyweight procedure of 
assigning a new EDNS number.
The draft is not about introducing feature negotiation - we already did 
that. The draft is about refining the mechanism so that we can get testing 
and pre-new-version deployment done without it hurting too much.

BTW, the draft does not require an extra round trip for the case where the 
option is supported, any more than EDNS0 does.

>   Therefore, new extensions should be

This point is worth thinking about.
I think that having one mechanism that everyone knows about is better than 
defining one mechanism per extension, and that the administrative procedure 
of collapsing a set of features into a version number gives us a chance to 
get our packet space back once the experimentation phase is over.
But OTOH, the FEATURE mechanism is not useful for signalling per-call 
request differences; extensions might need their own OPTions too, in which 
case we do waste space.

Other thoughts?

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

---

From: Randy Bush <[email-masked]>
Date: Wed, 13 Dec 2000 12:22:08 -0800

> and pre-new-version deployment done without it hurting too much.

so, we already have the camel's nose.  it won't open a much wider hole to
let the head and neck in.  and it will allow significantly more bactrian
benefits.

i am tempted.

randy

---

From: Kevin Darcy <[email-masked]>
Date: Wed, 13 Dec 2000 15:05:41 -0500

If I may make a suggestion:

The EDNS0.5 draft appears to me to logically encompass 2 inter-related
proposals:

1) A "Feature Code" Proposal: a proposal to implement FEATURE codes, which are
similar in function and context to OPTION codes, but, unlike OPTION codes,
which may be purely discretionary between particular clients or servers, or
only for certain transactions, are "standards track", boolean elements of
protocol behavior, expected to eventually -- assuming they prove themselves
worthy -- be absorbed into protocol VERSIONs.

2) An "Aggregator" Proposal: a proposal to implement an OPTION which
aggregates 2 or more 2-octet values, representing boolean "switches" of some
sort, in a sorted list in its data area. This is primarily a
space-conservation measure (since a standalone data-less OPTION occupies 4
octets), although as a secondary benefit, this aggregator might make
composition and parsing of multiple booleans slightly more efficient.

Obviously, these proposals have considerable synergy, given that FEATUREs, if
implemented widely, could consume significant amounts of packet space if --
_sans_ some sort of aggregation mechanism -- they had to be presented as
separate data-less OPTIONs.

But, I think the two parts can be viewed and evaluated independently. The
Aggregator Proposal, as I have previously opined, could potentially be used
for boolean OPTION codes as well as just FEATURE codes, or mixtures of the two
(providing that collisions were avoided somehow). Therefore, I think it has
positive value -- as a pure space-conservation measure -- regardless of
whether the Feature Code Proposal has positive value or not. Coincidentally, I
think the Feature Code Proposal has positive value as well, because I strongly
believe that DNS needs to evolve and grow in order to keep pace with the
accelerating pace of other Internet protocols. But the acceptance or rejection
of one part of the draft doesn't necessarily imply acceptance or rejection of
the other part. Perhaps the draft should be split?

In response to Andreas' specific point about an aggregator with a single
FEATURE code wasting more space than a data-less OPTION expressing the same
boolean concept, I think this is yet another reason why the ranges for OPTION
codes and FEATURE codes should be co-ordinated with each other -- given
collision-protection, a solo FEATURE code could, if desired, be presented as a
standalone data-less OPTION element, to conserve space.

Speaking of space-conservation, I also think that a client or server which
implements no FEATURE codes beyond the ones implicit in the VERSION it
advertises, should not be obligated to provide an *empty* FEATURE aggregator.
The draft as currently written uses mandatory -- or at least non-discretionary
-- language and seems to imply that FEATURE aggregators are *always* supplied
by clients and servers. But where it conveys no useful information, I think
the aggregator should be omitted in the interests of conserving space. Maybe
the mandatory/non-discretionary language could be changed/clarified.

- Kevin

---

From: Robert Elz <[email-masked]>
Date: Thu, 14 Dec 2000 08:43:40 +1100

Date:        Wed, 13 Dec 2000 09:22:46 -0800
    From:        Harald Alvestrand <[email-masked]>
    Message-ID:  <[email-masked]>

I think I agree with Andreas, this draft made me a little queasy...

  | The problem with EDNS was that its mechanism is very coarse grained, so 
  | that we cannot do (for instance) negotiated tests with the next Binary 
  | Label-type extension without going through the heavyweight procedure of 
  | assigning a new EDNS number.

I think that's a feature (of EDNS0).  It makes it very hard to
add new stuff, not something that can be easily done.  What's
more because it adds a difficult mechanism to add new features,
it actually makes it more difficult than before EDNS0 when there was
no mechanism at all (so something relatively simple could be invented
- like "no-one currently sets this bit" - and maybe it would work).

kre

---

From: Paul A Vixie <[email-masked]>
Date: Wed, 13 Dec 2000 14:16:11 -0800

> I think that's a feature (of EDNS0).  It makes it very hard to add new
> stuff, not something that can be easily done.  What's more because it
> adds a difficult mechanism to add new features, it actually makes it more
> difficult than before EDNS0 when there was no mechanism at all (so
> something relatively simple could be invented - like "no-one currently
> sets this bit" - and maybe it would work).

It's definitely the case that EDNS was designed to allow protocol evolution
rather than protocol brownian motion.  We should not be standardizing
things we're not sure of.  The EDNS weakness identified by the 0.5 draft
is that because there's a numerical comparison of version numbers, it's
somewhat difficult to _experimentally_ deploy new elements.  However once they
aren't experimental any more, the protocol should not support their withdrawal.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 13 Dec 2000 14:40:25 -0800

>- like "no-one currently sets this bit" - and maybe it would work).

People have not stopped doing this.

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 15 Dec 2000 02:21:36 +0800

I discussed my idea for the large zone problem yesterday with a couple people.
The responses I got is "speechless-ness", "gasp for air", and "dont go there,
james". I gather I am, once again, onto something ranging from "nuts" to "very
bad idea".

The industry, whether the engineers like it or not, is moving towards a
flatter lever. gTLD has always been flat, and other ccTLD is doing similar
stuff. It is not going to be an isolated problem for one registry but all
registry is going to be affected in one way or another. HOWEVER, I do not buy
into the idea that the world is flat and "I rule, you fix my problem or die"
speech, thank you very much.

Now, back to the idea, considering the discussion at IDN on introducing the
"presentation layer" (or others), we could view the large zone problem as a
presentation problem.

Put it this way, people like to have abc.com. They want to "see" abc.com on
the web URL, their email etc. However, this does not mean the zone data in the
DNS must be abc.com. (IDN ACE has same stuff, what you see is not what you
get).

What this means no one would really care if the technical folk maintain the
abc.com zone as a.b.c.com.

Wait, before you fall of the chair and bang your head, STOP.

It does not matter what you put in the zone, so long you can translate abc.com
to a.b.c.com in someway. It does not matter what the server do at the backend,
or how it encodes it into the name server etc. data are data, are just bits on
the wire and how we play with them and decide what they mean. User only really
cares what they see on their screen.

Of course, abc.com -> a.b.c.com 'transformation' is not going to work. It
would fail for 123abc.com. But the basic idea is this.

As some mention to me, this is also a kludge much like Mark proposal. I
totally agree but this system have a silent way to introduce the hierarchy
back into the DNS silently.

A better solution is to relook at DNSSEC. I am not sure how we can fix it but
I know DNSSEC is not going to fly at its current stage. It is beyond
understanding for mortals. (We are talking about DNS admins who cant even get
SOA record right.)

Anyone at the IETF interested to speak about this, feel free to look for me. I
am in a bright RED T-shirt which say "Bad Idea Fairy" courtesy of Bill
Manning.

-James Seng

---

From: Edward Lewis <[email-masked]>
Date: Thu, 14 Dec 2000 14:34:08 -0500

At 7:05 PM -0500 12/12/00, Andreas Gustafsson wrote:
>I object to advancing the draft.

Not to pick on Andreas, and not to disagree with the objections...but I'd
like to ask the group how we will (or would) approach the retiring of the
NXT RR in favor of the NO RR.

Mind you, the NO RR is not a lock to knock out the NXT RR, but I think this
is a reasonably realistic "challenge problem" to edns0(.5).

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                NAI Labs
Phone: +1 443-259-2352                      Email: [email-masked]

"It takes years of training to know when to do nothing" - Dogbert

Opinions expressed are property of my evil twin, not my employer.

---

From: Kevin Darcy <[email-masked]>
Date: Thu, 14 Dec 2000 16:46:59 -0500

Since we're floating potentially "bad" (catastrophic, cataclysmic, whatever)
ideas, here's one that's been rattling around in my brain a while:

                     A new kind of delegation mechanism based on regular
expressions.

Imagine being able to delegate "a[^\.]*\.com$" through "z[^\.]*\.com$" to
DIFFERENT SETS OF SERVERS. No more monolithic "com" zone. Ditto .net. Ditto .org.
Ditto the new gTLD's coming up.

Within an organization, imagine being able to delegate all
"^www\..*\.example\.com$" to the web server group, all
"^mail\..*\.example\.com$" to the mail server group, "^ldap\..*\.example\.com$"
to the directory services group, etc. without giving a damn about any subdomains
(geographical, organizational, whatever) that may happen to be sandwiched between
the initial label and the terminating domain name.

I realize there are serious, perhaps fatal problems with this scheme. This is
just my pathetic attempt to qualify for one of those "Bad Idea Fairy" T-shirts
(since I'm not even at the IETF, I had to make it *extra* bad!) :-)

- Kevin

---

From: Nathan Jones <[email-masked]>
Date: Fri, 15 Dec 2000 10:13:51 +1100

On Fri, Dec 15, 2000 at 02:21:36AM +0800, James Seng/Personal wrote:
>It does not matter what you put in the zone, so long you can
>translate abc.com to a.b.c.com in someway. 
>
>As some mention to me, this is also a kludge much like Mark
>proposal. I totally agree but this system have a silent way to
>introduce the hierarchy back into the DNS silently.
>
>understanding for mortals. 

Just as DNSSEC may be beyond understanding for many, I think the idea
of silently introducing hierarchy by transforming abc.com to a.b.c.com
is difficult to understand without some notes on how it will work.

In the example, abc.com would still need to exist in the DNS in order
to provide a translation to a.b.c.com, so the large zone (com) is not
reduced in size anyway.

If the intention is to change the protocol and the software that
implements it such that resolvers just know to try a.b.c.com, then how
would you orchestrate the change; and for what real benefit?

Trying to get my head around your comments, I had a look through the
IDN discussion (http://www.imc.org/idn/mail-archive/) where you said
things like: "Lets go for a truely distributed structure with no
centralized registry model." Does this mean there should be no unique
namespace?

I understand that you are referring to a next generation of DNS, but
it reminded me of "RFC2826 - IAB Technical Comment on the Unique DNS
Root" in which similar proposals were labelled technically naive.

Perhaps some explanatory notes on how you see this "DNSng" working
would help people better understand your suggestions.

--
nathanj

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 15 Dec 2000 15:10:39 +0800

> to provide a translation to a.b.c.com, so the large zone (com) is not

Example,

1. Client send abc.com in DNS/EDNS packet to server.

2. Server receive abc.com from DNS packet, do internal process and
   break it do a.b.c.com.

3. Server do its normal DNS magic on a.b.c.com and then return answer
   to Client, with a.b.c.com readjusted back as abc.com.

4. Repeat for every recursion (i.e. .COM server need patch, abc.com server
   also need patch etc).

So no, you dont have abc.com in your zone file. Instead, you have a.b.c.com.
We are effectively breaking up a flat level name into hierarchy. And instead
of dealing with one large zone, you can then deal with multiple zones.

Once again, i need to remind everyone that transforming abc.com into a.b.c.com
is probably too simplicity and wont work. We need more exotic transformation
which will work with sub-delegation etc.

Incidently, you notice that there wouldnt be any changes in the DNS clients or
resolver/caching server. The changes only occurs for server side, and only for
servers which wants to break their large zone.

> would you orchestrate the change; and for what real benefit?

No, DNS protocol dont change (at least not the wire format). Only software
implementation. I would say it is an architecture change.

> would help people better understand your suggestions.

I was discussing this offline with some folk. But the general idea is if we
were to do DNSng, and we got a chance to start all over again, Do we want to
design a system which creates a monopolistic hierarchical structure again?

I am not saying unique root is bad or suggesting alternative root. I am
suggesting "NO ROOT". (Okay, I like to come up with bad ideas :-P).

-James Seng

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 16 Dec 2000 12:42:25 -0800

>suggesting "NO ROOT". (Okay, I like to come up with bad ideas :-P).

a few philosophical thougths:

the central human question of naming is what happens when two entries wish 
to be known by the same name.

The alternatives are:
- Return data for both (search)
- Return data for one (lookup)
- Return data for none (hah!)

DNS provides a name-to-unique-entry mapping; no search.
So the first alternative does not work for the applications the DNS are 
used for.

Across the DNS, we have seen multiple ways to decide which to return when 
both want them:
- show reasonable proof that you are the rightful owner, then keep it
(.se, .edu)
- first asker gets it, and keeps it until evicted (.com)
- nobody gets it because we can't agree on the rules (.)
Specifying which decision mechanism to use is out of scope for the IETF 
(and most of the wars in ICANN have been over the "eviction" clause of .com)
But the DNS has a simple way of deciding who the current "tenant" is: 
follow the chain of authoritative delegations from the root of your choice.
(Specifying which root to use is also out of scope for the IETF; observing 
midly that the DNS is quite a bit less useful if there isn't agreement on a 
single "public" root is as far as we have gone.)

So - any new proposal needs to specify which mechanism to use to decide 
which of two claims for a name-to-info mapping to believe; saying "the 
answer that got to you first" is not quite a specification to inspire 
confidence.

A root is not the only answer. It's only the simplest (AFAIK).

---

From: John Gilmore <[email-masked]>
Date: Sun, 17 Dec 2000 11:10:52 -0800

James Seng said:
> I was discussing this offline with some folk. But the general idea
> is if we were to do DNSng, and we got a chance to start all over
> again, Do we want to design a system which creates a monopolistic
> hierarchical structure again?

> A root is not the only answer. It's only the simplest (AFAIK).

Correct.

When the DNS was designed, very little was known about distributed
databases.  Today I have been told by distributed database designers
that it is within the state of the art to build a widely distributed
database which will permit broad distribution of update operations, yet
still converge on a single value of "truth" about a particular record.

As Harald said, the proposal would need to specify a mechanism to use
to decide how to converge on a single value.  Once such a mechanism
was designed and debugged, it would permit the system to automatically
decide among competing claims to a name (e.g. based on the update
timestamp, or on other deterministic criteria if the timestamps were
identical).  The important point is that the process converges on a
single answer.  It's even better if the process can't be manipulated
to favor a particular player or class of players (so that they would
"win" more often).

Such a system would eliminate or reduce the power asymmetries that are
built by design into hierarchies like the current DNS.  This would
reduce the likelihood that significant power over a DNSng would be
captured by any particular faction (like SAIC, government lobbyists,
trademark lawyers, or anybody else).  This would provide a positive
social benefit, by reducing the risk of abuse that has become obvious
in the current hierarchical design.  The Internet routing system, for
example, is not hierarchical, and it's been much harder for any single
player to abuse it.  Despite government connections, nobody has yet
exerted the kind of monopoly control that SAIC/Network Solutions
abused to gain billions of dollars, and help their friends the
trademark lawyers, at the expense of the rest of the Internet
community.

Such a DNSng project would definitely be research, and would take a
minimum of a decade before the bulk of the Internet would choose to
replace their use of the current DNS with it.

The Electronic Frontier Foundation board has indicated some interest
in sponsoring or otherwise assisting with some of the research
required to bring this idea closer to fruition.  I believe that the
key is to interest a gifted distributed database designer, to lead the
effort to clearly define the problem and produce a protocol that
solves it.  Know one?

	John Gilmore

---

From: "Brian W. Spolarich" <[email-masked]>
Date: Fri, 22 Dec 2000 22:05:42 +0000 (GMT)

On Sun, 17 Dec 2000, John Gilmore wrote:

| When the DNS was designed, very little was known about distributed
| databases.  Today I have been told by distributed database designers
| that it is within the state of the art to build a widely distributed
| database which will permit broad distribution of update operations,
| yet still converge on a single value of "truth" about a particular
| record.

  John, do you have any pointers to particular implementations that
possess these properties and are available under some sort of open-source
licensing arrangement?

  -bws