108 Digital Life Security #12: DNS — The Internet's Address Book and a Security Control You May Not Realize You Have

Digital Life Security Series ...Practical ways to protect your devices, accounts, privacy, information and home

You open your browser and type the name of a website.

You do not normally type its IP address.

You type a name.

Somehow, within a fraction of a second, your computer figures out where that website can be found.

That process depends heavily on one of the most important systems on the Internet:

DNS.

The Domain Name System is often described as the Internet's address book.

That is a useful starting point.

But DNS does much more than help us find websites.

It helps direct email.

It publishes security information.

It helps authenticate email.

It helps applications locate services.

And because DNS helps determine where our computers connect, it also has important security implications.

We Have Already Been Using DNS

DNS has quietly appeared throughout this series.

When we discussed email security, SPF information was published through DNS.

DKIM public keys were published through DNS.

DMARC policies were published through DNS.

When we discussed networks, DHCP could tell a device which DNS server to use.

When we followed packets through VLANs, devices still needed DNS to locate Internet services by name.

DNS has been working behind the scenes the entire time.

Humans Like Names

Imagine trying to remember the numerical network address of every website you visit.

Names are much easier.

Instead of remembering a changing collection of IP addresses, we can remember:

example.com

DNS helps connect that human-friendly name to the technical information computers need.

But DNS is not simply one giant database sitting somewhere on the Internet.

It is a distributed, hierarchical system.

Start at the End: Your Computer Needs an Answer

Suppose you enter:

www.example.com

Your browser needs to determine where that name should lead.

Before sending a new DNS request across the Internet, the computer or browser may first check information it already has.

Perhaps the answer was recently looked up and is still cached.

If not, the system generally asks a DNS resolver for help.

What Is a DNS Resolver?

A DNS resolver is a system that performs DNS lookups on behalf of clients.

Your device may learn which resolver to use through DHCP or other network configuration.

That resolver might be operated by:

• Your Internet service provider
• Your router or local network
• Your organization
• A public DNS provider
• A security service
• Another configured DNS system

Your computer essentially asks:

Where can I find this name?

The Resolver May Already Know

DNS resolvers use caching.

If another user recently asked for the same information, the resolver may already have a valid answer stored temporarily.

Instead of repeating the entire lookup process, it can return the cached answer.

This improves speed and reduces unnecessary DNS traffic.

But cached information does not live forever.

TTL: How Long Should We Remember This?

DNS records commonly include a value called TTL.

TTL stands for Time To Live.

It tells caching systems approximately how long the information may be retained before it should be refreshed.

A shorter TTL can allow DNS changes to be noticed sooner.

A longer TTL can reduce lookup traffic and improve caching efficiency.

This is why DNS changes may not appear everywhere instantly.

Different systems may still have previously cached information until its allowed lifetime expires.

What If the Resolver Does Not Know?

Now the real DNS hierarchy becomes visible.

If the recursive resolver does not already have the necessary information, it can begin asking other DNS servers where to look.

A simplified journey looks like this:

Client → Recursive Resolver → Root → Top-Level Domain → Authoritative DNS

Let's break that apart.

The Root DNS Servers

At the top of the DNS hierarchy is the root.

The root system does not need to know the IP address of every website on Earth.

Instead, it can direct resolvers toward the DNS infrastructure responsible for top-level domains.

For example:

.com

.org

.net

.gov

and many others.

The root essentially helps answer:

Who knows more about this part of the DNS hierarchy?

The Top-Level Domain

Suppose we are looking for:

example.com

The resolver can be directed toward the DNS servers responsible for the .com top-level domain.

Those servers do not necessarily provide the final IP address either.

Instead, they can identify the authoritative DNS servers responsible for:

example.com

We are moving down the hierarchy.

Authoritative DNS

An authoritative DNS server provides DNS information for a domain for which it is authoritative.

This is where records for the domain are maintained.

The recursive resolver can ask:

What is the address associated with www.example.com?

The authoritative system returns the appropriate DNS information.

The resolver returns the answer to the client and may cache it according to the record's TTL.

Now the browser knows where to attempt its network connection.

DNS Does Not Fetch the Website

This distinction is important.

DNS does not normally download the web page.

DNS helps the computer determine where the service can be reached.

After DNS resolution, the browser still has to establish the appropriate network connection and communicate with the web server.

Then HTTPS, TLS certificates, HTTP, browser security, and everything else we have discussed come into play.

DNS answers a location question.

HTTPS answers different security questions.

Another Layer in the Journey

Our web-page journey now looks something like this:

1. You enter a domain name.

2. DNS helps determine where that domain can be reached.

3. Your device sends packets toward the destination.

4. Routers move the packets between networks.

5. Firewalls apply network policy.

6. TLS helps establish an encrypted HTTPS connection and authenticate the site identity represented by the certificate.

7. HTTP carries web requests and responses.

8. The browser processes the content.

Different systems.

Different jobs.

Working together.

Common DNS Record Types

DNS contains different types of records for different purposes.

Let's meet several of the most common ones.

A Records

An A record associates a name with an IPv4 address.

Conceptually:

www.example.com → 192.0.2.25

The actual address above is simply an example.

AAAA Records

An AAAA record associates a name with an IPv6 address.

The four A's may look strange at first, but they are simply the DNS record type used for IPv6 addresses.

CNAME Records

A CNAME record creates a canonical-name relationship, allowing one DNS name to refer to another name.

For example, a service might direct one hostname toward another hostname rather than directly specifying an IP address.

This can make service management more flexible.

MX Records

MX stands for Mail Exchange.

MX records tell email systems which mail servers are responsible for receiving email for a domain.

If someone sends email to:

person@example.com

the sending mail system can use DNS to discover where mail for example.com should be delivered.

DNS is therefore part of the email-delivery infrastructure.

TXT Records

TXT records allow domains to publish text information through DNS.

They are used for many purposes.

Security-related examples include:

• SPF information
• DKIM-related information
• DMARC policies
• Domain ownership verification
• Other service configuration

This is why we encountered DNS so heavily during our email-security discussion.

DNS Is Part of Identity

This is an important realization.

DNS is not merely helping us locate servers.

Organizations also publish information through DNS that helps other systems make decisions about domain identity and authorization.

If an attacker gains control over a domain's DNS configuration, that can become a serious security event.

They may be able to redirect services, interfere with email configuration, or alter security-related DNS records.

Your Domain Registrar Is a Security Account

Where is control over a domain ultimately managed?

Often through a domain registrar account and DNS hosting provider.

That means your domain registrar account deserves strong protection.

A compromised registrar or DNS-management account could allow an attacker to make powerful changes without ever logging into the web server itself.

Protect important domain accounts with:

• Strong unique credentials
• Multifactor authentication or passkeys when available
• Current recovery information
• Limited administrative access
• Careful monitoring of unexpected changes

We have discovered another high-value account.

Security Is About Control Points

Our series keeps revealing systems that have disproportionate power.

Your email account can reset other accounts.

Your password manager stores credentials.

Your phone may hold authentication factors.

Your router controls network traffic.

Your registrar and DNS systems can control where Internet services are located.

These are important control points.

Security effort should reflect the amount of power an account or system possesses.

What Happens If DNS Lies?

Suppose you type the correct website name.

But the DNS information your computer receives is false.

Instead of directing you toward the legitimate system, the false information points somewhere controlled by an attacker.

This is one reason DNS security matters.

Attacks involving false DNS information may be described using terms such as DNS spoofing or DNS cache poisoning, depending on the technique involved.

DNS Cache Poisoning

A resolver may cache DNS answers.

If an attacker can somehow cause incorrect information to enter that cache, users relying on the resolver might receive the fraudulent information until it expires or is removed.

Modern DNS implementations contain protections intended to make such attacks more difficult, but the concept is important.

A poisoned address book can send people to the wrong place.

What About HTTPS?

Here our security layers help one another.

Suppose malicious DNS sends your browser toward the wrong server while you are trying to reach:

bank.example

The attacker still faces another problem.

Your browser expects a valid TLS certificate for the hostname you requested.

If the fraudulent server cannot present a certificate that validates appropriately for that name, the browser should produce a certificate warning or fail the secure connection.

This is another example of defense in depth.

DNS helps locate the destination.

TLS independently helps authenticate the secure endpoint.

One layer can help detect failure in another.

Do Not Ignore Certificate Warnings

This also explains why bypassing certificate warnings can be dangerous.

If something has redirected your connection to the wrong server, the certificate warning may be the security system telling you:

The server I reached cannot prove that it is the site you asked for.

Clicking through the warning removes an important layer of protection.

DNSSEC Adds Cryptographic Validation

DNS has another security technology called DNSSEC, or Domain Name System Security Extensions.

DNSSEC allows DNS information to be cryptographically signed so validating resolvers can verify that certain DNS data is authentic and has not been improperly modified between the authoritative source and validation.

This helps protect the integrity and authenticity of DNS responses.

But DNSSEC does something very specific.

DNSSEC Does Not Encrypt DNS

This distinction is extremely important.

DNSSEC helps verify DNS data.

DNSSEC does not primarily hide the DNS query from observers.

For confidentiality, we need to discuss something else.

Traditional DNS Queries Can Be Visible

Traditional DNS traffic has historically often been sent without encryption between the client and its resolver.

That means systems along that portion of the network path may potentially observe DNS queries.

Even if the website itself uses HTTPS, the DNS lookup may reveal information about which domain is being requested.

This led to technologies designed to encrypt communication between clients and DNS resolvers.

DNS over HTTPS

DNS over HTTPS, commonly abbreviated DoH, carries DNS queries through HTTPS.

This encrypts the communication between the client and the chosen DoH resolver.

Someone simply observing that local network path cannot read the DNS request in the same traditional way.

DNS over TLS

DNS over TLS, or DoT, is another approach.

It uses TLS to create an encrypted channel for DNS communication between the client and resolver.

DoH and DoT use different transport approaches, but both can provide confidentiality for that portion of the DNS journey.

Encrypted DNS Does Not Make You Invisible

This is another place where we should avoid turning a security feature into a magical privacy shield.

Encrypting DNS prevents certain observers from simply reading the DNS query between the client and resolver.

But other network information may still reveal information about communications.

The DNS resolver itself may still receive the queries.

The destination service still receives connections.

Other metadata may remain visible.

Encryption protects specific information along specific parts of a communication path.

Always ask:

Encrypted from whom?

Between which endpoints?

Who Do You Trust With Your DNS?

This becomes an interesting security question.

Your DNS resolver receives information about the names your devices are attempting to locate.

You therefore have a trust relationship with that resolver.

The resolver might belong to your ISP.

It might be a public DNS service.

It might be operated locally.

It might be part of a security filtering service.

The decision is not simply:

Which DNS server is fastest?

Privacy, security, reliability, filtering, logging policies, and operational trust can also matter.

DNS Can Become a Security Filter

Here is where DNS becomes especially interesting for home and small-business security.

A security-focused DNS service can maintain information about domains known or suspected to be associated with:

• Malware
• Phishing
• Command-and-control systems
• Fraudulent sites
• Other unwanted destinations

When a device asks for one of those domains, the DNS service can refuse to return the normal destination or otherwise block the lookup according to policy.

The device may never reach the malicious server.

Stop the Connection Before It Starts

Imagine malware on a computer attempting to contact:

malicious-example.invalid

Before connecting, it asks DNS where that domain is located.

A security-filtering resolver recognizes the domain as blocked.

The normal address is not provided.

The connection may be stopped before the device reaches the malicious destination.

That is another layer of defense.

DNS Filtering Is Not Perfect

An attacker might use a previously unknown domain.

Malware might connect directly to an IP address.

A compromised legitimate website might still resolve normally.

A device might bypass the intended DNS resolver if network policy allows it.

Encrypted DNS can also complicate network-level DNS filtering if devices independently select outside resolvers.

So DNS filtering should not be treated as complete protection.

It is another layer.

Defense in Depth Keeps Appearing

Consider a malicious website.

We might have:

DNS filtering attempting to block the domain.

Browser protection identifying known malicious content.

TLS validation checking certificates.

Endpoint security watching downloaded files or behavior.

User awareness recognizing the suspicious request.

Network segmentation limiting what a compromised device could reach.

No one layer has to carry the entire security burden.

DNS Logs Can Become Evidence

Remember our principle:

Security is about evidence.

DNS activity can sometimes provide useful evidence during an investigation.

Suppose a computer begins repeatedly resolving a strange domain every few minutes.

That does not automatically prove the computer is infected.

But it may be worth investigating.

DNS logs can help answer questions such as:

• Which device requested a domain?
• When was it requested?
• How frequently?
• Was the domain expected?
• Was it blocked?
• Are several devices requesting it?

We are beginning to move from prevention toward network monitoring.

DNS Can Help Us See the Network Thinking

Before many applications communicate with an Internet service, they need to discover where that service lives.

DNS requests can therefore reveal something about what devices are attempting to do.

A smart television may contact several services.

A camera may contact a cloud platform.

A phone may contact dozens of Internet services.

Looking at DNS activity can be an educational way to discover just how much communication happens quietly in the background.

This Could Be Very Interesting With IoT Devices

Suppose we place IoT devices or cameras on their own network.

We might eventually ask:

Which domains are these devices contacting?

How often?

Why?

Do they still function if unnecessary Internet access is restricted?

Do cameras need cloud connectivity?

Do they contact servers we expected?

Segmentation gives us control.

DNS and network monitoring can give us visibility.

Control and Visibility

Those two words are worth remembering.

Control: What communication do we permit?

Visibility: What communication is actually happening?

A firewall provides control.

Logs provide visibility.

DNS filtering can provide both.

A mature security design benefits from having both control and visibility.

What DNS Server Are You Using?

Here is a simple exercise.

Look at the network configuration on one of your devices or in your router.

Can you determine which DNS resolver is being used?

Did the device receive that DNS information through DHCP?

Is the router acting as an intermediary?

Is the device using an encrypted DNS service?

Does the browser have its own DNS configuration?

Different systems may handle DNS differently.

The goal is not to immediately change anything.

The goal is to understand the path.

Then Look at Your Own Domain

If you manage a website or email domain, DNS becomes even more interesting.

Look at its DNS records.

Can you identify:

• A records
• AAAA records
• MX records
• CNAME records
• TXT records
• SPF information
• DKIM information
• DMARC information

Instead of seeing a mysterious list of records, you can begin asking what each one actually does.

DNS Is Infrastructure

DNS is easy to overlook because it normally works silently.

But imagine if DNS stopped working.

Your Internet connection might still physically exist.

Your Ethernet cable could be connected.

Your Wi-Fi could be working.

Your router could be functioning.

You might even be able to reach systems directly by IP address.

Yet many ordinary Internet activities would appear broken because names could no longer be resolved.

This gives us another troubleshooting lesson.

“The Internet is down” may actually mean “DNS is not working.”

Follow the Layers

If a website will not load, we can now ask:

Does the device have network connectivity?

Did DHCP provide valid configuration?

Can the device reach its gateway?

Is DNS resolving the hostname?

Can packets reach the destination?

Is the firewall allowing the traffic?

Is TLS working?

Is the web server responding?

Is the browser processing the page correctly?

That is a much better troubleshooting process than simply restarting everything and hoping.

DNS Has Three Security Questions

We can summarize DNS security with three broad questions.

Integrity:
Did we receive the correct DNS information?

Confidentiality:
Who can see what names we are requesting?

Availability:
Can we obtain the DNS information when we need it?

Those should look familiar.

We have returned to the CIA triad:

Confidentiality. Integrity. Availability.

The same security model we introduced while discussing phone security now applies to DNS infrastructure.

The Pieces Keep Connecting

We began this series with ordinary users trying to protect themselves online.

Now we can see relationships among:

Browsers.

Email.

SPF.

DKIM.

DMARC.

Passwords.

Passkeys.

Phones.

Networks.

DHCP.

Routers.

Firewalls.

VLANs.

DNS.

TLS.

They are not separate worlds.

They are pieces of the same digital infrastructure.

DNS Is More Than an Address Book

Calling DNS the Internet's address book is useful.

But now we know it is much more.

DNS helps locate services.

It helps route email.

It publishes authentication information.

It supports domain ownership and service configuration.

It can provide a layer of security filtering.

It can provide evidence about network activity.

And control of DNS can mean control over important parts of a digital identity.

The next time you type a website name and the page appears almost instantly, remember:

A remarkable distributed system just helped your computer answer one of the most fundamental questions in networking:

Where do I need to go?