The next version of the root-servers.net hints file should not have any netSOL owned root servers in it. That will make the transition easier. -- William Allen Simpson Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32

On Wed, 17 Sep 2003, William Allen Simpson wrote:

Googling around, I couldn't find a definitive list of the root-servers owners. Any canonical method of determining which hints we should remove? I'd like to drop them from our config files.

http://www.root-servers.org/ allan -- Allan Liska allan@allan.org http://www.allan.org

The next version of the root-servers.net hints file should not have any netSOL owned root servers in it. That will make the transition easier.

excuse me for the harsh language, but that's just silly. verisign's root name servers (a-root and j-root) are professionally run by some of the best dns techs in the industry. nothing that's happening with dot-com or dot-net should be considered relevant to verisign's *root* servers in any way. the *root* servers do not carry dot-com or dot-net, they just carry "." itself, and arpa, and in-addr.arpa, and in some cases root-servers.net. -- Paul Vixie

On Wed, 17 Sep 2003 00:38:14 EDT, Mike Tancsa <mike@sentex.net> said:

I trust your assessment of the DNS techs. But what about the DNS tech's bosses? They ordered some pretty lumpy things be done with .com and .net. Given that track record, whats to stop them from ordering the GTLD techs from doing something equally lumpy.

Well, for starters, Verisign is the ONLY one doing the .com and .net zones. To pull a stunt like that at the root, they'd have to get the OTHER 9 or 10 organizations to buy in, or they'd find themselves outvotes 13 servers to 2, or whatever the exact numbers are....

Speaking on Deep Background, the Press Secretary whispered:

Yes, I understand that. But based on their recent actions I dont feel anyone should trust Verisign to act towards any of the Internet community's best interests let alone 1/13th of its core functionality. I think there is a fundamental breaking of trust here. (IMHO anyways)

---Mike

RENAULT: I am shocked, shocked to find that gambling is going on in here! Has there really been trust towards NSI/Verisign's Suits, by the crowd here? [Of late, say the last few years...] I thought it closer to the opposite..... -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

On Tue, 16 Sep 2003, John Brown wrote:

not all the *root-servers* carry .arpa or in-addr.arpa

J (one of verisigns) does not carry this zone, based on their own internal decision.....

Actually, I thought that was one of Jon Postel's decisions when they were experimenting with creating "root-only" root servers. Unfortunately, the progress on that front didn't continue after the DNS wars started.

If we take a step back, we could say that the whole Verisign incident demonstrated pretty clearly that the fundamental DNS premise of having no more than one root in the namespace is seriously wrong. This is the fallacy of "universal classification" so convincingly trashed by J.L.Borges in "The Analytical Language of John Wilkins". Sigle-root classifications simply do not work in real-world contexts. On a more practical plane, as long as there is a central chokepoint there will be an enormous advantage for a commercial or political interest to control that chokepoint. As Internet becomes more and more important, the reward for playing funny games with the top levels of the name space are only bound to get higher. I do not want to play a Nostradamus, but it is pretty obvious that it's likely to be sooner than later that there will be an incident in which a bribed or planted Verisign employee aids a massive identity theft on behalf of a criminal group. And that we will see politically-motivated removal of domain names (my bet is that porn sites will be targeted first). How about twiddling NS records pointing to sites of a political party not currently in power? DNS is no longer a geeks sandbox, it lost its innocence. The Name Service is engineered with this fatal weakness. It cannot be fixed, as long as it depends on any central point. It already has many problems with trademark and fair competition laws. In some countries, national DNS roots are controlled by secret police. It is a good time to stop patching it, and start thinking about how to address the root cause of the problem: namely, that there's no way for an end-user to choose (or create) his own "root" of the search space. (The implication is that names become paths - which matches human psychology quite well, considering that we posess an evolved ability to navigate using local landmarks). In fact, we do have an enormously useful and popular way of doing exactly that - this is called "search engines" and "bookmarks". What is needed is an infrastructure for allocation of unique semantic-free end point identifiers (to a large extent, MAC addresses may play this role, or, say, 128-bit random numbers), a way to translate EIDs to the topologically allocated IP addresses (a kind of simplified numbers-only DNS?) and a coordinated effort to change applications and expunge domain names from protocols, databases, webpages and such, replacing URLs containing domain names with URLs containing EIDs. This way, the whole meaning-to-address translation chain becomes decentralized and absolutely resistant to any kind of deliberate monopolozation (except for scale-free networking effect). And, in any case, I would trade Verisign for Google any day. --vadim

On Wed, 17 Sep 2003, [ISO-8859-1] Mathias KЖrber wrote:

...

If we take a step back, we could say that the whole Verisign incident demonstrated pretty clearly that the fundamental DNS premise of having no more than one root in the namespace is seriously wrong. This is the fallacy of "universal classification" so convincingly trashed by J.L.Borges in "The Analytical Language of John Wilkins". Sigle-root classifications simply do not work in real-world contexts.

... for objects which are created outside said classification and need to/ want to/should be classified in it. However, the DNS does not pretend to classify anything existing outside it in the real-world but implements a namespace with the stated goal of providing unique identification (which still requires a single-root)

Technically, DNS encodes the authority delegation, _and_ tries to attach human-readable labels to every entity accessible by the Internet. If the goal were unique identification, MAC addresses would do just fine. No need for DNS. The whole snake nest of issues about DNS revolves around the fact that the labels themselves carry semantic load. Semantic-free labels do not generate trademark, fair-use, squatting, etc controversies - and there's quite a lot of those around us. The issue with authority delegation is not clear-cut, too, for it raises the important questions "who's the authority?" and "how authority is selected?". This is pretty much the question most wars were fought about.

So this argument is bogus IMHO...

I would say you should consider it more carefully. As is, we have an artificially contentuous structure, which cannot be fixed. There are known better methods of converting semantically loaded labels into pointers to the entities, which do not suffer from the artificially imposed limitation of seeing everyting as a strict hierarchy. Most Internet users are well-versed in use of those methods. So the question here is merely engineering, and convincing people to switch over. _Users_ have already voted with their patterns of use... how often do you see them actually typing domain names in? Address books, bookmarks, "my favorites", "Reply-To:" etc are used in most cases, as is Yahoo or Google. Your statements, in effect, confirm my position that most people do not even recognize semantic value of the domain names, considering them mere unique IDs. In other words - there are much better search engines than DNS. Remove it from the critical path, and the whole Verisign, ICANN, etc issue will go away, with little practical change in the end-user experience. --vadim

Date: Wed, 17 Sep 2003 18:39:27 -0400 (EDT) From: bdragon@...

Any solution which requires uniqueness also requires a singular ultimate authority.

Or cooperation between multiple authorities. Of course, how realistic is that? Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 785 865 5885 Lawrence and [inter]national Phone: +1 316 794 8922 Wichita _________________________________________________________________ DO NOT send mail to the following addresses : blacklist@brics.com -or- alfra@intc.net -or- curbjmp@intc.net Sending mail to spambait addresses is a great way to get blocked.

...

Any solution which requires uniqueness also requires a singular ultimate authority.

Not really. You can just take random numbers. If you have enough bits (and a good RNG) the probability of collision would be less than probability of an asteroid wiping the life on Earth in the next year.

That doesn't help in this case. You need a way to verify ownership of an identifier. I don't want anyone else to be able to claim my identifier. Perhaps we can devise a scheme where I generate a random number and morph it into a 'private key'. Then I pass it through some algorithm to generate a 'public key' which is the identifier that I use. I then use the private key to prove my ownership of the public key. Nobody else can claim my public key because they don't know the corresponding private key. In fact, you could just use an RSA public key as the identifier directly. This is likely not the best algorithm, but it's certainly an existence proof that such algorithms can be devised without difficulty. In fact, I'm going to call my patent attorney instead of sending this email. ;) DS

On Wed, 17 Sep 2003, David Schwartz wrote:

That doesn't help in this case. You need a way to verify ownership of an identifier. I don't want anyone else to be able to claim my identifier.

Perhaps we can devise a scheme where I generate a random number and morph it into a 'private key'. Then I pass it through some algorithm to generate a 'public key' which is the identifier that I use. I then use the private key to prove my ownership of the public key. Nobody else can claim my public key because they don't know the corresponding private key.

In fact, you could just use an RSA public key as the identifier directly. This is likely not the best algorithm, but it's certainly an existence proof that such algorithms can be devised without difficulty.

In fact, I'm going to call my patent attorney instead of sending this email. ;)

Heh, you mean like the nym based security that djb mentions at http://cr.yp.to/djbdns/forgery.html I've also seen several other proposals for the same thing. Most of them revolve around making a hash of the public key and using it as part of the domain name. Just so that I don't have to worry about somebody patenting any of these variations a year or more in the future, here is a public disclosure: A method for authentication where a public key is converted to a representation usable by a DNS server and used as a domain name. Conversion includes, but is not limited to, hashing, checksumming, compressing, encoding, encyphering, translating to hex, binary, octal, or other symbol system, or any other representation that may be returned by a DNS server. For the purposes of the following example the client is a device that wishes to look up a record in DNS that allows it to communicate with a server. A server is a device that communicates with clients. The conversion may be loss-less or lossy. If the conversion is loss-less then the conversion is reversed by the client in order to determine the public key. If the conversion is lossy then the complete public key is communicated to the client by the server and is compared to the lossy representation used for DNS by performing the same conversion. If the comparison fails the authentication fails. Mike. +----------------- H U R R I C A N E - E L E C T R I C -----------------+ | Mike Leber Direct Internet Connections Voice 510 580 4100 | | Hurricane Electric Web Hosting Colocation Fax 510 580 4151 | | mleber@he.net http://www.he.net | +-----------------------------------------------------------------------+

On Wed, 17 Sep 2003 bdragon@gweep.net wrote:

...

On Wed, 17 Sep 2003, [ISO-8859-1] Mathias Körber wrote:

...

...

If we take a step back, we could say that the whole Verisign incident demonstrated pretty clearly that the fundamental DNS premise of having no more than one root in the namespace is seriously wrong. This is the fallacy of "universal classification" so convincingly trashed by J.L.Borges in "The Analytical Language of John Wilkins". Sigle-root classifications simply do not work in real-world contexts.

...

... for objects which are created outside said classification and need to/ want to/should be classified in it. However, the DNS does not pretend to classify anything existing outside it in the real-world but implements a namespace with the stated goal of providing unique identification (which still requires a single-root)

Technically, DNS encodes the authority delegation, _and_ tries to attach human-readable labels to every entity accessible by the Internet.

If the goal were unique identification, MAC addresses would do just fine. No need for DNS.

MAC addresses are not without authority delegation. The IEEE is the ultimate authority in said case.

Any solution which requires uniqueness also requires a singular ultimate authority.

Even MACs aren't entirely unique. Some places used to assign MAC addresses like they assigned IP addresses and the NIC had to be reconfigured for the assigned MAC. An admin was freely able to assign a MAC to Joe Blow using a 3Com or Cisco OUI without fear of retribution. I personally have never seen any use in such a thing but obviously someone did. Justin

On Wed, 17 Sep 2003 bdragon@gweep.net wrote:

...

MAC addresses are not without authority delegation. The IEEE is the ultimate authority in said case.

Any solution which requires uniqueness also requires a singular ultimate authority.

Even MACs aren't entirely unique. Some places used to assign MAC addresses like they assigned IP addresses and the NIC had to be reconfigured for the assigned MAC. An admin was freely able to assign a MAC to Joe Blow using a 3Com or Cisco OUI without fear of retribution. I personally have never seen any use in such a thing but obviously someone did.

Justin

manufacturer assigned macs are guaranteed to be globally unique. A specific enterprise reconfiguring the mac is akin to an enterprise using RFC1918 space.

There was another manufacturer one of the really low budget cards, I forget the brand but they were shipped in a box which looked like a dunkin's munchkins box. If you bought several boxes of these, I think six in a box and the entire package was $30 you were likely to find more than 2 or 3 with the same addressing. These were 10 meg only and I can't for the life of me remember the brand. Used the tulip driver for linux if that helps refresh memories. On Thu, 18 Sep 2003, Mr. James W. Laferriere wrote:

Hello Whoever ,

On Thu, 18 Sep 2003 bdragon@gweep.net wrote:

...

...

...

MAC addresses are not without authority delegation. The IEEE is the ultimate authority in said case. Any solution which requires uniqueness also requires a singular ultimate authority. Even MACs aren't entirely unique. Some places used to assign MAC addresses like they assigned IP addresses and the NIC had to be reconfigured for the assigned MAC. An admin was freely able to assign a MAC to Joe Blow using a 3Com or Cisco OUI without fear of retribution. I

On Wed, 17 Sep 2003 bdragon@gweep.net wrote: personally have never seen any use in such a thing but obviously someone did. Justin manufacturer assigned macs are guaranteed to be globally unique. A specific enterprise reconfiguring the mac is akin to an enterprise using RFC1918 space. I have to agree with Mr. Shore here . Mac addresses are NOT unique from ALL manufacturers '.' . I do beleive that there was a a brand (maybe not USA) that the cadr came without mac-address hard assigned on the card , You HAD to , using their configuration tool assign one . JimL -- +------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | P.O. Box 854 | Give me Linux | | babydr@baby-dragons.com | Coudersport PA 16915 | only on AXP | +------------------------------------------------------------------+

* sigh * s/there/their/ s/mps/mbs/ s/:)/:}/ 8-) Richard Irving wrote:

Mr. James W. Laferriere wrote:

...

Hello Whoever , On Thu, 18 Sep 2003 bdragon@gweep.net wrote:

...

...

On Wed, 17 Sep 2003 bdragon@gweep.net wrote:

manufacturer assigned macs are guaranteed to be globally unique. A specific enterprise reconfiguring the mac is akin to an enterprise using RFC1918 space.

I have to agree with Mr. Shore here . Mac addresses are NOT unique from ALL manufacturers '.' . I do beleive that there was a a brand (maybe not USA) that the cadr came without mac-address hard assigned on the card , You HAD to , using their configuration tool assign one . JimL

There was actually a fly by nighter that had one of the earliest EISA based 100mps FD FE in the early 90's, where ALL there cards had the SAME MAC, the people issuing ranges had only assigned them the ONE...

So, they burned it on all their cards!

Really.

Obviously, you could only use one per network... :P

And, FWIW, old VAX gear had assignable MAC's....

But, other than freak cases, the original point is true.. today most MAC's are globally unique.

HSRP not withstanding.....

(To every rule, there is an exception, including this one.)

Speaking on Deep Background, the Press Secretary whispered:

On Thu, 18 Sep 2003 15:10:57 -0400 (EDT) bdragon@gweep.net wrote:

...

manufacturer assigned macs are guaranteed to be globally unique.

Theoretically. I didn't experience it personally, but I believe there was at least one fairly well known event a few years back where a manufacturer shipped cards with duplicated UAAs.

Ascend had a run of Pipeline ISDN routers where the record stuck the record stuck the record stuck [1] the MAC incrementor stuck on the production line. No one noticed for months until some poor guy had TWO on one LAN segment... [1] Apologies to Monty Python.. -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

"Dominic J. Eidson" wrote:

On Thu, 18 Sep 2003, John Kristoff wrote:

...

Fortunately, this practice rarely occurs these days (token ring / SNA shops often did this) although I'd be curious if anyone still does it.

box:~ # /sbin/lspci | grep 'Happy' 01:03.1 Ethernet controller: Sun Microsystems Computer Corp. Happy Meal (rev 01) box:~ # /sbin/ifconfig | grep 'eth' eth0 Link encap:Ethernet HWaddr DE:AD:BE:EF:00:B0 eth1 Link encap:Ethernet HWaddr DE:AD:BE:EF:00:B1 eth2 Link encap:Ethernet HWaddr DE:AD:BE:EF:00:B2 eth3 Link encap:Ethernet HWaddr DE:AD:BE:EF:00:B3

It didn't come with it's own MAC address pre-programmed...

Sun, by default, loads their manufacturer ID as the first three bytes and uses the system ID (burned into the *mumble-mumble* chip on the motherboard) in the last three. Since the sysID is unique this guarantees global uniqueness. This also means, by default, all NICs in a Sun have the same MAC. This is considered a feature. There is a knob in the EEPROM, 'local-mac-address?', that will use the MAC address(es) burned into the card rather than the sysID. However, for a NIC integrated into the motherboard, like an hme, there is no "local" MAC, just the sysID. -- Crist J. Clark crist.clark@globalstar.com Globalstar Communications (408) 933-4387

On Wed, Sep 17, 2003 at 02:50:51AM -0700, Vadim Antonov quacked:

In fact, we do have an enormously useful and popular way of doing exactly that - this is called "search engines" and "bookmarks". What is needed is an infrastructure for allocation of unique semantic-free end point identifiers (to a large extent, MAC addresses may play this role, or, say, 128-bit random numbers), a way to translate EIDs to the topologically allocated IP addresses (a kind of simplified numbers-only DNS?) and a coordinated effort to change applications and expunge domain names from protocols, databases, webpages and such, replacing URLs containing domain names with URLs containing EIDs.

Oh, you mean something like the Semantic Free Referencing project? http://nms.lcs.mit.edu/projects/sfr/ (Blatant plug for a friend's research, yes, but oh my god does it seem relevant today) -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.net/ I do not accept unsolicited commercial email. Do not spam me.

Off list, I'd like to speak with providers in the Charlotte, NC area capable of providing one or more of the following services: One or two racks of colo and multi-homed internet connectivity Wholesale Cable Internet Wholesale DSL Point to point T1 lines PRI Voice lines Thanx. Ray. ray@oneunified.net 704 576 5101 -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be clean.