Implementing DNSSEC

In the practice labs, we utilize a DNS zone with DNSSEC in the main server which also serves as the AD. As like a real world scheme, there would be other servers which considered a non-authoritative server that will hold DNSSEC keys provided by the main server. This is where the concept of trust anchor is shown, the child DNS server will be distributing DNSSEC trust anchor keys to resolvers.

Each zone will be signed with a zone-signing key (ZSK) where it has a private key to sign the records and a public key for verifications. A verified records will result a RRSIG in which combined with the records and the ZSK can be used to verify that the records are valid.

However, a ZSK by itself will not create a secure environment which an attacker could actually create their own ZSK and records to trick the resolver. Thus, a key-signing key would be needed where it creates signature of the public ZSK and KSK records. The private KSK would be held securely by the root server. Now the resolver is able to validate the ZSK with the KSK and the siganture and then validate the DNS records with the valid public ZSK.

On signing a zone with DNSSEC, signatures and DNSKEYs are created as well for the name servers in the zone. KSK and ZSK encryption type could easily be configured on zone signing wizard. In the labs, the KSK is configured with more secure encryption than ZSK. Though it might cause a larger process for the server, changing KSK would be harder as it would break the integrity on the chain of trust.

A client which holds the public KSK will be comparing the hashes with the parent records. A matched hash means that the public KSK is valid and the zone can be trusted. Thus, a public KSK in DNSSEC should have higher security than ZSK to reduce the complexity in establishing the public KSK in all the records.

DNSSEC gives the client the ability to ensure that the information received from the DNS server is valid. The client can validate its received information and key through the chain of trust and ensuring that the integrity of the of the address match the one on the authoritative server. This will also make sure that the address record is not tampered while on transport.

On an event where the address sent has been tampered, the client would not be able to resolve the address. DNSSEC has the ability deny the existence of a address in a domain with NSEC. The NSEC record is also signed by the authoritative server thus can be validated by the client.

DNSSEC gives the purpose of utilizing integrity of the address record transferred and making sure that it comes from the original zone. This ensures that a man-in-the-middle (MITM) attack would not be possible with the keys validation process.