Subject: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 21 Nov 2006 12:02:43 -0800

Since the issue here seems to be precedent it seems more productive to discuss the choices draft. If people actually read choices they will realize that DKIM complies with the findings of fact there.

Since 1) choices is not an RFC 2) the DKIM group have had extensive discussions with the DNS directorate and the choices draft author it seems to me that the effort in this forum would be better directed at examining choices and ask if this really reflects the best way to achieve everyone's goals.

In particular there are architectural approaches proposed after the initial choices draft that have been raised with the editor of the draft and in DNSEXT that are not addressed in the draft.

> From: [email-masked] [mailto:[email-masked]] 

> In fact, the issue of port 53 services being such an 
> important infrastructure leads me to think that the IETF 
> should freeze the DNS protocol definition for anything that 
> is not directly related to the job that port 53 servers MUST 
> do. Things like DNSSEC are OK, but leveraging DNS for a 
> global distributed database are not.

Read the original discussions of SMTP that led to the development of DNS. You will find that the proposed use is entirely within the original scope that Jon Postel anticipated.

DNS was originally designed to be multi-protocol and multi-network. That's why the class mechanism exists to support Heisod and CHAOS.

The lack of protocol meta-data is a major reason for the difficulty of changing IETF protocols. The SRV record is a great leap forward, it would be even better if people actually used it to advertise their POP3, SUBMIT and IMAP services.

> Since there is great interest in using the DNS protocol for a 
> distributed database, it would help to fork the DNS protocol 
> and deal with this work in a separate WG and using a separate 
> port number. 

There is already a revolt underway and people are using the DNS to distribute policy. One approach is to say 'we know best, la-la-la not listening'. A better approach that is more likely to have the desired effect is to define a protocol that meets these peoples needs.

A second reason I intensely dislike this approach is that the DNS should be the one and only authoritative source for resolving information bound to a DNS name in the Internet class. There must be a single point of administration.

A much better approach would be to specify a limited mechanism for distributing policy through the DNS. This would have two levels:

1) A very limited sequence of tag=value pairs to be used to encode the simplest forms of policy statement 'This sender always uses S/MIME', 'This sender always uses DKIM'.

2) A defined tag value that specifies a URI where a comprehensive XML encoded policy can be found.

The reason for the two levels is that there are many useful protocol policy statements that are very simple and can be encoded in a very short response. It seems unnecessary to force people to pull a http URL out of the DNS and then extract a statement like 'DKIM' or 'STARTLS=TRUE' ot 'LDAP=ldap.example.com:2234'.

We do not need to define a directory infrastructure to support the second level, URLs will do just fine. We use the DNS to provide the authoritative resolution protocol.

Now lets consider the issues raised in CHOICES carefully

Choices gives four options of which only two are viable:

1) Use a prefix record in the same manner as SRV and NAPTR

	To make this approach work we have to consider the prefix record as being in a sense a modifier to the semantics of the record being prefixed. So _DKIM.example.com TXT has its syntax defined by the DNS protocols and its semantics defined by the prefix.

	The disadvantage of prefix records is that it is not possible to define a wildcard of the form _prefix.*.example.com. So if an application requires the ability to make a default statement prefix records do not work without additional mechanism

2) Define a new RR

	This approach works so long as the deployed DNS infrastructure at the sender and receiver and all relays inbetween all support exchange of unknown record types. 

	Wildcards work with a new RR ith the proviso that the wildcard semantics of DNS are not necessarily the semantics that the administrator would want. A wildcard only matches non-existant nodes. So some form of preprocessor is going to be required to define a default policy record that applies to every node in a zone.

	The disadvantage with this approach is that there are only 65,536 possible RRs. This is not currently a problem but is almost certain to become a problem if every protocol and every new Web Service requires a policy record.

Now lets consider the essential goals that parties might want to achieve:

1) Deployment of DNSSEC
	This is dependent on the ability to deploy new RRs.

2) Deployment of DKIM base
	This does not need the ability to specify default keys and thus does not require wildcards

3) Deployment of DKIM policy
	This does require the ability to specify default policy and thus requires wildcards

4) Support for general extensibility of the DNS

5) Ensure general extensibility of the DNS does not lead to collapse of the DNS

The last is critical of course but in a sense the DNS collapsed five years ago. It only operates today because a vast sum has been spent ($200 million+) keeping it running. The load on the core DNS is not caused by legitimate use. The load comes from misconfigured DNS systems and malicious attacks. The legitimate load is barely measurable. It is a major mistake to think that the DNS is so fragile that it can't be used to good purpose.

We do however have a legitimate concern that goals 4 and 5 are potentially at odds. I don't think that the proposal made in CHOICES is optimal, that is I don't think that 'create a new RR for every use but establish a mechanism for vetting proposed uses' is optimal. The problem is that every RR that you add is a change to the DNS infrastructure, another opportunity for someone somewhere to mess up.

The approach that CHOICES does not address is to solve the wildcard prefixing problem by introducing a new record that acts as a pointer, the Prefix Pointer record: PREPTR.

To encode the wildcard record _prefix.*.example.com we create the following records:

*.example.com                 PREPTR _preptr.example.com
_prefix._preptr.example.com   TXT   "This is the default record"

This has all the advantages of defining a new RR. Wildcards work, it is not necessary to define a new RR for every single protocol that might want a policy statement. All that is required to put out a policy statement is an IANA registered prefix.

[In actual fact the PTR record could almost certainly be used for this purpose but introducing a new record has political benefits and creates a useful deployment incentive for DNS servers that support new records.]

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Nov 2006 22:07:16 -0500

> The lack of protocol meta-data is a major reason for the difficulty of changing IETF protocols. The SRV record is a great leap forward, it would be even better if people actually used it to adverti…

actually the SRV record can easily be a step sideways or backward if not 
carefully used.  let's see...it slows down session establishment; 
increases the load on DNS; increases the potential for failures due to 
misconfiguration, link congestion, link failure, or server failure; and 
in some cases gives ISPs yet another hook to impose walled gardens on 
their customers, decrease the transparency of the network, and thus 
impair the ability of the network to support new applications.

there are cases where SRV is useful, but it's a big stretch to call it a 
great leap forward.

(and of course none of this has any bearing on DKIM.)

Keith

p.s. rather than adding more and more burdens to DNS, what we really 
need to be doing is figuring out how to replace it with something more 
robust and more flexible.  (Yes, you'd have to arrange that DNS queries 
and queries to the new database would return consistent results; you'd 
also have to make sure that DNSSEC didn't break, but those are both 
doable.)

DNS is getting very long in the tooth, and is entirely too inflexible 
and too fragile.  The very fact that we're having a discussion about 
whether it makes more sense to add a new RR type or use TXT records with 
DKIM is a clear indicator that something seriously is wrong with DNS. 
Adding a new RR type should not require a single line of DNS server or 
client library code to be recompiled, nor any changes to the 
configuration of any server not advertising such records.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 22 Nov 2006 15:16:10 +1100

> configuration of any server not advertising such records.

	No.  It just means that the people spreading FUD have succeeded.

	RFC 3597 (2003) formalised the handling of unknown RR types
	and classes.  The first draft was written in 2000 and it
	described treating unknown RR's as opaque data blobs.

	RFC 2535 (1999) (DNSSEC) depended upon unknown RR types being
	being treated as opaque blobs.  While it didn't explictly ban
	the use of compression pointers in new types it was known not
	to use compression in new RR types.

	RFC 1035 even attempted to get unknown RR's treated as
	opaque data blobs.  Unfortunately the description of where
	compression could be used was flawed.

	I really don't know why we are arguing about this anymore.
	Adding new RR's has not been a real issue this millenia.

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

---

From: John C Klensin <[email-masked]>
Date: Tue, 21 Nov 2006 23:28:35 -0500

--On Tuesday, 21 November, 2006 22:07 -0500 Keith Moore
<[email-masked]> wrote:

> actually the SRV record can easily be a step sideways or
> backward if not carefully used.  let's see...it slows down
> session establishment; increases the load on DNS; increases
> the potential for failures due to misconfiguration, link
> congestion, link failure, or server failure; and in some cases
> gives ISPs yet another hook to impose walled gardens on their
> customers, decrease the transparency of the network, and thus

And, to add one more observation to Keith's list, unless one is
extremely careful, especially when considering using SRV to add
support for protocols that were defined without it, one also
risks recreating all of the problems that caused WKS to be
deprecated.  In other words, 

	* If there is no SRV record present, can I assume the
	service is not supported?   (No)
	
	* If there is an SRV record present, can I assume the
	server is supported and available? (No, not that either).

> there are cases where SRV is useful, but it's a big stretch to
> call it a great leap forward.

Agreed.

     john

---

From: Keith Moore <[email-masked]>
Date: Tue, 21 Nov 2006 23:57:39 -0500

> 	compression could be used was flawed.

maybe I've missed it, but is there a standard way of extending the text 
format of zone files to recognize new RRs without recompiling the 
server?  and is there a standard way to distribute machine-readable 
definitions of new RR types?

(of course there are lots of other reasons to look for a replacement for 
DNS even if the new RR type problem is solved, but that doesn't mean the 
new RR type problem shouldn't be solved)

---

From: Dave Crocker <[email-masked]>
Date: Tue, 21 Nov 2006 21:28:34 -0800

> extremely careful, especially when considering using SRV to add
...
>> call it a great leap forward.

As usual, I am confused.

The MX record was, in fact, a great leap forward (after a number of false 
starts.)  I can tout its success vigorously because I had nothing to do with it 
but have always marveled at how profound its benefit has been.  Indeed I'd be 
happy to wax extensively on the basis of my views, but I suspect that a 
scholarly consideration of the MX contribution is not quite the focus for this 
thread.

SRV instantiates the MX service model, except for other protocols.

As long as we ignore the underscore names, etc. "encoding" methods that were 
chosen for defining a particular SRV -- and by ignore, I mean ignore, rather 
than imply anything positive or negative -- then I do not see why SRV is more 
(or less) dangerous than MX.

Or perhaps I should be asking:  MX was excellent for a particular service model. 
   And rendezvous requirements do suggest that there is benefit is being able to 
have different services, under a generic domain, vectored to different actual hosts.

So:

    1) Aren't there other instances of that model -- I'll call it a proxy or 
store-and-forward model;

    2) Aren't there other models that it could be useful for?

If there are cases for which SRV is "dangerous" for, what are they? What makes 
them more dangerous than, say, using MX records?

I saw the long list of generic dangers of using the DNS for anything.  My 
question is for what cases using SRV is particularly bad and why?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: David Conrad <[email-masked]>
Date: Tue, 21 Nov 2006 21:55:54 -0800

> maybe I've missed it, but is there a standard way of extending the  
> text format of zone files to recognize new RRs without recompiling  
> the server?  and is there a standard way to distribute machine- 
> readable definitions of new RR types?

rfc3597

---

From: Mark Andrews <[email-masked]>
Date: Wed, 22 Nov 2006 17:00:35 +1100

> server?

	Yes.  See RFC 3597.

	See also RFC 4701 which shows the DHCID RR in both the
	generic format and the type specific format.

> and is there a standard way to distribute machine-readable 

	No.  Then again we keep coming up with new methods of
	encoding data.  Early adoptors of new RR's just need to be
	able to handle a binary blob of data.  Most (all) dns
	libraries have methods to extact domain names, etc. from
	the binary blobs.

---

From: [email-masked]
Date: Wed, 22 Nov 2006 11:55:54 +0000

> Read the original discussions of SMTP that led to the development of
> DNS. You will find that the proposed use is entirely within the 
> original scope that Jon Postel anticipated.

And since SMTP has been an utter and complete failure
in operations, I find that to  be a dubious point.
In any case, we are not talking about a small research
network here, we are talking about the global ubiquitous
public communications network that is in the process of
replacing the telephony network. SMTP and DNS were
originally developed for that small research network.

Many years of operational experience have shown that
domain naming services, when properly implemented and
properly maintained, are wildly successful and widely
used. Success like that should be left alone.

SMTP, on the other hand is an operational failure and
even today, no one really knows how to properly
implement and properly maintain an SMTP service. The
actions of criminals exploiting weaknesses in the
SMTP architecture have led to a series of bandaids
that still have not proven to be effective.

If the IETF wants to continue defining a stream of
bandaids for SMTP, that is fine as long as they do
not screw up the existing DNS infrastructure. One
simple way to ensure this is to refuse to extend
the DNS protocol as defined for use on port 53,
the domain naming service.

It might be a good idea to get to work on a new
mail architecture which would replace SMTP, POP,
SUBMIT and IMAP. At least now we know the use-cases 
very well including many corner cases exploited by
criminals in their businesses.

> DNS was originally designed to be multi-protocol and multi-network. 
> That's why the class mechanism exists to support Heisod and CHAOS.

That's why it seems quite reasonable to continue
work on the protocol as a more general distributed
database service. But not on port 53 which is
mission critical for the ONE NETWORK which
rules them all.

> There is already a revolt underway and people are using the DNS to 
> distribute policy. One approach is to say 'we know best, la-la-la 
> not listening'. A better approach that is more likely to have the 
> desired effect is to define a protocol that meets these peoples needs.

If that protocol was defined on a port other than 53,
people would still use it. In fact, more people would 
use it because it can be deployed operationally without
disrupting port 53 services. Decoupling this from domain
naming makes it easier for people to get approval from
their bosses who are terrified that their website might
become unaccessible. That's life in the real world.

> A second reason I intensely dislike this approach is that the DNS 
> should be the one and only authoritative source for resolving 
> information bound to a DNS name in the Internet class. There must be
> a single point of administration.

Many years ago LDAP became a second authoritative source.
The real issue here is whether LDAP or DNS is a better
protocol for a distributed database. There is no need
for that battle between LDAP and DNS to play out on 
port 53. As for a single point of administration, that
is not a protocol design issue nor an engineering issue.

> XML encoded policy can be found.

Last time I looked, a URI was a string of text.
Why wouldn't you just use a TXT record for this?
In fact, why wouldn't you put all this extra information
in another server somewhere and just put one TXT
record with URI into the DNS. That way, the IETF does
not need to weigh the costs and benefits of monkeying
with domain naming services. 

> It seems unnecessary to force people to pull a http 
> URL out of the DNS and then extract a statement like 'DKIM' or 
> 'STARTLS=TRUE' ot 'LDAP=ldap.example.com:2234'.

To me it seems unneccessary to force someone to decide
whether or not to trust the source of an email message
after the message has been received. If we had an email
architecture based on a chain of trust, none of these
band-aids would be necessary.

> 5) Ensure general extensibility of the DNS does not lead to collapse

In my view, this is job ONE! However I don't think the concern
should be about global collapse. Rather I think the concern
should be that monkeying with the DNS causes an increase in the
frequency of local collapse, i.e. a single DNS server becomes
unable to continue providing domain naming services. The owners
of the domain naming infrastructure intend for it to be used
for domain naming, not for solving everybody's need for a global
distributed database. 

1) The DNS protocol is a proven way to build a global distributed
   database.
2) There is a need for global distributed databases other than
   domain naming.
3) For some reason, LDAP has not gained traction as a solution for
   this need.
4) Therefore, the IETF should define a DNS protocol based alternative
   to LDAP that runs on a port other than 53.

Once this is done, all new RRs should go into the new distributed
database protocol. This also provides the opportunity for a new 
version of DNS, the domain naming service, that strips out all the
unused cruft to enable domain naming service operators to simplify
the software that they use.

--Michael Dillon

---

From: [email-masked]
Date: Wed, 22 Nov 2006 12:05:16 +0000

> configuration of any server not advertising such records.

Hear, hear!

The DNS features that are in operation and are required for
a functioning domain naming service, are a subset of the 
DNS as defined way back in the days of that small research
network with high hopes. Today's DNS is an absolutely vital
and critical part of the world's telecommunication network.
An architectural component in that role should be simple and
robust. We need to create a new version of DNS that removes
the cruft, matches what is actually used operationally, and
is more robust, i.e. less reliant on distributed servers for
its resilience. 

While I wish that the proponents of adding new RRs would 
notice that LDAP can do the same job without any need for
registering a new schema with the IETF, I understand that 
people want to leverage a successful protocol. Therefore,
I think that the IETF would be wise to define DDDBP (DNS
Distributed Database Protocol) using the same basic DNS
protocol but running on a different port number. Divert
all the DNS enhancement work to DDDBP unless it clearly
addresses a need for the domain naming service infrastructure.

--Michael Dillon

---

From: Eliot Lear <[email-masked]>
Date: Wed, 22 Nov 2006 13:19:06 +0100

> in operations, I find that to  be a dubious point.

Anything used by close to a billion people can't be classed a complete 
failure.

> that still have not proven to be effective.

It's like what Churchill said.  It's the worst thing out there, except 
for all the others.  SMTP won in the market place because people want 
the ability to send and receive messages on a non-prearranged basis.  
This constraint tied to a complete inability to secure end points has 
led to your headaches.  Furthermore, the problem is not limited to mail, 
but can be seen in IM, and may likely show up in other forms of 
communication.  Much of this is simply the nature of software.

> the domain naming service.

This problem extends beyond the IETF, but the IETF is doing quite a bit 
to accommodate the wild west nature of the net.  It is not just DKIM.  
NEA and focus on identity through BoFs such as DIX and WAE indicate some 
effort to better secure communications.  It is not a substitute for 
securing end points, but improving these functions will help.  Paul 
Hoffman's work to standardize communication with reputation services 
also shows promise.

Eliot

---

From: [email-masked]
Date: Wed, 22 Nov 2006 12:41:23 +0000

> Anything used by close to a billion people can't be classed a complete 

The failure is not that it is ignored but that it is
so difficult to operate. Both the end users and the
server operators are unhappy with what they get from
the email system based around SMTP, POP, SUBMIT and IMAP.

> for all the others.

There were no alternatives to SMTP on an IP network until 
Instant Messaging came along. IM is wildly successful even
though it has the same problems as pre-SMTP email, i.e.
there are multiple incompatible protocols and networks.
It reminds me of the days people used to quote several
email addresses, Internet, MCI Mail, UUCP, Bitnet, Compuserve.
But even with these disadvantages, IM continues to gain
mindshare because SMTP based email is so terrible.

> SMTP won in the market place because people want 

> communication.  Much of this is simply the nature of software.

It has nothing to do with software and everything to do
with architecture. IM networks have less problems because
all the participants share a relationship with the IM
service providers. Nobody has yet tried to build an 
open-ended email network based on a chain of trust
between participants. Instead we have the flat SMTP
protocol open to all comers and two client protocols
that do NOT support sending an email message.

--Michael Dillon

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 22 Nov 2006 13:53:19 +0100

Changing the subject since this has left DNS behind... just a few points of 
fact...

--On 22. november 2006 12:41 +0000 [email-masked] wrote:

> Instant Messaging came along.

not since X.400 over X.25 died, no. I thought you were older than that....

> service providers.

hm. who is the service provider for jabber:[email-masked], and what 
relationship does he have with the operators of jabber:[email-masked]? Last 
time I checked, I could still chat with myself... SOME IM networks enforce 
such a relationship as the one you mention. not all.

              Harald

---

From: Pekka Savola <[email-masked]>
Date: Wed, 22 Nov 2006 17:42:16 +0200 (EET)

On Tue, 21 Nov 2006, Keith Moore wrote:
> p.s. rather than adding more and more burdens to DNS, what we really need to 
> be doing is figuring out how to replace it with something more robust and 
> more flexible.  (Yes, you'd have to arrange that DNS queries and queries to 
> the new database would return consistent results; you'd also have to make 
> sure that DNSSEC didn't break, but those are both doable.)
>
> DNS is getting very long in the tooth, and is entirely too inflexible and too 
> fragile.  The very fact that we're having a discussion about whether it makes 
> more sense to add a new RR type or use TXT records with DKIM is a clear 
> indicator that something seriously is wrong with DNS. Adding a new RR type 
> should not require a single line of DNS server or client library code to be 
> recompiled, nor any changes to the configuration of any server not 
> advertising such records.

Keith,

I've seen you say this for many years now, but I'll bite now.
Do you have ideas what a more flexible, less fragile, and in 
general a better mechanism would:

  1) be or look like, or

  2) what requirements we should have for building and deploying it?
     (if such a thing or a close likeness doesn't exist)

I wonder if there are practical alternatives.  A bit more dialogue on 
"what else" instead of "DNS is a bad idea" might help in figuring out 
whether there is anything the IETF could do about it.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Nov 2006 07:51:32 -0800

> criminals in their businesses.

Standard response to common, blanket call for replacing current Internet Mail 
protocols...

<mantra>

When you:

    1. Get anything that looks like a community consensus about the functional 
requirements for email that are not being met,

    2. Try to add them to existing email protocols, and

    3. Fail

Then it will make sense to discuss replacement protocols.

Over the last 10 years, there have already been many attempts at the first step 
and they have quickly failed.

Independent of the social and political problems of gaining consensus, the 
functional difficulty is in defining changes that do not cripple the ability of 
email to support the very wide range of human communication styles for which it 
is needed.

It is trivial to design changes that cover only a narrow range of styles. 
Although a wrong-headed path, even then, the hard question is *which* narrow range?

Email abuse is a social phenomenon, not a technical one.  Nothing will make it 
disappear.

The best we can hope for is to reduce it to tolerable levels, the same as for 
any other criminal activity elsewhere in many societies.

</mantra>

d/

-- 

   Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Nov 2006 07:54:27 -0800

On Tue, 2006-11-21 at 21:28 -0800, Dave Crocker wrote:

> The MX record was, in fact, a great leap forward (after a number of
> false starts.)  I can tout its success vigorously because I had
> nothing to do with it but have always marveled at how profound its
> benefit has been.  Indeed I'd be happy to wax extensively on the basis
> of my views, but I suspect that a scholarly consideration of the MX
> contribution is not quite the focus for this thread.
> 
> As long as we ignore the underscore names, etc. "encoding" methods
> that were chosen for defining a particular SRV -- and by ignore, I
> mean ignore, rather than imply anything positive or negative -- then I
> do not see why SRV is more (or less) dangerous than MX.

SRV records facilitated a transition from WINS.  The problem with SRV is
caused by their induced long timeouts when discovering these services
often placed behind corporate firewalls.  Most of those services are not
safely exposed to the Internet.  Until this discovery process completes,
a laptop is unusable for the duration, which can be a long period.
While there may be valid reasons for SRV records, what is seen by the
Internet must be organized in separate zones split at the _tcp label. It
would appear kludged support for DNS is also why new RRs are
dysfunctional and CNAMES are fragile.  

> Or perhaps I should be asking:  MX was excellent for a particular
> service model.  And rendezvous requirements do suggest that there is
> benefit in being able to have different services, under a generic
> domain, vectored to different actual hosts.
> 
> So:
>     1) Aren't there other instances of that model -- I'll call it a
>        proxy or store-and-forward model;
>

Yes, except for problems caused by a particular vendor's use.

> If there are cases for which SRV is "dangerous" for, what are they?

Services that are typically found using SRV records places this service
into a bad neighborhood.  In this neighborhood, security is so poor, a
wall must surround the entire area.  

>  What makes them more dangerous than, say, using MX records?

The neighborhood of services. 

-Doug

---

From: Tony Finch <[email-masked]>
Date: Wed, 22 Nov 2006 16:00:49 +0000

On Wed, 22 Nov 2006, [email-masked] wrote:
>
> SMTP, on the other hand is an operational failure and even today, no one
> really knows how to properly implement and properly maintain an SMTP
> service. The actions of criminals exploiting weaknesses in the SMTP
> architecture have led to a series of bandaids that still have not proven
> to be effective.

Any communications mechanism which allows you (or your organization) to
receive messages from people (or organizations) you have no prior
relationship with is vulnerable to spam. Spam is NOT an SMTP problem.

Tony.
-- 
f.a.n.finch  <[email-masked]>  http://dotat.at/
BAILEY: CYCLONIC BECOMING NORTHWESTERLY SEVERE GALE 9 TO VIOLENT STORM 11,
OCCASIONALLY HURRICANE FORCE 12 IN SOUTH, DECREASING 7 TO SEVERE GALE 9 LATER.
HIGH OR VERY HIGH. RAIN OR SQUALLY SHOWERS. MODERATE OR POOR.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 22 Nov 2006 08:13:08 -0800

> not since X.400 over X.25 died, no. I thought you were older than that....

And there were all of the individual providers that Michael cited, such as MCI 
Mail.

 >> all the participants share a relationship with the IM

It *is* interesting that the diversity of disconnected email services was viewed 
as a basic problem to solve, whereas most of the Internet user community does 
not seem to feel the same pressure to unify IM.

Hmmm.  Maybe IM satisfies a different set of needs than does email.  So we had 
better be a bit cautious about trying to generalize implications between them.

d/
-- 

   Dave Crocker

---

From: Keith Moore <[email-masked]>
Date: Wed, 22 Nov 2006 12:40:56 -0500

>> whether it makes more sense to add a new RR type or use TXT records 
>> with DKIM is a clear indicator that something seriously is wrong with 
>> DNS. Adding a new RR type should not require a single line of DNS 
>> server or client library code to be recompiled, nor any changes to the 
> Do you have ideas what a more flexible, less fragile, and in general a 
> better mechanism would:
> 
>  1) be or look like, or
> 

here's the background: starting about 12 years ago I designed and coded 
up a system called RCDS which was designed to keep track of replicas of 
web-accessible resources.  part of this system was a thing called the 
resource catalog, or RC for short.  the idea behind RC was that 
authorized parties could use it to store information about a URI.  it 
was federated and replicated like DNS, but the keys were in URI space 
rather than domain space.  this was before NAPTR and SRV records were 
formalized but the intent was to use something like NAPTR records to 
parse URIs and to use SRV records to find the RC servers for a 
particular URI.

RC was developed in response to suggestions that we store all of the 
metadata about a URI in DNS.  this would have been a real mess for lots 
of reasons - partially because DNS wasn't designed to key on URIs, 
partially because we needed a lot more extensibility in the equivalent 
of RR types than DNS could ever do, partially because we needed a 
different consistency and caching model, partially because we needed 
more flexibility in "additional information" handling, partially because 
  we needed to be able to have different RRs be updated by different 
parties at different times and yet still have signatures over multiple 
RRs signed by those different parties.

so anyway I came up with some ideas about how to solve those problems, 
designed a protocol, implemented a RC client and server, and used it to 
keep track of web replicas.  and then I realized that it didn't have to 
just be used for web replicas, but could keep track of metadata about 
anything that could be named with a URI.  so I designed a distributed 
computing system called SNIPE that used RC to keep track of information 
about processes - e.g. process locations (processes could migrate), 
process status, and communications channels that could be used to 
contact those processes.

and then I realized that it would be possible to encode DNS RRs in RC in 
a lossless way so that the original DNS-format RRs could be recovered, 
and DNSSEC signatures could still be verified.  and that convinced me 
that there could be a transition path from DNS to something else - e.g. 
a single server could support queries for both DNS and RC protocols from 
a single backing store, and perhaps even handle DNS dynamic update in 
addition to RC update.  new apps that wanted to make use of the 
increased flexibility of RC would use the RC query and/or update 
protocol, legacy apps would probably continue to use DNS because it 
would be supported by more zones.

I'm not saying that RC would be a great drop-in replacement for DNS, as 
it was just a prototype and several of its ideas were never tested 
extensively to see whether they were as useful as I thought they would 
be.  but the experience with RC convinced me that DNS could be replaced 
with something much more flexible and still have an orderly transition, 
and that this could be used as a way to fix a lot of the longstanding 
problems with DNS.  assuming, of course, that second-system effect could 
be avoided.

Keith

---

From: Douglas Otis <[email-masked]>
Date: Wed, 22 Nov 2006 11:33:43 -0800

On Nov 22, 2006, at 7:42 AM, Pekka Savola wrote:

>> DNS is getting very long in the tooth, and is entirely too  
>> inflexible and too fragile.  The very fact that we're having a  
>> discussion about whether it makes more sense to add a new RR type  
>> or use TXT records with DKIM is a clear indicator that something  
>> seriously is wrong with DNS. Adding a new RR type should not  
>> require a single line of DNS server or client library code to be  
> I've seen you say this for many years now, but I'll bite now. Do  
> you have ideas what a more flexible, less fragile, and in general a  
> better mechanism would:
>
>  1) be or look like, or
>
> I wonder if there are practical alternatives.  A bit more dialogue  
> on "what else" instead of "DNS is a bad idea" might help in  
> figuring out whether there is anything the IETF could do about it.

There is a new method for using names to navigate the Internet.  It  
is based upon a proprietary application added to network stacks  
distributed on millions of systems forming a loosely coupled matrix.   
This application is now available for XP from Microsoft and will be  
included within Vista. This name resolution application does not rely  
upon DNS, and assigns unique public keys based upon your drive's  
serial number for example, along with an IPv6 address tused in  
conjunction with RFC 4380 across IPv4.  This application is able to  
navigate past corporate firewalls and directly connect computers  
together within LANs or using adhoc wireless, all without user  
intervention.  This does not require an centralized registry, and  
permits the use of DNSified names freely assigned to various systems.

This proprietary application is  targeting a 10 billion dollar gaming  
market, but will support file sharing and interactive collaboration  
applications.  It also looks to be the perfect tool for running bot- 
nets as well.

A fun site that reviews this topic:
http://www.ppcn.net/n1358c38.aspx

-Doug

---

From: Peter Dambier <[email-masked]>
Date: Thu, 23 Nov 2006 19:01:49 +0100

DNS is broken since people started disallowing AXFR transfers.

DNS is no longer about publishing information about hostnames and numbers
but about keeping this information a seecret.

So not using DNS at all and distributing host files is much better than
DNS and more reliable :)

On the other hand, in good old /etc/hosts days you could always reverse
query and get all aliases to every ip address. E.g. NIS still works like
that. And NIS has mostly the same bells and whistles DNS has, like MX
records and unimaginable additional record types.

In addition DNS is designed with a single one root scope. So if you
have to deal with chinese, arab and russian namespaces then DNS probably
is not the right choice :)

If ISPs were not starting to block port 53 DNS the I would guess somebody
will come up with a totally new idea and implement this using the port
53 DNS interface but even bonjour/rendezvous work with a port different
from 53.

Kind regards
Peter and Karin

Pekka Savola wrote:
>> robust and more flexible.  (Yes, you'd have to arrange that DNS 
>> queries and queries to the new database would return consistent 
>> results; you'd also have to make sure that DNSSEC didn't break, but 
>> those are both doable.)
>>

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Von-Erthal-Strasse 4
D-64646 Heppenheim
+49(6209)795-816 (Telekom)
mail: [email-masked]
mail: [email-masked]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/

---

From: Eric Burger <[email-masked]>
Date: Fri, 24 Nov 2006 10:30:11 -0500

Or, the reality that with (at the time) a single dominant network provider
made the inter-networking point moot.

---

From: John C Klensin <[email-masked]>
Date: Sun, 26 Nov 2006 22:35:44 -0500

--On Friday, 24 November, 2006 10:30 -0500 Eric Burger
<[email-masked]> wrote:

> Or, the reality that with (at the time) a single dominant
> network provider made the inter-networking point moot.

Eric, you are being a little cryptic, perhaps unintentionally.
What do you mean about a single dominant provider and at what
time?  

I would add an observation to Dave's about possibly different
sets of needs by reminding everyone that considerable IM
functionality (other than presence) isn't new.  We had
SEND/SOML/SAML from the beginning of SMTP, even though they had,
IMO, a very short practical lifespan and, even then, were used
only in limited communities.  We also we had a couple of flavors
of the "talk" protocol which were certainly heavily used in some
places.  "Talk" involved a conversational session while SEND et
al was closer to what we would call a short message service
today.  Off the Internet and in the land of BITNET/EARN/etc.,
there was also an end to end short message protocol and
mechanism that was extensively used.

None of these supported a presence mechanism in the sense that
we understand it today.  As a result, one had to bind a user
identity to a target host in much the way SMTP does, rather than
having someone attach to the network at any point and announce
presence and, implicitly, location.  It is arguably those
presence and mobility mechanisms and not IM itself that is the
recent development.  To the degree to which those mechanisms are
what caused IM to take off, perhaps that reinforces Dave's view
of different services serving different needs.

     john

>> And there were all of the individual providers that Michael
>> cited, such as MCI Mail.
>> 
>> 
>>>>> but can be seen in IM, and may likely show up in other
>>>>> forms of communication.  Much of this is simply the nature
>>>>> of software.
>>>> 
>> as a basic problem to solve, whereas most of the Internet
>> user community does not seem to feel the same pressure to
>> unify IM.
>> 
>> Hmmm.  Maybe IM satisfies a different set of needs than does
>> email.  So we had better be a bit cautious about trying to
>> generalize implications between them.
>> 
>> 
>> d/
> 
>

---

From: Patrick Vande Walle <[email-masked]>
Date: Mon, 27 Nov 2006 10:58:11 +0100

> but about keeping this information a seecret.

Not sure I understand your point. You query a record, you get an answer.
Why on earth would you want to suck all the world's zone files ?

> is not the right choice :)

Agree. Add to that the current architecture does not allow competition
at the TLD level. There can only be one registry for any given TLD,
leading to artificial scarcity and lack of consumer choice.

>>     (if such a thing or a close likeness doesn't exist)

Aside from the technical requirements to return reliable answers to
queries, it should also make it possible to have multiple registries for
the same TLD and and shield the Internet community from possible
political interference on the root. A possible design is CoDNS
(http://www.cs.cornell.edu/people/egs/beehive/codons.php).

Patrick Vande Walle

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 27 Nov 2006 11:27:01 +0100

On 27Nov 2006, at 10:58 AM, Patrick Vande Walle wrote:

> return reliable answers to
> the same TLD

Hmmm, "Reliable answers" and "multiple registries for the same TLD"  
in the same sentence?

Multiple registries imply multiple namespaces. That implies that  
there is no coherency, which I interpret as not being reliable.

CoDNS still provides a unique namespace, the same as we have now. It  
simply does not rely on port-53.

In fact see their FAQ (http://www.cs.cornell.edu/people/egs/beehive/ 
faq.html).

> Will we need to purchase new names if the world switches over to  
> CoDoNS?
>
> No. CoDoNS serves the same name hierarchy as legacy DNS. The  
> namespace will remain identical to what it was before.

--Olaf

-----------------------------------------------------------
Olaf M. Kolkman
NLnet Labs
http://www.nlnetlabs.nl/

---

From: [email-masked]
Date: Mon, 27 Nov 2006 10:42:48 +0000

> Why on earth would you want to suck all the world's zone files ?

Some people want to publish their own Domain Naming Service
with additional information such as new top level domains.
But they don't wnat to go through any IANA/ICANN process.
If they can suck down all the top level zone files then
it is easy for them to publish an ALTERNATIVE DNS VIEW
that contains their own additions. Anyone who uses their
view will then see the so-called official DNS info as
well as the overlay.

> leading to artificial scarcity and lack of consumer choice.

This is yet again an attempt to extend the scope of the DNS
beyond what it was designed to do. DNS was created because of the
need for a distributed naming service and in today's Internet, the
domain naming service is a critical part of the Internet's 
infrastructural underpinnings. It is not a product which is 
bought by consumers. It is, by design, controlled by a single
authority at each level. If that were changed then companies
like IBM would lose their authoritative ownership of ibm.com
and that is not in their best interests nor is it in the best
interests of consumers.

The restrictions imposed by the current architecture provide
the stability and reliability that is required in a system
that plays such a critical infrastructure role in the public
Internet. 
 
> queries, it should also make it possible to have multiple registries for

The protocol does not prevent this. Indeed many private internets
do operate their own root or add unofficial TLDs to their DNS.
A good book on the DNS will explain how to do this safely. 

A lot of the people who want to see "competition" in the domain 
naming service, fail to understand the IETF's role in this space.
The IETF can only specify a protocol. They cannot wave a magic
wand and make the whole world start using a new protocol or migrate
from an existing protocol. In fact, if there was significant demand
for such competition, no support from the IETF would be needed. 
In 1991, http was created outside of the IETF. It met with such
huge demand that a later version of the protocol was issued as an
IETF protocol 5 years later in RFC 1945.

--Michael Dillon

---

From: Patrick Vande Walle <[email-masked]>
Date: Mon, 27 Nov 2006 12:44:06 +0100

Olaf M. Kolkman wrote, On 27/11/2006 11:27:

> Hmmm, "Reliable answers" and "multiple registries for the same TLD" in
> the same sentence?
> 
> Multiple registries imply multiple namespaces. That implies that there
> is no coherency, which I interpret as not being reliable.

From
http://www.cs.cornell.edu/people/egs/beehive/codons-sigcomm04/node15.html

"CoDoNS enables multiple namespace operators to manage the same part of
the name hierarchy [...] Ideally, competing operators would preserve a
single consistent namespace by issuing names out of a common, shared
pool. In the presence of conflicting or inconsistent records, clients
simply pick the records signed by an operator they trust, similar to the
way they pick between separate sets of root servers today. Essentially,
nameowners have the ability to choose the namespace operator that will
endorse their records based on price, service and functionality."

Patrick Vande Walle

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 27 Nov 2006 14:53:22 +0100

Patrick Vande Walle wrote:
> pool. In the presence of conflicting or inconsistent records, 

One doesn't need to read further to observe that this is a broken
namespace.

     Brian

---

From: John C Klensin <[email-masked]>
Date: Mon, 27 Nov 2006 10:48:24 -0500

--On Monday, 27 November, 2006 12:44 +0100 Patrick Vande Walle
<[email-masked]> wrote:

>> Hmmm, "Reliable answers" and "multiple registries for the
>> same TLD" in the same sentence?
>> 
>> Multiple registries imply multiple namespaces. That implies
>> that there is no coherency, which I interpret as not being
>> reliable.
> 
> From
> "CoDoNS enables multiple namespace operators to manage the
> same part of the name hierarchy [...] Ideally, competing
> operators would preserve a single consistent namespace by
> issuing names out of a common, shared pool. In the presence of
> conflicting or inconsistent records, clients simply pick the
> records signed by an operator they trust, similar to the way
> they pick between separate sets of root servers today.
> Essentially, nameowners have the ability to choose the
> namespace operator that will endorse their records based on
> price, service and functionality."

Patrick, to complement Brian's comment and avoid getting hung up
on precise definitions of "namespace"...

There are many situations in which one can be quite relaxed
about collections of names.  In appropriate situations, one can
tolerate duplicate names (with or without a disambiguation
procedure) and one can tolerate having users (clients) select
among endorsers or even (effectively) provide their own
endorsements and make choices on a name-by-name basis.  We may
be headed down exactly that path with ENUM and ENUM variants:
whether that will be good for ENUM or VoIP will probably be
resolved in the marketplace, but it is as harmless to the
network as the naming rules I use for the namespace of email
addresses within jck.com (or, presumably, the rules you use for
the email namespace within vande-walle.eu).

It is also worth remembering that countries can tolerate
multiple currencies (although most don't, and actually react
quite hostilely to independent currency developers) and that
duplication in names of people is very common ("will 'Joe Smith'
please stand up?").

On the other hand, if one is going to have a network in which
all resources are publicly available and unambiguous without
prior negotiations between each client and server and in which
one doesn't want to allow the time and resources for a
post-query disambiguation process (which is exactly what we do
to identify the desired "Joe Smith" from that pool) then
identifiers must be unique.   Not overlapping name spaces, or
fragments of a name space that the client gets to pull together
based on its own choice algorithms, or a fraction of the
aggregate name space chosen on the basis of "least bad" or "most
complete" service by a name-vendor, but _unique_ and
comprehensive.

In particular, if I use my view of the DNS to create an object
identifier (e.g., a URI) and pass it to you, it much be
resolvable in your environment to point to the same object that
I intended or we are both in trouble.   Now, in principle, I
could pass you both the identifier and my entire context of
selected namespace vendors and you could push down your vendor
context but consider putting that identifier along with several
others generated by other people in their contexts... well, one
would like this to work reliably and in finite time.

It is a different issue, although tied to precisely this set of
difficulties, but this is one of the reasons why many of us
continue to say "don't put 'that' into the DNS, let's look at
'above DNS' solutions" to address a variety of naming,
locational, and navigational functions.  If one really wants
competition (or parallelism) over the right to designate the
definition of individual names, then one can imagine all sorts
of interesting systems, many of them matched to specific
applications.  For them, query-time disambiguation, negotiation
about attributes and their use in selection, competitive
suppliers (look at the so-called "keyword" market), and a host
of other options may all make sense.  But _they_ need a
reliable, consistent, DNS with unique and unambiguous naming to
work successfully.  And, conversely, weakening those properties
of the DNS could prevent those services from developing properly
and being interoperable at the identifier level.

The "CoDoNS" idea might actually be very useful for some of
those "above DNS" functions.  But considering it as an
alternative to the DNS seems to either exhibit a profound
misunderstanding of what the DNS is about or, perhaps, a desire
to use terminology that excites funding agencies or journal
editors.

    john

---

From: John Levine <[email-masked]>
Date: 27 Nov 2006 16:14:30 -0000

>If they can suck down all the top level zone files then it is easy
>for them to publish an ALTERNATIVE DNS VIEW that contains their own
>additions. Anyone who uses their view will then see the so-called
>official DNS info as well as the overlay.

When I see claims like this, I really have to wonder how well people
understand the way that the DNS works.  If you want to publish your
own root that merges the real root (the one that the A through M root
servers publish with advice from ICANN) with stuff of your own, you
can do it now, and it wouldn't make any practical difference if you
could AXFR every zone in the world.

If you want to add your own TLDs, the easiest way to do it is to FTP
the root zone, which is easy and quite legal to get, add in your own
TLDs, and try and persuade people to use your servers.  The root zone
changes slowly, so downloading and remixing your root once a day would
be plenty.

If you want to offer mutant versions of popular TLDs, the most
practical way to do that is with a semi-transparent proxy that serves
up your versions of the stuff you want to change, and fetches the rest
of the data from the real versions as needed.  AXFR access to the
popular TLDs would be useless, because the zones are so big.  The
gzipped version of the COM zone is about a gigabyte and takes several
hours to download via my not very busy T1, and an AXFR would be two or
three times that.  Even if you had an OC3, you could never keep a
mirror of COM up to date with AXFR, and while the other popular zones
are smaller, they all update in less time than it'd take to AXFR a
copy.  No significant zone is propagated by AXFR now, and no useful
mirror or alternate root would use it, either.

The real reason that alternate roots haven't caught on is that there
is no demand for them from the people who use the DNS.  (There's
plenty of demand from people who imagine they would get rich if they
could own .WEB or .SEX or whatever, but that's irrelevant.)  For all
of the failings of the current roots and of ICANN, with which as a
member of the ICANN ALAC I am extremely familiar, it works well enough
for the things that people use it for, and that shows no sign of
changing despite occasional efforts to screw it up like wildcards in
TLD zones.

With this in mind, I don't see much point in arguing about setting up
something just like DNS but different.  When we stick DKIM keys in TXT
records with prefixed names scattered around the leaves of the DNS, it
may injure some people's sense of propriety, but it doesn't break
anything that works, and nobody other than DNS theologists care that
it didn't use a new RR type.  I have been publishing the contact info
for abuse.net through the DNS for several years, using a specialized
server (written in perl) that synthesizes TXT, A, and HINFO records on
the fly from the underlying database.  Works great, performs much
better than the WHOIS and HTTP versions that preceded it, and doesn't
break anything.  Maybe some of my hacks won't work with DNSSEC, but
we'll burn that bridge when we get to it.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: Peter Dambier <[email-masked]>
Date: Mon, 27 Nov 2006 17:36:28 +0100

...
> changing despite occasional efforts to screw it up like wildcards in

John, there is demand for it.

To find out why, look at these domains:

Status China Root

soa("XN--55QX5D.","2006112704","CDNS3.CNNIC.NET.CN","210.52.214.86").
soa("XN--55QX5D.","2006112704","CDNS4.CNNIC.NET.CN","61.145.114.120").
soa("XN--55QX5D.","2006112704","CDNS5.CNNIC.NET.CN","61.139.76.55").
soa("XN--55QX5D.","2006112704","HAWK2.CNNIC.NET.CN","159.226.6.185").

soa("XN--FIQS8S.","2006112704","CDNS3.CNNIC.NET.CN","210.52.214.86").
soa("XN--FIQS8S.","2006112704","CDNS4.CNNIC.NET.CN","61.145.114.120").
soa("XN--FIQS8S.","2006112704","CDNS5.CNNIC.NET.CN","61.139.76.55").
soa("XN--FIQS8S.","2006112704","HAWK2.CNNIC.NET.CN","159.226.6.185").

soa("XN--IO0A7I.","2006112704","CDNS3.CNNIC.NET.CN","210.52.214.86").
soa("XN--IO0A7I.","2006112704","CDNS4.CNNIC.NET.CN","61.145.114.120").
soa("XN--IO0A7I.","2006112704","CDNS5.CNNIC.NET.CN","61.139.76.55").
soa("XN--IO0A7I.","2006112704","HAWK2.CNNIC.NET.CN","159.226.6.185").

Status Arab Root

soa("XN--IGBHZH7GPA.","12","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--LGBBAT1AD8J.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGB2DDES.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBA3A5AZCI.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBA5B5CCEU.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBAH1A3HJKRD.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBAXP8FPL.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBB7FJB.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBB7FYAB.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBC0A9AZCG.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBCPQ6GPA1A.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBERP4A5D4AR.","2006111409","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBG8EDVM.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--MGBU4CHG.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--NGBEE7IID.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--WGBL6A.","5","AR-ROOT.NIC.NET.SA","212.26.18.12").
soa("XN--YGBI2AMMX.","9","AR-ROOT.NIC.NET.SA","212.26.18.12").

soa("XN--MGBAAM7A8H.","12652","NS1.UAENIC.AE","213.42.0.226").
soa("XN--MGBAAM7A8H.","12652","NS2.UAENIC.AE","195.229.0.186").

soa("XN--PGBS0DH.","2005062700","NS.ATI.TN","193.95.66.10").
soa("XN--PGBS0DH.","2005062700","NS2.ATI.TN","193.95.67.22").

Status I-DNS.NET

soa("XN--3RC8E2BB9H.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--81B8B9A9C.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--C1AVG.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--E1APQ.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--G2B9A1A.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--I1B6B7E.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--J1AEF.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--P1AG.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--P1AI.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--QLC9A5A.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--USC8B9A.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--USCN1BV9BH3H.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--VF4B131B.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--ZB0BNW.","2006112608","NSA.I-DNS.NET","64.62.142.131").
soa("XN--ZV4B74Y.","2006112608","NSA.I-DNS.NET","64.62.142.131").

Those people dont talk english and they dont use latin keyboerds.
That is why you never heard of them.

Kind regards
Peter and Karin

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher-Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: [email-masked]
mail: [email-masked]
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
http://www.cesidianroot.com/

---

From: Joe Baptista <[email-masked]>
Date: Mon, 27 Nov 2006 11:43:42 -0500

Oops - I forgot about that one.  Yes the Chinese Ministry of Information 
and Industry have many chinese top level domains registered.  The are 
now the largest alternative root system on the planet next to icann and 
resolve for some 150 million users.  And i anticipate they will soon 
surpass that.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 27 Nov 2006 11:07:32 -0800

> SEND/SOML/SAML from the beginning of SMTP, even though they had,

Just to nit-pick, since Internet history has become an important topic:

By "beginning of SMTP" John actually means the mid-1970s, in the original 
Arpanet FTP-based mail service.

And since I think it was a particularly clever option, I'll note that one of the 
commands John cites was "deliver to the recipient's screen if they are logged in 
and deliver it to their mailbox if they aren't."

Would be nice to have that in today's world, wouldn't it?

> we understand it today.

There as a close approximation, as I recall, with the way the Finger mechanism 
was implemented at some sites.  You would Finger a particular username at a host 
and the returned information would tell you if they were logged in.

>  As a result, one had to bind a user
> presence and, implicitly, location. 

Mumble.  I'd claim that the current presence mechanisms do the same thing that 
was done originally.

If I came in through an arpanet dial-up at some random place on the net, and 
telneted to my home system, then the finger for that home system would show me 
as 'present'.  I am not seeing how today's presence systems are fudamentally 
different from that.

  It is arguably those
> of different services serving different needs.

I think it was Graham Klyne who pointed out to me that IM and Internet Mail also 
do tradeoffs in reliability vs. timeliness.

An IM is not expected to survive a system crash, whereas an email is.  That 
leads to very different software development decisions, such as whether to incur 
the cost of a write-to-disk for every message.  In the aggregate, the cost 
difference can be huge.

d/
-- 

   Dave Crocker

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 27 Nov 2006 20:11:51 +0100

> could AXFR every zone in the world.
I haven't seen any reason to change my opinion about that particular 
brand of flimflam since RFC 2826 (May 2000).

               Harald

---

From: Douglas Otis <[email-masked]>
Date: Mon, 27 Nov 2006 12:42:17 -0800

On Nov 27, 2006, at 7:48 AM, John C Klensin wrote:

> On the other hand, if one is going to have a network in which all  
> resources are publicly available and unambiguous without prior  
> negotiations between each client and server and in which one  
> doesn't want to allow the time and resources for a post-query  
> disambiguation process (which is exactly what we do to identify the  
> desired "Joe Smith" from that pool) then identifiers must be  
> unique.   Not overlapping name spaces, or fragments of a name space  
> that the client gets to pull together based on its own choice  
> algorithms, or a fraction of the aggregate name space chosen on the  
> basis of "least bad" or "most complete" service by a name-vendor,  
> but _unique_ and comprehensive.

PNRP attempts to ensure numeric identifiers are unique, where names  
freely associate without concerns of conflict.  The basic goal is to  
overcome limitations of DNS using more elaborate structures.  This  
extra information might provide a sequence of IPv4 and IPv6 addresses  
needed to navigate through various gateways and NATS.  The end-points  
of this navigation are introduced through "groups" where each member  
of the group retains other member's certificates as a means to  
verifying and differentiate possible naming overlaps.  This does not  
require unique names , but rather numbers based upon similar concepts  
developed by the T10 group for CAS.

This different (and some what scary strategy) allows for the ideal  
end-to-end networking paradigm.  Each and every network node is  
visible to the Internet for true end-to-end communication.  Firewalls  
designed to shore up flaws often found with complexity created by  
ever growing features are bypassed.  The demand for (anti-productive)  
gaming and effortless collaboration tools are designed to segment  
networks into "groups."  This demand may soon offer a (proprietary)  
alternative to DNS, where navigation still takes place at the browser  
using this "different" type of namespace.  As noted in the  
promotional literature, there are no copyrights on numbers.

-Doug

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 28 Nov 2006 09:34:55 +0100

Dave Crocker wrote:
> Brian E Carpenter wrote:
> An alternate view is that one does not need to read further to note that 
> this scheme calls for coordination at the top of the naming hierarchy, 
> just like any other scheme needs to, in order to be viable.
> 
> Whether the coordination is performed by a central authority or a 
> cooperative society of participants is entirely irrelevant, to the 
> underlying requirement of preventing name conflicts.

Yes. And I should add that I didn't mean to attack CoDoNS as if
it was a bad piece of work. I meant to promote the notion that
substituting one way of guaranteeing namespace uniqueness for another
really doesn't change anything fundamental, if we still have to admit
the possibility of "conflicting or inconsistent records".

     Brian

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 28 Nov 2006 11:41:22 +0100

On Mon, Nov 27, 2006 at 10:58:11AM +0100,
 Patrick Vande Walle <[email-masked]> wrote 
 a message of 32 lines which said:

> Add to that the current architecture does not allow competition at
> the TLD level. There can only be one registry for any given TLD,

It is not artificial, it is the way it has to work. You cannot have
multiple registries for one TLD, period. No more than you can have
perpetual motion.

Demonstration "ad absurdum": let's assume two registries R1 and R2
manage the namespace ".example". A customer C1 wants to create
foobar.example and asks to registry R1. A customer C2 wants to create
foobar.example and asks to registry R2. There is a conflict.

You can solve the problems in various ways (see Emin Gun Sirer's
message) but most of them create a "super-registry" on the top of R1
and R2 and you are back to the unique registry model.

Other ways to solve the problem, without a super-registry, have other
issues:

* You can share the namespace, for instance, R1 has the right to names
whose length is > N characters (this was proposed in the WSIS: ITU
could manage names <= 2 and ICANN the rest). In essence, it makes
several namespaces in ".example" so, again, you're back to the rule
"One namespace, one registry".

* You can give in the "non conflicts" rule. This is what happens to
most "alternative inclusive roots". Ask your users how they feel about
it.

> A possible design is CoDNS

CoDoNS, CoDNS is a different thing.

It is interesting to see that the CoDoNS guy at the OARC 2006 meeting
emphasized exactly the opposite, so I believe you expect from CoDoNS
more than what they even promise :-)

http://public.oarci.net/files/workshop-2006/Sukhar-P2PDNS.pdf

"CoDoNS serves the exact same namespace with the exact same
interface."

He added "CoDoNS is just a resolver".

---

From: Emin Gun Sirer <[email-masked]>
Date: Tue, 28 Nov 2006 07:32:00 -0500

Hi Stephane,

On Tue, 2006-11-28 at 11:41 +0100, Stephane Bortzmeyer wrote:
> let's assume two registries R1 and R2

This is a false statement. A basic course on distributed systems will
cover lots of design alternatives where R1 and R2 are symmetric,
mutually distrusting and there exists no super-registry, yet there is a
way to establish whether R1 or R2 acquired the name first. 

> "One namespace, one registry".

This is a non-solution. The namespace is not shared.

> most "alternative inclusive roots". Ask your users how they feel about

This is underspecified, but because words like "secure timestamp" or
"blinded signature" or "commitment" or "quorum" or "consensus" or
"agreement" do not appear in it, it is likely a non-solution. Btw, not
_all_ of those keywords need to appear in a good solution, but probably
at least one should appear somewhere.

If anyone would like some design alternatives for a way to establish
whether R1 or R2 acquired the name first, without a super-registry, I'll
be happy to outline them. There are lots of possibilities, depending on
what one is willing to assume of the environment. But I'll do this only
if asked. Judging by the tone of the msgs, the folk on this list believe
themselves to be an expert at all things distributed and resembling a
name-service, so no point covering elementary topics.

Gun.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 28 Nov 2006 14:11:00 +0100

On Tue, Nov 28, 2006 at 07:32:00AM -0500,
 Emin Gun Sirer <[email-masked]> wrote 
 a message of 48 lines which said:

> A basic course on distributed systems will cover lots of design
> alternatives where R1 and R2 are symmetric, mutually distrusting and
> there exists no super-registry,

Feel free to give pointers, specially to systems which have been
deployed. From what I remember from my time in the academic world, the
imagination of the researchers in distributed systems is limitless and
they have invented protocols for everything. But few of them have been
deployed.

In the database area, we just start to have multi-master setups
deployed, even despite the fact that the masters are *not*
mutually distrusting.

> whether R1 or R2 acquired the name first, without a super-registry,
> I'll be happy to outline them.

This would be a very interesting Internet-Draft to read. But I suggest
to write the I-D on CoDoNS first :-)

I sincerely hope that we can find one day, better systems than the
DNS. But I'm very skeptical.

> But I'll do this only if asked.

Consider it done.

> Judging by the tone of the msgs, the folk on this list believe
> themselves to be an expert at all things distributed and resembling
> a name-service,

I am may be an expert in name service but certainly not in distributed
systems. What I may be is an expert on snakeoil detection. I see
CoDoNS as having two parts, one is a very interesting system to
replace the DNS servers by a better P2P protocol (a part which is
certainly worth a RFC). The other is vague claims of being able to
replace the complete registry system.

> so no point covering elementary topics.

I certainly appreciate "Distributed systems for ignorants" lectures. I
could learn a lot. Just do not mix "ignorants" (who can learn and who
want to learn) and "dummies", who just deserves marketing talk like
http://news.bbc.co.uk/1/hi/technology/4954208.stm.

---

From: Emin Gun Sirer <[email-masked]>
Date: Tue, 28 Nov 2006 08:14:54 -0500

Stephane,

> multiple registries for one TLD, period. No more than you can have

Be careful about making statements about impossibility without an
associated impossibility proof. History is full of people who look sort
of funny in retrospect. Protocols for serialization and agreement with
byzantine participants are well-established. This is kind of like saying
"heavier-than-air machines cannot fly," in 2006.

Gun.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 28 Nov 2006 14:23:59 +0100

On Tue, Nov 28, 2006 at 08:14:54AM -0500,
 Emin Gun Sirer <[email-masked]> wrote 
 a message of 14 lines which said:

> associated impossibility proof.
 
Already sent. Of course, proofs, like software, may have bugs :-) The
IETF is not a bad place to discuss them.

> This is kind of like saying "heavier-than-air machines cannot fly,"
> in 2006.

We still do not have perpetual motion or solved the squaring of the
circle.

Your reasoning is very strange: because some people were wrong in the
past, it means we cannot be sure of anything and we should waste our
time on things which are impossible?

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 Nov 2006 08:27:04 -0500

--On Monday, 27 November, 2006 11:07 -0800 Dave Crocker
<[email-masked]> wrote:
 
> By "beginning of SMTP" John actually means the mid-1970s, in
> the original Arpanet FTP-based mail service.
> 
> And since I think it was a particularly clever option, I'll
> note that one of the commands John cites was "deliver to the
> recipient's screen if they are logged in and deliver it to
> their mailbox if they aren't."

Yes.  I wanted to keep the note from becoming even longer, but
you are of course correct -- both on the substance and that
those things are important.

> Would be nice to have that in today's world, wouldn't it?

I think so.  And I'm getting interested in the difference
between IM-ish systems for which the model is "if they aren't
online, it is lost" and "they aren't online now, but your
message will be held and delivered when they are".

> There as a close approximation, as I recall, with the way the
> Finger mechanism was implemented at some sites.  You would
> Finger a particular username at a host and the returned
> information would tell you if they were logged in.

Indeed.  Or with, e.g., talk, one could try to set up a
connection and assume that failure meant "not present".  Both
are approximations, but so are today's presence mechanisms.

>> identity to a target host in much the way SMTP does, rather
>> than having someone attach to the network at any point and
>> announce presence and, implicitly, location. 
> 
> Mumble.  I'd claim that the current presence mechanisms do the
> same thing that was done originally.
> 
> If I came in through an arpanet dial-up at some random place
> on the net, and telneted to my home system, then the finger
> for that home system would show me as 'present'.  I am not
> seeing how today's presence systems are fudamentally different
> from that.

Subjectively and from my perspective, the present systems
"feel", and sometimes actually are, much more distributed.  But,
yes, from the perspective you describe, we have advanced very
little in terms of basic functionality.

>> recent development.  To the degree to which those mechanisms
>> are what caused IM to take off, perhaps that reinforces
>> Dave's view of different services serving different needs.
> 
> I think it was Graham Klyne who pointed out to me that IM and
> Internet Mail also do tradeoffs in reliability vs. timeliness.
> 
> An IM is not expected to survive a system crash, whereas an
> email is.  That leads to very different software development
> decisions, such as whether to incur the cost of a
> write-to-disk for every message.  In the aggregate, the cost
> difference can be huge.

Indeed.
    john

---

From: Eliot Lear <[email-masked]>
Date: Tue, 28 Nov 2006 14:28:11 +0100

> way to establish whether R1 or R2 acquired the name first. 

Please explain this to me.  Who determines who was first, and what do 
you mean by "mutually distrusting" in this context?

Eliot

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 28 Nov 2006 14:45:23 +0100

On Tue, Nov 28, 2006 at 02:28:11PM +0100,
 Eliot Lear <[email-masked]> wrote 
 a message of 11 lines which said:

> what do you mean by "mutually distrusting" in this context?

In distributed systems, "mutually distrusting" means they are not
under the same rule ("not in the same AS" would say a BGP user), and
they can play dirty tricks to each other. For instance, two registrars
of ".com" are "mutually distrusting" so a protocol between registrars
MUST NOT assume they will be nice to each other.

Coordinating two actors in a distributed system is difficult enough
but, if they are mutually distrusting, it becomes... daunting.

---

From: Emin Gun Sirer <[email-masked]>
Date: Tue, 28 Nov 2006 08:31:04 -0500

> > But I'll do this only if asked.

Ok, here is a rough protocol sketch. For simplicity, I'll gloss over
non-critical details, e.g. timeout handling. Bear with the notation,
we'll end up with something neat at the end:

- assume that R1 and R2 pick random numbers r1 and r2 which they 
  keep private, and agree on random numbers v1 and v2.
- they keep counters n1 and n2, starting at 0
- there is a global counter seqno, starting at 0
- they each have public/private key pair K_r1 and k_r1.

- use h(s, n) to refer to a secure one-way hash chain, such that
	h(s,n) = sha(sha(sha(...sha(s)...))),
	where there are n sha() applications,
   note that knowing h(s, n) gives you no way to determine h(s, n-1),
   but knowing h(s,n-1), it is trivial to check that h(s,n)=sha(h(s,n-1)

- In the beginning, R1 sends h(r1, N+1) to R2, and vice versa.

- To register a name, R1 sends <seqno, name, ip> signed 
	with k_r1 and blinded with h(r1, N-n1) to R2
- R2 signs and returns the packet, 
	note that it cannot see what it just signed due to the 
	blinding factor, and it cannot guess the blinding factor,
- If R1 or R2 have a packet outstanding in the network, they  
	toss one of the packets away (either theirs or their opponent's)
	to establish progress. which packet they throw away is
	determined by a random bit derived from v1 or v2, respectively.
- Both R1 and R2 increment seqno when they hear from the other party
- R1 reveals x=h(r1, N-n1), R2 checks to make sure that sha1(x)
	yields the previously revealed h(r1, N+1).
- The blinding factor is removed to yield a packet, signed by both
	R1 and R2, with the desired name and binding.

Voila, bindings now have signatures from _both_ parties, even though
both are mutually suspicious, and no one gets to know what the other
party is doing. R1 cannot deduce what name R2 is trying to register, 
and submit a fake "concurrent" request for the same name - it only gets
to find the name out when the protocol concludes. 

It's pretty early in the morning here and I wrote this without
consulting Bruce Schneier's excellent book, so it's likely to be in
error :-), but you get the idea and there should be a more generic
version of a similar protocol in there that is not in error.

>I see

You're right, the second part is not something that is germane to the
system. CoDoNS would do just fine without the multiple registrars per
domain. In retrospect, we wanted to point out that a different kind of
nameservice is possible with CoDoNS+DNSSEC. In reality, it is too tricky
and too nuanced an idea to get across, and, as I said, we'd be happy if
IANA just signed the single TLD delegations already.

Best,
Gun.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 28 Nov 2006 09:24:52 -0500

What this thread is lacking is:

There is a difference between being a registry and being a DNS operator.

The role of a registry is to associate a resource with a principle. 
Like a domain name with a company. Or range of addresses with a 
person.  Or a value in a protocol field with a semantic.  Or an 
address with a network.  Or a motor vehicle with an owner.  Or a 
company with a tax identifier.  (Registries are not just for the 
Internet.)

The role of a DNS operator is to publish data associated with a 
domain name.  The challenge is to reliably provide the service over 
the unreliable nature that is the Internet.  DNS operations is a 
highly technical job, more so that the legality behind registration. 
Unlike the "market" for registration being beyond the Internet, the 
market for DNS operations is pretty much the IP-connected world 
(okay, not just the Internet, but networks using the same technology 
base until we have DNS over other transports).

When we talk of domain name registries, DNS operations is a component 
of a registry.  DNS operations is not the most important role, 
however, it just seems that way in the IETF environment because DNS 
is the most technically involved component.  WhoIs and EPP are 
child's play compared to DNS, technically.  And the IETF is rather 
oblivious to the billing processes, the name dispute process,  etc.

There are a number of differing models in play for how domain name 
(and other Internet) registries operate.  There is the ICANN shared 
registry model which makes registrars and pre-registrars compete to 
sell services but rely on a central registry.  There is the NRO model 
in which the central registry, IANA, is almost powerless and the five 
Regional Internet Registries duke it out for the honor of delegating 
Internet resources.  (In fact, recently IANA adopted a policy of 
doling out IPv6 addresses in certain sizes via a policy foisted from 
the RIRs to IANA, not from IANA to the RIRs.)  When I say "powerless" 
I mean to draw out that IANA hardly has "monopolistic powers" even 
though they have the pool of resources doled out.

Not all domain name registries operate that same way.  ccTLDs have 
other operating models.  Off-hand I can't give specific examples, but 
I know of ones that don't have registrars, some that offer a 
registrar-of-last-resort, and some that compete alongside the 
registrars.  I mention that because there is now about 5 years of 
history of this kind of market to study, if anyone is concerned about 
whether a "monopoly registry" is an evil thing.

The one weakness I see in the presentation of CoDoNS is one that is 
common amongst academic exercises.  While it treats a technical 
problem in a formally defined say, it suffers from the "assume 
frictional surfaces" syndrome.  This disease is not fatal, it is more 
like the flu, meaning that the work is worthwhile and there are some 
nuggets of real helpful technology, but taken as one package it is no 
better than what is out there today - which does not have to assume 
frictionless surfaces.

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

Dessert - aka Service Pack 1 for lunch.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 28 Nov 2006 15:25:09 +0100

just to add to the confusion...

gmail will actually store the transcripts from your gtalk sessions in your 
gmail inbox. Blurring the difference again....

---

From: Edward Lewis <[email-masked]>
Date: Tue, 28 Nov 2006 09:24:52 -0500

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 28 Nov 2006 15:25:09 +0100

---

From: Emin Gun Sirer <[email-masked]>
Date: Tue, 28 Nov 2006 10:00:48 -0500

Hi Ed,

> better than what is out there today - which does not have to assume 

It's certainly true that operationally oriented folks would like to see
issues addressed at a different level than academic folks. And this is
entirely reasonable; I can see how academic papers or quick email notes
would engender that feeling. 

Just to put things in perspective:

- CoDoNS showed how to use a P2P system to serve names, and to do so
	with high performance. Previously, this was considered
	impossible because DNS query distributions follow Power Law
	distributions, and such query distributions were considered
	to be impossible to handle. There are lots of papers on 
	heuristics-based approaches to managing a name cache that
	have no guarantee of working, and there is a paper from highly
	esteemed colleagues at MIT who wrote that serving DNS with a
	P2P substrate was impossible (which was the state of the art
	at the time). We showed how to do it.

- We rewrote a new DNS implementation based on this new P2P architecture
	that is backwards compatible with existing resolvers and
	supports the same namespace as the current DNS. Remember how
	long the BIND9 effort took, with extensive resources? CoDoNS is
	a comparable effort, plus it has a P2P organization, plus it
	has a radically new way of managing cache contents and cache
	update traffic. By just 2 people total (actually, almost
	entirely 1 person, my former graduate student, Rama).

- We serve some names authoritatively through our system to protect
	them from DoS, as evidenced by the www.electoral-vote.com
	effort, where we provided both DNS and CDN services to a site
	under serious threat of DoS attacks. 

So, you can say whatever you like about academic research in general,
but when it comes to the CoDoNS, we know about friction-bearing
surfaces.

Best,
Gun.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 28 Nov 2006 08:01:29 -0800

John C Klensin wrote:
> Yes.  I wanted to keep the note from becoming even longer, but...

ack.  figured that, but found myself compelled that the history lesson was 
useful for the record.

> little in terms of basic functionality.

I believe that none of the proprietary IMs is anything other than purely 
centralized.

Having to configure multiple IM accounts, to be able to talk to different 
people, doesn't feel at all 'distributed' to me, except in the bad sense of 
multiple, disconnected, centralized services.

d/

-- 

   Dave Crocker

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 Nov 2006 12:27:59 -0500

--On Tuesday, 28 November, 2006 08:01 -0800 Dave Crocker
<[email-masked]> wrote:

>> "feel", and sometimes actually are, much more distributed.
>> But, yes, from the perspective you describe, we have advanced
>> very little in terms of basic functionality.
> 
> I believe that none of the proprietary IMs is anything other
> than purely centralized.
> 
> Having to configure multiple IM accounts, to be able to talk
> to different people, doesn't feel at all 'distributed' to me,
> except in the bad sense of multiple, disconnected, centralized
> services.

No question about it.  I was thinking partially about Jabber,
with interoperability between implementations and hosts, and
Skype with (at least as I understand it) a fairly distributed
architecture.  As to the rest, I assume that, sooner or later,
we will the same thing we saw with email: as functions and
capabilities diverge, gateways (and multiprotocol clients)
deliver only least common denominator services and get less
capable, and, well,... Know anyone with a large installed base
of ccMail users these days?

I think there is another interesting story in the fact that
multiprotocol clients seem more effective and useful, and much
more widely used and deployed, for IM than their equivalents
were for email.  Part of it is certainly related to the fact
that the usual email model is not-very-smart-MUA->
smarter-Submission-server, while the IM one, at least in terms
of what the user sees, is client->client.

  john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 28 Nov 2006 10:14:14 -0800

John C Klensin wrote:
>> Having to configure multiple IM accounts, ...>
> 

Right.  Which was why I said "proprietary".  (Jabber, having been turned into 
XMPP, nicely dodges that qualifier...)

> with interoperability between implementations and hosts,

 From some recent experiences, it is looking as if it still needs to go through 
some implementation learning curve.  I suspect it's not a protocol issue, but 
I've seen some interoperability problems and would bet the issue was software 
maturity.

  and Skype with (at
> least as I understand it) a fairly distributed architecture.  As to the rest,

oh.

> I think there is another interesting story in the fact that multiprotocol
> clients seem more effective and useful, and much more widely used and
> deployed, for IM than their equivalents were for email.  Part of it is

Maybe.  I'm seeing enough oddities with the popular, multi-protocol IM client 
that I use to continue to believe that the combinatorials that are inherent with 
multiple, competing protocols make long-term viability a real question.

Back when I wrote email gatewaying software -- and it's design was with a 
canonical model that each service was mapped to/from --  I know that every time 
I added a new email service, I had to go into the core and make tweaks.  Or 
sometimes deeper changes.

d/
-- 

   Dave Crocker

---

From: "Brian Rosen" <[email-masked]>
Date: Tue, 28 Nov 2006 13:49:03 -0500

If you squint hard enough, everything has already been invented.  Telegraph
operators had a form of presence if you squint hard enough.

Presence is a continuously updated 'display' of a set of other people's
status.  Finger didn't do that.  Yeah, you COULD have used the mechanism to
implement a form of presence, but I don't remember anyone ever doing that,
and if they did, it didn't make anyone sit up and take notice like the IM
folk's buddy status systems did.  They invented presence, as we know it, and
of course it's not entirely new, but then again, little else is.

Finger had antecedents in various time sharing systems versions of "who is
logged in" mechanisms.  They in turn had predecessors in various user id
logging mechanisms on batch systems.  I recall being able to determine who
was in the CMU Comp Center by looking at a fairly often posted list of batch
runs made for the 1108, and the G20 graphics systems certainly had
mechanisms to know who was on the other displays way before I got there.

Sending real time messages to users logged in is almost as old.  The G20
graphics systems had such facilities.  Every time sharing system did, and of
course, the telegraph operators had a similar facility.  They aren't IM.

Brian

> -----Original Message-----
> From: Dave Crocker [mailto:[email-masked]]
> Sent: Tuesday, November 28, 2006 11:01 AM
> To: John C Klensin
> Cc: [email-masked]
> Subject: Re: IM and Presence history
> 
> 
> 
> John C Klensin wrote:

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 28 Nov 2006 22:17:31 +0100

On Tue, Nov 28, 2006 at 08:31:04AM -0500,
 Emin Gun Sirer <[email-masked]> wrote 
 a message of 64 lines which said:

> Ok, here is a rough protocol sketch.

Very interesting. One more reason to ask it is transformed into a full
Internet-Draft. Do you think it fits well in Hallam-Baker, Phillip's
"logical registry" model?

> For simplicity, I'll gloss over non-critical details, e.g. timeout
> handling.

It still leaves many questions in my mind:

* how does it scale? It is reasonable to assume hundreds or even
thousands of managers for ".com". If each domain registration requires
thousands of signatures, which have to be done in turn, and
synchronously, it is a problem (mny distributed protocols assume only
a handful of nodes because they are very talkative).

* DNS registration is not binding a name to an IP! (See Edward Lewis'
good description). It is binding a name to an entity which is often
fuzzily defined (see whois' output). How do you address this?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 28 Nov 2006 22:17:31 +0100

---

From: Eliot Lear <[email-masked]>
Date: Tue, 28 Nov 2006 22:48:17 +0100

Brian Rosen wrote:
> folk's buddy status systems did.

Mel Pleasant wrote a program for the DEC-20 called "watch", which was 
commonly used on many -20s at the time (this goes back to at least the 
early 80s).  You would provide a list of individuals you were interested 
in watching and the program would sit on top of your EXEC and 
occasionally burp out messages that So-And-So has just {logged 
{in|out}|attached|detached}.  At Rutgers we had a program that sat on 
the consoles beneath OPR that would spit out login and logout messages 
of anyone who had wheel.

Now if you combined Watch with Toggle, a program that let you blat a one 
line message to someone (it also TREPLACEd the EXEC) you had many of the 
same IM features you have today (no graphical smileys, bold or italic 
facing, or direct file transfers).

Eliot

---

From: Emin Gun Sirer <[email-masked]>
Date: Tue, 28 Nov 2006 19:31:50 -0500

Stephane & Phillip,

I'm thinking of writing a short report that summarizes the invaluable
discussion here and beefing up the system sketch. I think we now agree
that it is possible to have multiple operators manage names in a single,
shared namespace without recourse to a centralized super-registry. 

>Do you think it fits well in Hallam-Baker, Phillip's "logical registry"
>model?

Yes, the registrars together implement a logical registry without any
centralized component.

> * how does it scale? 

The protocol I sketched was for just two parties; it can be generalized,
but let's take that discussion offline. It's certainly possible to do
it, but something that'll work fast and with participants that will
trigger timeouts might require quorums, a slightly different approach.

> fuzzily defined (see whois' output). How do you address this?

One can use a protocol like that to just serialize the events, i.e.
establish order, regardless of what the events that comprise a
registration are.

>What you absolutely cannot get away from is a mechanism to ensure 
>joint action. 

True. The question was whether the mechanism necessarily had a
centralized component.

>the point of the exercies here is to meet the needs of the Internet
>users, not solve cute academic puzzles for the sake of arbitrary
>ideological goals.

For one, I am totally agnostic on this issue. It's possible and maybe
even practical to delegate a space to multiple operators without a
super-registry, and neither I nor the workings of CoDoNS care whether we
do that or not.

As an Internet user, I wonder about two things in the long term:
	- why is it so expensive to register a name?
	- what can we do to keep SiteFinderJr from happening?

In the short term, I think we have bigger issues to worry about (e.g.
current DNS's vulnerability to denial-of-service attacks).

Gun.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 28 Nov 2006 18:55:53 -0800

On Nov 28, 2006, at 4:31 PM, Emin Gun Sirer wrote:

> Stephane & Phillip,
>
> I'm thinking of writing a short report that summarizes the  
> invaluable discussion here and beefing up the system sketch. I  
> think we now agree that it is possible to have multiple operators  
> manage names in a single, shared namespace without recourse to a  
> centralized super-registry.

You might want to review patent 7,065,587 as well.  Rather than a  
hierarchical name space, there are GUIDs and "friendly names"  
socially structured into groups.  In addition to friendly names,  
GUIDs can combine with DNS names as well.  There is no need for a  
super-registry, but rather a way to generate GUIDs.  Perhaps this is  
the structure of things to come, where belonging to a group matters  
more than a centralized authority.

-Doug

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 29 Nov 2006 10:43:14 +0100

> Yes, the registrars together implement a logical registry without any

I would prefer it if you referred to a logical namespace. Whether or
not there is a registry is a bit of an implementation issue.

...
> 	- why is it so expensive to register a name?

Both Milton Friedman and JM Keynes are dead now, but really your
question is linked to whether we treat the namespace as a public
good to be administered for the greater public good, or as a
commodity to be treated like coffee beans. And that really isn't
a question for this technological community.

     Brian

---

From: [email-masked]
Date: Wed, 29 Nov 2006 11:27:11 +0000

> way to establish whether R1 or R2 acquired the name first. 

This is the problem of using complex and sophisticated 
technical arguments against shared registy models. The fact
is that the domain naming service delegates exclusive control
over a subdomain to a single entity. From that model, companies
like IBM are assured total and exclusive control of the subdomain
ibm.com. If you change that model, then IBM ceases to have
such exclusive control.

I note that numerous organizations have taken an interesting
subdomain and used it to delegate sub-subdomains to other parties.
Such organizations can even share the sub-domain if they wish to.
But doing that infects the entire sub-tree of their domain with
the new model. In order to preserve the possibility that some
domain owners can have total and exclusive ownership we need 
to maintain a single authoritative and exclusive owner of the 
root.

Or in other words, if IBM wants to keep ibm.com then the root
must remain under the control of a single exclusive authority.
 
Fancy technology cannot change this.

--Michael Dillon

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 29 Nov 2006 12:59:36 +0100

> 	- what can we do to keep SiteFinderJr from happening?
what do you think of as "expensive"?

I can register a name for a year for the price of 2 beers (ok, beer in 
Norway is expensive too...)

There are very few components of setting up something useful on the 
Internet that cost less.

                      Harald

---

From: John C Klensin <[email-masked]>
Date: Wed, 29 Nov 2006 07:50:26 -0500

--On Tuesday, 28 November, 2006 22:48 +0100 Eliot Lear
<[email-masked]> wrote:

> Brian Rosen wrote:
>> If you squint hard enough, everything has already been
>> invented.  Telegraph operators had a form of presence if you
>> squint hard enough.
>> 
>> Presence is a continuously updated 'display' of a set of
>> other people's status.  Finger didn't do that.  Yeah, you
>> COULD have used the mechanism to implement a form of
>> presence, but I don't remember anyone ever doing that, and if
>> they did, it didn't make anyone sit up and take notice like
>> the IM folk's buddy status systems did.
> 
> Mel Pleasant wrote a program for the DEC-20 called "watch",
> which was commonly used on many -20s at the time (this goes
> back to at least the early 80s).  You would provide a list of
> individuals you were interested in watching and the program
> would sit on top of your EXEC and occasionally burp out
> messages that So-And-So has just {logged
> {in|out}|attached|detached}.  At Rutgers we had a program that
> sat on the consoles beneath OPR that would spit out login and
> logout messages of anyone who had wheel.
> 
> Now if you combined Watch with Toggle, a program that let you
> blat a one line message to someone (it also TREPLACEd the
> EXEC) you had many of the same IM features you have today (no
> graphical smileys, bold or italic facing, or direct file
> transfers).

And there were versions of either finger or whois servers
(probably both) that had "continuous" options.  I would still
claim that today's presence models are a significant change,
especially when they are adapted in a distributed
independently-operated server environment and that real-time
messaging is not.  However, what this subthread demonstrates is
that they were conceptually an incremental change, not a giant,
discontinuous, intellectual leap.   

I thought we all knew that.

       john

---

From: Eric Burger <[email-masked]>
Date: Wed, 29 Nov 2006 08:05:36 -0500

Actually, as I fuzzily recall in the 1986 - 1992-ish period, MCImail had a
large presence for business messaging and CompuServe had a lion's share of
consumer messaging.

Before the flames go on, realize that (1) my memory is fuzzy and (2) the
market was seriously fractured.  The large enterprise market was doing the
Notes thing; the small enterprise market was doing the cc:mail, netware,
etc. thing, and interoperability was something that people gave lip service
to.

What a difference five years made!  By 1996, pretty much everyone
interoperated with Internet Mail.

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 29 Nov 2006 08:16:35 -0500

> However, what this subthread demonstrates is
Oh, I agree, we knew that.   There are very, very few discontinuous
intellectual leaps in our part of the universe.  It's hard to name one that
happened in the past decade or two.

Can we name any discontinuous intellectual leaps of late in computer
networking?  Now that I think about it, forget "of late", have there EVER
been any?

---

From: Marshall Eubanks <[email-masked]>
Date: Wed, 29 Nov 2006 08:21:41 -0500

> networking?  Now that I think about it, forget "of late", have  

circuit switching -> packet switching

Some people have never recovered.

Regards
Marshall

---

From: Patrick Vande Walle <[email-masked]>
Date: Wed, 29 Nov 2006 14:32:07 +0100

Brian E Carpenter wrote, On 29/11/2006 10:43:
> your question is linked to whether we treat the namespace as a public
Depends how you look at it. Technological choices do have an impact on
what the society is able to do (or not). It is up to the society to tell
the engineers what it needs/wants. But I agree there are other fora for
this.

Patrick

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 29 Nov 2006 08:34:36 -0500

> networking?  Now that I think about it, forget "of late", have there EVER

Turing machine? (Computers, but not Networking)

The original Ethernet? (not really "discontinuous", but quite a big leap)

Janet

---

From: Emin Gun Sirer <[email-masked]>
Date: Wed, 29 Nov 2006 11:42:17 -0500

> what do you think of as "expensive"?

Anything that has 1000% or higher markup. There is also another kind of
expense: solving the SiteFinder problem took a lot of time, public
outcry and moral outrage from a large group of people. It would have
been nice to just scoot over to a competitor. These are the arguments
for providing competition in a single namespace, as opposed to trying to
solve problems by legislation and public outcry.

Probably won't help with the price of Norwegian beer though.

>Both Milton Friedman and JM Keynes are dead now, ...

Let's not torque the discussion off topic. Free market economics does
not come to bear on the issue because there is no free market to speak
of for registries.

>must remain under the control of a single exclusive authority.

Agreed. There should be a single logical root, with an entity that has
exclusive authority over it.

>However, to back up a step, what is it that you actually need/want?

A quick question: Right now, we'd like to have a domain delegated to a
large number (say 100+) of nameservers. The registrars we have gone
through impose a limit on the number of nameservers they are willing to
accept. Is this a limit stemming from the .COM registry, or is there a
registrar out there that will let us delegate a .COM domain to a few
hundred nameservers? (And no, not all nameservers need to be returned in
response to every query. A random sampling would be fine). 

Gun.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 29 Nov 2006 12:40:09 -0500

>not come to bear on the issue because there is no free market to speak

What did I say about frictionless surfaces?

>large number (say 100+) of nameservers. The registrars we have gone

The terminology used here indicates a need for a deeper understanding of DNS.

>response to every query. A random sampling would be fine).

The conventional limit on the number of name servers for a zone is 
derived from the pre-EDNS0 limit of 512 bytes in a UDP'd DNS message. 
When you query for the root zone SOA you get back the SOA, 13 NS 
records, and 13 glue A records.  If it were 14, then the message 
would be truncated and probably lead to a TCP connection attempt.

 From this hard (operations) limit, the notion of 13 as maximum crept 
into registry software.  And not just .COM.

Ideally, the limit would be lower, as IPv6 wasn't invented when the 
number 13 was derived.  To stay under the 512 limit and still include 
AAAA records, a lower limit would be needed.

Your parenthetical comment is contrary to one of the most important 
principles in the DNS, coherency.  Especially high up in the 
hierarchy.  It would be hard to debug problems if the returned set of 
servers in a referral changed very rapidly.  There is the practice of 
tailoring answers to a querier, although this is globally incoherent 
in the strict sense at least the answers to the querier in question 
stay fairly constant (and coherent from different available sources).

Of course, the 13 name limit does not limit you to 13 name servers. 
With anycast, the number can be unbounded subject to the concerns 
with routing.  And if you add in load balancers you can have even 
more servers.  It depends on how you count 'em.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 Nov 2006 10:40:37 -0800

> The original Ethernet? (not really "discontinuous", but quite a big leap)

I think that Ethernet, like the Web, are actually excellent COUNTER-examples. 
Ethernet is Alohanet with carrier-sense, collision-detect, exponential backoff. 
  And, of course, it runs over wire rather than radio.

IMO, Ethernet and the Web represent (high quality) incremental work that had 
discontiguous impact.

The major part of the incremental work was systems-level synthesis of just the 
right set of features, at the right time.

d/

-- 

   Dave Crocker

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 29 Nov 2006 22:21:39 +0100

On Wed, Nov 29, 2006 at 12:40:09PM -0500,
 Edward Lewis <[email-masked]> wrote 

> The terminology used here indicates a need for a deeper understanding of 

I suspect that he is deliberately trolling, in order to prove a point
(that DNS is too limited to handle domains who need a lot of
reliability).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 29 Nov 2006 22:19:30 +0100

On Wed, Nov 29, 2006 at 11:42:17AM -0500,
 Emin Gun Sirer <[email-masked]> wrote 
 a message of 36 lines which said:

> Right now, we'd like to have a domain delegated to a large number
> (say 100+) of nameservers.

See Edward Lewis' respond (basically, global anycast + local anycast
and you have as many servers as you wish).

> The registrars we have gone through impose a limit on the number of
> nameservers they are willing to accept.

The limit typically comes from the registry (eight nameservers in
".fr").

> (And no, not all nameservers need to be returned in response to
> every query. A random sampling would be fine).

Since they are all part of the same RRset, it is not legal to return
only a part of them. A RRset must be returned completely (or the TC
bit set).

BTW, did you test if typical resolvers (say, BIND) can handle as many
nameservers? I doubt it, they probably have a fixed array to store the
nameservers they try.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 29 Nov 2006 22:21:39 +0100

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 29 Nov 2006 22:19:30 +0100

---

From: Carl Malamud <[email-masked]>
Date: Wed, 29 Nov 2006 15:55:30 -0800 (PST)

Hi -

I actually think the question of how a namespace is to be administered
is a perfectly valid one for the IETF to consider if it impacts the 
performance or functionality of a protocol.  

We do that all the time when we give explicit instructions to the IANA 
in an "IANA Considerations" section.  The IETF could also do the same 
in an "ICANN Considerations" section when it comes to the DNS.  

Carl

---

From: Dave Crocker <[email-masked]>
Date: Wed, 29 Nov 2006 17:01:30 -0800

> mission critical for the ONE NETWORK which

The essential argument that you are making, I think, is about the DNS
*operational* service, rather than about the DNS protocol.  Hence the call for
using a different port for additional uses. (cf., SMTP and SUBMISSION, of course.)

Yet responses so far are about the protocol, or maybe about protocol "support".

The observation that the vast bulk of current DNS use is for a particular
function that is essential to real-world use of the basic infrastructure ought
to be obviously true to folks.

So the question is whether adding other uses of it might pose any significant
problems.  This is not a protocol question, but an ops, admin, and management
question.

Will the different uses create traffic patterns, administrative requirements, or 
the like, that threaten the current, essential service, in any of the ways 
previously cited?

A small example:  The current DNS is typically administered by a particular kind
of group within an organization's IT structure.  Do the proposed new uses pose
any problems for this, by virtue of needing a possibly different set of
administrators?  (It turns out that the controversial underscore naming
technique provides a way of vectoring some new uses to new administrative groups.)

d/
-- 

   Dave Crocker

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Nov 2006 11:27:26 +0100

> performance or functionality of a protocol.  

Yes, as long as it can be expressed technically. RFC 2826 and
http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html
are good examples, IMHO. So was RFC 3177, although it needs
revisiting today.

> in an "ICANN Considerations" section when it comes to the DNS.  

Actually, no. It is always IANA. However, RFC 2860 section 4.3
specifically excludes the IETF giving IANA guidance in certain areas.

     Brian

dows NT 5.1; en-US;
	rv:1.6) Gecko/20040113
To: Carl Malamud <[email-masked]>
Cc: [email-masked]
Subject: Re: Something better than DNS?

> performance or functionality of a protocol.  

Yes, as long as it can be expressed technically. RFC 2826 and
http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html
are good examples, IMHO. So was RFC 3177, although it needs
revisiting today.

> in an "ICANN Considerations" section when it comes to the DNS.  

Actually, no. It is always IANA. However, RFC 2860 section 4.3
specifically excludes the IETF giving IANA guidance in certain areas.

     Brian

---

From: Emin Gun Sirer <[email-masked]>
Date: Thu, 30 Nov 2006 16:41:12 -0500

My research group, as well as everyone who currently uses PlanetLab (and
presumably the future GENI platform, if it comes to pass) faces a
different deployment scenario than what the operational folks are used
to. Setting up anycast might be possible, but is operationally very very
difficult for lots of (partly non-technical, partly technical) reasons.
Hence the genuine question on where the limit stemmed from.

> The terminology used here indicates a need for a deeper understanding of DNS.

My terminology is correct, and your message is a simple ad hominem. You
should point out the error if there is one, and demonstrate how it
translates to a lack of understanding. Earlier in the thread, I
addressed people who claim to understand distributed systems, who could
not properly define the term "Byzantine," and we did not stoop to this
level. Someone with a spine would offer an explanation or an apology,
but I'm not holding my breath on either count :-). 

SB>I suspect that he is deliberately trolling, in order to prove a point
SB>(that DNS is too limited to handle domains who need a lot of
SB>reliability).

Stephane, I say enough controversial things as it is that you can
(perhaps?) argue over what I actually said, instead of making up random
and wildly inaccurate stuff. I don't believe "DNS" is too limited. The
wire format is very flexible.

> hierarchy.  

Did you make this principle up or is it enunciated somewhere? There are
lots of places where it is violated.

> with routing.  

I asked because global anycast is not always feasible, esp. when the
hosts have already assigned IPs, and it is not easy to assign new IP
addresses to them.

> And if you add in load balancers you can have even 
> more servers.  

This spreads the load within a point of presence, but won't improve
service by expanding the bottleneck prior to the balancer.

Gun.