LAB 57 ‐ DNS management for 3 tier application, Public vs Private Zone - DevWithNehaCloud/Oracle-Cloud-Infrastructure-wiki GitHub Wiki

DNS Management for Three-Tier Application – Public vs Private Zone

1. Overview

In a three-tier application, DNS is used to translate human-readable domain names into IP addresses or service endpoints.

A typical architecture contains:

  • Web Tier – Handles user requests
  • Application Tier – Processes business logic
  • Database Tier – Stores application data

DNS is used differently for internet-facing communication and internal communication between these tiers.

2. DNS (Domain Name System)

DNS translates a domain name into an IP address or service endpoint.

Example

www.company.com → Public Load Balancer IP or Hostname

Instead of accessing an application using an IP address, users access it using a domain name.

Interview Definition

DNS (Domain Name System) translates human-readable domain names into IP addresses or service endpoints so users and applications can connect using names instead of numeric addresses.

3. Public DNS Zone

A Public DNS Zone contains records that can be resolved over the internet.

Three-Tier Application Flow

Internet User | www.company.com | Public DNS Zone | Public Load Balancer | Web Tier | Application Tier | Database Tier

Example Public Record

www.company.com → Public Load Balancer IP or Hostname

When a user enters www.company.com in the browser:

  1. The DNS resolver queries the public DNS zone.
  2. The DNS zone returns the public Load Balancer IP or hostname.
  3. The request reaches the public Load Balancer.
  4. The Load Balancer forwards the request to the backend Web/Application tier.
  5. The application communicates with the Database tier internally.

Important Point

The public DNS record does not need to expose the private IP addresses of the Web, Application, or Database servers.

4. Private DNS Zone

A Private DNS Zone is used for internal name resolution within a private network, such as an OCI VCN. It is useful when private resources need to communicate using hostnames instead of hardcoded private IP addresses.

Example

db.internal.company.com → 10.0.2.10

Here, 10.0.2.10 can represent the private IP address of a database server.

Benefits of Private DNS

  • Provides internal hostname resolution
  • Avoids hardcoding private IP addresses
  • Makes application configuration easier to maintain
  • Keeps internal resources private
  • Makes it easier to change the backend IP without changing application configuration

5. Public DNS vs Private DNS

Feature Public DNS Private DNS
Accessibility Internet-facing Internal / private network
Resolution Public DNS resolvers Private DNS resolver
Typical use User-facing application Internal application communication
Example www.company.com db.internal.company.com
Target Public Load Balancer Private application / database resources
Visibility Publicly resolvable Only within associated private network

6. DNS Records

DNS supports different types of records depending on the requirement. Common DNS records include:

  • A Record (Maps name to IPv4)
  • AAAA Record (Maps name to IPv6)
  • CNAME Record (Canonical Name / Alias)
  • MX Record (Mail Exchange)
  • TXT Record (Text / Verification)
  • NS Record (Name Server)
  • PTR Record (Pointer / Reverse DNS)

7. A Record

An A record maps a hostname to an IPv4 address.

Example

www.company.com → 203.0.113.10

For a three-tier application, the public A record can point to the public Load Balancer IP.

www.company.com | ↓ Public Load Balancer | 203.0.113.10

Interview Answer

An A record maps a domain name or hostname to an IPv4 address. In our three-tier architecture, the public DNS A record can resolve the application domain to the public Load Balancer.

8. CNAME Record

A CNAME (Canonical Name) record maps one hostname to another hostname.

Example

app.company.com → www.company.com

The CNAME does not directly map to an IP address. It points one hostname to another hostname.

9. OCI DNS

OCI DNS is the managed DNS service provided by Oracle Cloud Infrastructure. OCI DNS supports:

  • Public DNS Zones
  • Private DNS Zones
  • Private Views
  • DNS Resolvers
  • Traffic Management Steering Policies
  • HTTP Redirects
  • TSIG Keys

OCI DNS can be used to manage DNS records for applications hosted in OCI.

10. Public DNS Zone in OCI

A Public DNS Zone is used when DNS records need to be resolved from the internet.

Example

www.company.com | ↓ Public DNS Zone | ↓ Public Load Balancer

The public DNS zone can contain an A record that points the application domain to the public Load Balancer. The domain itself can be registered with a domain registrar such as GoDaddy, while DNS hosting can be managed separately using OCI DNS.

11. Private DNS Zone in OCI

A Private DNS Zone is used for internal DNS resolution.

Example

db.internal.company.com | ↓ Private DNS Zone | ↓ 10.0.2.10

Private DNS is useful for communication between:

  • Web Tier → Application Tier
  • Application Tier → Database Tier
  • Other private OCI resources

The resources can use meaningful hostnames instead of directly using private IP addresses.

12. Private View

A Private View is a collection of private DNS zones that can be associated with a VCN. It allows resources inside the associated VCN to resolve records from the private DNS zones.

Simplified Flow

Private VM | DNS Query | VCN DNS Resolver | Private View | Private DNS Zone | Private IP Address

13. OCI DNS Resolver

The OCI DNS Resolver handles DNS queries for resources inside a VCN. It can resolve:

  • OCI internal hostnames
  • Private DNS zone records
  • External DNS names through forwarding

Example

An application VM can query: db.internal.company.com

The OCI DNS resolver resolves the name to: 10.0.2.10

The application then connects to the database using the hostname.

14. Internal DNS Resolution vs External DNS Resolution

External DNS Resolution

Used when users or systems outside the private network need to resolve a public hostname.

Internet User | ↓ Public DNS | ↓ Public Load Balancer

Example: www.company.com

Internal DNS Resolution

Used by resources inside the private network.

Application VM | ↓ OCI DNS Resolver | ↓ Private DNS Zone | ↓ Database Private IP

Example: db.internal.company.com

15. DNS Resolution in a Three-Tier Application

A three-tier application can use both Public DNS and Private DNS.

Public Flow

Internet User | ↓ www.company.com | ↓ Public DNS Zone | ↓ Public Load Balancer | ↓ Web Tier

Private Flow

Web/Application Tier | ↓ Private DNS Resolver | ↓ Private DNS Zone | ↓ Database Hostname | ↓ Private Database IP

This provides a clear separation between external user access and internal resource communication.

16. DNS in Three-Tier Architecture

A typical DNS-enabled three-tier architecture:

                     INTERNET
                        |
                        |
                www.company.com
                        |
                        ↓
                 PUBLIC DNS ZONE
                        |
                        ↓
              PUBLIC LOAD BALANCER
                        |
                        ↓
                 WEB TIER
              Public / Frontend
                        |
                        ↓
                 APPLICATION TIER
                    Private
                        |
                        ↓
                PRIVATE DNS RESOLVER
                        |
                        ↓
                PRIVATE DNS ZONE
                        |
                        ↓
                DATABASE TIER
                    Private

Key Concept

The public DNS zone is mainly used for external user access, while the private DNS zone is used for internal resource resolution.

17. DNS and Load Balancer

In a public three-tier application, the public DNS record generally points users to the public Load Balancer.

Example

www.company.com | ↓ Public DNS | ↓ Public Load Balancer | ↓ Backend Web/Application Servers

The backend servers can remain in private subnets. This means users do not directly access the private backend servers.

18. Traffic Management Steering Policies

OCI DNS provides Traffic Management Steering Policies to control how DNS traffic is directed. They can be used for scenarios such as:

  • Load balancing
  • Failover
  • Geographic routing
  • Disaster Recovery (DR)
  • Traffic distribution

Example DR Scenario

                www.company.com
                       |
                       ↓
             DNS Steering Policy
                 /           \
                /             \
               ↓               ↓
         Primary Region   Secondary Region
               |               |
              LB              LB

If the primary region becomes unavailable, DNS traffic can be directed toward the secondary region depending on the configured steering/failover policy.

19. HTTP Redirects

OCI DNS provides HTTP Redirect functionality to redirect users from one URL to another.

Example

http://company.com | ↓ https://www.company.com

This is useful for redirecting users to a preferred or secure (HTTPS) URL.

20. TSIG Keys

TSIG (Transaction Signature) is used to authenticate DNS transactions. It provides a mechanism for securely authenticating communication between DNS systems. TSIG is useful when integrating OCI DNS with external DNS systems that support shared-secret-based authentication.

21. Complete DNS Flow for a Three-Tier Application

External User Request

User | | www.company.com ↓ Public DNS | | Resolves public LB ↓ Public Load Balancer | ↓ Web Tier | ↓ Application Tier | ↓ Database Tier

Internal Database Resolution

Application Server | | db.internal.company.com ↓ OCI DNS Resolver | ↓ Private View | ↓ Private DNS Zone | | Resolves private IP ↓ Database Server

22. Why Use DNS Instead of IP Addresses?

Without DNS

Application | ↓ 10.0.2.10

If the database IP changes, the application configuration file and connection strings must also be manually updated.

With DNS

Application | ↓ db.internal.company.com | ↓ 10.0.2.10

If the database IP changes, only the DNS record needs to be updated. The application code continues using the same hostname without redeployment.

23. DNS in OCI Three-Tier Architecture

In an OCI three-tier architecture:

  • The Load Balancer is public-facing.
  • The Web, Application, and Database resources can remain in private subnets.
  • Public DNS is used for external application access.
  • Private DNS is used for internal hostname resolution.
  • OCI DNS Resolver handles DNS resolution inside the VCN.
  • Private DNS avoids exposing internal IP addresses through public DNS.

Architecture View

                 INTERNET
                     |
                     ↓
              PUBLIC DNS
                     |
                     ↓
            PUBLIC LOAD BALANCER
                     |
                     ↓
                WEB TIER
                     |
                     ↓
                APP TIER
                     |
                     ↓
            OCI DNS RESOLVER
                     |
                     ↓
            PRIVATE DNS ZONE
                     |
                     ↓
                DB TIER

24. Interview Explanation

Question

How did you use DNS in a three-tier application?

Answer

In our three-tier architecture, we used Public DNS for external application access. The public DNS record resolved the application domain (e.g., www.company.com) to the public Load Balancer IP. The Load Balancer then forwarded incoming traffic to the backend servers.

For internal tier-to-tier communication, we used Private DNS inside the OCI VCN. This allowed the Application tier to resolve database hostnames (such as db.internal.company.com) to private IP addresses. This approach avoided hardcoding private IP addresses inside configuration files and kept all internal IPs secure and unexposed to the public internet.

25. Important Interview Points

  • Public DNS: Used for internet-facing access; resolves domain names to public endpoints like Load Balancers. Publicly queryable.
  • Private DNS: Used for internal name resolution inside the VCN; resolves private hostnames to private IPs. Not accessible from the internet.
  • OCI DNS Resolver: Built-in VCN resolver that handles lookups for private zones, internal OCI hostnames, and external forwarding.
  • Private View: A logical collection of private zones linked to a VCN to allow resources in that VCN to resolve internal records.
  • Traffic Management: DNS-level routing policies used for geo-steering, load distribution, and multi-region DR failover.

26. DNS Lab – Public DNS Walkthrough

Step 1: Verify the Load Balancer

Verify that the OCI public Load Balancer is active and has a public IP address assigned.

Public Load Balancer -> Public IP / Hostname

Step 2: Test the Application Using Load Balancer IP

Open the Load Balancer public IP in a web browser: http://<LOAD_BALANCER_PUBLIC_IP> Verify that the default application page loads.

Step 3: Create Public DNS A Record

In the OCI Public DNS Zone, create an A record pointing the domain to the public IP: www.company.com -> <LOAD_BALANCER_PUBLIC_IP>

Step 4: Verify DNS Resolution

Run one of the following commands from your local machine terminal: nslookup www.company.com or: dig www.company.com Confirm that the returned IP matches the Load Balancer public IP.

Step 5: Test the Domain

Open http://www.company.com in your browser. The request path completes: Public DNS -> Public Load Balancer -> Backend Application

27. DNS Lab – Private DNS Walkthrough

Step 1: Create a Private DNS Zone

Create an internal private DNS zone in OCI DNS (e.g., internal.company.com).

Step 2: Create a Private DNS Record

Add an A record mapping the database hostname to its private IP: db.internal.company.com -> <PRIVATE_DB_IP>

Step 3: Associate the Private DNS Zone

Add the private zone to the default Private View associated with your VCN's DNS Resolver.

Step 4: Test from an Application VM

SSH into your private Application VM and test internal resolution: nslookup db.internal.company.com or: dig db.internal.company.com The query should resolve directly to the Database private IP.

Step 5: Test Application-to-Database Connectivity

Verify connectivity using the private hostname: Application VM -> db.internal.company.com -> Private DNS Resolver -> Private DNS Zone -> Database Private IP

28. Final Architecture Summary

                     INTERNET
                        |
                        ↓
                www.company.com
                        |
                        ↓
                 PUBLIC DNS ZONE
                        |
                        ↓
              PUBLIC LOAD BALANCER
                        |
                        ↓
                     WEB TIER
                   Public/Private
                        |
                        ↓
                     APP TIER
                      Private
                        |
                        ↓
                OCI DNS RESOLVER
                        |
                        ↓
                PRIVATE DNS ZONE
                        |
                        ↓
                     DB TIER
                      Private

29. Final Summary

DNS provides name resolution between users, applications, and infrastructure resources.

For a three-tier application:

Public DNS ↓ Public Load Balancer ↓ Web Tier ↓ Application Tier ↓ Private DNS / Internal Resolution ↓ Database Tier

  • Public DNS manages external, internet-facing traffic reaching the Load Balancer.
  • Private DNS manages internal, secure communication between application and database tiers.
  • Using hostnames instead of static IP addresses makes cloud infrastructure decoupled, resilient, and easy to maintain during maintenance or failovers.

Streps to host our

Load Balancer and Application Validation

1. Load Balancer Health Check

After configuring the Load Balancer and backend application server, we verified the health of the backend server from the OCI Load Balancer console.

The backend server was showing Healthy, which confirmed that the Load Balancer was able to successfully communicate with the application server.

Result: Load Balancer backend health is OK / Healthy.

2. ITSM Application Validation

The ITSM ticketing tool HTML content was deployed on the application server.

We placed the HTML content under the web server directory and configured the index.html file. The application was then accessed through the public IP address of the OCI Load Balancer.

Example:

http://

Result: The ITSM application was successfully accessible through the Load Balancer public IP.

Next Step: Configure Custom DNS

The next step is to configure a custom DNS name for the application instead of accessing it using the Load Balancer public IP.

We will purchase/register a domain through GoDaddy and then create a DNS record that points the domain name to the OCI Load Balancer public IP address.

The high-level flow will be:

User Browser | | https://www. v GoDaddy DNS | | DNS A Record v OCI Load Balancer Public IP | v Backend Application Server | v ITSM Ticketing Tool

Planned DNS Configuration

After purchasing the domain from GoDaddy, we will:

  1. Open the GoDaddy DNS Management page.
  2. Locate the DNS Records section.
  3. Add an A Record.
  4. Configure the record to point to the OCI Load Balancer public IP.
  5. Save the DNS configuration.
  6. Wait for DNS propagation.
  7. Verify that the domain name resolves to the OCI Load Balancer.
  8. Access the ITSM application using the custom domain name.

🌐 Configure Public DNS A Record in GoDaddy Map your purchased custom domain to your verified OCI Public Load Balancer IP address using the GoDaddy DNS Management console.

🛠️ Step-by-Step Instructions

Log in to your [GoDaddy Account](https://account.godaddy.com/ First, go to GoDaddy or any other DNS management vendor and buy a domain name

  1. Now we to map our load balancer ip with a name. Go to DNS management
nslookup tickettool.nehapro.online

Create a CNAME Record in GoDaddy

  1. Again go to DNS management page and click on Add new record. Select type CNAME and give name which you want to add before the domain name.

Note: Ping may fail if ICMP traffic is not allowed. A successful nslookup is sufficient to confirm DNS resolution. This confirms that nslookup tickettool.nehapro.online is correctly resolving to the public OCI Load Balancer.

verify the CNAME using CLI

nslookup -type=CNAME supporttickettool.nehapro.online