What is DNS?

The Domain Name System (DNS) is the phonebook of the Internet. Humans access
information online through domain names, like nytimes.com or espn.com. Web
browsers interact through Internet Protocol (IP) addresses. DNS translates domain
names to IP addresses so browsers can load Internet resources.

How does DNS work?

The process of DNS resolution involves converting a hostname (such as
www.example.com) into a computer-friendly IP address (such as 192.168.1.1). An IP
address is given to each device on the Internet, and that address is necessary to find
the appropriate Internet device - like a street address is used to find a particular
home. When a user wants to load a webpage, a translation must occur between what
a user types into their web browser (example.com) and the machine-friendly address
necessary to locate the example.com webpage.

In order to understand the process behind the DNS resolution, it’s important to learn
about the different hardware components a DNS query must pass between. For the
web browser, the DNS lookup occurs "behind the scenes" and requires no interaction
from the user’s computer apart from the initial request.

[  ] 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. All domains are required to have at least a few essential DNS records for a user
to be able to access their website using a domain name, and there are several optional records that
serve additional purposes.
 Record Types:
o A  The record that holds the IP address of a domain

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

o MX  Directs mail to an email server

o NS  Stores the name server for a DNS entry
o CNAME  Forwards one domain or subdomain to another domain, does
NOT provide an IP address

o SOA  Stores admin information about a domain. All DNS zones

need an SOA record in order to conform to IETF standards. SOA records are also
important for zone transfers. Learn more about the SOA record.

o SRV  Specifies a port for specific services

o PTR  Provides a domain name in reverse-lookups
o RP  Responsible person
o HINFO  Host inforamtion record includes CPU , OS
o TXT  Lets an admin store text notes in the record. These records
are often used for email security

There are 4 DNS servers involved in loading a webpage:

DNS recursive resolver – (The DNS local Server FROM ISP)

A recursive name server is the first stop in a DNS query. The recursive name server is a middleman
between a client and a DNS name server. After receiving a DNS query from a web client/browser, a
recursive name server will either respond with cached data, or send a request to a root name server,
then another request to a TLD name server, and then last request to an authoritative name server.
After receiving a response from the authoritative name server containing the requested IP address,
the recursive name server then sends a response to the client.

During this process, the recursive name server will cache information received from authoritative
name servers. When a client requests the IP address of a domain name that was recently requested
by another client, the recursive name server just deliver the client requested record from its cache to
the client.
Root nameserver (Root Zone Server)

A root name server is a name server for the root zone of the Domain Name System

The 13 DNS root name servers are known to every recursive name server . A root server accepts a
recursive name server’s query which includes a domain name, and the root name server responds by
directing the recursive name server to a TLD name server, based on the extension of that domain
(.com, .net, .org, etc.). The root name servers are supervise by a nonprofit organization called
the Internet Corporation for Assigned Names and Numbers (ICANN).

A TLD nameserver:

A TLD name server maintains information for all the domain names that share a
common domain extension, such as .com, .net, or whatever comes after the last dot
in a url. For example, a .com TLD name server contains information for every website
that ends in ‘.com’. If a user was searching for google.com, after receiving a response
from a root name server, the recursive name server would then send a query to
a .com TLD name server, which would respond by pointing to the authoritative name
server (see below) for that domain.

An authoritative Nameserver (The Main DNS Server)

the authoritative nameserver is at the end is a server that actually holds, and is responsible for, DNS
resource records. When a recursive name server receives a response from a TLD name server, that
response will direct from the authoritative name server to an recursive name server . The
authoritative name server is usually the last step in the journey for an IP address. The authoritative
name server contains information specific to the domain name it serves (e.g. google.com) and it can
provide a recursive name server with the IP address of that server found in the DNS A record, or if
the domain has a CNAME record (alias) it will provide the recursive name server with an alias
domain, at which point the recursive name server will have to perform a whole new DNS lookup to
procure a record from an authoritative name server (often an A record containing an IP address –
DNS record types describe below). 
It’s worth mentioning that in instances where the query is for a subdomain such as foo.example.com
or blog.cloudflare.com, an additional nameserver will be added to the sequence after the
authoritative nameserver, which is responsible for storing the subdomain’s CNAME record.
The 8 steps in a DNS lookup:

Steps in a DNS lookup

Often DNS lookup information will be cached either locally inside the querying computer or remotely
in the DNS infrastructure. There are typically 8 steps in a DNS lookup. When DNS information is
cached, steps are skipped from the DNS lookup process which makes it quicker. The example below
outlines all 8 steps when nothing is cached.

A user types ‘example.com’ into a web browser and the query travels into the Internet and is
received by a DNS recursive name server.

1. The recursive name server then queries a DNS root name server
2. The root server then responds to the resolver (recursive name server) with the address of a Top
Level Domain (TLD) DNS server (such as .com or .net), which stores the information for its
domains. When searching for example.com, our request is pointed toward the .com TLD.
3. The resolver then makes a request to the .com TLD.
4. The TLD server then responds with the IP address of the domain’s authoritative name server,
example.com.
5. Lastly, the recursive name server sends a query to the domain’s authoritative name server.
6. The IP address for example.com is then returned to the resolver from the authoritative name
server.
7. The DNS resolver then responds to the web browser with the IP address of the domain requested
initially.
8. The browser makes a HTTP request to the IP address
9. The server at that IP returns the web page to be rendered in the browser.
What are the types of DNS queries?

In a typical DNS lookup three types of queries occur. By using a combination of these queries, an
optimized process for DNS resolution can result in a reduction of distance traveled. In an ideal
situation cached record data will be available, allowing a DNS name server to return a non-recursive
query.

Recursive query - In a recursive query, a DNS client requires that a DNS server (typically a DNS
recursive resolver) will respond to the client with either the requested resource record or an error
message if the resolver can't find the record.

Iterative query - in this situation the DNS client will allow a DNS server to return the best answer it
can. If the queried DNS server does not have a match for the query name, it will return a referral to a
DNS server authoritative for a lower level of the domain namespace. The DNS client will then make a
query to the referral address. This process continues with additional DNS servers down the query
chain until either an error or timeout occurs.

Non-recursive query - typically this will occur when a DNS resolver client queries a DNS server for a
record that it has access to either because it's authoritative for the record or the record exists inside
of its cache. Typically, a DNS server will cache DNS records to prevent additional bandwidth
consumption and load on upstream servers.

DNS Cache

The purpose of caching is to temporarily stored data in a location that results in improvements in
performance and reliability for data requests. DNS caching involves storing data closer to the
requesting client so that the DNS query can be resolved earlier and additional queries further down
the DNS lookup chain can be avoided, thereby improving load times and reducing bandwidth/CPU
consumption. DNS data can be cached in a variety of locations, each of which will store DNS records
for a set amount of time determined by a time-to-live (TTL).

DNS caching is two types:

Browser DNS Caching

OS level DNS Caching

Client applications DNS caching

Modern web browsers are designed by default to cache DNS records for a set amount of time. The
purpose here is obvious; the closer the DNS caching occurs to the web browser, the fewer processing
steps must be taken in order to check the cache and make the correct requests to an IP address.
When a request is made for a DNS record, the browser cache is the first location checked for the
requested record.

Operating system (OS) level DNS caching

The operating system level DNS resolver is the second and last local stop before a DNS query leaves
your machine. The process inside your operating system that is designed to handle this query is
commonly called a “stub resolver” or DNS client. When a stub resolver gets a request from an
application, it first checks its own cache to see if it has the record. If it does not, it then sends a DNS
query (with a recursive flag set), outside the local network to a DNS recursive resolver inside the
Internet service provider (ISP).

When the recursive resolver inside the ISP receives a DNS query, like all previous steps, it will also
check to see if the requested host-to-IP-address translation is already stored inside its local
persistence layer.

The recursive name server also has additional functionality depending on the types of records it
has in its cache:
If the resolver does not have the A records, but does have the NS records for the authoritative
nameservers, it will query those name servers directly, bypassing several steps in the DNS query. This
shortcut prevents lookups from the root and .com nameservers (in our search for example.com) and
helps the resolution of the DNS query occur more quickly. If the resolver does not have the NS
records, it will send a query to the TLD servers (.com in our case), skipping the root server. In the
unlikely event that the resolver does not have records pointing to the TLD servers, it will then query
the root servers. This event typically occurs after a DNS cache has been purged
 DNS ZONE 

It is a process of sharing DNS records, the whole zone file, or only the most recent DNS records.

The DNS zones are a part of the DNS that can be administrated through an authoritative DNS server.

These zones differentiate between distinctly managed areas in the DNS namespace. A DNS zone is a
portion of the DNS namespace that is managed by a specific organization or administrator. A DNS
zone is an administrative space which allows for more granular control of DNS components, such as
authoritative nameservers. The purpose of the division is exactly to facilitate the administration of
the DNS. The whole DNS is organized with a hierarchical structure – root level, TLD, domain name,
subdomain, etc.

Zone files are simple text files with DNS records. A zone file will contain the whole information for a
domain.

A zone file is a plain text file stored in a DNS server that contains an actual representation of
the zone and contains all the records for every domain within the zone. Zone files must
always start with a Start of Authority (SOA) record, which contains important information
including contact information for the zone administrator.
The DNS Master Zone (also known as DNS Primary Zone) is the part of the namespace to
which you have the control to add and remove DNS records, and that way, you can manage
your domain name. Each host (part of the domain) that you can manage needs a DNS Master
Zone so that you can administrate it, and also, you can have just one per host.

It hosts your zone file, which is the text document that contains all the DNS records for your
domain name/host. The DNS Master Zone permits read and write. It is located inside a
Master authoritative nameserver.

For better security, availability, and redundancy in general, you will need DNS Slave Zones
(DNS Secondary Zones) inside Slave DNS servers (Secondary DNS). The Slave Zones are read-
only copies of the original Master Zone.

There are two main benefits of using a secondary DNS server:

- Redundancy and resilienc.

- Load balancing

DNS Zone transfer

In DNS, you can copy data from the Master DNS zone to the Secondary DNS zones through a process
called DNS Zone transfer. There are two types of zone transfer:

- Full zone transfer (AXFR) – a complete zone transfer, where the Secondary DNS servers copy
the whole zone file.
- Partial zone transfer (IXFR) – In this case, the Secondary servers will check all the new
changes that happened since their last update (deleted and added DNS records) and get only
them

To function correctly, the system needs to keep been updated. That could happen in two ways:

- Push – The Master DNS server can propagate a zone transfer to the Secondary DNS servers.
- Pull – The Secondary DNS server can check for changes inside the Master zone, and if they
find any differences by comparing the SOA records, they can start a zone transfer.

Transferring a DNS zone using Dig:

You can perform a full DNS zone transfer using the popular Dig command. You can go ahead and try it
with zonetransfer.me. and its nameserver. It is a website created for testing.

1. Open the Terminal application on your Linux computer. 

2. Type “dig zonetransfer.me -t ns”. In the answer section, you will see the nameservers for the
domain name. We will use one of them for our next dig command, the @nsztm1.digi.ninja.
3. Now type “ dig axfr zonetransfer.me @nsztm1.digi.ninja.”. Wait a few seconds, and you will see
all the DNS records – SOA, TXT, A, AAAA, MX, NS, etc.

Zone transfers and hackers’ attacks:

Hackers can obtain the zone file by performing an AXFR request. You can prevent this if you allow
just trusted DNS servers to perform AXFR queries. You can use Whitelisting to add the IP addresses of
the allowed DNS servers that can perform DNS zone transfer. A good way to perform Secure zone
transfers is to use DNS Transaction Signatures – TSIG. It is a way to secure the communication
between two points using symmetric encryption (hmac-sha224, hmac-sha256, hmac-sha384, hmac-
sha512). Inside the zone file, there are DNS records that can be for inside use only. You can imagine
that this kind of information could be dangerous in the hands f a cyber-criminal.

Conclusion:

DNS zone transfer is the method of sharing DNS records from the Primary DNS server
to the Secondary DNS servers. If you create a new DNS zone, you will need to
perform an AXFR zone transfer. If you already have set up all the DNS zones and you
just make changes to the primary DNS zone, then it will be an IXFR zone transfer.

What’s DNS enumeration?

DNS enumeration is one of the most popular reconnaissance tasks there is for building a profile of
your target. In plain english, it’s the act of detecting and enumerating all possible DNS records from a
domain name. This includes hostnames, DNS record names, DNS record types, TTLs, IP addresses,
and a bit more, depending on how much information you’re looking for. With effective DNS
enumeration, you can clone DNS zones manually, using scripts or by exploiting DNS zone transfer
vulnerabilities, known as AXFR (Asynchronous Transfer Full Range) Transfer. This latter type of DNS
transfer takes place when an attacker detects a misconfigured DNS server that is actually responding
to AXFR requests.

Why is DNS security important?

Standard DNS queries, which are required for almost all web traffic, create opportunities for DNS
exploits such as DNS hijacking and on-path attacks. These attacks can redirect a website’s inbound
traffic to a fake copy of the site, collecting sensitive user information and exposing businesses to
major liability. One of the best known ways to protect against DNS threats is to adopt the DNSSEC
protocol.

What is DNSSEC (DNS Security Extensions)?

Like many Internet protocols, the DNS system was not designed with security in mind and contains
several design limitations. These limitations, combined with advances in technology, have made it
easy for attackers to hijack a DNS lookup for malicious purposes, such as sending a user to a
fraudulent website that can distribute malware or collect personal information.

DNS Security Extensions (DNSSEC) is a security protocol created to mitigate this problem. DNSSEC
protects against attacks by digitally signing data to help ensure its validity. In order to ensure a secure
lookup, the signing must happen at every level in the DNS lookup process.

This signing process is similar to someone signing a legal document with a pen; that person signs with
a unique signature that no one else can create, and a court expert can look at that signature and
verify that the document was signed by that person. These digital signatures ensure that data has not
been tampered with.

DNSSEC implements a hierarchical digital signing policy across all layers of DNS. For example, in the
case of a ‘google.com’ lookup, a root DNS server would sign a key for the .COM nameserver, and
the .COM nameserver would then sign a key for google.com’s authoritative nameserver.

While improved security is always preferred, DNSSEC is designed to be backwards-compatible to

ensure that traditional DNS lookups still resolve correctly, albeit without the added security. DNSSEC
is meant to work with other security measures like SSL/TLS as part of a holistic Internet security
strategy

DNSSEC creates a parent-child train of trust that travels all the way up to the root zone. This chain of
trust cannot be compromised at any layer of DNS, or else the request will become open to an on-
path attack.

To close the chain of trust, the root zone itself needs to be validated (proven to be free of tampering
or fraud), and this is actually done using human intervention. Interestingly, in what’s called a Root
Zone Signing Ceremony, selected individuals from around the world meet to sign the root DNSKEY
RRset in a public and audited way.

What are some common attacks involving DNS?

DNSSEC is a powerful security protocol, but unfortunately it is not currently universally adopted

- DNS spoofing/cache poisoning: This is an attack where forged DNS data is

introduced into a DNS resolver’s cache, resulting in the resolver returning an
incorrect IP address for a domain. Instead of going to the correct website, traffic can
be diverted to a malicious machine or anywhere else the attacker desires; often this
will be a replica of the original site used for malicious purposes such as
distributing malware or collecting login information.
DNS tunneling: This attack uses other protocols to tunnel through DNS queries and
responses. Attackers can use SSH, TCP, or HTTP to pass malware or stolen information into
DNS queries, undetected by most firewalls.

DNS hijacking: In DNS hijacking the attacker redirects queries to a different domain name
server. This can be done either with malware or with the unauthorized modification of a DNS
server. Although the result is similar to that of DNS spoofing, this is a fundamentally different
attack because it targets the DNS record of the website on the nameserver, rather than a
resolver’s cache.
NXDOMAIN attack: This is a type of DNS flood attack where an attacker inundates a
DNS server with requests, asking for records that do not exist, in an attempt to cause
a denial-of-service for legitimate traffic. This can be accomplished using sophisticated
attack tools that can auto-generate unique subdomains for each request. NXDOMAIN
attacks can also target a recursive resolver with the goal of filling the resolver’s cache
with junk requests.

Phantom domain attack: A phantom domain attack has a similar result to an

NXDOMAIN attack on a DNS resolver. The attacker sets up a bunch of ‘phantom’
domain servers that either respond to requests very slowly or not at all. The resolver
is then hit with a flood of requests to these domains and the resolver gets tied up
waiting for responses, leading to slow performance and denial-of-service.

Random subdomain attack: In this case, the attacker sends DNS queries for several
random, nonexistent subdomains of one legitimate site. The goal is to create a
denial-of-service for the domain’s authoritative nameserver, making it impossible to
lookup the website from the nameserver. As a side effect, the ISP serving the attacker
may also be impacted, as their recursive resolver's cache will be loaded with bad
requests.

Domain lock-up attack: Attackers orchestrate this form of attack by setting up

special domains and resolvers to create TCP connections with other legitimate
resolvers. When the targeted resolvers send requests, these domains send back slow
streams of random packets, tying up the resolver’s resources.
Botnet-based CPE attack: These attacks are carried out using CPE devices (Customer
Premise Equipment; this is hardware given out by service providers for use by their
customers, such as modems, routers, cable boxes, etc.). The attackers compromise the
CPEs and the devices become part of a botnet, used to perform random subdomain
attacks against one site or domain.

What is the best way to protect against DNS-based attacks?

In addition to DNSSEC, an operator of a DNS zone can take further measures to secure their servers.
Over-provisioning infrastructure is one simple strategy to overcome DDoS attacks. Simply put, if your
nameserver can handle several multiples more traffic than you expect, it is harder for a volume-
based attack to overwhelm your server.

Anycast routing is another handy tool that can disrupt DDoS attacks. Anycast allows multiple servers
to share a single IP address, so even if one DNS server gets shut down, there will still be others up
and serving. Another popular strategy for securing DNS servers is a DNS firewall.

What is a DNS firewall?

A DNS firewall is a tool that can provide a number of security and performance services for DNS
servers. A DNS firewall sits between a user’s recursive resolver and the authoritative nameserver of
the website or service they are trying to reach. The firewall can provide rate limiting services to shut
down attackers trying to overwhelm the server. If the server does experience downtime as the result
of an attack or for any other reason, the DNS firewall can keep the operator’s site or service up by
serving DNS responses from cache.

DNS Firewall makes running reliable DNS easy by protecting and accelerating any organization’s DNS
infrastructure. With DNS Firewall enabled, DNS queries for your nameservers get sent to the nearest
data center where the legitimacy of the requests are checked and malicious traffic is blocked.

Onboarding DNS Firewall is easy, with a simple change of your nameservers’ IP addresses, your DNS
infrastructure can be protected in as little as 5 minutes.

In addition to its security features, a DNS firewall can also provide performance solutions such as
faster DNS lookups and reduced bandwidth costs for the DNS operator.

Advanced DDoS Mitigation for DNS

DDoS attacks on DNS infrastructure are becoming increasingly more common. Cloudflare’s DNS
Firewall has DDoS mitigation at its core, leveraging the the same DDoS protection that has mitigated
some of the largest DDoS attacks to date. When malicious traffic is aimed at your origin nameservers,
Cloudflare’s DDoS protection reroutes that traffic and absorbs it across its global network.

Hide Your Origin IP Addresses From Attackers

DNS Firewall also masks the true origin IP addresses of providers’ nameservers behind Cloudflare’s IP
addresses, keeping them safe from being targeted by attackers.
DNS as a security tool:

DNS resolvers can also be configured to provide security solutions for their end users (people
browsing the Internet). Some DNS resolvers provide features such as content filtering, which can
block sites known to distribute malware and spam, and botnet protection, which blocks
communication with known botnets. Many of these secured DNS resolvers are free to use and a user
can switch to one of these recursive DNS services by changing a single setting in their local router.