Stay networked. Get informed. Broadcast your projects.

DNSSEC

DNSSEC

During the last week of Advanced Security II of IGCBP a very interesting discussing regarding DNSSEC and its implementation was carried on.

I must confess that from my technical background the need of DNSSEC was clear and unquestionable. But, after reading other point of views I understand that other aspects that must be taken into account.

The DNS protocol can be exploit in several ways, mainly by attackers trying to redirect users to other sites that is not the expected one.

DNSSEC is a security extension that can protect users from attacks where DNS response are altered in the path from server to the client.

The fact that it is not the solution for all already know threats and it is somehow not very well understood might be delaying its implementation.

Some of the points I would like to discuss

DNSSEC is not a PKI.

DNSSEC is basically a private/public key schema for signing and authenticating information.
There is no certificate neither Certification Authorities, certification paths, expiration date, etc.

A DNS zone administrator generates a pair of keys (using a variety of crypto algorithms). Then keeps the private key securely stored and distributes the public one.

With the private key, he/she signs information of a give domain name zone. And DNS resolvers will verify the authenticity of signature using the public key associated with the give domain name and retrieved via DNS queries.

The public key is distributed via domain name administration systems available from Registrars. With such systems, the users can upload the public key associated with a domain, which will them be provided to anyone via DNS queries.

DNSSEC implementation can impact things

One of the points discussed is the impact of DNSSEC implementation on things that are working “nicely”, as the normal DNS infrastructure.

And the DNSSEC implementation can impact things and, in certain situations, leave domain names “inaccessible”

As mentioned before, the DNS server administrator will have a private key in his/her control. This key will be used to sign the information of a give domain name zone. And those signatures will have an expiration date (the key does not expire, but signatures does).
If by mistake or by forgetting it, the signature of records of a given domain name expires, those information will be “invalid” for any DNS resolver sending queries with DNSSEC enabled option.

But, from my perspective, this can be addressed in a very simple way.
Currently, DNS administrators already have several and important “duties” to maintain a DNS server and domain name zones. Signature and keys management will be an additional one.

And I agree that knowledge and training is extremely important matter for anyone implementing DNSSEC (and any new and important feature or service).

DNSSEC is important

And to wrap up this writing I would try to justify my first comments about how “logical” for me was the need of DNSSEC from a very technical perspective.

DNSSEC is not the solution of all problems, this is clear.
But, it does solve a very “risky” one: to attackers to impersonificate DNS answers redirecting users without them even noticing it.

If I am a domain name administrator or the IT manager of a company which depends on the Internet for its business I would seriously think about implementing any measure available to protect my values.

And in the case of a network administrator taking care of, among other things, a DNS recursive server, it would also be highly recommended to depl0y DNSSEC in those servers.
This would avoid that users of the network under his/her control became a victim of identity thief, or virus, trojan, etc.

Replies to This Discussion

Permalink Reply by Eleanor Adwoa Forbea Afful on July 11, 2011 at 1:58pm

Thanks Ricardo for the quick explanation on DNSSEC. You mean there are no certificates and the signatures expires but the keys to the given domain name zone do not. How does one maintain a database of signatures and keys without certificates? Because I think maintaining a list of signatures for every domain does not scale . How could every computer maintain a list of every signature for every domain it needs to verify? Then there is need of using a chain of trusted certificates.

By using the hierarchical property of the DNS, one can use DNSSEC to check certificates without knowing the
certificate of every single domain.
‣ Computers can learn certificates by tracing from a trusted key down the DNS delegation chain
‣ Of course, this only works if each level of the DNS deploys DNSSEC...
‣ For this to work, registries need to keep a list of signatures of its child zones, and publish them in their
own signed zone.

To deploy DNSSEC fully, zone managers need to:
‣ Sign their zone with a certificate
‣ Publish the certificates of their child zones
‣ Share their certificate with their parent zone
‣ The administration of these is much of the reason why
DNSSEC has been difficult to deploy
‣ And why “signing the root” is considered so important — it theoretically allows a single signature to verify the whole DNS!

Permalink Reply by Ricardo Patara on July 12, 2011 at 3:58pm

Eleanor.

Those are all very good points.

To address your question regarding keys and signatures validity. Differently of PKI certificates, the keys have not time expiration. But, the signature of a given information (DNS records in this case) will have a validity.

And from the perspective of a DNS domain zone administrator, this implies in one more duty: to keep track of domain name records signatures validity. And this would not implies much burden on those administrators as they already have to keep track of other important information of a domain name they are responsible for.

From the perspective of a DNS client, or DNS recursive server, it will not be need to keep all public keys in cache in order to resolve DNS requests.

When a DNSSEC query is to be performed by a given DNSSEC client/recursive, it will start to construct the sol called "Authentication Chain" [RFC 4033 - http://www.rfc-archive.org/getrfc.php?rfc=4033], and to do so, it will query the

upper level DNS servers for public keys associated with the domain name record being resolved.

Those public keys, once received, can be cached by the DNS client/recursive for the amount of time specified in the

TTL (time to live), but also for the validity of the signature of the key (yes, DNSSEC keys are also signed. It can be

a self signed signature or follow a schema of Key Signing Key as described in RFC 4641 - DNSSEC

 Operational Practices - http://www.rfc-archive.org/getrfc.php?rfc=4641]).

RSS

Welcome to
Diplo Internet Governance Community

Sign Up
or Sign In

Members

View All

Groups

IGF 2013 Bali

37 members
Diplo @ISOC

79 members

e-Government

44 members
Community Networks Africa

1 member

ICT Policy

39 members

View All

Website and downloads

Visit Diplo's IG website, www.diplomacy.edu/ig for info on programmes, events, and resources.

The full text of the book An Introduction to Internet Governance (6th edition) is available here. The translated versions in Serbian/BCS, French, Spanish, Arabic, Russian, Chinese, and Portuguese are also available for download.