Not really, as the load on the root and tld servers is lessened by caching the information (for a ttl). So if you do a query for www.bar.com to a root server, you are getting a referral to the servers authoritative for.com.
I thought, the root servers themselves are authoritative for their entire toplevel domain, updating their own data from the real single master "often"...
You would cache this information, so if you then want to go to www.foo.com, you will reuse this information and thus cannot go to the other.com server.
So, I would automatically ask the server authoritative for bar.com about foo.com? Does not sound plausible -- either you are a guru or you are wrong:-)
DNS is embedded in so many machines and is already such a complex standard, that it is impossible to change something so fundamental and have it work.
Unlike DNSSEC, my plan only requires modifications to the root-servers' software, which, I'm sure, is already heavily modified and customized. And it does not have to happen in one instant either -- those servers can be updated gradually.
It exploits a human/administrative problem -- the user pressing "Continue" when alerted to the certificate mismatch. Maybe, the applications should not even offer that option.
Encrypting ARP will not solve that -- there can be other methods for "man-in-the-middle" attacks.
Plus whatever method you chose for ARP-encryption, it will, likely, suffer from the same weakness of having to allow to "continue" in case of misconfiguration (or an attack masquarading as such).
When campuses use SSL protected systems for grades it is just asking for trouble. [...] Basicly ARP needs to get secure
What's wrong with using encryption at higher levels? Like, indeed, SSL?
True, browsers and other software store passwords in files, which are usually accessed unencrypted (SMB, vanilla NFS), but these file are usually encrypted these days -- decrypted only by the software itself.
Except all the.com servers simply replicate from the.com master, which is run by VeriSign.
And "under my plan", they'll replicate from several servers -- what's the big deal?
AFAIK, no one has figured out how to have multiple registries for a single domain.
Well, I'm offering a way -- a simple hash of the domain name requested. Such as summing up all letters' ASCII values and % the result by the number of contenders. Only the root-servers' software needs to be modified for this.
True, but objectively comparing the competitors would become possible. Currently Verisign can respond to any criticism with: "Well, nobody can do it any better."
Nobody -- including Verisign themselves -- knows, whether this is true or not. With my method objective metrics can collected and minimum standards imposed.
As for changing, my simple formula will force automatic reshuffle of all domains any time another competitor enters the fray.
It currently works on the hierarchical basis, right? So all.com must be under the same "roof".
With little effort, the system can be modified to ask a different set of "root" servers based on some simple formula on the domain-name. Like, sum up all letters of the name and % by the number of competitors.
Then we'll be able to measure the efficiency of each contender -- number of failures, average response time, &c. and compare them.
Is their insistence to include everything (and the kitchen sink) into their tarballs. And that includes Berkeley DB, stlport, jpeg, png, expat, freetype, zlib, sablotron, etc.
It truly is insane... I'm grateful, Sun's license does not allow them to bundle in their own Java in too...
Was not there a bunch of articles and editorials in 2001-2002 describing, how easy it is to obtain technical documents and blueprints for various public infrastructure objects and private buildings? Brooklyn Bridge, Hoover Dam?
That the government is trying to stem this information flow through legal means at its disposal is, actually, somewhat reassuring. Whether the actions are effective is unclear, of course. Nor is it clear, whether our terrorism-free 3.5 years after 2001 are thanks to, in spite of, or unrelated to the government's actions.
clearly you guys are spending too much time coding and not enough thinking
No disagreement here -- that was my point, in fact.
two thousand floating points ain't a giant string, unless you are programming an 8086 in Elbonia.
Just tested simply sprintf-ing the same double 2000 times into the same text buffer on a PII-Xeon @450MHz with 2Mb of L2-cache, the whole program and the puny buffer are entirely in cache (which is not the case in real-life). 5-16 milliseconds (of user time, ignoring the sys-time)... The PII is not much slower, than the Sparcs we are using. Even if the latest and greatest CPUs are 10 times faster (which they aren't), why waste their power on chewing XML tags?
Converting two thousand numbers to text should take 50 microseconds at the most.
Now add the time to parse it on the other end, and consider, that the whole point of passing it is to have some computations happen. And the computations themselves happen in about 200 milliseconds...
Now realize that size of the XML-file is 3-4 times bigger than it needs to be -- but the network packets are still 1500 bytes and with XML we need 5 or 6 (at best) instead of 2. Bandwidth is cheap, but latency is not...
Now throw in the loss of precision from the double-text-double conversion(s) and climb up the wall next to me...
Using XML in such scenarios is like overnighting papers from one end of the office floor to the other. Defending this practice is like saying, that FedEx is really fast and efficient everywhere except in Elbonia...
It drives me up the wall, that my employer is using XML to let parts of their own application communicate with other parts. DTDs are not used and all parts still need to be modified/recompiled whenever one of them changes. Same people maintain both ends of the communication.
Theirs is, in reality, a proprietory format, but to stay buzz-word compliant they use XML, which hurts performance -- sometimes dearly...
For example, to pass a couple of thousands of floating-point numbers from front end to a computation engine, each is converted to text string with something like <Parameter> around it. The giant strings (memory is cheap, right?) are kept in memory until the whole collection is ready to be sent out... The engine then parses the arriving XML and fills out the array of doubles for processing.
It really is disgusting, especially since freely available alternatives exist... For instance, PVM solved the problem of efficiently passing datasets between computers a decade ago, but nooo, we only studied XML in college -- and it is, like, really cool, dude...
They also use steel penetrator cores, and would certainly make swiss cheese out of one of these concrete huts.
There are different bullets. The ones you describe are, probably, more expensive than others.
In Afghanistan, Soviet Army was filing off sides of the bullets to make them unstable. They were still flying straight because of the rotation, but the moment they hit anything, they'd go "beserk" tearing things apart.
It was, I'm told, to destroy the clay walls, which were too strong for regular bullets, but too soft for artillery (the pieces would fly through without exploding). But then they discovered, that these bullets do a lot more damage to living things too...
How available are rounds for the AK-47? How powerful are the rounds compared to a.223? A.308? I've seen what a.308 can do.
Hey, it was high school. We only got to shoot these babies once. 7 shots per pupil at paper targets 50m away -- under very strong supervision.
I'm sure that (standard).22 ammo couldn't go through these concrete huts
Really? I did not think, these huts are strong at all. Wind/water protection, that's all I'd expect...
If regular steel Humvees don't cut it in Iraq, requiring armor plates, I doubt this concrete will do. And the hut is even easier to shoot at, than a Humvee, which is a moving vehicle.
I not only know, what 'Kalashnikov' means, I was the fastest in my high-school class to disassemble the weapon and put it back together with my eyes closed. (With open eyes another guy won.)
So which was it?
I used the name because it is the weapon of choice of most of the armed forces opposing regular militaries world wide.
Kalashnikov's design was brilliant in its simplicity -- although 'the real thing' is expensive, a crude, but deadly and efficient imitation can be made in a village smith shop.
a defendable base with concrete walls. Portable bunker.
I doubt these walls will be able to withstand even a Kalashnikov bullet, much less an RPG...
Eventually -- maybe. But for now it is unlikely to be usable as a bunker, even if other military applications are possible -- the walls ought to be stronger than a tent's, for example.
Slashdot Mirror
Unlike DNSSEC, my plan only requires modifications to the root-servers' software, which, I'm sure, is already heavily modified and customized. And it does not have to happen in one instant either -- those servers can be updated gradually.
Encrypting ARP will not solve that -- there can be other methods for "man-in-the-middle" attacks.
Plus whatever method you chose for ARP-encryption, it will, likely, suffer from the same weakness of having to allow to "continue" in case of misconfiguration (or an attack masquarading as such).
What's wrong with using encryption at higher levels? Like, indeed, SSL?
True, browsers and other software store passwords in files, which are usually accessed unencrypted (SMB, vanilla NFS), but these file are usually encrypted these days -- decrypted only by the software itself.
Why encrypt ARP, again?
And "under my plan", they'll replicate from several servers -- what's the big deal?
Well, I'm offering a way -- a simple hash of the domain name requested. Such as summing up all letters' ASCII values and % the result by the number of contenders. Only the root-servers' software needs to be modified for this.
Nobody -- including Verisign themselves -- knows, whether this is true or not. With my method objective metrics can collected and minimum standards imposed.
As for changing, my simple formula will force automatic reshuffle of all domains any time another competitor enters the fray.
With little effort, the system can be modified to ask a different set of "root" servers based on some simple formula on the domain-name. Like, sum up all letters of the name and % by the number of competitors.
Then we'll be able to measure the efficiency of each contender -- number of failures, average response time, &c. and compare them.
Or am I totally wrong? Any DNS gurus here?
Remember, Michael Moore is filming the elections.
It truly is insane... I'm grateful, Sun's license does not allow them to bundle in their own Java in too...
Heck, until any other word-processor does it.
Talk about provocative titles...
I was talking about USA -- that is, what American government should worry about first. As all other governments do.
Or FreeBSD -- the killer OS?.. Good for Apple.
Was not there a bunch of articles and editorials in 2001-2002 describing, how easy it is to obtain technical documents and blueprints for various public infrastructure objects and private buildings? Brooklyn Bridge, Hoover Dam?
That the government is trying to stem this information flow through legal means at its disposal is, actually, somewhat reassuring. Whether the actions are effective is unclear, of course. Nor is it clear, whether our terrorism-free 3.5 years after 2001 are thanks to, in spite of, or unrelated to the government's actions.
You can now return to your regular Bush-bashing.
Does anybody?.. I guess, not...
No disagreement here -- that was my point, in fact.
Just tested simply sprintf-ing the same double 2000 times into the same text buffer on a PII-Xeon @450MHz with 2Mb of L2-cache, the whole program and the puny buffer are entirely in cache (which is not the case in real-life). 5-16 milliseconds (of user time, ignoring the sys-time)... The PII is not much slower, than the Sparcs we are using. Even if the latest and greatest CPUs are 10 times faster (which they aren't), why waste their power on chewing XML tags?
Now add the time to parse it on the other end, and consider, that the whole point of passing it is to have some computations happen. And the computations themselves happen in about 200 milliseconds...
Now realize that size of the XML-file is 3-4 times bigger than it needs to be -- but the network packets are still 1500 bytes and with XML we need 5 or 6 (at best) instead of 2. Bandwidth is cheap, but latency is not...
Now throw in the loss of precision from the double-text-double conversion(s) and climb up the wall next to me...
Using XML in such scenarios is like overnighting papers from one end of the office floor to the other. Defending this practice is like saying, that FedEx is really fast and efficient everywhere except in Elbonia...
Theirs is, in reality, a proprietory format, but to stay buzz-word compliant they use XML, which hurts performance -- sometimes dearly...
For example, to pass a couple of thousands of floating-point numbers from front end to a computation engine, each is converted to text string with something like <Parameter> around it. The giant strings (memory is cheap, right?) are kept in memory until the whole collection is ready to be sent out... The engine then parses the arriving XML and fills out the array of doubles for processing.
It really is disgusting, especially since freely available alternatives exist... For instance, PVM solved the problem of efficiently passing datasets between computers a decade ago, but nooo, we only studied XML in college -- and it is, like, really cool, dude...
... was convincing humans, he does not exist.
env LANG=C date -r 1111111111
Thu Mar 17 20:58:31 EST 2005
There are different bullets. The ones you describe are, probably, more expensive than others.
In Afghanistan, Soviet Army was filing off sides of the bullets to make them unstable. They were still flying straight because of the rotation, but the moment they hit anything, they'd go "beserk" tearing things apart.
It was, I'm told, to destroy the clay walls, which were too strong for regular bullets, but too soft for artillery (the pieces would fly through without exploding). But then they discovered, that these bullets do a lot more damage to living things too...
If regular steel Humvees don't cut it in Iraq, requiring armor plates, I doubt this concrete will do. And the hut is even easier to shoot at, than a Humvee, which is a moving vehicle.
Kalashnikov's design was brilliant in its simplicity -- although 'the real thing' is expensive, a crude, but deadly and efficient imitation can be made in a village smith shop.
Eventually -- maybe. But for now it is unlikely to be usable as a bunker, even if other military applications are possible -- the walls ought to be stronger than a tent's, for example.
From "SpamGuard" to RDF/RSS syndicating to "message boards" there are bugs and no place to complain about them...
Or does one need to re-write her/his software to use their own?
Funny you should leave Village Voice out of your comparison. GNAA would be a major source of revenue for them.