In a tunnelled hosted browser run, why pass an internal hostname rather than its address?
answer
- a name means something where it resolves
- the name crosses, not the address
- resolve at the inside end
- host header and certificate follow the name
- split horizon answers, it does not error
basics
~20 sAn internal name means something only to a resolver inside your network, so the name itself must cross the tunnel and resolve at the inside end. A pre-resolved address freezes one machine's answer, which the rented browser cannot check.
solid answer
~50 sA name is only meaningful where a resolver answers it, and for an insurer's internal claims-adjuster tool that resolver sits inside the network — which is also where the relay sits. So the useful arrangement carries the **name** across the hop and resolves it at the inside end, where it means what you intend. Resolving it yourself first, and configuring the suite with the resulting address, throws that away: you have substituted whatever your machine answered at that moment, and the rented browser has no way to notice it was wrong. It also breaks things that depend on the name rather than the address — the HTTP `Host` header the server uses to select a virtual host, the name a certificate is issued for, and any redirect the application issues back to its own hostname. Configure the suite with the hostname and let the arrangement do the resolving.
go deeper
Always put the hostname in your test configuration, never the address you looked up. The relay inside the network is what resolves it, and it can only do that if the name is what you gave it.
Be able to list what follows the name rather than the address: the host header a server uses to pick a virtual host, the name a certificate is issued for, and the canonical hostname an application redirects to.
Expect a split-horizon scenario. Explain why a wrong answer is more dangerous than no answer, and why you check resolution from the relay's host rather than from your own machine.
Be ready to standardise it: environments addressed by name, one place holding those names, and a rule that a suppressed certificate warning is a defect to investigate rather than a workaround to keep.
## What "resolvable only inside" actually means Saying a service is internal usually conflates two separate facts, and separating them is most of the lesson. - **The name is unpublished.** Only resolvers inside your network hold a record for the claims-adjuster tool's hostname. Ask any resolver outside and you get nothing back. - **The address is unroutable from outside.** Even handed the right address, a machine on the public internet has no path to it. A tunnel arrangement fixes the second by performing the request from a machine that does have a path. It fixes the first only if the *name* is what crosses the hop, because resolution has to happen on the side where a resolver knows the answer. This is why the practical instruction is so simple and so often ignored: put the hostname in your suite's configuration and let the relay resolve it. ## Why substituting the address is worse than it looks Teams reach for an address for understandable reasons — a resolver was flaky, someone wanted to skip a lookup, a colleague pasted what worked on their machine. The substitution has four separate consequences, and they fail in different ways: 1. **You have frozen one machine's answer.** The address is whatever your resolver returned at the moment you looked. If the service moves, is rebalanced, or resolves differently from the relay's host, nothing tells you. The suite keeps running against the wrong place, or against nothing. 2. **The HTTP `Host` header changes.** A request made to a literal address sends that address as the host. Servers that select a virtual host from it will hand you the wrong application, or a default page, or an error that looks nothing like a networking problem. 3. **Certificate validation fails or is suppressed.** A certificate is issued for a name. Opening the site by address produces a mismatch, and the usual fix — turning verification off — quietly removes a real check from every run thereafter. 4. **Redirects put the name back anyway.** Internal applications routinely redirect to their canonical hostname after a login or a locale choice. So the first request works by address and the second one needs the name resolved after all, which produces the baffling symptom of a suite that reaches the site and then loses it. ## Split horizon: the same name, two answers The most expensive version of this is a name that resolves **everywhere**, but to different things. Many organisations publish an externally-visible record for the same hostname the internal tool uses: a marketing page, a login portal, an access gateway. Inside, the name points at the claims-adjuster application; outside, it points somewhere else entirely. The consequence for a tunnelled run is sharp. If resolution happens on the inside end, the browser gets the internal service. If resolution happens anywhere else, it gets the public answer — and that answer *responds*. Nothing errors. The suite loads a page, finds none of its elements, and reports what looks like a front-end regression in the claims-adjuster tool. A name that fails to resolve announces itself; a name that resolves to the wrong thing does not. | symptom | likely cause | |---|---| | name does not resolve at all | request was resolved outside, or the relay's host lacks the record | | page loads but is the wrong application | split-horizon name resolved on the public side | | first request works, later ones fail | a redirect to the canonical name after an address-based entry | | certificate warning suppressed to proceed | site opened by address rather than by name | ## The honest limits of the rule Two hedges keep this from becoming an overstatement. First, *which* end resolves is a property of how the arrangement carries the request, not something the relay decides by nature. An arrangement that passes the name through and resolves at the far end behaves as described; one that connects to an address chosen earlier cannot. The rule you can act on is your side of it: supply a name, not an address, so that the arrangement is able to do the right thing. Second, the relay's host is what resolves, and its view is not automatically the same as yours. A machine in a different segment may use different resolvers, hold different search domains, or sit behind a different split of the same name. So "it resolves on my laptop" is evidence about your laptop, and the check worth running is the one performed from the relay's host. ## What to do in a suite - Configure environments by **hostname**, never by address, and keep the hostname in one place rather than scattered through cases. - Verify resolution **from the relay's host**, not from a developer machine, whenever reach is in doubt. - Treat a suppressed certificate warning as a signal that something is being reached by address, and find out what. - When a tunnelled run loads a page whose contents are wrong rather than missing, suspect a split-horizon name before suspecting the application. - Keep the environment's name identical to the hostname people actually use for the internal tool, so redirects and virtual-host selection behave as they do in production.
- What is the worst failure mode of resolving the hostname on the wrong side?A split-horizon name that resolves publicly to a different service. Nothing errors — a page loads, elements are missing, and the run reads as a front-end regression in the internal tool. A name that fails to resolve announces itself immediately; a name that resolves to the wrong thing is diagnosed hours later, usually by someone checking what the page actually contained.
- Someone says resolution is fine because the hostname works from their laptop. Why is that not enough?Because the relay's host is what performs the lookup, and it may use different resolvers, different search domains, or sit on a different side of a split name. Reachability from a developer machine is evidence about that machine. The check worth running is the same lookup and the same connection attempt from the host carrying the relay.
- A tunnelled run had to disable certificate verification to get past a warning. What does that tell you?Almost always that the site is being opened by address rather than by name, since certificates are issued for names. Disabling verification removes a genuine check from every subsequent run and hides the original mistake. The fix is to restore the hostname in the configuration, not to keep the suppression in place.
saying these in an interview costs you the question
- Configures the suite with an address to skip a lookup
- Assumes the rented browser can resolve internal names itself
- Thinks a name that resolves anywhere resolves to the same thing
- Disables certificate checks instead of restoring the hostname
- Treats a wrong-looking page as an application regression first
- Verifies resolution from a laptop rather than the relay's host