Multi-Domain Support in OCI Load Balancer: Host-Based Routing Explain
Rajesh Madhavarao
Jul 4, 2025 11:02:30 AM
Contents
Managing multiple environments, like development, testing, and staging, can often lead to unnecessary complexity and infrastructure sprawl. By utilizing a single OCI Load Balancer to manage multiple domains (e.g., dev.example.com, test.example.com), businesses can significantly reduce the need for separate load balancers or compute instances. This consolidation translates into lower infrastructure costs, simplified SSL certificate management, and easier ongoing maintenance.
At Eclipsys Solutions, we help organizations design and implement scalable, secure, and cost-effective OCI architectures. Our experience in OCI Load Balancer configurations, multi-domain routing, and best practices in backend optimization allows clients to realize faster time-to-value while maintaining operational excellence.
In this guide, we’ll walk through how you can configure an OCI Load Balancer to route traffic based on the domain name, allowing multiple DNS records (e.g., dev.example.com, test.example.com) to coexist seamlessly behind a single public IP.
Using a shared backend set for multiple non-production domains like dev.example.com and test.example.com allows you to optimize resource usage and reduce infrastructure costs.
Instead of deploying separate load balancers or compute instances for each environment, you can consolidate traffic routing through a single OCI Load Balancer, making it an ideal setup for development, QA, or UAT environments.
What is Host-Based Routing?
Host-based routing allows an incoming HTTP/HTTPS request to be directed to different Backend Sets based on the Host header in the request. This is especially useful when:
- Two branded domains point to the same application.
- You serve multi-tenant clients from a shared backend.
- You have vanity domains or aliases mapped to one app.
Load Balancer Configuration
The screenshot shows an OCI Load Balancer (app_lb1) configured as follows:
- Shape: Flexible (autoscaling from 10 Mbps to 2000 Mbps)
- Health: ✅ OK
- Backend Set: Only one backend set is used, and it is healthy
- IP Type: Public (used to serve traffic to the internet)
- Web Application Firewall: Not configured in this example (optional but recommended)
- Access Logging: Disabled (can be enabled for deeper analysis)
- Request ID Header: Enabled (X-Request-Id)
Backend Set Configuration: One Set to Serve Them All
As shown in the image above, the OCI Load Balancer uses a single backend set:
For this example, the backend set is configured with one compute instance (typically there will be a backend pool, such as OKE, depending on your use case), and it's capable of handling traffic for multiple domain names:
In the Hostnames section of the OCI Load Balancer, we’ve created two branded DNS entries:
These hostnames are attached to listeners on the load balancer and route traffic to the same backend set (lb_bs_2025-0609-0943). This means:
- You can serve multiple branded URLs from a single application backend.
- Traffic routing is handled at the load balancer level, without modifying IIS or the application logic.
- Host-based routing keeps things clean and scalable.
Listener Setup for Multi-DNS Traffic
To enable HTTPS traffic for both dev.example.com and test.example.com, we configured a single HTTPS listener on port 443:
- A single listener serves multiple DNS hostnames by attaching both under the “Hostnames” setting.
- The SSL certificate is managed by OCI Certificate Service, ensuring easy renewal and strong encryption.
- Traffic is routed to the same backend set, meaning both branded domains serve the same application instance.
- You can extend this setup later using routing policies or path route sets to direct different domains or paths to separate backends if needed.
IIS Configuration Notes for Multi-DNS Support
When configuring multiple DNS hostnames (like dev.example.com and test.example.com) behind the same IIS site, it's important to adjust the SSL binding settings for the site to work correctly behind the OCI Load Balancer:
🔧 Required IIS Binding Adjustment
In IIS > Site Bindings > HTTPS, uncheck:
✅ Require Server Name Indication (SNI)
🛠 Why this matters:
- When SNI is enabled, IIS expects the HTTPS request to include the exact hostname in the TLS handshake.
- OCI Load Balancer may not consistently forward the SNI header when multiple DNS names point to the same backend set.
⚠️ Note: This is a practical workaround for shared backend scenarios. For production use, enabling SNI with proper hostname configuration is preferred.
Both dev.example.com and test.example.com now correctly resolve and serve the application via IIS without SSL/TLS handshake errors.