[Autogenerated] Welcome back to protocol.
Deep Dive, DNS. We've learned how to avoid
outages and single points of failure And
what questions to answer when we're
investigating a slowdown. But what about
security? Can we lock down our zones so
they're not updated by hackers? Can we
used needs to keep malware out of the
company. The answer's are coming up in our
next module securing DNS. DNS Servers are
always the top prize for Attackers.
Pulling the cache content is a treasure
trove of which websites are being accessed
from a domain. Of course, all Dina servers
should be protected by firewalls. But what
could be done on the server itself to add
another layer of protection? That's what
will be covering in this module. This is
Sahani, one of the security analysts from
our parent company, Globomantics. She is
working with Jaden, the DNAs admin to
harden the DNA servers. Prevention is
always better than incident response. So
Suhani briefs Jaden on the most common
types of attack and the best methods of
prevention. DNA's is vulnerable to many
types of attacks, some of the most common
we see here First, a DNA's amplification
attack depends on internet accessible
servers who allow recursive queries. The
attack floods those servers with auto
generated requests for non existent
domains. With the source address of the
victim. The servers sand replies to the
victim, causing in a distributed denial of
service to the victim. What can we do to
ensure that we're not one of those servers
and therefore not part of that problem?
Our firewall should block recursive
queries for internet facing DNA servers,
allowing only iterative queries. If our
firewall can't perform such deep packet
inspection, we can set up rate limiting,
then we can also turn off recursive
queries at the server for those that slip
by the firewall, only our clients that are
on the inside should be sending a
recursive query to the server. Distributed
denial of service attacks or D doses can
be application based, like the DNS
amplification attack or network based,
which is just a boatload of traffic. The
first sign of any application based attack
is that the server response time slows
down, yet its network traffic is going up.
That should jump outta 2D at API cap or by
using net stat at the server. DNA spoofing
is poisoning the DNAs cache or
authoritative records on the server, which
simply means changing them. So when
clients query for a site, they get a
mirror site for the purpose of stealing
credentials. Man in the middle attacks are
sometimes used for this firewall, and
blocking those recursive look apps from
the outside will help to mitigate this.
DNA servers can also filter or block, DNS
replies. The approach is to look at who is
sending the query, how it's formed for
what domain. Then either drop the request
based on information already in the
database or cache or drop it based on the
iterative responses. If the queries in the
policy or block list the client receives
silence. So if a client goes ahead and
queries for really something weird dot
com, we want our DNA server to drop that
request before that client even has a
chance to find out what the IP addresses
and therefore make a connection attempt to
the web proxy server. The goal is to ___
it in the bud. Microsoft calls this DNA's
policy, and many fields can be filtered.
One example is query type. If my entire
environment is IP V four, why bother
having my DNS server do recur version for
IP V six requests. Bind can also filter
based on query types, but it can also
filter content based on categories of
sites common for malware or ransomware, or
anything else that's unwanted by blocking
domain names. Updated block lists can be
downloaded from GitHub and added to your bind. Resolved dot config file.