Internal ALB, Public DNS Name: Is It Actually Exposed?

Run a public DNS lookup against an internal load balancer and you may get a private address back, which looks like a misconfiguration until you check what the record is for. AWS documents that internal load balancer names can be publicly resolvable while their nodes hold only private addresses. The resolver answered where the service is; it did not create a route, open a security group or authenticate anyone. Whether that answer is a problem depends on facts you can check in order.

Step one: read the scheme, not the IP

The scheme field is the load balancer's own statement about its boundary. aws elbv2 describe-load-balancers --names app-internal returns a Scheme of either internal or internet-facing, plus an address type for IPv4 or dual stack. An internet-facing load balancer can still forward to private targets, so seeing private backend addresses proves nothing about the front end.

Write the scheme down before looking at anything else, because every later judgement depends on it. It also tells you which controls exist, from security groups and listener rules to the feature set of that load balancer type. A scheme copied from an old console screenshot is worse than no note at all. Re-read it from the API and paste the value into the ticket.

Step two: see what the name resolves to

Query from outside the VPC with dig +short app-internal-1234567890.eu-west-1.elb.amazonaws.com and note whether the answers are in 10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16. A private answer from a public resolver is the expected behaviour for an internal load balancer name; it is not evidence that the address is routable from the internet.

Resolve the same name from inside the VPC and compare. If the two answers differ, you are looking at split-horizon naming, and that difference is a design detail rather than a leak.

Step three: list the paths that can reach it

A private address is reachable from wherever a route and a security rule exist. Enumerate those deliberately: site-to-site VPN, client VPN, VPC peering, transit gateway attachments, Direct Connect, and any proxy or bastion inside the VPC. One of them is the intended path, and the rest are the ones an attacker would look for.

Then check the controls on each path: security groups on the load balancer, network ACLs on the subnets, and the routing that makes the path exist at all. Most reported "internal service exposed" cases resolve here, either because an unintended peering existed or because the path was intended and the application had no authentication.

Step four: test the listener and the application separately

Try to connect from a network that should not reach the service and confirm you cannot. Then try from one that should, and confirm you reach a listener. Those two results separate network reachability from application behaviour, and they are the only evidence that matters for the exposure question.

A reachable listener is not the same as an accessible application. Check the TLS certificate and protocol policy, then the application's own authentication and authorization. An internal tool that accepts any caller on the corporate VPN is exposed to every compromised laptop on that VPN, which is a different risk from an internet-facing one but still a risk.

Remember that controls differ by type. Application-layer firewalls attach to one load balancer family and not the other, so confirm what is actually available for the scheme and type in front of you instead of assuming parity.

Step five: decide whether the name itself matters

Public resolvability can disclose a service name, a region and an address range. Treat that as an information-disclosure question with a policy answer, not an automatic incident: keep sensitive business terms out of resource names, and note the disclosure in your risk record if the naming convention reveals more than you want.

If the organization wants a private naming experience, a private hosted zone can serve an alias that only resolves inside the associated VPCs. That changes the name users see; it does not make the provider-generated name secret, and it does not remove any network path.

Do not try to pin addresses to hide the answer. Load balancer addresses change, pinning breaks TLS validation habits, and the control you actually need is who can establish the connection and what the application demands of them. Check the four facts, write them down, and the question stops being ambiguous.