Please tell me that you're being sarcastic, and that you're not *THAT* stupid. The US government has a very long track record of doing whatever it wants, regardless of legality and regardless of how it affects other countries. Here are just a few examples:

1. Changing the US' daylight savings time (which isn't even permanent; they reserved the right to change it back if they feel like it).

2. The illegal NSA wiretaps.

3. The US government refusing Freedom Of Information Act requests requesting the truth about the JFK assassination which occurred over 45 years ago.

4. The UIGEA law, the US law banning online gambling, which was ruled illegal by the WTO. The US basically said "screw you, we'll do whatever the hell we want".

5. The "agreements" between the US and EU regarding airline passenger (PNR) data. The US has never, and will never, agree to the same data protections that the EU requires on such data, but the EU has agreed to hand the data to the US anyway (thus violating EU law) because otherwise EU citizens would not be able to fly to the US.

6. Guantanamo Bay, whose sole purpose is to imprison and torture people without having to follow those pesky US laws, not to mention those pesky international laws agreed to at the Geneva conventions.

As for your comment about this being no different than the International Standards which are located in France -- how often are those original standards used to verify data? DNS servers are queried millions of times every day, and a change could result in anything from an invisible man-in-the-middle attack (because if your system gets a rogue DNS answer, it'll think it's connected to the correct site, and you won't know any different) to literally sectioning off any part of the Internet the government wants to censor. Think about it as Big Brother to the Great Firewall of China. By giving the US government complete control over the root server, you're effectively giving the US the ability to censor the Internet for the world. But hey, that's OK, because I'm sure nobody here is cynical enough to believe the US government might ever do anything unsavory or questionable.

Lastly, given the US government's undeniable lack of computer security, do we really want THEM to be the ones in charge of protecting the security of the entire Internet?

Hey Chris C "Lastly, given the US government's undeniable lack of computer security, do we really want THEM to be the ones in charge of protecting the security of the entire Internet?"

Haven't they been doing wonders already turning our banking system into a giant welfare program? Im not sure at this point what's worse. All the corporate thugs controlling the internet (as they do, arin,icann etc.... they all operate from money in toliet stalls) or our government which we could sum up their ability in one word."Amtrak" What a raging success that government ran program has been.

I say 50/50.

Currently, recursive DNS servers need to be kept up to date with the addresses of the root servers. This changes rarely, maybe once a year.

Why not allow the organisation looking after each TLD to sign their zone then distribute updated keys once a year?

Ok, greater administrative overhead and not 'correct', but China, Iran, Russia et al can rest assured that their DNS is safe from those in the US.

Perhaps I'm missing something.

Each TLD is signed separately with DNSSEC. The way you can tell that the TLD signature is valid is by looking up the key associated with it one level higher up. The same method is used to let domain owners create domains without needing to get the TLD to resign its zone file.

The question here is who signs the root zone? By necessity, the key used to sign the root is implicitly trusted by DNSSEC resolvers. That effectively gives then the ability to choose which key is authoritative for each TLD, which some people consider a problem (above their existing ability to redelegate a TLD).

I've not read all of the DNSSEC RFCs, but the way this works for HTTPS is that your system (by nature of installing the web browser) has a list of trusted root publickeys, and each key lookup is a chain of signatures which must end up being signed by one of the configured roots.

RFC 4033 similarly implies that you can store a list of "trusted root keys", i.e. a country such as China could easily add extra keys, or a company can add it's own root key for signing internal web sites instead of paying Verisign for internal systems.

As such, the article says "in the simplest case, a single root" but a non-single solution could also be possible. It depends on how keen people really are to implement DNSSEC at all.

A possibly bigger political question is what the companies who sell HTTPS certificates will make of this, given that DNNSEC may overlap or reduce some of the need for HTTPs, and the current market for HTTPS certificates makes a bunch of money. This therefore raises the question of who would get the money for all of the DNSSEC certificates if there's a single root signer.

The DoC has operated the root zone forever, and the only alternative is worse (IANA itself), so bitch about it *now* isn't likely to achieve much unless a viable alternative is mooted.

But, that has little to do with DNSSEC, other than cementing authority that's already pretty firmly held.

The solution is to distribute the public keys of the TLDs alongside the root NS hints. That _file_ can be signed (e.g., by PGP), which the OS/DNS resolver vendors (who are the ones who pick up the root hints file and distribute it to their users) can verify that it was generated and signed by somebody that they—on behalf of their users—deem trustworthy.

The benefit of this over simply signing the root zone is that it's not any more complicated than the key-distribution mechanism that'll be required for the root zone signing key anyway, and it makes the signature of the root zone irrelevant for most purposes: because the TLD signatures can be verified without referencing the root, it can be signed by the US, or IANA, or nobody at all, and it doesn't make one bit of difference. If the world has a falling-out with the DoC (or IANA), it's a matter for the world's Internet users (via the resolver distributors) to decide who the new trustworthy source of TLD keys is. They could even form a web of trust whereby each vendor picks a TLD, verifies its key in person, and distributes it to the others; no single-point root key distribution required.

Of course, the danger with this is that it would demonstrate how irrelevant IANA really is.

> You normally pay annually to have a name in .org or .com or every 2 years to have a name in

> .co.uk . With DNSSEC the domain registrar will have to provide cyrypto certification services

> along with domain registration.

Yes, I know about the cost or registering a domain name. My point if that the registrars charge maybe $5-10 per year for the domain name but often north of $100 for a SSL certificate. If the $5-10 now includes a DNSSEC key (as it should) then the need for the $100+ certificate may decrease. Which would be good news for end users although not necessarily for the certificate providers.

Fast, effective, costless solution. Of course there's no money in it for the security guys, so they push DNSSEC instead... administered by the US gov. Yeah right. How long before half the internet is Arkansased? (China, Iran, "adult" sites, non-christian-values abiding domains, gambling sites, domains featuring "inapropriate" language, anyone who doesn't spy on users -or who does but doesn't give the info to the CIA, ...)

"This is no difference than the International Standards which are located in France"

The speed of light is located in France?

Not sure I follow your logic here. Signing DNS and SSL certificates are two completely different things, and serve completely different purposes.

DNSSEC confirms that the IP address returned when you make a DNS request is the correct one.

SSL confirms that the website you reach is the real one, eg the https:\\secure.foo.com you see really does belong to Foo Corporation, and not Mr B H Hacker who's setup the site on his server and tricked your computer to go to him instead of the real one. It provides authenticity by ensuring that if you want to purchase an SSL certificate for Foo Ltd, you can prove that you really are Foo Ltd (there's quite a few checks done, especially if you're a Ltd or PLC company, hense their justification for the high prices). And finally, and perhaps most importantly, it allows you and the server your connecting to to establish a secure tunnel down which all the communications are sent, thus protecting you from anyone sniffing your connection.

What SSL doesn't do is care about what IP address the site is on. As long as you have the certificate information you can install it on any server at any address. So the two don't cross over at all, to my mind they compliment each other, improving the overall security for viewing normal websites, and improving yet futher the security of secure websites.