Next, let's take a look at DNS and security issues related to its use.
When thinking about DNS resolving fully qualified domain names
to IP addresses and transmitting on port 53,
we see immediately that an RFC 1035, the local user,
or client,
is known as a resolver because part of their requests come from
their own system to resolve an IP to a hostname.
If they don't have the answer,
then they may be referred to a specific DNS server's database or referred
to root servers in order to resolve an external request.
There are also various extensions to DNS we'll talk about in a second
that help us to enhance functionality and security.
The process, by default, looks like this.
A resolver has already tried to resolve a name to an IP address by means of
their host record before they connect to a DNS server.
The DNS server will then take that and walk it through the different
zones that make up the fully qualified domain name.
So the dot that's appended to the end of the search
actually goes up to the root servers,
which will have a reference for the IP address
associated with the top‑level domain.
Then the top‑level domain will have an IP address for the lower level,
or subdomain, for the exact provider that you are looking to work with.
That provider will then also have the IP address for the
specific service that you were trying to consume.
Now the essential records that allow this to happen
on a DNS system would be the host, or A record,
the start of authority zone for which it is a parent in the
hierarchy that's responsible for the resolution.
The name server record is the address of the specific
name servers that are out there.
The reverse lookup, where I can supply an IP and get a name.
And then also the mail exchange record.
With DNS,
the security issues include a lack of integrity and
confidentiality when it's running in its native space.
DNS shadowing is also a threat where the attacker can get access to
the domain registrant's account and create subdomains from the parent
domain or use some malicious derivation of that name in order to
direct people to a rogue website.
There's also the issue of amplification and reflection attacks.
DNS has been used in large‑scale attacks concerning amplification,
returning large amounts of data with small requests,
and reflection, spoofing the response to an unsuspecting victim.
Traffic interception and surveillance could also be another issue.
So let's address how we would secure ourselves.
First off,
using RFC 5011 would reference a DNS security specification that automates
a trust anchor process of validating thousands of possible DNS systems
that may exist in a resolver's DNS hierarchy.
So the purpose of DNSSEC is to validate our authenticate zone
transfers with a digital signature in order to thwart an attacker
that falsifies requests from DNS queries.
Also,
you could enhance your DNS by ensuring your email domain has a
Domain‑based Message Authentication Reporting and Conformance policy with
Sender Policy Framework and Domain Keys Identified.
This is an amalgam of using public private key management that can
authenticate and can secure or assign keys for a particular DNS zone.
Going to take a look at that process flow shortly after this slide.
DNS over HTTPS, or DoH,
is what allows a consumer to have a confidential request of DNS that
is embedded inside port 443 protecting port 53.
Constantly doing log reviews in your DNS environment,
having passwords that are difficult,
and only using multi‑factor access to manage these
systems is a requirement for securing DNS.
Let's look at the DNSSEC records, the DNS Security records.
There's a record called an RRSIG, which is a cryptographic signature.
There's the DNSKEY, which is a public signing key.
There's the DS record, which is a hash of the DNSKEY.
And then there's the NSEC and NSEC3, which is designed for denial of existence,
and the CDNSKEY and the CDS,
which are child‑to‑parent zone update request records.
Let's look at how does this operate in a functioning environment.
The first step towards securing a zone with DNSSEC is to group all the records
with the same zone type inside of a resource record set,
or the RRset.
So, for example, we have the AAAA records in your zone with the same label,
and we bundle those into a single AAAA RRset.
Once we've done that,
we're going to use a combination of public/private key management,
or asymmetric keys, that are zone‑signing keys.
When we operate these keys, for instance,
when the private key is active,
what it is doing is it's acting as an authenticator to sign the
RRset data in order to produce and RRSIG,
or signature.
The public key is necessary because that's what's going to prove out the
owner when it decrypts from the client perspective,
or the resolver's perspective, the RRSIG.
It is the resolver that is going to use a combination
of then this transferred RRset, the RRSIG,
and the DNS public key in order to create a verified
reference to the zone that was transferred.