David and all,
Interesting Dissertation in response to Ed's correctly enunciated original
response to you on this thread. Let us break this down a bit for purposes
of clarity and delineation so as to to purposefully confuse the readers...
(Follow below your remaining remarks)
David R. Conrad wrote:
> Ed,
>
> > No, it is not -- I can easily "sand-box" you and make you use my "reporting
> > point" and, you may never know what bit you. It is a common misconception
> > to suppose that because the namespace is coherent to you it will be also
> > coherent to me or, that it cannot be made decoherent by an attacker or simple
> > bad luck, net congestion, etc.
>
> I'm sure you have a point here, but it is unclear to me exactly what it
> might be.
Ah, than Ed was correct judging from this comment. You seem to be under
a misunderstanding after all. This explains much indeed. But let's digress
further... (More below)
>
>
> The DNS is a distributed database that insures a coherent view of the
> its contents via a hierarchical singly rooted system -- nothing more or
> less. Of course you can come up with weirdness if you go and break it
> via various attacks -- the same can be said with any infrastructure (if
> I cut your power cord, you don't get electricity).
Proposing an enhancement to a hierarchical structure or extending it out
a bit is hardly breaking that structure at all. In fact that is why we have
integration
techniques in database and software design as well as protocols. So what
Ed is suggesting is simply an extension or potentially a enhancement, nothing
more or less, to the current DNS hierarchical structure. In fact this has
already been done to some extent, as you well know.
>
>
> > The solution is semantic addressing.
>
> Oh, sorry. I thought we were talking about the DNS, not some mythical
> directory service vaporware.
Oh my, a disingenuous personal attacking sort of comment this seems to be.
How gosh! And of course how unnecessary....
>
>
> However, with respect to semantic addressing, for some reason, in the
> real world, people find putting a globally unique identifier on their
> business cards and on billboards useful. In particular, an identifier
> that doesn't bring up their competitors when a customer tries to resolve
> that identifier and require human input to terminate the resolution
> tends to be preferred.
Certainly it does David. And as Ed suggest the extension or enhancement
only strengthens that capability, not detract from it. Again a fact that of course
you are already very well aware of.
>
>
> >> To avoid naming conflicts, you must either return to a
> >> single root or have some external coordination mechanism (thereby moving
> >> the coherency requirement to an external agent).
> > There are *several* options -- the
> > above being but two of the ones you do not mention: (i) cryptography and,
> > (ii) a virtuous cycle based on maximizing profits by decreasing friction.
>
> Both (i) and (ii) can, of course, be both cateogorized as "external
> coordination mechanisms".
Indeed they can. As can the extension of the hierarchical structure of the
DNS which Ed has suggested as well. But also not necessarily so. There
can and is intragal or integrated structures already in existence as well.
Again something that you already know as well David.
>
>
> Again, (and I'd recommend reviewing RFCs 1034 and 1035 if you don't
> believe me), the DNS requires a _single_ root.
This is inherently not accurate as has already been demonstrated. Again
a fact that you already know as well. But none the less these "RFC's" are
Requests for Comment, not necessarily standards. Hence are not etched in
stone as it were. Nor were "RFC's" ever intended to be. Again another
fact that you already know as well David....
> If you do not have a
> single root, then you must use some sort of external coordination
> mechanism to emulate the single root where external in this context
> implies some sort of policy derived system to either adjudicate
> conflicts or disallow conflicts from occuring. Given such a policy
> derived system would be external to the DNS protocol itself, you would
> be opening up vast avenues of breakage.
Nice premise but does not necessarily lead to you conclusion. Again
we already know that you conclusion here is basically invalid and proven
to be unsupported...
>
>
> Exactly why you would want such potentials for breakage is unclear to
> me, particularly given it would take far less external coordination to
> agree to a common "superuser".
The problem with a "Single Threaded" or "superuser" as you put it here
is that it lacks flexibility and detracts for commercial and non-commercial
open competition and is ripe for capture by "Unfriendly Elements", of which
we are now beginning to see yet again with the ICANN. Not a good competition
based model...
>
>
> > This is another common misconception -- that cryptography provides security.
>
> It may be your misconception, but it most assuredly is not mine.
This comment differs greatly from what you stated above. So, I can
only conclude that you are even more confused than you thought you were,
based of course on your own comments of course...
>
>
> > At the end, DNSSEC will just be another "good try" but not "good enough" as it
> > ignores what it wants to assert -- security.
>
> "It" doesn't want to assert security. It does assert a hierarchy of
> trust from which some level of security can be derived, depending on how
> much you trust each node of that hierarchy you would traverse. With
> DNSSEC is is possible to have a greater level of assurance that a
> particular label is actually incorporated within a zone by the
> individual(s) who possess the zone's key. In the real world as opposed
> to theoretical discussions, this is seen to be of value.
And the same would apply and does in fact apply in extending our
that hierarchical structure of the DNS as Ed suggests.
>
>
> Regards,
> -drc
>
>
Regards,
--
Jeffrey A. Williams
CEO/DIR. Internet Network Eng/SR. Java/CORBA Development Eng.
Information Network Eng. Group. INEG. INC.
E-Mail [EMAIL PROTECTED]
Contact Number: 972-447-1894
Address: 5 East Kirkwood Blvd. Grapevine Texas 75208
