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>.<sub-domain-for-anypointdns>.anypointdns.net
<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:
my-company-dlb-prod.lb-prod-eu-rt.anypointdns.net
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:
internal-<lb-name>.<sub-domain-for-anypointdns>.anypointdns.net
For example:
internal-my-company-dlb-prod.lb-prod-eu-rt.anypointdns.net
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 mycompany.com and you want to expose your APIs over api.mycompany.com to the public and with api-internal.mycompany.com 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:
api.mycompany.com —- CNAME —- my-company-dlb-prod.lb-prod-eu-rt.anypointdns.net
api-internal.mycompany.com —- CNAME —- internal-my-company-dlb-prod.lb-prod-eu-rt.anypointdns.net
Allowlist (Whitelist) on DLB
You can apply a whitelisting rule on DLB in order to control incoming traffic. At default it is 0.0.0.0/0, 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, 0.0.0.0/0.
