DNS itself does not send browser HTTP redirects, but a DNS policy can return an alternate destination that serves a block or safety page. A loop occurs when that page, the original site, authentication, or another proxy repeatedly sends the client back. Capture each DNS answer and HTTP location in order, then correct the single cycling rule.
Do not begin by clearing everything or allowing the destination. First write the loop as A to B to A, including which component made each transition. That sequence prevents the common mistake of calling every repeated page a DNS loop and changing policy when the cycle actually belongs to a web server, sign-in flow, captive portal, or proxy.
Name the two kinds of redirection
DNS returns resource records used during name resolution. RFC 1034 describes aliases such as CNAME records, but an alias is still a DNS answer, not an HTTP instruction to load another URL.1 HTTP redirection is different: a server sends a 3xx response with a Location value that tells the client where to continue.2 A useful diagnosis records both layers separately.
A filtering resolver may implement a redirect action by returning an address for a controlled block or safety destination instead of the ordinary answer. That destination can then serve a page or issue its own HTTP redirect. Trouble begins when the destination hostname is covered by the same redirect, when an authentication flow returns to the blocked name, or when multiple gateways disagree about the canonical scheme or host.
| Step | DNS evidence | HTTP or app evidence |
|---|---|---|
| Request A | Resolver and returned answer | Initial URL or app action |
| Arrive at B | Lookup for policy destination | Status and Location header |
| Return to A | Fresh or cached answer | Redirect, callback, or proxy rule |
| Repeat | Same matched policy? | Same transition and timestamp? |
Capture the loop as a sequence
- Choose one affected device, browser or app, network, exact starting hostname, and five-minute window.
- Confirm which resolver receives the fresh request and which profile or resource it identifies.
- Record the DNS answer, matched action, rule source, and any policy destination for every name in the cycle.
- Capture HTTP status and Location values with browser developer tools or an approved command-line client, avoiding credentials and private tokens.
- Stop after the first repeated transition; a short A-B-A trace is safer and clearer than dozens of retries.
Use a clean session only after preserving the original evidence. Cached DNS answers, cookies, service workers, HSTS state, and open connections can change the observed path. Compare the first trace with a controlled fresh trace rather than assuming that a cache clear proves the root cause.
Find the edge that repeats
- Policy destination is redirected by the same rule: exclude the controlled destination from that redirect policy.
- Original hostname alternates with a login or callback host: verify each dependency and the application’s registered return target.
- HTTP and HTTPS versions alternate: inspect web-server, proxy, and TLS termination rules rather than widening DNS policy.
- Two hostnames declare each other canonical: fix the application or proxy owner of the contradictory Location responses.
- Only one device cycles: compare resolver path, resource identity, profile, cache, VPN, and browser Secure DNS state.
Match DNS activity to the exact device and interval, but interpret it narrowly. Lookups can arise from embedded resources, prefetching, and background applications, so adjacency does not establish causality.3 The repeated edge needs both a reproducible policy decision and a corresponding next step in the browser or app trace.
DNS filtering cannot read page contents, full URLs, URL paths, Location headers, search terms, in-app chats, voice audio, or full browser history. It can reveal that a domain lookup received an allow, block, redirect, or observation outcome. Use HTTP, proxy, browser, or application evidence to explain what happened after resolution.
Repair the owner, not the symptom
Change the smallest component that owns the repeated edge. Exclude a controlled block-page hostname from its own redirect, correct a mistaken resource assignment, repair an application callback, or remove one contradictory web redirect. Do not globally allow the original destination, disable a baseline, or turn off every redirect. Those actions may stop the visible cycle while silently defeating the intended boundary.
Check policy precedence before applying a lower-scope exception. In Veilty, a resource may override reusable baseline policy when permitted, but it cannot weaken enforced Space or Tenant policy. If enforced policy owns the redirect, its authorized owner must decide the correction. Documenting that boundary avoids ineffective rules and confusing future investigations.
Verify the loop is gone
Replay the same starting action on the same device and network. Confirm the sequence terminates in the intended allowed page or controlled policy response, the policy destination itself remains reachable, and the resolver records the expected action. Then test one representative allowed workflow and one blocked destination to ensure the correction did not become a broad bypass.
Repeat after relevant DNS and browser state expires, and check another affected device only if the original report covered one. Record the start host, repeating edge, root owner, changed rule, before-and-after trace, reviewer, and review date. Retain detailed activity only for the named diagnostic purpose and shortest useful window.
Redirect loop questions
Can a CNAME record create an HTTP redirect loop?
Not by itself. A CNAME aliases one DNS name to another during resolution; it does not instruct a browser to request a new URL. The eventual web server, proxy, application, captive portal, or policy destination can issue HTTP redirects. Capture both DNS answers and HTTP responses to locate the repeating layer.
Should I allow the original site to stop the loop?
Only when policy review shows it should be allowed. A blanket allow may hide a mistaken redirect rule, wrong profile, or broken block-page exception. First identify the repeated transition and its owning rule, then change the narrowest policy element and confirm the intended allow or block outcome remains.
Why does the loop affect only one device?
That device may use a different resolver, profile, cached answer, VPN, browser Secure DNS setting, authentication state, or proxy path. Compare it with a working device under the same timestamped test. Preserve the difference until you know which path or policy decision changes the sequence.
Trace one Veilty redirect
In Veilty, trace one affected resource inside its Space or Tenant from the original hostname to the policy destination and first repeated step. Review retained activity only through a permitted role; it is end-to-end encrypted with user-held keys, while the resolver necessarily processes live requests. Identify the baseline, enforced, resource, or catalog decision that owns the redirect, correct one edge, and replay both the intended outcome and a control case.