On 12/06/2010 09:06 AM, Ray Dillinger wrote: > On Sun, 2010-12-05 at 21:51 -0800, David Barrett wrote: >> Agreed on it not going anywhere anytime soon. I think they haven't been >> clear on what problem they're trying to solve. If it's to prevent >> government seizures of the domain, I'd suggest that be built into the >> existing DNS infrastructure in a backwards-compatible fashion. Ideally >> this would be part of DNSSec (though I don't think it is) as something like: >> >> 1) When the domain is registered (and renewed), record the new owner's >> public key in a big TXT record. >> >> 2) When the domain's DNS record is changed in any way, sign it with that >> public key. (This means only the owner can actually update the DNS record.) >> >> 3) On the client (or recursive DNS server) side, cache a domain's public >> key (if available) until its registration expires. (The "TTL" for the >> key is independent from the TTL of the record itself.) > > I'm not sure here - is the domain's public key distinct from the owner's > public key in this context? 'Cause if they are the same then the > recursive DNS nodes (and clients) can evaluate the validity of order to > change the DNS record. If they're not the same, then where does the > domain's private key live and how does the system deal with compromised > keys?
There is only one key, owned by the domain owner (not the registrar). It'd work like this: 1) I register domain supersecure.com, which has never been used before. 2) When registering it with Register.com, I choose the "Securely register this domain" option, and upload my public key, a DNS record description, and a signed hash of that record. 3) Register.com publishes the record for the first time, with my public key in a TXT record, and a signed hash of the record in another. 4) A DNS client (or intermediate server) receives a request to resolve supersecure.com for the first time. It has no prior cache, so it accepts the new value without question. 5) The domain's TTL expires, and the DNS client receives a second request. It redownloads the latest version of the record, validates the hash, and continues. ----------- ICANN seizes the domain ------------------ 6) Everything continues to function until the TTL expires 7) The domain's TTL expires, and the DNS client receives a third request. It redownloads the latest version of the record, but finds the signature fails (the hash doesn't match, or is improperly signed). It refuses the updated record and continues hosting the old record indefinitely (up until the expiration of the domain itself, at which time it reverts back to ICANN control). ------------- Domain owner resolves issue with ICANN ------- 8) Domain owner pushes an updated version of the DNS record. 9) DNS clients keep retrying (using the same TTL) throughout the temporary seizure, and eventually find that the new record has a valid signature. Obviously this has a lot of problems. If you lose the key to the domain, you're totally screwed. If a DNS client hadn't ever attempted to resolve your domain prior to ICANN seizing it, it'll go to them. Etc. But it gives your domain limited, temporary protection from seizure, for those people who already use you. For example, if Facebook used this, every DNS cache in the world is already populated. If your company used it, all your customers and users would continue functioning, for a while, giving you breathing room to figure out a long term solution. But ultimately, ICANN seizing the domain eventually is not a bug, it's a feature -- it's a core requirement of any centralized authority that they have central authority. This is one way to weaken that authority without taking it away entirely. Furthermore, any P2P-DNS (DDNS) system would have the same problem if it still has a central authority. Indeed, the problem has absolutely nothing to do with technology and everything to do with who you trust to resolve names to values. If that trusted person changes the mapping, then according to that design, that's a good thing. -david _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
