For better understanding of Domain Name System Security Extensions To understand the Domain Name System Security Extensions DNSSEC ]. Its important to grasp basics of how to utilize Domain Name System [ DNS and DNSSEC. The operation of Internet depends on DNS .
Each page.. thats frequented for each email message and every image that is retrieved from social media websites: all of these activities depend on DNS to translate human friendly domain names [ like icann.org and icann.org to IP addresses like 192.0.43.7 and 2001:500.88:200:7 needed by routers servers as well as various other equipment used by networks to guide traffic on the Internet toward the right destination.
The usage of Internet on any device starts with DNS. Lets take an example.. the user enters an address for site within their mobiles browser. The browser uses an Stub Resolver which is vital element of smartphones operating system to begin the translating the websites domain name into Internet Protocol [ IP ] address.
A stub resolver is described as simple DNS client which transmits requests from an application to get DNS details to more complicated DNS client referred to as an “recursive resolver”. lot of network operators employ Recursive resolvers to handle DNS requests or queries.. They will be transmitted over their networks via devices.
(smaller companies and organizations may employ recursive resolvers within diverse networks such as Recursive resolvers.. They provide free service to the people in general like Google Public DNS OpenDNS as and Quad9. The Quad9 resolver is good example.
Recursive resolver detects and resolves the results of DNS requests made to the an stub solver. Resolution involves the recursive resolver transmitting its their own DNS requests typically to names servers that are trusted. DNS data for each domain are stored on the authoritative nameserver in the Internet. DNS information associated with domains is called zone.
Some organizations.. who use private DNS servers that make their own zones however typically organizations hire this service from third parties. There are variety of businesses.. who handle DNS zones for other companies including hosting providers registrars internet registries as well as Network Server Service Providers to name handful of.
DNS by itself doesnt guarantee security.
DNS was developed in the early 80s during the time when Internet was not yet as widespread and security was not an essential aspect of creation. That signifies.. that when an recursive resolver makes request at an official name server it does not have way of verifying whether the reply is authentic.
It only confirms if responses are believed to come from specific an IP address.. the resolver initially made the request. But relying on the origin IP address to determine responses origin is not an authentic method to verify the source of response as the IP address in the DNS response packets can be changed or modified easily.
As DNS was initially designed to resolve queries it is not able to recognize fake response of its queries. The attacker can cover up legitimate server resolved query by using spoofing to generate response that appears to be coming from an authentic server. It is.. that attackers can redirect user to an untruthful website and then not be aware of the redirection was malicious.
Recursive resolvers save DNS data they receive directly from name servers that are authoritative to speed up the resolution process. When stub resolve requests DNS data that it holds in its cache it will reply immediately without waiting for the delay caused by the request to authoritative name servers.
The method of caching has drawbacks however if an attacker tries to transmit fake DNS response which is recognized by recursive resolvers then the attacker might have impacted the cache that resolvers use. The attacker will then transmit false DNS details to different devices that are able to request data.
For better understanding of the risks posed due to poisoning of caches have one look at the following situation.. This happens when user visits the banks site. It requests its set names servers for the its IP address.
But an attacker could be able to manipulate resolvers through the introduction of the IP address.. It was pointing away from the official site rather to website that was created by criminals. The fake site is spoof of the official site of bank and looks like the real one.
The users who do not have knowledge of the website will enter the username and password as they normally do. The user however has misplaced their bank account details to an attacker and later login to account on legitimate bank site for transfer of funds or to perform different illegal activities.
The DNS Security Extensions [ DNSSEC ]
Engineers of the Internet Engineering Task Force [ IETF that is the authority accountable in the field of DNS protocols have been aware for many years.. The insufficient authentication methods for DNS was major problem. The search for solution began in the beginning of 1990s. the result is DNSSEC Security Extensions [ DNSSEC The search for solution began in the early 1990s.
DNSSEC increases security in DNS by utilizing Digital Signatures that are encrypted by using public keys. By using DNSSEC DNS information is not DNS queries and responses that have been signed cryptographically but instead DNS data itself is authenticated by the owner of the details.
Every DNS zone has pair of keys public and private. the owner of the zone uses private keys to confirm details of DNS within zone and make digital signatures to protect data. The term “private key” implies key details are kept in secret by the person who owns the zone.
However its private key can be made available to the zone the owner and can be accessed by anybody. Recursive resolvers.. who search for information within the zone be able to access the public key of the zone.. which it uses to validate its authenticity. data.
resolver confirms.. that the signature is signed by DNS data it obtained is genuine. If that is the case DNS data is legitimate and is passed on to the user. If the signature is not able to verify resolver believes.. the possibility of an attack. It then discards data and then reports problem to the users.
DNSSEC has two essential features within DNSSEC that are the two most important characteristics of the DNS protocol:
* Data Origin authentication allows the resolver to authentically determine the origin of the data received the area from where it thinks.. the data originated from.
Data integrity security allows the resolver to ensure.. that the information has not been altered when it was initially authenticated by the owner of the zone using the private key for zone.
SSL certificates to verify DNSSEC keys
Each zone has to publicly disclose the public keys of its zone.. which is used by recursive resolvers to validate information within the the zone. Can resolvers be sure.. that the key public is authentic? Key for zones that are public is identical to other zone data.
Public key cant be secured by the zones private key. Instead it is encrypted with the secret key of the zone. For instance icann.org zone public key is signed by the zone.
In the same way that the DNS zone parent is responsible in publishing child zone list that includes authoritative name server zones parent is also accountable for verifying the authenticity of their childs public key.
The public keys for all zones are provided by the their parent zone except for the root zone which does not have parent.. That is able to verify the keys. The root public key zone therefore is the most important base for confirming DNS details.
If resolver can accept the public key for root zone its in position to be able to trust public key keys of zones.. which are secured by private key from root just like the public keys that is used to sign zones in the organization zone.
As resolver has the ability to rely on the public keys used by the zone or user it is capable of relying on the security of public keys that are sealed with private keys similar to those of the keys that are public on icann.org. The real world the parent zone is not required to verify the childs keys using the mechanism.. It is complicated but the end result is similar the situation when parent zone the childs signed keys. The result is similar to when the childs keys were signed by their parent.
The procedure of generating cryptographic keys.. which signify others cryptographic keys is termed as chain of Trust. Key.. which is made public in the beginning of chain of trust is referred to as trust anchor. The resolver is available in the list of trust anchors..
These keys are public.. They are associated with different zones which resolvers rely the keys implicitly. Most resolvers have just one trust anchor: key.. It is public key in the primary zone.
If you set this trust anchor at the at the top of DNS structure resolvers they could create chains of trust that could be used for any location in the DNS namespace so its an issue of making sure.. that each zone in the route has been authenticated.
Validating and signing using DNSSEC
To enable the Internet to offer security to every user DNSSEC must be widely employed. DNSSEC cannot be activated from the beginning and needs to be activated by network administrators through their resolvers to handle recursive queries and also by domain owners who have their own authoritative servers to manage their zones.
Resolvers and operators of authoritative servers have different reasons for activating DNSSEC for their server however when they activate DNSSEC the users are assured of getting authentic responses to DNS related questions. It is guarantee for users.. of being able to be able to access their your desired location on the internet.
The process of implementing DNSSEC authentication to resolvers.. Recurses are straightforward. The feature has been integrated within nearly every resolver.. they have been used for long time. It can be activated by modifying the contents of few lines in configure file for resolver.
When user asks resolvers to supply DNS details.. which is derived from signed zones or where the information is modified it will [ intentionally be denied any information provided. DNSSEC protects users from getting incorrect information in zones that are signed by releasing threats and preventing individuals from receiving information that has been altered.
Signing zones by using DNSSEC is simple process. But there are many zones.. who are registered with DNSSEC to ensure.. That users of valid resolvers can be sure.. that theyll receive correct data. The most trusted name server software will allow signing zones. Furthermore lot of third party DNS hosting providers also employ DNSSEC. In most cases installing DNSSEC to zone.. which is linked to.. which is hosted by the host provider is easy its as easy as checking box.
To enable domain owners to use DNSSEC for signing their information in zones that are both parent and child all the until the root zone they must be registered with DNSSEC to work as efficiently as it could be.
An unbroken sequence of zones signed.. starting from root zone allows resolvers to establish trust chain.. That extends out from the root zone in order to validate information. For the best chance of implementing DNSSEC for icann.org zone domain zone it must be signed in conjunction with its root zone.
There is good news.. the DNS root zone has been certified from the year 2010. DNS root zone has been signed in 2010 and each gTLD as well as several CcTLDs has also been accredited.
The last step to complete DNSSEC installation within zone. New zones need to have public key information transferred to the parent zone of zone. As we mentioned in the preceding paragraph parents zone must sign the public key for child zone and allows for trust chain built between the parent and the child.
Zone administrators typically have to transmit their private key for the zones parent organization via hand. The majority of the time is done through the registrar of the owner of the zone.
Similar to.. the person who has the control of zone communicates with the registrar to make additional modifications to zones for example listing the names of zones on servers.. They are also trusted.. So the owner must also contact registrars to modify the public keys of zones. Even though this is traditional the new protocols are designed to allow this procedure to automated in the near future.
The next steps to DNSSEC
As DNSSEC acceptance grows over time DNS will become the foundation for various protocols that require the ability to secure the storage of information way. The development of new protocols that depend on DNSSEC which means they can function only within zones that have been an authenticated.
Particularly DNS based authentication of named Entities DANE permits the publication of Transport Layer Security [ TLS keys for zones utilized by programs like mail transport.
DANE provides method of confirming the authenticity of certificates issued by authorities of public interest.. That does not require certificate authority. New ways of adding protection to DNS queries may allow for the use of DANE within the near future as well.
The year of 2018 saw ICANN altered the trust anchor that is employed by DNSSEC to switch the trust anchor used for DNS root for the first time. Many lessons learned on DNSSEC by this alteration. Also several resolvers began to become aware of DNSSEC and changed to the validation.
It was possible for the world to easily understand how DNSSEC procedure worked. As time passes ICANN expects to see greater acceptance of DNSSEC as resolver and those who own zones. This would result in.. that greater number of customers all over the world will benefit from DNSSECs secure security and encryption security.. That they will be getting original DNS answers to their problems.