|
DNSSEC adoption has been slow, but is now picking up speed, thanks to organizations leading the way.
In October, 2009 the .TM registry signed with DNSSEC. In June, 2010 both .ORG and .EURid both announced the signing of their registries with DNSSEC. Before .TM a handful of other registries also signed with DNSSEC, those being .SE, .BR, .BG, .CZ and .PR. Last week there were several press announcements of the Root zone, itself now being signed. While some registries have already signed, some have announced plans to sign and others are still trying to figure out their plan.
Either way, DNSSEC is here. How can we make DNSSEC adoption quicker and easier not only for the registry but for individual name owners? How can an organization get their zone signed? How can a simple domain owner get their domain name signed? How can registrars and ISPs help their customers adopt DNSSEC?
Security-DNS.net is a “DNSSEC Made Simple” tool designed to answer all of those questions. Provided by CommunityDNS, registries, organizations, individual domain name owners can submit their domain name or zone(s) and have a signed zone or name returned complete with their key and the respective DS record which may be handed to their registry. Registrars and ISPs may also use this tool to provide support for their customers, all free of charge. AND, they do not need to be a customer of CommunityDNS to benefit from this tool.
DNSSEC has understandably raised many questions for many on how implementation may impact not only their methods of operation but capacity. The signing process, however, is very simple and available to anyone wishing to sign with DNSSEC.
Sponsored byWhoisXML API
Sponsored byIPv4.Global
Sponsored byVerisign
Sponsored byRadix
Sponsored byDNIB.com
Sponsored byVerisign
Sponsored byCSC
> ...individual domain name owners can submit their domain name or zone(s) and have a signed zone or name returned complete with their key and the respective DS…
Why do you think it is a good idea to encourage naive folks to trust third parties with their private keys? Would you think it a good idea to provide such a service for web site SSL private keys?
Carl, Thanks for your questions. If people obtain their own DS records it will ultimately be up to their respective registry to accept the newly signed record. If an owner has a DS record and the TLD is not yet signed, nothing changes. The chain-of-trust associated with DNSSEC can only been established when the registry is able to accept the DS record. When .TM was signed last October it had the capability of allowing customers real-time DS records updating. An easy, community-based tool for signing a name just didn’t exist that would allow such signings to occur. Security-DNS.net was designed to bridge that gap. The tool as designed is one that allows organizations, such as registries sign their own zones as well as registrars and ISPs to help their customers with the signing process. Enterprises and even individual registrants, who are finding value in securing the chain-of-trust allowed through DNSSEC, can sign on their own schedule, especially for the registries that allow for real-time DS record updating. This also allows registrars, who may wish to manage the process on behalf of their clients, to have an effective tool in order to accomplish their tasks without having to build out a process of their own or purchase equipment to accomplish the signing process. The other value this tool provides deals with a key that has become compromised. If compromised the registrant can easily generate a replacement key and, for registries that allow real-time DS record updating, can have a newly established chain-of-trust, minimizing the effects of a compromised key.
> If an owner has a DS record and the TLD is not yet signed, nothing changes. The chain-of-trust associated with DNSSEC can only been established when the registry is able to accept the DS record.
See dlv.isc.org. Our DS records have been published there since July 2008.
> An easy, community-based tool for signing a name just didn’t exist that would allow such signings to occur.
I am not sure what your definition of “community based” is, but apparently dnssec-signzone from the bind package from isc.org does not qualify?
Owners need to setup proper private key hygiene for dnssec private keys, just like for the private keys associated with SSL certificates. Currently, organizations that run SSL enabled web servers have procedures for generating key pairs and all the other overhead associated with obtaining and installing SSL certificates, including managing the security of the private keys associated with those certificates. Those procedures generally use tools that ultimately depend on “openssl x509 ...” commands or their equivalent for their platform.
The equivalent procedures for dnssec keys depend on dnssec-signzone or some equivalent, and are much simpler than the corresponding SSL certificate procedures.
I don’t think that encouraging naive folks to trust third parties with their private keys is a good idea.
I have read the dlv.isc.org pages several times. What has me worried here is the fact that the somewhat skimpy description there is considerably more information on how the keys get into the 'temporary' DLV system than we have yet seen for what is meant to be the permanent infrastructure. Key hygiene is important, but that does not mean that a third party cannot do a better or a more secure job than your in house net-admin. I would hope and expect to be able to outsource that type of management to a trusted third party. That is not naive, it is responsible risk control. If I cannot afford to deploy decent procedures myself I outsource that to other parties who can. If DNSSEC is only going to be used for the minimal security purpose of defeating Kaminsky attacks then the key hygiene issues are irrelevant in any case. But the fact is of course that people will try to use it for much more. The real issue as far as I am concerned is not how I protect my key, it is how the people I am trying to connect to protect their key. It is like in accounting, you make sure you have an off-site copy of your accounts receivable file as you will lose money otherwise. Accounts payable is not as much of a concern as people will tell you if you owe them money.
> Key hygiene is important, but that does not mean that a third party cannot do a better or a more secure job than your in house net-admin.
You could hire a third party to generate and keep control of your keys, as long as you have some sort of contract where they are on the hook for security failures.
> If I cannot afford to deploy decent procedures myself I outsource that to other parties who can.
Would you expect to be able to outsource the security of your private keys for free? http://security-dns.net/ includes “and are made available to ISPs, Registrars, Commercial and Private entities at no charge”. It seems to me that only a naive person would fall for that. As I read it, the terms at http://security-dns.net/terms.html give you essentially no recourse if they leak your private key.
In principle you could outsource your key management to a third party. But outsourcing it to a free service with such terms is naive at best.
> it is how the people I am trying to connect to protect their key.
If amazon.com don’t protect their SSL private keys, then other folks could pretend to be http://www.amazon.com. If they don’t protect their dnssec private keys, then other folks could give signed dns answers for A record queries for amazon.com that would be accepted. In either case, amazon needs to protect their private keys, and I think that means not trusting free web sites to handle those keys for them.