Introduction To DNSSEC : DNS Security Extensions

DNSSEC (short for DNS Security Extensions) adds security to the Domain Name System (DNS). In fact, DNSSEC was designed to protect the Internet from certain attacks, such as DNS cache poisoning. DNSSEC is a specification of an extension to the DNS through the definition of additional DNS Resource Records that can be used by DNS clients to validate the authenticity of a DNS response, the data integrity of the DNS response, and where the response indicates no such domain or resource type exists, this negative information can also be authenticated.

DNSSEC provides:

1. Origin authentication of DNS data,
2. Data integrity
3. Authenticated denial of existence.

These functions are based on asymmetric cryptography system

In other words, if an attacker attempts to create a DNS response that has been altered from the original authentic response in some fashion, and the attacker then attempts to pass the response off as an authentic response, then a DNSSEC-aware DNS client should be able to detect the fact that the response has been altered and that the response does not correspond to the authoritative DNS information for that zone. In other words, DNSSEC is intended to protect DNS clients from forged DNS data. This protection does not eliminate the potential to inject false data into a DNS resolution transaction, but it adds additional information to DNS responses to allow a client to check that the response is authentic and complete.

As I said before, dnssec is based on cryptography, especially Public key cryptography which relies on a public and private key pair

Two types of keys are identified for use in zone signing operations. The first type is called

A Zone Signing Key (ZSK) and the second type are called a Key Signing Key (KSK). The ZSK Is used to sign the RRsets within the zone, and this includes signing the ZSK itself, the KSK is used to sign root of the Zone, which includes the ZSK and the KSK and may also be used outside the zone either as the trusted anchor in a security-aware server or as part of the chain of trust by a parent Name Server.

DNSsec mechanisms require also changes to the DNS protocol. DNSSEC adds four new resource record types: Resource Record Signature (RRSIG), DNS Public Key (DNSKEY), Delegation Signer (DS), and Next Secure (NSEC). These new RRs are described in detail in RFC 4034

What are the uses of each resource record?

DNSSEC uses public key cryptography to sign and authenticate DNS Resource record sets (RRsets).

The public keys are stored in DNSKEY Resource records, Digital signatures are stored in RRSIG resource records while, The NSEC resource record lists two separate things: the next owner name (in the canonical ordering of the zone) that contains Authoritative data or a delegation point NS RRset, and the set of RRTypes present at the NSEC RR’s owner name but for A DS RR it refers to a DNSKEY RR by Storing the key tag, algorithm number, and a digest of the DNSKEY RR, The DS RR appears only On the upper (parental) side of a delegation

Deploying Dnssec

1. Enable dnssec in authorative and recursive servers : Means that your dns will support dnssec functionality, so you have to add the following line in named.conf file (named configuration file):

Options {Dnssec-enable yes; };

2. Generate zsk and ksk for each zone :
   i/ Create zsk key:

   Dnssec-keygen -a rsasha1 -b 1024 -n zone ecole.com

   This command will generate 2 files with the following extensions:

   .key is public portion of the key

   .private is private portion of the key

   ii/ Create the ksk key:

   dnssec-keygen -a rsasha1 -b 1400 -f KSK -n zone ecole.com

3. Include keys in the zone file : we have to add the public portions to the zone file either but just including using this syntax :

$INCLUDE keys/Kecole.com.+005+12513.key; KSK

$INCLUDE keys/Kecole.com.+005+03977.key; ZSK

Or using command line mode :

Cat keys/Kecole.com.+005+12513.key >> ecole.db

cat keys/Kecole.com.+005+03977.key >> ecole.db

4. Sign the zone using the following command:

Dnssec-signzone -o ecole.com -t -k Kecole.com. +005+12513 ecole.db Kecole.com.+005+03977

5. Update named.conf file :

Replace :

zone “ecole.com ” {

file “ecole .db “;

};

With:

zone “ecole.com ” {

file “ecole.db.signed “;

};

6. Creating a secure delegation :

The process for signing a sub domain is essentially similar to that defined for signing a zone with one single difference; A Delegated Signer RR can be added to the ecole.com zone file to create secure delegation.

In fact we have to follow the same steps described before but while singing the zone we have to use the command:

dnssec-signzone -o etudiant.ecole.com -t -g -k Ketudiant.ecole.com.+005+64536

etudiant.db Ketudiant.ecole.com.+005+48560

The -g argument is used to generate two special files called dsset-etudiant.ecole.com. (Containing the DS RR for the parent) and keyset-etudiant.ecole.com. (Containing a copy of the public Key DNSKEY RR of the KSK).

When the parent administrator receives the dsset-etudiant.ecole.com. and, optionally, the keyset-etudiant.ecole.com. files, they are placed in the same directory where the ecole.com zone is signed. The dsset-etudiant.ecole.com. File is included in the original ecole.com zone. Re-sign the zone by executing the dnssec-signzone command exactly as before

The only thing that has changed is the additional Ds reecords in the new zone file, so that the sub domain zone gets its authentification through the delegation point in ecole.com in the parent zone

You may understand more the use of the Ds record in my next article which will be about DLV System and how to create a trusted anchor within a chain of trust

I hope it was useful and I want to thankyou for your time.