Skip to content

Chapter 3

Public and Private Exposure of a DLB

Every Dedicated Load Balancer gets two DNS names along with corresponding public and private IP addresses. We already discussed that a DLB will run on at least 2 workers. In that case, DLB will get 2 Public IP addresses and 2 Private IP addresses.

Public IP / DNS

Public IP addresses can be static or dynamic. You can choose while creating the DLB or change it after creating it. By default it is dynamic. It is recommended to use dynamic IPs. If you are going to add this DLB to an Allowlist, prefer using the DNS record not the IPs. 

The Public DNS naming convention is like this:


<lb-name>: This is the name of the Load Balancer that you decide to use. It must be unique across to subdomain.

<sub-domain-for-anypointdns>: This is the subdomain. It can vary where you are using CloudHub. For the US it is “lb”, for the EU control plane it is “lb-prod-eu-rt”. After the creation of the DLB, you can observe both the Public DNS name and the Public IPs from the interface or Anypoint CLI or CloudHub API. 

For example:

Private IP / DNS

Private IP addresses are always dynamically assigned. Since DLB is inside of your VPC, it will get an internal IP from the VPC CIDR Range. For security reasons, you may want to blacklist the private (internal) IP of the DLB, because the DLB is exposed publicly. But again there is no option to make private IP static. Every time a DLB restarts, it gets a random private IP from the CIDR. Therefore blacklisting is not a good idea. 

The Private DNS naming convention is almost the same as Public DNS. It has only a prefix: “internal-”, like this:


For example:

CNAME or A for DNS Records?

As we mentioned before, with DLB you can use vanity domains. For that, you need to purchase your vanity domain name certificate. Let’s say you own a domain named and you want to expose your APIs over to the public and with to the internal resources. In order to do that, you can create both A records or CNAME records. I would suggest you use CNAME records even if you are using static IPs for your DLB. Because in case you upscale or downscale your DLB, you need to update your A records as well. That will not be the case for CNAME records. You can create your record as the below example: —-  CNAME —- —-  CNAME —-

Allowlist (Whitelist) on DLB

You can apply a whitelisting rule on DLB in order to control incoming traffic. At default it is, meaning Anywhere can call your DLB. Whitelisting Anywhere is actually not a whitelisting right? And if you want your APIs to be called from the internet, it is supposed to be like that.

So when would you use whitelisting? This is the case most of the time if you are using a secondary DLB inside of the VPC for internal load balancing. So you can whitelist your local VPC CIDR. Okay, but why would you want to use a secondary DLB? We will come to that further down the road. 

The allowlist works for inbound connections at the load-balancer level only, not at the CN certificate level. Also in order to add an entry to the list, you have to use CIDR notation, as it is in the default entry,