On Tue, 1 Aug 1995, Kent W. England wrote:
At 8:43 AM 7/29/95, Michael Dillon wrote:
What about hijacking the root name servers? Here's the scenario.....
...
Could people be plotting this even as we speak? Is it a good idea? Would it solve the namespace problems we currently have?
Michael Dillon
I want bork.bork.bork and die.die.die top level domains, please or I will hijack your hijack. Thank you.
The whole point of hijacking the root domain servers is that it turns DNS from a centralised system into a more distributed system where cooperation is essential. I could be wrong because I don't fully understand BIND internals here, but if anyone wanted to copy the root domain and add new toplevel domains like .bork or .die on their own networks, they could just do it. Any references to .bork or .die would be correctly resolved and any other references would be delegated to the same .com and .org and .net servers that are currently in use. If other networks felt there was value in accessing the .bork and .die domains they would do similarily referencing your nameserver to resolve such references. Is there any technical reason this wouldn't work? Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com
I could be wrong because I don't fully understand BIND internals here, but if anyone wanted to copy the root domain and add new toplevel domains like .bork or .die on their own networks, they could just do it. Any references to .bork or .die would be correctly resolved and any other references would be delegated to the same .com and .org and .net servers that are currently in use. If other networks felt there was value in accessing the .bork and .die domains they would do similarily referencing your nameserver to resolve such references.
Is there any technical reason this wouldn't work?
Sure. Someone physically DENY'ing you the ability to transfer zone info or domain lookups. Of course, this is localized protection, so you could still hijack till your heart's content on all upper level servers. - paul _______________________________________________________________________________ Paul Ferguson US Sprint tel: 703.689.6828 Managed Network Engineering internet: paul@hawk.sprintmrn.com Reston, Virginia USA http://www.sprintmrn.com
On Tue, 1 Aug 1995, Paul Ferguson wrote:
I could be wrong because I don't fully understand BIND internals here, but if anyone wanted to copy the root domain and add new toplevel domains like .bork or .die on their own networks, they could just do it. Any references to .bork or .die would be correctly resolved and any other references would be delegated to the same .com and .org and .net servers that are currently in use. If other networks felt there was value in accessing the .bork and .die domains they would do similarily referencing your nameserver to resolve such references.
Is there any technical reason this wouldn't work?
Sure. Someone physically DENY'ing you the ability to transfer zone info or domain lookups. Of course, this is localized protection, so you could still hijack till your heart's content on all upper level servers.
DENY'ing is more like a social reason why it won't work. However if there was value to other hosts in accepting your new domain name *SERVICE* then it would be used. Without widespread acceptance/cooperation it wouldn't work. I think this would achieve a number of things. It would let the Internic off the hook by providing many alternative namespaces, it would reduce the value of .com domains by making them less exclusive, it would thoroughly confuse the entire issue of "shortage of good names" and having the "right domain name". Which is better, cars.com or com.cars or car.sales or sales.cars or ford.dealer or ford.used or ford.new or drinks.ford? Obviously any company with such a strong trademark that they can prohibit the use in any context (like Exxon) can still prevail within the jurisdiction that a give nameserver operates, but most names do not have such an exclusive control over use and depend heavily on context. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com
participants (2)
-
Michael Dillon
-
paul@hawksbill.sprintmrn.com