> ## Documentation Index > Fetch the complete documentation index at: https://docs.infrawatch.com/llms.txt > Use this file to discover all available pages before exploring further. # DNS risks > Find names that resolve into infrastructure you no longer control, and see who could claim them A dangling name is one of the cheapest attacks there is. Someone finds a hostname of yours that still points at a decommissioned service, claims that service, and now serves their content from your domain, with your certificate warnings absent and your users trusting the address. DNS risks finds those names, follows each one to the end of its resolution chain, and tells you whether the far end is claimable. ## Follow the whole chain A finding is not one record. It is the full path from the name you own to the point where control leaves you. | Part of the path | What it tells you | | ----------------- | -------------------------------------------------------------- | | Entry host | The DNS owner name where the exposed path starts | | Entry record type | What kind of record starts the path | | Chain | Every hop in resolution order, with its record type and target | | Terminal host | Where the path finally lands | | Terminal domain | The registrable domain at the terminal risk boundary | The terminal domain is the part that matters for triage. A chain that passes through three of your own names and ends on a domain you do not own is the risk, and the intermediate hops are how you explain it to whoever owns the record. CNAME, MX, and NS records are all covered, because a forgotten mail exchanger or delegated nameserver is as claimable as a forgotten web host. ## Group by provider Every finding is attributed to a canonical provider family, and the workspace surfaces the top providers with a count against each. This is usually the fastest way through a backlog. Dangling names are rarely random: a team decommissions a platform, and every name that pointed at it goes stale together. Filtering to that provider turns what looks like forty unrelated findings into one decommission you can hand to one owner. ## Know whether it can be taken Findings carry a claimability assessment, so you triage by exploitability rather than by record type: | Result | Meaning | | -------- | ------------------------------------------------------------ | | Possible | The target can be claimed. Treat as exploitable now. | | Claimed | Somebody already holds it. Investigate what is being served. | | Blocked | The provider prevents a claim on this target. | | Unknown | Claimability could not be determined. | A `claimed` result means the name resolves to infrastructure under someone else's control today. Open it before you close it. ## Narrow the queue Alongside provider and claimability, findings filter by apex domain, entry host, entry record type, response code, answer kind, answer IP, service, terminal host, terminal domain, confidence, whether the domain is available, and when the exposure started. Lifecycle selects what you are looking at: active detector findings, resolved history, or a deduplicated union where a current active episode wins. ## Work the finding DNS risks use the shared finding lifecycle, plus one state of their own: | Status | Meaning | | -------------- | ---------------------------------------- | | `open` | Newly raised | | `acknowledged` | Seen, not yet dealt with | | `accepted` | Real and accepted | | `resolved` | The record has been corrected or removed | | `ignored` | Not worth acting on | Inventory, findings, and the rest of the workspace. Investigate the same relationships across the whole internet map.