Cloud Foundry Documentation
- General Information
- Contribute to Cloud Foundry documentation
- Cloud Foundry concepts
- Cloud Foundry overview
- Security and networking
- Cloud Foundry security
- Container security in Cloud Foundry
- Container-to-container networking
- Identity-aware routing
- Orgs, spaces, roles, and permissions in Cloud Foundry
- Managing Roles
- Planning orgs and spaces in Cloud Foundry
- App Security Groups in Cloud Foundry
- Cloud Foundry app SSH components and processes
- High availability
- How Cloud Foundry manages apps
- Cloud Foundry components
- Cloud Foundry Command Line Interface (cf CLI)
-
- Information for Operators
- Deploying Cloud Foundry
- Administering Cloud Foundry
- Managing the runtime
- User accounts and communications
- Routing
- Enabling IPv6 for hosted apps
- Distributed tracing
- Enabling Zipkin tracing
- Enabling W3C tracing
- Supporting WebSockets
- Configuring load balancer health checks for CF routers
- Troubleshooting slow requests
- Troubleshooting router error responses
- Securing incoming traffic
- Configuring trusted system certificates for apps
- Bulletin Board System data store encryption
- Enabling and configuring TCP routing
- Configuring HTTP/2 support
- Isolation segments
- Delayed jobs in Cloud Foundry
- Managing apps and their stacks
- Running and Troubleshooting Cloud Foundry
- Cloud Foundry logging
- Configuring system logging
- Configuring Diego for upgrades
- Audit Events
- UAA audit requirements
- Usage events and billing
- Configuring SSH access for Cloud Foundry
- Configuring Diego Cell disk cleanup scheduling
- Configuring Health Monitor Notifications
- Adding a custom stack
- Monitoring and testing Diego components
- Troubleshooting Cloud Foundry
- UAA performance
- UAA performance metrics
- Scaling Cloud Controller
- Cloud Controller Multi-Process Mode (Puma)
- Scaling Cloud Controller (cf-for-k8s)
- Logging and metrics in Cloud Foundry
- Logging and metrics architecture
- Installing the Loggregator plug-in for cf CLI
- Security event logging
- App logging in Cloud Foundry
- Limiting your app log rate in Cloud Foundry
- Cloud Foundry component metrics
- Container metrics
- Loggregator guide for Cloud Foundry operators
- Logging and metrics in Cloud Foundry
- Configuring the OpenTelemetry Collector
- Deploying a nozzle to your Cloud Foundry Loggregator Firehose
- BOSH Documentation
- BOSH Backup and Restore (BBR)
- Information for developers
- Developing and managing apps
- How to push your app with Cloud Foundry CLI (cf push)
- Pushing your app using Cloud Foundry CLI (cf push)
- Deploying with app manifests
- App manifest attribute reference
- Deploying an app with Docker
- Deploying your large apps
- Starting, restarting, and restaging apps
- Pushing an app with multiple processes
- Running cf push sub-step commands
- Configuring app deployments
- Pushing apps with sidecar processes
- Using blue-green deployment to reduce downtime
- Troubleshooting app deployment and health
- SSH for apps and services
- Routes and domains
- Managing services
- Provisioning and integrating service instances
- Managing service instances
- Sharing service instances
- Delivering service credentials to an app
- Managing service keys
- Configuring Play Framework service connections
- Using an external file system (volume services)
- User-provided service instances
- Manage app requests with route services
- Streaming app logs
- Managing apps with the cf CLI
- Cloud Foundry environment variables
- Available Cloud Controller API client libraries
- Designing and running your app in the cloud
- Cloud Foundry API app revisions
- How to push your app with Cloud Foundry CLI (cf push)
- Cloud Foundry Buildpacks
- Cloud Native Buildpacks
- Classic Buildpacks
- What are classic buildpacks?
- Binary buildpack
- Go buildpack
- Hosted Web Core buildpack
- Java buildpack
- .NET Core buildpack
- NGINX buildpack
- Node.js buildpack
- Using PHP buildpack with runtimes
- Python buildpack
- R buildpack
- Ruby buildpack
- Staticfile buildpacks
- Creating custom buildpacks
- Information for Managed Service Authors
- Services in Cloud Foundry
- Service Broker API
- Managing service brokers in Cloud Foundry
- Managing access to service plans
- Binding credentials in Cloud Foundry
- CredHub
- Dashboard Single Sign-on
- Service instance sharing in Cloud Foundry
- Service broker examples
- App log streaming in Cloud Foundry
- Offering Route Services in Cloud Foundry
- Supporting multiple CF instances
- User Account and Authentication
- API Reference
- UAA API
- CAPI API
Setting up DNS for your Environment
Page last updated:
This topic describes how to set up DNS for your Cloud Foundry environment.
Domains
You must create several wildcard DNS records to point to your load balancers and routers. Consult the table below for details about these wildcard DNS records.
Cloud Foundry gives each application its own hostname in your app domain. With a wildcard DNS record, every hostname in your domain resolves to the IP address of your router or load balancer, and you do not need to configure an A record for each app hostname. For example, if you create a DNS record for a system domain *.example.com pointing to your router, every application deployed to the example.com domain resolves to the IP address of your router.
| Domain | Example | Notes |
|---|---|---|
| TCP | *.tcp.example.com | This handles TCP traffic destined for the TCP Router. |
| HTTP | *.sys.example.com | This is the system domain that handles HTTP traffic for system components destined for the Gorouter. |
| HTTP | *.example.com | This is the app domain that handles HTTP traffic for applications destined for the Gorouter. |
| WebSockets | *.ws.example.com | This is an optional domain that handles WebSocket traffic destined for the Gorouter. |
| SSH | *.ssh.example.com | This is an optional domain that provides SSH access to application containers. |
Example Topologies
Your exact configuration may vary significantly depending on your IaaS and your load balancing configuration. Below are the following example topologies.
- An Amazon Web Services (AWS) deployment using Elastic Load Balancer (ELBs)
- A deployment that uses HAProxy for load balancing
The diagrams below show which particular jobs will have traffic routed to them by load balancers. The instance groups may have different names. Run the bosh instances command to see the instance groups.
For example, in a default cf-deployment, the ssh_proxy job is deployed to an instance group name scheduler. Your load balancers must route traffic to that VM.
AWS
This topology has DNS configured to point five domains to four ELBs:

HAProxy
This topology has DNS configured to point five domains to one HAProxy:

