The priority was to build a decentralized hierarchical address book. The DNS network is hierarchical, organized in layers. Some years after it was first deployed, serious security flaws were discovered with this system. The results of DNS queries are cached so that they can be returned quickly.
There is no way for a recursive resolving DNS server or authoritative domain servers to know that they are getting bad information. The authoritative DNS records are signed by a private key which is kept secret. Servers that request the DNS records RRSet , also receive the signature and the public key, and can verify that the records have been signed with the private key. If the records have been signed with the right key, it is strong evidence that they are valid. Criminals are unlikely to have access to the private key.
Additionally, DNS servers higher up the hierarchy are able to validate the information contained in the records of the server immediately below them. The resolver can only check that a response appears to come from the same IP address where the resolver sent the original query. But relying on the source IP address of a response is not a strong authentication mechanism, since the source IP address of a DNS response packet can be easily forged, or spoofed.
As DNS was originally designed, a resolver cannot easily detect a forged response to one of its queries. An attacker can easily masquerade as the authoritative server that a resolver originally queried by spoofing a response that appears to come from that authoritative server. In other words an attacker can redirect a user to a potentially malicious site without the user realizing it.
Recursive resolvers cache the DNS data they receive from authoritative name servers to speed up the resolution process. If a stub resolver asks for DNS data that the recursive resolver has in its cache, the recursive resolver can answer immediately without the delay introduced by first querying one or more authoritative servers. This reliance on caching has a downside, however: if an attacker sends a forged DNS response that is accepted by a recursive resolver, the attacker has poisoned the cache of the recursive resolver.
The resolver will then proceed to return the fraudulent DNS data to other devices that query for it. As an example of the threat posed by a cache-poisoning attack , consider what happens when a user visits their bank's website. The user's device queries its configured recursive name server for the bank web site's IP address. But an attacker could have poisoned the resolver with an IP address that points not to the legitimate site but to a web site created by the attacker.
This fraudulent website impersonates the bank website and looks just the same. The unknowing user would enter their name and password, as usual. Unfortunately, the user has inadvertently provided its banking credentials to the attacker, who could then log in as that user at the legitimate bank web site to transfer funds or take other unauthorized actions. The zone owner uses the zone's private key to sign DNS data in the zone and generate digital signatures over that data.
As the name "private key" implies, this key material is kept secret by the zone owner. The InterNetX Blog provides you with news and background information on innovations concerning domains, servers, SSL and other industry-related topics. This system was developed at a time where cybersecurity was not a real thing. While the internet was growing, involving ever more activities and data, the importance of a secure DNS became clear.
Thanks to his invention, we can now surf using easy-to-remember URLs instead of long numeric IP addresses. This process at the base of the DNS is called domain name resolution. Unfortunately, during the communication, serious security risks hide. The DNS was created within an academic setting at a small scale; therefore, it did not envision the necessity to avoid cybersecurity-related problems. With time, it was discovered that hackers could easily infiltrate the name server and the DNS client and, for example, poison the server cache.
One of the main problems has been that DNS was not developed to verify the sender's identity, so the recipient cannot determine if the received DNS response comes from the server being queried. To counter this issue, DNSSEC is seen as a valuable solution to stop attacks and certify that the domain name is exactly what it claims to be. It adds source authentication to the DNS, thus guaranteeing the authenticity and integrity of the data.
Furthermore, it ensures the security and reliability of the information provided by the DNS. Without DNSSEC, it is impossible to determine if the DNS responses are correct or falsified, but especially if the connection has been established with the desired partner. This version, believed to be fully workable, was proved to be unsuitable for large networks.
Underneath the TLDs, we have domains like example. Each of these distinct namespaces is a DNS zone. But, how do we know that the data can be trusted? For example, to validate example. Then, to validate. Well, we assume we can trust the root zone. Building out from that trusted signature, all the child zones can be trusted.
0コメント