What Exactly Is DNS?

DNS or Domain Name Systems is a translation system that allows the users to browse the internet with a language we're comfortable with. Instead of typing and memorizing long sequences of numbers we can use names and letters (hostname). This "address book" is distributed around the world, stored on domain name servers that all communicate with each other. This distribution helps speed things up as there are multiple locations for the directory. This reduces load and reduces travel time.

Example: google.com
Actual IP: 8.8.8.8

How Exactly Does the DNS Work?

When a user tries to visit a website, initially the request is submitted, the computer will first search for its IP address, found on the local DNS cache memory. If successful, it will display the website immediately to the user. If it's unable to locate the IP address, the search query will then go to the recursive server which is maintained by the ISP (Internet Service Provider) to try and fetch the IP address. If the IP address is accurately located, the website will be displayed to the user.

The ISP will usually maintain a cache of IP addresses frequently accessed by their customers (e.g. commonly viewed websites such as Facebook or YouTube), so the chances of locating the requested websites are rather high. If the IP address can't be located, the recursive server directs the query to the root nameserver. If it's found here, the website is displayed. If not, the user query goes to the TLD nameserver, and if it's still not found, the destination the query goes to would be the authoritative server. This is where the IP address will be located, and the website will be retrieved and displayed to the user.

So, essentially, there are 4 levels the user query can go through to resolve a domain name into a computer-friendly IP address and display a website to a user. The recursive server will usually cache the IP address by extracting it from the authoritative server so it's readily accessible to users the next time they request it. There is usually a period the recursive server will cache the IP address for before it refreshes itself It's called the 'time to live. The usually directs the recursive server on how long to cache the IP address for when the communication between servers occurs.

To put it simply, one user search query leads to a whole series of queries and responses, almost like a chain reaction, to find and display a website in the blink of an eye!

DNS Resolution

DNS resolution is the process of converting a hostname into an IP address. Four operations are required to load a webpage.

The recursor is a server designed to receive queries from clients. It'll act as a middleman between the client and the DNS name server. It'll return data from its cache if it exists or will directly lookup the root name server.

The root name server contains information that makes up the root zone, which is the global list of top-level domains. The root zone contains:

Generic top-level domains such as .com, .net, and .org Country-code top-level domains such as in for India.

Top-level domain name server

A top-level domain (TLD) is the highest level of domain name in the root zone of the DNS of the internet. The Internet Corporation for Assigned Names and Numbers (ICANN) looks after most top-level domains.

Authoritative name server

The authoritative name server is the last operation in the name-server query. If the authoritative name server has access to the requested record, it'll return the IP address for the requested hostname back to the DNS recursor. This server holds the actual DNS records (A, CNAME, etc.) for a particular domain.

An Overview of DNS Querying:

A Recursive Name Server is a DNS server that receives DNS queries for informational purposes. These types of DNS servers do not store DNS records. When a DNS query is received, it will search in its cache memory for the host address tied to the IP address from the DNS query. If the recursive name server has the information, then it will return a response to query sender. If it does not have the record, then the DNS query will be sent to other recursive name servers until it reaches an authoritative DNS server that can supply the IP address.

An Authoritative DNS Server is a DNS server that stores DNS records (A, NAME, MX, TXT, etc.) for domain names. These servers will only respond to DNS queries for locally stored DNS zone files.

What is a DNS record?

DNS records (aka zone files) are instructions that live in authoritative DNS servers and provide information about a domain including what IP address is associated with that domain and how to handle requests for that domain. These records consist of a series of text files written in what is known as DNS syntax. DNS syntax is just a string of characters used as commands that tell the DNS server what to do. All DNS records also have a 'TTL', which stands for time-to-live, and indicates how often a DNS server will refresh that record.

What are the most common types of DNS record?

A record - The record that holds the IP address of a domain.

AAAA record - The record that contains the IPv6 address for a domain (as opposed to A records, which list the IPv4 address).

NAME record - Forwards one domain or subdomain to another domain, does NOT provide an IP address.

MX record - Directs mail to an email server. Learn more about the MX record.

TXT record- Lets an admin store text notes in the record. These records are often used for email security.

NS record - Stores the name server for a DNS entry.

SO record - Store's admin information about a domain.

SRV record - Specifies a port for specific services.

PTR record - Provides a domain name in reverse-lookups.

What are some of the less commonly used DNS records?

AFSDB record - This record is used for clients of the Andrew File System (AFS) developed by Carnegie Melon. The AFSDB record functions to find other AS cells. APL record - The 'address prefix list' is an experiment record that specifies lists of address ranges.

CAA record - This is the 'certification authority authorization' record, it allows domain owners state which certificate authorities can issue certificates for that domain. If no CAA record exists, then anyone can issue a certificate for the domain. These records are also inherited by subdomains.

DNSKEY record - The 'DNS Key Record' contains a public key used to verify Domain Name System Security Extension (DNSSEC) signatures.

CDNSKEY record - This is a child copy of the DNSKEY record, meant to be transferred to a parent.

CERT record - The 'certificate record' stores public key certificates.

CHID record - The 'DHCP Identifier' stores info for the Dynamic Host Configuration Protocol (DHCP), a standardized network protocol used on IP networks.

DNAME record - The 'delegation name' record creates a domain alias, just like NAME, but this alias will redirect all subdomains as well. For instance, if the owner of 'example.com' bought the domain 'website.net' and gave it a NAME record that points to 'example.com', then that pointer would also extend to 'blog. website.net' and any other subdomains.

HIP record - This record uses 'Host identity protocol', a way to separate the roles of an IP address, this record is used most often in mobile computing.

IPSECKEY record - The 'IPSEC key' record works with the Internet Protocol Security (IPSEC), an end-to-end security protocol framework and part of the Internet Protocol Suite (TCP/IP).

LOC record - The location record contains geographical information for a domain in the form of longitude and latitude coordinates.

NAPTR record - The 'name authority pointer' record can be combined with an SRV record to dynamically create URI to point to base on a regular expression.

NSEC record - The 'next secure record' is part of DNSSEC, and it's used to prove requested DNS resource record does not exist

RRSIG record - The 'resource record signature' is a record to store digital signatures used to authenticate records in accordance with DNSSEC.

RP record - This is the 'responsible person' record, and it stores the email address of the person responsible for the domain.

SSHFP record - This record stores the 'SSH public key fingerprints', SSH stands for Secure Shell and it's a cryptographic networking protocol for secure communication over an unsecure network.

What is dnsmasq and how it can be used?

Dnsmasq is free software providing DNS caching, DHCP, router advertisement and network boot features. It will decrease CPU and network usage and avoid DNS resolution failure by providing the cache.

It sounds great because DNS Cache will bring many advantages to your service & system.

• Lesser CPU usage.
• Lesser Network usage (Low latency in terms of the transaction for the service).
• Avoid the failure of resolving DNS (As there is cache).

Now it's the time to talk about what you need to be cautious about when you are using dnsmasq.

Dnsmasq Vulnerabilities

DNS masquerade is a widely used open-source DNS resolver used by many projects and hardware firmware worldwide, from Kubernetes (Kube-dns) to routers and other products. dnsmasq is the service providing the cache, so it will always be the target for DNS cache poisoning.

What should I do for dnsmasq vulnerabilities?

Many devices likely remain unpatched for the security patch and have overlooked the dnsmasq vulnerability. dnsmasq has been getting more popular and is responsive for the security vulnerability updates. So, if you update your dnsmasq software on time, your system will be safe.

DNS Poisoning

DNS cache poisoning, also known as DNS spoofing, is the act of entering false information by an attacker into a DNS cache, so that DNS queries return an incorrect response and users are directed to the wrong websites. This can be used by the attacker to be redirecting online traffic or stealing user credentials or user sensitive information.

Risks of DNS Poisoning

1. Data theft - Attacker may steal personal information (login credentials, account details, credit card numbers).
2. Malware infection - When users are directed to the attacker's fake website, attacker may install viruses or malware on their servers. So, the user will get harm.

How to prevent from DNS Poisoning

When we consider about the prevention. To prevent DNS spoofing, user-end protections are limited. Website owners and server providers are a bit more empowered to protect themselves and their users. To appropriately keep everyone safe, both parties must try to avoid spoofs.

The prevention measures for server providers and website owners are as follows:

1. Use tools for DNS spoofing detection.
2. End to end encryption.
3. Use Domain name system security extension (DNSSEC).

The prevention measures for endpoint users are as follows:

1. Never click on an unrecognized link.
2. Daily scan our system for viruses or malware.
3. Solve poisoning by flushing our DNS cache.
4. Use VPN (Virtual private network).

DNSSEC (Domain Name System Security Extensions) overview

The Domain Name System Security Extensions (DNSSEC) is an Internet standard that adds security mechanisms to the Domain Name System (DNS). It ensures both the authenticity and integrity of the DNS data, It is used to analyze the internally generated DNSSEC queries needed to build the chain-to-trust. This feature is enabled by default and can be useful to provide additional details about DNSSEC transactions.

A (local) DNS resolver can use DNSSEC to verify that the DNS zone data it receives has not been modified and is indeed identical to the authoritative zone. DNSSEC was developed mainly as means against DNS cache poisoning. It secures the transmission of resource records by means of digital signatures using asymmetric so-called public-key cryptography. If you are not familiar with the concept, think of it as a cleverly designed lock, where one key lock and one key unlocks. In DNSSEC, you get the unlocking public key, while the locking key is kept private. The owners of the authoritative server on which the zone to be secured is located signs each individual record using their private keys. DNS clients can validate this signature with the owner's public key to verify said authenticity and integrity.

A separate zone signing key (a pair consisting of a public and private key) is generated for each zone to be secured. The public part of the zone key is included in the zone file as a DNSKEY resource record. The private key is used to digitally sign each individual record of this zone. For this purpose, a new record type is provided, the RRSIG Resource Record, which contains the signature to the associated DNS record. For each transaction, the associated RRSIG record is supplied in addition to the actual resource record. The requesting resolver can then validate the signature using the public zone key.

DNSKEY records are used to propagate public keys through DNS: The owner of the key stores it as DNSKEY record on a publicly accessible DNS server. Anyone who needs this public key sends a corresponding DNSKEY request. You receive the public key in response. The procedure thus corresponds to any other DNS requests, for instance ordinary IP addresses. In practice however, this type of propagation is not sufficient since a complete zone could be forged. The public key must therefore either be introduced manually into the resolver as a trusted key or the associated DS resource record must be published in the overlying zone. The trusted key of the root zone (the uppermost level of the DNS hierarchy) is known by your Pi-hole and is hard-coded.

For a complete picture, we also need DS (Delegation Signer) records. Those are used to chain DNSSEC-signed zones. This allows multiple DNS zones to be combined into a chain of trust and validated via a single public key. The basic idea is to chain all the zones involved and use only the topmost one as the secure entry point. The security-providing and critical part is that DS record can be calculated from the DNSKEY, but not vice versa thanks to the used asynchronous cryptography.

Digital signatures: Signatures generated with DNSSEC are contained within the DNS zone itself in the new resource records which are called RRSIG (resource record signature) records. When a resolver issues a query for a name, the RRSIG record is returned in the response. A public cryptographic key called a DNSKEY is needed to verify the signature. The DNSKEY is retrieved by a DNS server during the validation process.

Zone signing Sign in a zone with DNSSEC means that you are individually signing all the records contained in the zone. This makes it possible to add, modify, or delete records in the zone without re-signing the entire zone. It is only necessary to re-sign the updated records.

DNSKEY A DNSKEY resource record stores a public cryptographic key that is used to verify a signature. The DNSKEY record is used by a DNS server during the validation process. DNSKEY records can store public keys for a zone signing key (ZSK) or a key signing key (KSK).

NSEC If the DNS server responds that no record was found, this response also needs to be validated as authentic and if there is no resource record, then there is no RRSIG record also. The answer to this problem is the Next Secure (NSEC) record. NSEC records create a chain of links between signed resource records. When a query is submitted for a nonexistent record, the DNS server returns the SEC record prior to where the nonexistent record would have been in the order. This allows for something called authenticated denial of existence.

NSEC3 is a replacement or alternative to SEC that has the additional benefit of preventing "zone walking" which is the process of repeating NSEC queries to retrieve all the names in a zone. A zone can be signed with either NSEC or NSEC3, but not both.

Delegation Singer A DS record is a DNSSEC record type that is used to secure a delegation. DS records are used to build authentication chains to child zones.

Trust anchors DNSKEY and DS resource records are also called trust anchors or trust points. A trust anchor must be distributed to all nonauthoritative DNS servers that will perform DNSSEC validation of DNS responses for a signed zone. If the DNS server is running on a domain controller, trust anchors are stored in the forest directory partition in Active Directory Domain Services (AD DS) and can be replicated to all domain controllers in the forest. On standalone DNS servers, trust anchors are stored in a file named TrustAnchors DNS.

DNSSEC Key Management

DNSSEC key management strategy includes planning for key generation, key storage, key expiration, and key replacement. Together, key expiration and replacement in DNSSEC is called key rollover.

How DNSSEC works?

DNSSEC uses digital signatures and cryptographic keys to validate that DNS responses are authentic. DNS zone can be secured with DNSSEC using a process called zone signing. Signing a zone with DNSSEC adds validation support to a zone without changing the basic mechanism of a DNS query and response. Validation of DNS responses occurs using digital signatures that are included with DNS responses. These digital signatures are contained in new, DNSSEC-related resource records that are generated and added to the zone during zone signing.

When a DNSSEC-aware recursive or forwarding DNS, server receives a query from a DNS client for a DNSSEC-signed zone, it will request that the authoritative DNS server also send DNSSEC records and then attempt to validate the DNS response using these records. A recursive or forwarding DNS server recognizes that the zone supports DNSSEC if it has a DNSKEY, also called a trust anchor, for that zone.

DNSSEC validation A recursive DNS server uses the DNSKEY resource record to validate responses from the authoritative DNS server by decrypting digital signatures that are contained in DNSSEC-related resource records, and then by computing and comparing hash values. If hash values are the same, it provides a reply to the DNS client with the DNS data that is requested, such as a host (A) resource record. If hash values are not the same, it replies with a SERVFAIL message. In this way, a DNSSEC-capable, resolving DNS server with a valid trust anchor installed protects against DNS spoofing attacks whether DNS clients are DNSSEC-aware.

DNS Server Vulnerabilities

DNS is too important to do without, but it's difficult to defend. In fact, DNS services are an excellent target for attack. Taking out an organization's DNS service renders it unreachable to the rest of the world except by IP address. If "f5.com" failed to be published online, every single Internet site and service we ran would be invisible. This means web servers, VPNs, mail services, file transfer sites everything. Even worse, if hackers could change the DNS records, then they could redirect everyone to sites they controlled. Imagine going to "f5.com" and landing on a page full of banner ads. Since DNS is built upon cooperation between millions of servers and clients over insecure and unreliable protocols, it is uniquely vulnerable to disruption, subversion, and hijacking. Here's a quick rundown of the known major DNS attacks.

Denial of Service

Denial-of-service attacks are not limited to DNS but taking out DNS decapitates an organization. Why bother flooding thousands of web sites when killing a single service does it all for you? The most famous DoS attacks against DNS are the recent Dyn, Inc. DDoS attacks which exceeded 40 gigabytes of noise blared at their DNS services. Dyn was running DNS services for many major organizations, so when they were drowned by a flood of illegitimate packets, so were companies like Amazon, Reddit, FiveThirtyEight, and Visa.

There are many ways to knock out DNS service, the simplest being a stream of garbage from thousands of compromised hosts (bots) in a DDoS attack. Instead of clogging up the pipe, attackers can also overwork the server with DNS Query Flood6 attacks from thousands of bots.

DNS can also be subverted for use as a denial-of-service weapon against other sites by way of DNS Amplification/Reflection. This works because DNS almost always returns a larger set of data than what was queried. A simple DNS query asking for F5.com only amounts to a few hundred bytes at most, while the response will be several orders of magnitude larger. This way an attacker can amplify network traffic through DNS servers, building up a tsunami from a ripple. Since DNS runs over UDP, it's a simple matter for attackers to craft fake packets spoofing a query source, so if they can fake thousands of queries from the victim's IP address, that tsunami of responses will return to overwhelm the victim. A bonus for the attacker is that, to the victim, it will appear as if a huge number of DNS servers are attacking it. All the while, the attacker stays safely hidden.

DNS Hijacking

Who owns what domain name and what DNS servers are designated to answer queries are managed by Domain Registrars, these are commercial services, such as GoDaddy, Nom, and Network Solutions Inc., where there are registered accounts storing this information, if attackers can hack those accounts, they can repoint a domain to a DNS server they control. Attacks like this have affected the New York Times 9, Linkedin, Dell, Harvard University, Coca Cola, and many others.

DNS Server Vulnerabilities

Because DNS services are software, they are likely to contain bugs. It's possible that some of these bugs will create software vulnerabilities that attackers can exploit. That's just the way it is with all software written by imperfect carbon-based life forms. Luckily, DNS is old (so we've had time to find most of the bugs) and simple (so bugs are easy to spot), but problems have cropped up. In 2015, there was a rather significant hole found in BIND, an open-source DNS server running much of the Internet10. Called CVE-2015-547711 (no cute name, thank you), BIND allowed an attacker to crash a DNS server with a single crafted query.

Another software vulnerability in DNS servers is the Recursive DNS spoof cache poisoning technique, which means that an attacker can temporarily change DNS database entries by issuing specifically crafted queries.

DNS Data Leakage

You can't run an unauthenticated Internet database full of important information without the occasional risk of leaking out something important. Attackers will often repeatedly query DNS servers as a prelude to an attack, looking for interesting Internet services that may not be widely known. For example, an organization may have a site called vpn.example.com which it doesn't advertise to anyone except its employees. If an attacker discovers this site, they've just found a new potential target in an attack. DNS records can also aid phishing expeditions by using known server names in their phony baloney emails.

Many organizations run DNS on the inside of the network, advertising local area network (LAN) resources for workstations. Some smaller organizations run split-horizon DNS servers that offer up Internet DNS services to the world as well as these LAN-based DNS services on the same box. A wrong configuration on that DNS server can lead to some devastating DNS data leakages as internal names and addresses are shared with attackers. Even giants can be tripped up by this seemingly simple vulnerability.

Final thoughts:

So, there you have it! It is clear how the DNS is critical to the functioning of the internet! As the internet grows and grows, so too does the DNS and the number of domain names and IP addresses register. Knowing how the DNS works and keeping in mind some of the best practices is pivotal to positive user experience as well as the success of your own website.