News of ISC Developing BIND Patch

http://apnews.excite.com/article/20030916/D7TJOF3G0.html

my favorite:
   VeriSign spokesman Brian O'Shaughnessy said Tuesday that individual
   service providers were free to configure their systems so customers
   would bypass Site Finder. But he questioned whether releasing a patch
   to do so would violate Internet standards.
                  ^^^^^^^^^^^^^^^^^^^^^^^^^^

What else is there to say? Any bets that Verisign tries to accuse ISC
of being a terrorist organization once the patch comes out? At the least
a spurious lawsuit seems certain.

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.

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.

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.

http://www.root-servers.org/

allan

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.

         ---Mike

dns techs in the industry. nothing that's happening with dot-com or dot-net

agreed.

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.

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.....

seems to be missing here........

abq-www-02# dig @f.root-servers.net arpa. ns +nocomment
; *** Invalid option: nocomment

; <<>> DiG 8.3 <<>> @f.root-servers.net arpa. ns
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
;; flags: qr aa rd; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 12
;; QUERY SECTION:
;; arpa, type = NS, class = IN

;; ANSWER SECTION:
arpa. 6D IN NS K.ROOT-SERVERS.NET.
arpa. 6D IN NS L.ROOT-SERVERS.NET.
arpa. 6D IN NS M.ROOT-SERVERS.NET.
arpa. 6D IN NS A.ROOT-SERVERS.NET.
arpa. 6D IN NS B.ROOT-SERVERS.NET.
arpa. 6D IN NS C.ROOT-SERVERS.NET.
arpa. 6D IN NS D.ROOT-SERVERS.NET.
arpa. 6D IN NS E.ROOT-SERVERS.NET.
arpa. 6D IN NS F.ROOT-SERVERS.NET.
arpa. 6D IN NS G.ROOT-SERVERS.NET.
arpa. 6D IN NS H.ROOT-SERVERS.NET.
arpa. 6D IN NS I.ROOT-SERVERS.NET.

;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET. 5w6d16h IN A 198.41.0.4
B.ROOT-SERVERS.NET. 5w6d16h IN A 128.9.0.107
C.ROOT-SERVERS.NET. 5w6d16h IN A 192.33.4.12
D.ROOT-SERVERS.NET. 5w6d16h IN A 128.8.10.90
E.ROOT-SERVERS.NET. 5w6d16h IN A 192.203.230.10
F.ROOT-SERVERS.NET. 5w6d16h IN A 192.5.5.241
G.ROOT-SERVERS.NET. 5w6d16h IN A 192.112.36.4
H.ROOT-SERVERS.NET. 5w6d16h IN A 128.63.2.53
I.ROOT-SERVERS.NET. 5w6d16h IN A 192.36.148.17
K.ROOT-SERVERS.NET. 5w6d16h IN A 193.0.14.129
L.ROOT-SERVERS.NET. 5w6d16h IN A 198.32.64.12
M.ROOT-SERVERS.NET. 5w6d16h IN A 202.12.27.33

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....

We need a peremptive strike to create our own RFC that says not to do this.

Ray Wong wrote:

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.

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

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

> 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.

Correct.

Unfortunately, the progress on that front didn't continue after
the DNS wars started.

Progress has continued albeit so slowly as to resemble stagnation.

Daniel

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

Thank you. Unfortunately, the obvious didn't come anywhere near the
top of my query (and I intuitively tried www.root-servers.net).

Allan Liska wrote:

... 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)

So this argument is bogus IMHO...

matjes

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

> 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

I see what it says is pretty much similar to what I was writing on the
matter of DNS some years ago :slight_smile: Should be on record somewhere in NANOG
archives.

I do not claim that I'm the author of this idea, though. Unfortunately, I
cannot remember how I acquired it :frowning:

Thank you for the pointer!

--vadim