Technical Case · KT-000020

Public Website Failed Internally Because DNS Owned the Name

The website worked from outside networks but failed from inside the company.The location boundary pointed away from the website itself and toward internal name resolution.

Documented by Published

Case ID

KT-000020

Category

DNS & Infrastructure Troubleshooting

Status

DNS Corrected / Internal Access Verified

Technologies

DNS / Active Directory DNS / Public Web

Problem

What happened?

A public website was reachable from outside networks but not from systems inside the company network.

Filtering and firewall-oriented changes did not resolve the symptom. The distinguishing clue was that the public domain overlapped with the organization's internal DNS namespace.

Investigation

How was the failing layer isolated?

Works outside but not inside is a location boundary. Compare name resolution before changing more security controls.

Investigation path: External test → Internal test → Filtering visibility → Whitelist result → Internal DNS → Public resolver comparison → DNS correction → Internal retest

Step 1

Prove the public site works

The website was confirmed reachable from outside the company network, reducing the likelihood that the public web service itself was down.

Step 2

Confirm the failure is internal

Internal users reproduced the failure, creating a clear inside-versus-outside boundary.

Step 3

Use failed security changes as evidence

Traffic was not appearing in the expected filtering path, and whitelisting did not change the result. That made continued filtering changes a poor next test.

Step 4

Compare DNS answers

The investigation moved to local DNS and the overlapping internal namespace. Internal resolution was compared with the expected public result.

Step 5

Correct internal DNS behavior and retest

Internal DNS behavior was corrected so the public website resolved correctly, then the affected network was retested.

Finding

What was actually proven?

The failure domain was internal DNS resolution

The source supports that the site worked externally, internal users failed before the expected web-filtering path, whitelisting did not help, firewall redirection and DNS were considered, local DNS was identified as the failure domain, and correcting internal DNS restored access.

It does not prove that every inside-only website failure is split DNS, that the firewall or filter can never be responsible, that every overlapping namespace is defective, or that every organization should apply one universal DNS correction.

This case is proof of one internal DNS failure domain, not a generic DNS correction guide.

Verification

Compare name resolution from inside and outside, query the hostname against internal DNS and a public resolver, check whether an internal DNS zone owns the public domain, verify the expected public address, then retest from an internal workstation after correction.

Lessons Learned

Use the location boundary before changing another control.

If a website works everywhere except inside the company, check split-brain or split-horizon DNS before blaming filtering.

The useful clue was not an error message. It was the difference between the internal and external paths.

Related Resources

Turn the case into a repeatable infrastructure test.

Scope

Scope the Problem

Define who, where, and which path is failing before changing controls.