Subject: Re: Little endians, big endians, and 16 bit eggs

From: "D. J. Bernstein" <[email-masked]>
Date: 22 Jan 2005 06:58:56 -0000

Christian Huitema writes:
> But the main difference is about control.

No. The main difference is that new types create giant interoperability
problems in the real world. Getting the IETF to allocate a new DNS type
is far easier than (for example) wiping out BIND 8.1.

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

--
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: "Anders Rundgren" <[email-masked]>
Date: Sat, 22 Jan 2005 09:13:30 +0100

Christian,
If you look at my DomainKeys example you can see that prefixes
is not the only possible way.  "Midfixes" does it all and without
requiring any DNS updates.  Look under "performance":
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00150.html
There may be use-cases that don't apply to midfixes.

Since you hopefully represent Microsoft, how about supporting
an XML companion to TXT?  DNS must be the only IT system
in the world that does not support XML!

What "this group" thinks about prefix is not important, the "market"
has already done its choice.  What's missing are guidelines.
Here is an attempt at least:
http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg00183.html

Anders

----- Original Message ----- 
From: "Christian Huitema" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, January 22, 2005 05:56
Subject: Little endians, big endians, and 16 bit eggs

OK, the real title of the reference papers was "On Holy Wars and a Plea
For Peace", and it did not refer to 16 bits eggs. Anyhow, let's please
first acknowledge the semantic equivalence between:

Name = example.net, Prefix = --myNewPseudoType, type = TXT, content =
string
And  
Name = example.net, Prefix = null, type = myNewType(1234), content =
string

Sure, there are differences, and it is worth noting them:

- The "prefix" case does not support wildcards (but there are
workarounds)
- There is a fear that some servers do not support new types

But the main difference is about control. Prefixes can be made up on the
fly by whoever thinks about them, while types must be registered through
a rather lengthy and contentious defined IETF process.

It does not have to be so. If this group really believes that inventors
of new protocols should use new types instead of cooking up prefixes,
then it is perhaps time to make sure that record types can be allocated
easily, maybe just as easily as TCP ports. And, by the way, TCP ports
also are 16 bit long.

-- Christian Huitema

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 22 Jan 2005 09:18:27 +0100

>> But the main difference is about control.

Yes, indeed.  The ability to introduce a new type whenever you
need and not asking for a "permission".

>problems in the real world.

There are no such problems if you create unique prefixes which
is trivial by using transklated URIs.

> Getting the IETF to allocate a new DNS type

How does TXT + prefixes wipe out BIND 8.1?

Anders

---

From: Andras Salamon <[email-masked]>
Date: Sat, 22 Jan 2005 13:02:10 +0200

On Fri, Jan 21, 2005 at 08:56:10PM -0800, Christian Huitema wrote:
> Anyhow, let's please

Agreed, these are largely equivalent.  Also somewhat equivalent would be

Name = example.net, Prefix = null, class = someNewClass, type =
someNewType, content = string

However, there _is_ a semantic difference since you are associating
the data with different domain names.  As you point out this mostly
affects wildcards, but there are also situations where queries for
--myNewPseudoType "records" for example.net could result in responses
of "string" in the one case, NXDOMAIN in a second case and "NOERROR,
0 answers" in a third, requiring extra client logic to handle the
NXDOMAIN case.  After all, --myNewPseudoType.example.net not existing
doesn't say anything about example.net existing or not.  In comparison,
if the new RRtype solution returns NXDOMAIN then we know example.net
does not exist, simplifying client-side code.

-- Andras Salamon                   [email-masked]

---

From: Alex Bligh <[email-masked]>
Date: Sat, 22 Jan 2005 16:14:06 +0000

--On 22 January 2005 09:13 +0100 Anders Rundgren 
<[email-masked]> wrote:

> DNS must be the only IT system in the world that does not support XML!

Is that a complaint or an endorsement?

Serious point: DNS is/was a low level protocol which did a fair job
of turning requests for hostnames into IP addresses with a reasonably
small number of bytes transmitted. The larger the edifice is built,
the more one worries about the humble foundations.

Alex

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 22 Jan 2005 18:47:49 +0100

>the more one worries about the humble foundations.

Since needs have changed quite a bit since DNS was created,
so should DNS.  If every web-page drags down 10K and up,
averaging on 100K using TCP, why should 512 bytes UDP be
all a DNS server manages to do?

XML is today the de-facto config-language.  It is even used
in mobile phones.  So imo DNS is indeed one of the most dated
things in the entire Internet space.   That also includes ideas such
as having a central registry for app-data types.  App-data is not protocols
or ports.

There may be problems with prefix,suffix schemes but I cannot find
much substance like that
-you always get *all* TXT records
-you cannot allocate more than about 203 TXT records

DUAL MORAL STANDARDS

The worst is, that things like iab-dns-choices have created a
bad morale among developers that now must (in order to pass
as RFC) support:
TXT to be able to rollout
NEW-specific to please IETF

Then they must also write in the I-D that "TXT is the 'interim' solution,
we expect all to switch to NEW asap".  Since the "interim" works
why should this ever happen?  It is a blatant lie IMNSHO.

"app-data" types should not have to be published at all outside
their user community.

thinks
Anders

---

From: [email-masked]
Date: Sat, 22 Jan 2005 19:22:06 +0100

> in mobile phones.

I have no problem with XML being used in mobile phone. I strongly
disagree with any claim that XML is *the* de-facto configuration
language.

> So imo DNS is indeed one of the most dated
> things in the entire Internet space.

RFC 791         September 1981
RFC 1035        November 1987

Both IP and DNS have changed since they were developed, and they will
change again. I don't believe "one of the most dated things in the
entire Internet space" is a reasonable characterization of DNS.

> NEW-specific to please IETF

Is the problem here the IETF, or the companies that develop systems
and applications that make it extremely difficult to introduce new
RR types?

Steinar Haug, Nethelp consulting, [email-masked]

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 22 Jan 2005 22:27:43 +0100

>disagree with any claim that XML is *the* de-facto configuration

Let put it this way.  The majority of systems intrduced the last
three years use XML.

>entire Internet space" is a reasonable characterization of DNS.

As a directory system it is certainly lagging at least.  512 bytes?  
That suuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuucks!

>Is the problem here the IETF

It is the IETF who have created the incentive for dual standards.

> or the companies that develop systems

The DNS specifications does not contain any kind of RFC
that supports a _smooth_ introduction of new RR types. 

IF it should work there must be a way to publish not only a puni16-bit number
but the environment as well so that DNS admin GUIs knows what to do.

This will never happen as:
1. There is no _proven_ need for new RR types except for things that only deals with DNS itself
2. Such a scheme would use XML and that seems to be something the DNS community
don't understand at all
3. It will take forever and be extremely hard to agree on

The problem is BTW really buried in the archaic DNS system itself.  Other
extension mechanisms allow the introduction of private data here thinking
of X.509 extensions.

>Steinar Haug, Nethelp consulting, [email-masked]

Won't hire :-)

---

From: Mark Andrews <[email-masked]>
Date: Sun, 23 Jan 2005 10:46:37 +1100

> that supports a _smooth_ introduction of new RR types. 

	RFC 103[345] basically said that new RRs should be treated
	as opaque blobs by servers that don't understand them.  It
	said don't use compression pointers in new RRs.  It said
	you should expect to see new RRs.  This is all that is
	required for a cache / firewall to query, store and pass
	new RRs.  It still required the authoritative servers that
	served the new RRs to be updated and applications that
	wanted to use the new RRs to be know about them.

	We went ahead and used compression pointers when we shouldn't
	have.  We didn't treat new RRs as opaque blobs.  By doing
	this we did cause lots of problem when we introduced new
	RRs.  This created the *myth* that adding new RRs was hard.
	It really isn't hard to add new RRs.  We just went about
	it the wrong way.  We also learned not to do this.

	RFC 3597 reinforced what was in RFC 103[345] taking into
	account that we had failed to follow RFC 103[345] for a
	while and added a default presentation format.  This provided
	a standard method to add new RRs to authoritative servers
	that don't know the new RR format.

	The problems people are reporting today are non-compliance
	problems.  The way to fix non-compliance problems is to
	remove the offending software / hardware.

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

---

From: Douglas Otis <[email-masked]>
Date: Sat, 22 Jan 2005 16:58:01 -0800

On Sat, 2005-01-22 at 09:47, Anders Rundgren wrote:
> On Sat, 2005-01-22 at 08:14, Alex Bligh wrote:
>

A smaller packet size does two things, it ensures the packet can be
handled, and constrains the amount of UDP traffic.  The number of
interactions within DNS depends upon a sequence of low latency events
from perhaps many sources.  There are additional burdens created with
changes to IP and DNS that make this MTU restriction more of an
imperative.  Due to this pressure, perhaps someday the MTU for DNS may
be safely increased without incurring additional problems.   Until then,
this would suggest, to accommodate changes to the underlying transport,
new resource records should be assured to be smaller and not larger.

TCP connections require maintaining state for 5 packets of setup and
tear down in addition to the data packets, thus adding a delay of at
least 3 round trips.  Should TCP be employed for a common reply, the
ability to sustain DNS service would be reduced by this added overhead.

> as having a central registry for app-data types.  App-data is not protocols

Prefixing script with the conventional XML headers would be prohibitive.
Such as the following 370 bytes: 
 <?xml version="1.0" encoding="UTF-8" standalone='yes'?>
 <root xmlns="urn:ietf:params:xml:schema:widget-01" 
        xmlns:m2="urn:ietf:params:xml:widget-02" 
        xmlns:m3="urn:ietf:params:xml:widget-03" 
        xmlns:m4="urn:ietf:params:xml:widget-04" 
        xmlns:m5="urn:ietf:params:xml:widget-05" 
        xmlns:xsi="http://www.w3.org/2001/XMLSchema"; 
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#";>

This header could be replaced by applying a convention for such a header
to preface the resource record or via a standardized token that replaces
such a header.  Just using an XML header would be prohibitive.  The XML
language itself represents about a 20% increase in script related
encoding.  Hardly a good fit when attempting to constrain record size.

> -you cannot allocate more than about 203 TXT records

I think a label prefix, virtual or otherwise, will be needed.  Ideally a
record should fit within only a fraction of the available packet.

> NEW-specific to please IETF

Alas, neither of these techniques solves the underlying problem.  The
choice dilemma is predicated upon an expectation wildcards may be used
to assert policy within any possible sub-domain.

> "app-data" types should not have to be published at all outside

Labeling conventions allow communities to coexist.  A case made for
usurping a TXT record seems flawed.

-Doug

---

From: Danny Mayer <[email-masked]>
Date: Sat, 22 Jan 2005 20:34:48 -0500

>in the world that does not support XML!

No, we, NTP, don't and won't support XML either. That's a huge
overhead just to transfer data. If you want XML in the transferred
data, now you are talking about a much higher level of usage of
TCP which has a much larger overhead just to transfer A records
for example, not withstanding EDNS0.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Sat, 22 Jan 2005 21:01:46 -0500

>Let put it this way.  The majority of systems intrduced the last

What kind of systems? DNS is part of the base infrastructure of
the Internet. How many of these systems even have to do with the
base infrastructure? If you want to discuss configuration languages,
that's off-topic. You can use any language you want to tell your
DNS server what the records are you want to serve.

>That suuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuuucks!

512? See EDNS0.

>that supports a _smooth_ introduction of new RR types.

See the unknown record type - RFC 3597.

>but the environment as well so that DNS admin GUIs knows what to do.

GUI admins for DNS is off topic. That's a function of the DNS implementation.

>1. There is no _proven_ need for new RR types except for things that only 

Neither SRV nor NAPTR are DNS specific RR types.

>2. Such a scheme would use XML and that seems to be something the DNS 

The DNS community see you advocating sending large amounts of data for
simple requests, forcing the servers to use TCP and greatly increasing the
load not just on the servers but on the networks for no preceived gain. If
you want to contribute a way of reducing the garbage requests that DNS
gets, it would be a big help.

>3. It will take forever and be extremely hard to agree on

You need to decide EXACTLY you want first. There's almost never a
possibility of going back and revisiting the requirements once it's
agreed upon.

>extension mechanisms allow the introduction of private data here thinking

No, the problem is in thinking the XML should fit everything. If all you have
is a hammer then everything is a nail. You need to look at the objectives
of DNS not your minor application. It's minor in the sense that A, NS
and MX volume swamp almost every other type of request made including
the fact that your application will still need to make those lookups as well
as it's own.

Have you thought about the effect your recommendation would make on
the root servers, TLD's, memory, cache, network utilization, etc? The
list goes on.

Danny

---

From: Andras Salamon <[email-masked]>
Date: Sun, 23 Jan 2005 10:15:01 +0200

> As a directory system it is certainly lagging at least.  512 bytes?  

DNS has a specific purpose, as defined in the RFCs.  It is not a generic
"directory system".
    http://www.dns.net/dnsrd/rfc/

See also draft-klensin-dns-role-05.txt for a good overview of how the
"DNS community" sees the function of DNS.

There have been several efforts to set up alternatives, for instance
LDAP and various X.500 directories (for instance, see the above list
of RFCs for the history of some of these).  I'm still waiting for
widespread deployment of a next generation directory system which can
handle infrastructure directory duties as well as DNS.

> that supports a _smooth_ introduction of new RR types. 

You are right.  To introduce a new RR type you have to publish an RFC
describing it.  Takes a bit of work.

> 1. There is no _proven_ need for new RR types except for things that only deals with DNS itself

That is debatable.  It depends on what function you think DNS fulfils.
Again, see draft-klensin-dns-role-05.txt.

> 2. Such a scheme would use XML and that seems to be something the DNS community

Methinks you judge too quickly.

---

From: [email-masked]
Date: Mon, 24 Jan 2005 17:43:00 +0000

> Let put it this way.  The majority of systems intrduced the last

	and the life expectancy of these systems is?

> As a directory system it is certainly lagging at least.  512 bytes?  

	DNS is not a directory system...  :)

> that supports a _smooth_ introduction of new RR types. 

	yet.
 
> 3. It will take forever and be extremely hard to agree on

	your assertions are interesting, but lack credibility.
	there are -proven- needs for new RR types (among other DNS attributes)
	Such new things will not all use XML (its too heavy-weight) but some
	may.
	Forever is a -very long- time.  But if its couched in terms of
	the life expectancy of "the majority of systems intrduced in the
	last three years" ... you may be right.

so....  repeat after me... "The DNS is not a directory system"

--bill

---

From: Samuel Weiler <[email-masked]>
Date: Mon, 24 Jan 2005 22:17:00 -0500 (EST)

> describing it.  Takes a bit of work.

Not necessarily.  RFC2929 sets aside about half of the type code space
as "Specification Required".  RFC2434 and 2434bis both define
"specification required" as: "Values and their meaning must be
documented in an RFC or other permanent and readily available
reference, in sufficient detail so that interoperability between
independent implementations is possible."

Presumably an academic paper, a book, or even a tech report would
suffice as 'permanent and readily available'.  So might a legislative
act or a published decision of a court of law.  Even a New York Times
article might meet that standard.  As to the specific standard IANA
applies, I'm not certain: I've repeatedly asked that question of Doug
Barton, IANA manager, and I have yet to get an unequivocal answer.

All that said, even publishing an RFC to get a typecode isn't that big
of a deal.  Three new typecodes were assigned by RFC3755.  The
individual submission that led to 3755 was first published on 27
February 2003.  The initial IANA assignments were made on 3 November
2003, approximately 8 months later, after the doc passed the IESG.

The IPSECKEY and SSHFP RRs have also been assigned.  IPSECKEY was
approved by the IESG on 28 September 2004 -- IANA made that assignment
on 20 December, less than two months later.

-- Sam

---

From: Edward Lewis <[email-masked]>
Date: Mon, 24 Jan 2005 23:23:11 -0500

>>  describing it.  Takes a bit of work.

The ATMA RR type is not defined in an RFC.  Here is the definition:
     ftp://ftp.atmforum.com/pub/approved-specs/af-saa-0069.000.pdf

This is probably a historical oddity, but it can happen.

>Barton, IANA manager, and I have yet to get an unequivocal answer.

Those examples are far fetched.  The intent is that the definition be 
readily and freely available.  The ATM Forum has charged or required 
membership for access to some documents.  But, as far as I know, 
there has never been a charge to retrieve the document mentioned 
above.  (I am not an authority on the ATM Forum modes of operation.)

>on 20 December, less than two months later.

I think that is an overly rosy picture.  The time it takes from IESG 
approval to IANA reserving the number is usually quite short.  But it 
is the work up to IESG approval has historically taken quite a lot of 
time.

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

"A noble spirit embiggens the smallest man." - Jebediah Springfield

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Tue, 25 Jan 2005 10:14:03 +0100

On Mon, 24 Jan 2005 23:23:11 -0500

>  is the work up to IESG approval has historically taken quite a lot of 

As a working group we cannot do much to speed up that particular part of the
process.

However, the IESG will come to the DNSEXT group for assessment of
these proposals.

<our charter>

 The lifetime of the group is set by the work items above but while
 these are ongoing the working group has additional tasks:

        o Reviewing and providing recommendations about the
          specification, by other working groups, of RR types that do
          not require any special processing and that do not require any
          special naming conventions.

</our charter>

IMHO this is something this group should be able to do within a few
weeks. The earlier such proposals hit this group the better. 

(Note the "not require any special processing", what has been causing debate
over the last weeks is just that: the need for special processing to
find the zonecut.)

-- Olaf

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC