DNSSEC, which stands for DNS Security Extensions, is a method by which DNS servers can verify that DNS data is coming from the correct place, and that the response is unadulterated. In this article we will discuss what DNSSEC can and cannot do, and then show a simple ISC Bind 9.3.x configuration example.
DNSSEC is a public/private key system. This means that the owner of a DNS zone has a private key and a public key. Using the private key to digitally sign a zone will allow anyone with the zone's public key to verify that the data is authentic. As with all public key crypto systems, the method by which the entire world obtains your public key is a problem. If an attacker can intercept the transmission of your public key, the entire zone is compromised, so sending keys via email or other Internet vehicles probably isn't a good idea.
The proposed solution to the basic key management problem is to have Network Solutions sign everyone's public key. For example; myname.com will create a key, sign it, and then send it to Network Solutions for signing. DNS servers around the world who have Network Solutions' key are now able to reject DNS records about myname.com that aren't accompanied by the appropriate signatures.
This is the proposed method for global DNSSEC. It hasn't happened. There is no Network Solutions key that everyone knows, and Network Solutions has no mechanism to gather *.com keys. The highest level domain, '.' (dot), also needs to be under some administrative control. IANA or ICANN can hold this key, and sign all TLD's (.com, .org, etc), but the political mess this would create puts the implementation a long ways off. Whether the U.S. holds the key to the entire Internet or not, someone must before DNSSEC can work globally. Until this is in place, DNSSEC cannot protect anything outside your administrative control or access; meaning you have to manually distribute keys.
Read this full article at Enterprise Networking Planet
Powered by AkoComment! |
