This is not a problem with Namecoin, right? Traditional DNS has the exact same problem, namely general intolerance to failure.
Namecoin is essentially a key-value store. A .bit domain is a key under Namecoin's d/ namespace, and the value is some JSON data describing the domain, per this spec: http://dot-bit.org/Namespace:Domain_names_v2.0
Edit: Actually, to further clarify, Namecoin itself doesn't know/care about the semantics of what data is stored for a domain. The data is interpreted by applications that act as application layer bridges to other resolver protocols. Check out nmcontrol and NamecoinToBind for examples.
It seems like a pretty fundamental problem...Namecoin uses a system that enforces consistency, so you can't make it depend on a system that doesn't enforce consistency without breaking it.
If enough clients saw the transaction I don't see what the problem is. The domain owner would also be running a client after all, and they'd have the private keys to prove that they own the transaction.
Once it makes it into the longest running blockchain with enough confirmations there's no reason to check the old DNS again (I don't think, unless I'm missing something). The next time the old DNS will need to be queried is when the domain expires. Maybe, by that point, no one will be relying on the previous system anymore. ;)
So now one population of namecoin nodes sees the hacked entry, accepts the transaction, and puts it in a block. Another population doesn't see it and rejects the transaction. The blockchain forks.
You might get by if the hacked DNS is seen by a minority of users. Then the chain without the disputed transaction will win anyway and all is well.
But suppose most DNS nodes have the hacked entry? Then the minority will refuse to accept the majority chain, since they can't validate it, and the fork persists. If that seems implausible, imagine a hacker watching for a new DNS namecoin entry, and making his hacked DNS server immediately remove it.
A few things would help a bit:
- Only accept namecoin registrations when the matching DNS entry is old enough to have propagated everywhere
- If the longest blockchain has old blocks that don't validate against DNS, keep checking. Hopefully the errant DNS servers will get fixed soon and that'll resolve the fork.
- If the disputed block gets old enough, just go ahead and accept it if it's in the longest chain. You're just trying to minimize squatting, and letting some skilled squatters through isn't the worst disaster.
But it's still kind of a mess because namecoin isn't just a naming system, it's also a currency. For as long as the fork persists, people can doublespend their coins. It'll be resolved but in the meantime maybe a merchant has shipped goods. You're essentially creating money that depends on the integrity of DNS for security.
This proposal involved hard-forking Namecoin, and has a lot of inherent issues with it. Also note that this proposal is by "some guy on a Namecoin forum", and not anything official.
And note that Bitcoin was a proposal by "some guy with a fake name."
Yes, this needs to be addressed. The proposal can be kept as-is with the following modification/addition:
In order to prevent such attacks, it could be required that transactions need be confirmed across N "different networks", where "different networks" can be measured by some metric (IP2location, the first two octets of an IPv4 address, etc.). The value for N can be based as a percentage of the number of nodes running in the past 48 hours, or some other means.
Copied from here: http://dot-bit.org/forum/viewtopic.php?p=7746#p7746
The problem I see with this proposal is each client needs to check the DNS record independently to ensure a transaction is valid. What happens if the DNS server happens to be unreachable or the owner accidentally or maliciously removes the signature in a DNS record after their transaction has been included in a block?
Or maybe I'm misunderstanding things and Namecoin works differently?