Cloud DNS and Name Resolution

Cloud workloads should not depend on people remembering IP addresses. DNS provides the naming layer that allows users, applications, and services to locate resources reliably.

Welcome to Lab 06 of the CompTIA Cloud+ practical lab sequence.

In the previous labs, you built:

a cloud virtual network
public, application, and database subnets
route tables
public and private connectivity
network security controls

You can now answer:

Can traffic reach the destination?

Now you will add the naming layer and answer:

Can the workload find the destination by name?

You will move from:

10.10.20.15

to:

app.cloudplus.lab

and understand how that hostname is resolved to the correct IP address.

🎯 Mission Information

Item	Details
Lab	06 — Cloud DNS and Name Resolution
Difficulty	Beginner → Intermediate
Estimated Time	60–90 Minutes
Certification Alignment	CompTIA Cloud+
Primary Focus	DNS & Service Name Resolution
Previous Lab	05 — Cloud Security Groups and Network Access Controls
Career Alignment	Cloud Administrator, Cloud Engineer, Cloud Support Engineer, Cloud Security Engineer
Major Skills	DNS Records, Public DNS, Private DNS, Resolution, Troubleshooting
Deliverable	Cloud DNS Design + Name Resolution Validation Report

🏢 Scenario

Your cloud environment now contains:

Internet
   ↓
Web Tier
   ↓
Application Tier
   ↓
Database Tier

The application team has been using IP addresses during initial testing.

For example:

Web Server:
10.10.10.10

Application Server:
10.10.20.10

Database:
10.10.30.10

This approach becomes difficult to maintain because:

addresses may change
workloads may be replaced
applications should not hard-code infrastructure IPs
troubleshooting becomes harder

Your manager asks you to implement DNS-based naming.

The desired model is:

web.cloudplus.lab
        ↓
10.10.10.x

app.cloudplus.lab
        ↓
10.10.20.x

db.cloudplus.lab
        ↓
10.10.30.x

The web application should locate the application server by name, and the application server should locate the database by name.

🎯 Lab Objectives

By completing this lab, you should be able to:

explain DNS
understand hostname-to-IP resolution
distinguish public and private DNS
understand DNS zones
explain common DNS record types
create DNS records
understand cloud DNS resolvers
configure internal service names
validate name resolution
distinguish DNS failures from routing failures
identify incorrect DNS records
understand TTL concepts
troubleshoot cloud DNS systematically
document cloud DNS architecture
explain DNS during cloud technical interviews

🧠 Why This Lab Matters

A beginner may configure an application using:

Database Server:
10.10.30.25

That works until:

Database Rebuilt
      ↓
New IP
      ↓
Application Breaks

A stronger model uses:

db.cloudplus.lab
      ↓
DNS
      ↓
Current Database IP

Then applications depend on:

a stable service name

rather than:

a potentially changing infrastructure address.

01 — Understand DNS

DNS stands for:

Domain Name System

Its basic purpose is to translate names into network information.

A simplified process is:

User / Application
      ↓
Hostname
      ↓
DNS Query
      ↓
DNS Resolver
      ↓
DNS Record
      ↓
IP Address

🧠 Simple Example

A user enters:

portal.example.com

DNS may return:

203.0.113.20

The network connection then uses the IP address.

02 — Separate DNS From Connectivity

DNS performs:

name resolution.

Routing performs:

packet forwarding.

Security controls determine:

whether communication is permitted.

Use this model:

Hostname
   ↓
DNS
   ↓
IP Address
   ↓
Routing
   ↓
Security
   ↓
Service

🚨 Important

A DNS record can resolve correctly while the application remains unreachable.

Likewise, the network can work perfectly while DNS is broken.

03 — Review the Current Cloud Environment

Your environment should resemble:

10.10.0.0/16
    |
    ├── Public
    │   10.10.10.0/24
    |
    ├── Application
    │   10.10.20.0/24
    |
    └── Database
        10.10.30.0/24

Identify the private IP addresses currently assigned to your test workloads.

📝 Record

Web VM:

Private IP:

Application VM:

Private IP:

Database VM:

Private IP:

04 — Understand a DNS Zone

A DNS zone represents an administrative namespace.

For this lab, use a private training namespace such as:

cloudplus.lab

The zone can contain records such as:

web.cloudplus.lab
app.cloudplus.lab
db.cloudplus.lab

🧠 DNS Hierarchy

Conceptually:

cloudplus.lab
    |
    ├── web.cloudplus.lab
    ├── app.cloudplus.lab
    └── db.cloudplus.lab

05 — Understand Public DNS

Public DNS provides records accessible from public DNS infrastructure.

Example:

www.example.com
      ↓
Public DNS
      ↓
Public IP

Public DNS is appropriate for services intended to be publicly discoverable.

06 — Understand Private DNS

Private DNS provides naming inside controlled environments.

Example:

db.cloudplus.lab
      ↓
Private DNS
      ↓
10.10.30.10

This name should not necessarily need to exist on the public internet.

🧠 Security Benefit

Private DNS helps keep internal service names and addresses within the environment where they are required.

07 — Public vs Private DNS

Use:

Public DNS	Private DNS
Internet-facing names	Internal service names
Publicly resolvable	Private-network resolvable
Often maps to public services	Often maps to private IPs
Used by external users	Used by internal workloads

08 — Understand DNS Resolvers

A DNS resolver receives DNS queries from clients and attempts to find the answer.

Conceptually:

Application
    ↓
DNS Resolver
    ↓
DNS Namespace
    ↓
Record

Cloud providers often provide built-in DNS-resolution services for workloads.

09 — Identify the DNS Resolver Used by Your VM

On a Linux VM, inspect the current resolver configuration.

Depending on the system, use:

cat /etc/resolv.conf

or appropriate system-resolution tooling.

Record:

DNS Resolver:

Search Domain:

Notes:

🧠 Important

Modern Linux distributions may use local resolver components, so the address visible in /etc/resolv.conf may not always be the upstream DNS server directly.

Focus on understanding:

which resolution path the system uses.

10 — Test Existing DNS Resolution

From a lab VM, test a known hostname.

For example:

nslookup example.com

or:

dig example.com

if available.

Observe:

query name
returned IP
responding resolver

11 — Understand A Records

An A record maps a hostname to an IPv4 address.

Example:

app.cloudplus.lab
      ↓
A
      ↓
10.10.20.10

12 — Understand AAAA Records

An AAAA record maps a hostname to an IPv6 address.

Conceptually:

app.example
      ↓
AAAA
      ↓
IPv6 Address

13 — Understand CNAME Records

A CNAME creates an alias to another hostname.

Example:

portal.cloudplus.lab
      ↓
CNAME
      ↓
web.cloudplus.lab

🧠 CNAME Use

CNAME can help when:

multiple user-friendly names should reference another canonical hostname.

14 — Understand MX Records

MX records identify mail servers for a domain.

They are not the focus of this lab, but you should understand their purpose for Cloud+.

15 — Understand TXT Records

TXT records can store text-based information.

They are commonly used for:

domain verification
security-related configuration
email-related validation

16 — Understand PTR Records

PTR records support reverse lookup.

Instead of:

Name → IP

reverse DNS can support:

IP → Name

17 — Understand TTL

TTL means:

Time To Live

It determines how long DNS information may be cached.

Conceptually:

DNS Record
 ↓
TTL
 ↓
Cache Duration

🧠 Why TTL Matters

A long TTL may:

reduce DNS queries
make changes take longer to propagate through caches

A short TTL may:

support faster change
increase DNS-query frequency

18 — Create the Private DNS Zone

Using your provider’s supported private DNS service, create a lab zone.

Example:

Zone:
cloudplus.lab

Associate it with:

cloudplus-lab-net-01

or your equivalent virtual network where required.

🧠 Important

Private DNS association determines:

which networks can resolve the private namespace.

19 — Apply Tags

Use your lab standards.

Example:

Tag	Value
Environment	Lab
Course	CompTIA-CloudPlus
Purpose	DNS
Owner	Student

20 — Create the Web DNS Record

Create:

Name:
web.cloudplus.lab

Type:
A

Value:
<Web Private IP>

🧠 Why Use the Private IP?

Internal workload-to-workload communication should generally use the private network where appropriate.

21 — Create the Application DNS Record

Create:

Name:
app.cloudplus.lab

Type:
A

Value:
<Application Private IP>

22 — Create the Database DNS Record

Create:

Name:
db.cloudplus.lab

Type:
A

Value:
<Database Private IP>

23 — Record the DNS Design

Hostname	Record	Address	Purpose
web.cloudplus.lab	A	10.10.10.x	Web Tier
app.cloudplus.lab	A	10.10.20.x	App Tier
db.cloudplus.lab	A	10.10.30.x	DB Tier

24 — Validate the Web Record

From an appropriate VM, run:

nslookup web.cloudplus.lab

or:

dig web.cloudplus.lab

Expected:

web.cloudplus.lab
      ↓
Web Private IP

25 — Validate the Application Record

Run:

nslookup app.cloudplus.lab

Expected:

application server private IP.

26 — Validate the Database Record

Run:

nslookup db.cloudplus.lab

Expected:

database private IP.

27 — Test Application-Tier Resolution

From the web workload, test:

app.cloudplus.lab

This validates the intended service-discovery path:

Web
 ↓
DNS
 ↓
Application IP

28 — Test Database Resolution

From the application workload, test:

db.cloudplus.lab

The intended path is:

Application
 ↓
DNS
 ↓
Database IP

29 — Separate Resolution From Port Connectivity

Suppose:

db.cloudplus.lab

resolves correctly to:

10.10.30.10

but the application cannot connect.

DNS is probably not the root cause.

Check:

DNS
  ✓
   ↓
Routing
   ↓
Security Group
   ↓
Host Firewall
   ↓
Database Service

30 — Test by Name and IP

For a workload service, perform both:

Connection by IP

and:

Connection by Hostname

Use the results to narrow the problem.

🧠 Diagnostic Matrix

IP	Hostname	Likely Area
Works	Works	Connectivity Healthy
Works	Fails	DNS
Fails	Fails	Routing/Security/Service
Fails	Resolves	DNS Works; Connectivity Issue

31 — Understand Internal Service Discovery

Applications should ideally use names such as:

db.cloudplus.lab

rather than hard-coded IPs.

This allows infrastructure to change underneath the application.

🧠 Example

Today:

db.cloudplus.lab
      ↓
10.10.30.10

Tomorrow:

db.cloudplus.lab
      ↓
10.10.30.25

The application configuration can remain the same if DNS is updated correctly.

32 — Change a DNS Record

In your lab, modify one test record to another approved test address or secondary workload.

Observe that:

Hostname

remains unchanged while:

Resolved IP

changes.

33 — Observe DNS Caching

Immediately query the record again.

Depending on:

TTL
resolver
local cache

you may temporarily see the previous result.

🧠 DNS Troubleshooting Lesson

After DNS changes, ask:

Could I be seeing cached information?

34 — Restore the Correct Record

Return the hostname to its intended workload IP.

Validate again.

35 — Understand DNS Propagation

Public DNS changes may take time to appear consistently because of caching.

Private cloud DNS environments may behave differently depending on implementation.

Do not assume:

DNS update means every client instantly sees the change.

36 — Create an Alias Record Concept

Where supported, create or document an alias such as:

portal.cloudplus.lab
      ↓
web.cloudplus.lab

This demonstrates:

one service can have more than one logical name.

37 — Test the Alias

Resolve:

portal.cloudplus.lab

Confirm it ultimately maps to the expected web workload.

38 — Review the Private DNS Association

Confirm the DNS zone is associated with the correct:

virtual network
project
private environment

🚨 Common Misconfiguration

The zone and records may be correct, but if the private network is not associated:

workloads may not be able to resolve them.

39 — Test Resolution From the Wrong Environment

Where safe and practical, attempt to resolve:

db.cloudplus.lab

from outside the associated private environment.

Expected:

private DNS should not necessarily resolve publicly.

🧠 Security Lesson

Internal DNS should generally not expose unnecessary internal names to external users.

40 — Understand Split DNS

Some architectures use different answers depending on where a query originates.

Conceptually:

Internal User
      ↓
app.example.com
      ↓
Private IP

while:

External User
      ↓
app.example.com
      ↓
Public IP

This is sometimes called:

split DNS
split-horizon DNS

41 — Understand DNS and Load Balancing

Later, when you introduce load balancing, DNS may point to:

Application Name
      ↓
Load Balancer
      ↓
Multiple Workloads

rather than directly to one VM.

🧠 Architecture Evolution

Your current model:

web.cloudplus.lab
      ↓
Single VM

may later become:

web.cloudplus.lab
      ↓
Load Balancer
      ↓
VM 1
VM 2

42 — Understand DNS Failure Symptoms

Common DNS symptoms include:

hostname not found
wrong IP returned
intermittent resolution
stale IP
public name works but private name fails
one VM resolves while another does not

43 — Troubleshooting Scenario — IP Works, Hostname Fails

This is the classic DNS scenario.

Use:

Application Works by IP
        ↓
Hostname Fails
        ↓
Check DNS

Do not immediately modify:

route tables
security groups

without evidence.

44 — Check the Hostname

Confirm there is no typing error.

Example:

Expected:

app.cloudplus.lab

Entered:

apps.cloudplus.lab

45 — Query the DNS Record Directly

Use:

nslookup app.cloudplus.lab

or:

dig app.cloudplus.lab

Check whether:

response exists
address is correct

46 — Check the Resolver

Verify the client is using the expected DNS resolver.

Ask:

Is this workload actually sending its queries to the cloud/private DNS service?

47 — Check DNS Zone Association

Verify:

Private DNS Zone
      ↓
Correct Cloud Network

48 — Check the DNS Record

Review:

hostname
record type
IP value
TTL

49 — Troubleshooting Scenario — Wrong Address Returned

Suppose:

app.cloudplus.lab

returns:

10.10.30.10

instead of the application address.

This is primarily:

a DNS-record configuration problem.

50 — Correct the Record

Update it to the intended application IP.

Re-query the name.

If the old answer remains temporarily:

consider caching.

51 — Troubleshooting Scenario — One VM Resolves, Another Does Not

Compare:

VM A Resolver
vs
VM B Resolver

Also check:

subnet
virtual network
DNS configuration
zone association

52 — Troubleshooting Scenario — Resolution Works, Connection Fails

Suppose:

app.cloudplus.lab
      ↓
10.10.20.10

resolves successfully.

But TCP connectivity fails.

Move down the stack:

DNS
 ✓
 ↓
Routing
 ↓
Cloud Security
 ↓
Host Firewall
 ↓
Service

53 — Troubleshooting Scenario — Public DNS Works, Private DNS Fails

Investigate:

private DNS zone
network association
resolver settings
private record

54 — Troubleshooting Scenario — DNS Recently Changed

Consider:

Cached Record

before repeatedly changing the DNS configuration.

55 — Deliberately Break a Record

In your isolated lab, temporarily change:

app.cloudplus.lab

to an incorrect test IP.

Attempt to use the application name.

Observe the failure.

56 — Investigate the Failure

Use:

Hostname
 ↓
DNS Query
 ↓
Returned IP
 ↓
Expected IP Comparison

Identify:

incorrect DNS record.

57 — Restore the Correct DNS Record

Return:

app.cloudplus.lab

to the correct application IP.

Re-test until the correct result is returned.

58 — Document the DNS Incident

Use:

Problem:

Affected Hostname:

Expected IP:

Resolved IP:

Root Cause:

Corrective Action:

Validation:

Lesson Learned:

59 — Create a DNS Troubleshooting Flow

Use:

Hostname Correct?
      ↓
DNS Query Sent?
      ↓
Resolver Correct?
      ↓
Record Exists?
      ↓
Record Value Correct?
      ↓
Zone Association Correct?
      ↓
Cache?
      ↓
Resolved IP Reachable?

60 — Review DNS Security Considerations

DNS is part of the security architecture.

Consider:

who can modify DNS records
whether administrative changes are logged
which zones are public
which zones are private

🧠 Why DNS Administration Is Sensitive

An unauthorized DNS change could redirect:

Users
 ↓
Trusted Hostname
 ↓
Wrong Destination

DNS modification should therefore be protected by:

IAM
logging
change control

61 — Review Public DNS Exposure

Do not publish internal records publicly without requirement.

Avoid exposing unnecessary information such as:

internal-db.example.com

if it provides no business benefit.

62 — Review DNS Logging

Where your provider supports DNS query or administrative logging, identify what telemetry is available.

Possible events include:

DNS query activity
record creation
record modification
record deletion

🧠 Incident Response Connection

DNS logs can help answer:

Which domain did this workload attempt to contact?

63 — Review DNS and Malware Detection

Security teams often use DNS activity to investigate:

unusual domains
newly contacted destinations
suspicious external communication

This becomes more important later in:

CySA+
incident-response labs
cloud incident investigation

64 — Build the Final DNS Architecture Diagram

                 Private DNS Zone
                  cloudplus.lab
                        |
         +--------------+--------------+
         |              |              |
         v              v              v
 web.cloudplus.lab app.cloudplus.lab db.cloudplus.lab
         |              |              |
         v              v              v
  10.10.10.x      10.10.20.x      10.10.30.x
         |              |              |
         v              v              v
      Web Tier       App Tier        DB Tier

65 — Build the Service Communication Diagram

User / Client
      ↓
web.cloudplus.lab
      ↓
Web Tier
      ↓
app.cloudplus.lab
      ↓
Application Tier
      ↓
db.cloudplus.lab
      ↓
Database Tier

66 — Create the DNS Record Register

Name	Type	Value	Scope	Purpose
web.cloudplus.lab	A	10.10.10.x	Private	Web
app.cloudplus.lab	A	10.10.20.x	Private	Application
db.cloudplus.lab	A	10.10.30.x	Private	Database
portal.cloudplus.lab	Alias/CNAME	web.cloudplus.lab	Private	Friendly Name

67 — Update Your Resource Inventory

Add:

Resource	Type	Purpose	Status
cloudplus.lab	Private DNS Zone	Internal Naming	Active
web.cloudplus.lab	DNS Record	Web Tier	Active
app.cloudplus.lab	DNS Record	App Tier	Active
db.cloudplus.lab	DNS Record	Database Tier	Active

68 — Capture Evidence

Capture sanitized evidence of:

DNS zone
records
network association
successful name resolution
intentionally broken resolution
restored resolution

Do not capture:

private credentials
account secrets
sensitive production names

69 — Perform Final Validation

Verify:

web.cloudplus.lab
      ↓
Correct Web IP

app.cloudplus.lab
      ↓
Correct App IP

db.cloudplus.lab
      ↓
Correct DB IP

Then verify:

Name Resolution
      ↓
Routing
      ↓
Security
      ↓
Application Connectivity

🧪 Final Validation Checklist

Validation	Status
Private DNS zone created
Network association configured
Web DNS record created
App DNS record created
DB DNS record created
Web record resolves correctly
App record resolves correctly
DB record resolves correctly
Public/private DNS understood
TTL reviewed
Alias concept tested
DNS vs routing differentiated
Broken record tested
Root cause identified
Record restored
DNS documentation completed
Resource inventory updated

70 — Cleanup Decision

Keep the private DNS zone and core records if you are continuing the Cloud+ sequence.

They will be useful in later labs involving:

three-tier architecture
load balancing
high availability
monitoring
troubleshooting

Remove only temporary test records that are no longer required.

🎯 Certification Connection

A Cloud+ scenario may say:

A user can access a server by IP but not by hostname.

Think:

IP Works
Hostname Fails
      ↓
DNS

Another may say:

The hostname resolves correctly, but the application still cannot connect.

Think:

DNS
 ✓
 ↓
Routing
 ↓
Security
 ↓
Service

The key is learning to isolate:

which layer is failing.

🎤 Interview Questions

Practice without notes.

1. What is DNS?

2. What problem does DNS solve?

3. What is a DNS resolver?

4. What is a DNS zone?

5. What is an A record?

6. What is an AAAA record?

7. What is a CNAME?

8. What is a PTR record?

9. What is TTL?

10. Public DNS vs private DNS?

11. Why should applications use hostnames instead of hard-coded IP addresses?

12. How would you troubleshoot a hostname that does not resolve?

13. Why can a DNS change appear delayed?

14. What is DNS caching?

15. What is split DNS?

16. Why is DNS administration security-sensitive?

18. If DNS resolves correctly but the application is unreachable, what would you check?

19. Why might one VM resolve a private hostname while another cannot?

20. How does DNS support cloud high availability?

🚨 Scenario Interview Question 1

A user can access 10.10.20.10 but cannot access app.cloudplus.lab.

Focus on:

DNS Resolver
 ↓
DNS Record
 ↓
Zone Association
 ↓
Caching

🚨 Scenario Interview Question 2

db.cloudplus.lab resolves, but the application cannot connect to the database.

DNS is working.

Move to:

Route
 ↓
Security Group
 ↓
Host Firewall
 ↓
Database Listener
 ↓
Authentication

🚨 Scenario Interview Question 3

A DNS record was updated, but some clients still receive the old address.

Consider:

cached DNS information and TTL.

🚨 Scenario Interview Question 4

Internal workloads cannot resolve a private DNS record, but public DNS works.

Check:

private zone
virtual-network association
resolver configuration
record existence

🚨 Scenario Interview Question 5

The database server was replaced and received a new IP.

A strong design uses:

db.cloudplus.lab
      ↓
Update DNS
      ↓
New Database IP

rather than modifying every application configuration with a new IP.

🚨 Scenario Interview Question 6

A developer wants to publish all internal hostnames in public DNS because it makes troubleshooting easier.

Discuss:

whether public publication is required
information exposure
private DNS
operational alternatives

🚨 Scenario Interview Question 7

An unauthorized DNS record change redirects a production hostname.

Discuss:

IAM
audit logging
change history
immediate record restoration
impact assessment
prevention

🧠 DNS Troubleshooting Interview Framework

Use:

Hostname
 ↓
Resolver
 ↓
Zone
 ↓
Record
 ↓
Returned IP
 ↓
Route
 ↓
Security
 ↓
Service

💬 Interview Tip

Avoid:

“I would restart DNS.”

A stronger answer is:

“I would first confirm the exact hostname and query it directly, verify which resolver the client is using, check the relevant public or private zone and record value, validate network or zone association, consider TTL and caching, and then test connectivity to the resolved IP to determine whether the remaining issue is DNS, routing, security, or the application.”

That demonstrates Cloud Support Engineer thinking.

📁 Portfolio Deliverables

Keep sanitized versions of:

1. DNS Architecture Diagram

Show:

Private DNS
 ↓
Web / App / DB Names
 ↓
Private IPs

2. DNS Record Register

Document:

hostname
record type
IP
scope
purpose

3. DNS Troubleshooting Case

Show:

Incorrect Record
 ↓
Wrong IP
 ↓
Investigation
 ↓
Correction
 ↓
Validation

4. Public vs Private DNS Design

Explain which records belong in each namespace and why.

5. Service Naming Architecture

Show the application using:

app.cloudplus.lab
db.cloudplus.lab

rather than hard-coded addresses.

📝 Resume Examples

Instead of:

Configured DNS.

Use:

Implemented private cloud DNS for segmented web, application, and database workloads using internal service hostnames, DNS records, virtual-network association, and validated hostname-to-IP resolution.

Or:

Troubleshot cloud name-resolution failures by validating client resolver configuration, DNS zones, record values, caching, network associations, routing, and downstream service connectivity.

⭐ Job-Readiness Check

You should now be able to:

explain DNS clearly
describe hostname-to-IP resolution
understand DNS resolvers
distinguish public and private DNS
explain DNS zones
understand A and AAAA records
explain CNAME concepts
explain TTL
understand DNS caching
create internal service names
validate DNS queries
troubleshoot incorrect records
identify zone-association issues
distinguish DNS failures from routing failures
explain how DNS supports application flexibility
understand DNS security and audit concerns
document cloud DNS architecture professionally

🏆 Mission Complete

You have now added the naming layer to your cloud environment.

Your architecture has progressed from:

IP Address

to:

Service Name
      ↓
DNS
      ↓
IP Address
      ↓
Network
      ↓
Workload

Your application can now follow a cleaner model:

web.cloudplus.lab
      ↓
app.cloudplus.lab
      ↓
db.cloudplus.lab

The key lesson from this lab is:

DNS solves naming. It does not replace routing, security, or application availability. Strong cloud troubleshooting requires identifying exactly which layer is failing.

🚀 What’s Next?

Your environment now has:

compute
segmented networking
routing
network security
DNS

The next lab moves into another fundamental cloud capability:

storage.

You will work with:

block storage
object storage
file storage
storage use cases
capacity
performance
persistence
attachment and mounting
cloud storage selection
basic storage troubleshooting

You will compare:

Block Storage
vs
File Storage
vs
Object Storage

and learn when each model should be used.

➡️ Next: Lab 07 — Cloud Storage Fundamentals Lab