Resolvers
Resolvers are the worker identity kind reserved for reverse-DNS (PTR) lookups on scan results — the role that performs them once the resolver runtime ships. A resolver is provisioned, enrolled in mTLS, monitored and revoked exactly like a scanner — it is the same binary and the same identity lifecycle — but its role is fixed at creation: a resolver never receives port-scan work and a scanner never performs DNS. Every resolver belongs to exactly one resolver group (its DNS vantage point). Configuration only in this release: a resolver enrolls and heartbeats today; lookups start when the resolver runtime ships.
Inputs
| Name | Description | Allowed values | Default |
|---|---|---|---|
Name | Unique identity name | Letters, numbers, hyphens and underscores; 1–100 characters; unique across scanners AND resolvers | — |
Resolver group | The vantage point this resolver joins — its members must see the same DNS | An existing resolver group | — |
Description | Optional note about where the resolver runs | Any text | Empty |
IP binding mode | How strictly the identity is tied to its source address | IP, subnet, ASN or none | IP |
Fields & columns
| Name | Description |
|---|---|
Name | Editable inline — the identity name |
Resolver Group | Editable inline — pick another group from the dropdown to move the resolver (saved immediately) |
Description | Editable inline — optional note about where the resolver runs |
Status | Pending (never registered), Active (heartbeating), Offline (missed heartbeats) or Disabled |
mTLS | Enrollment state of the identity certificate, as for scanners |
Binding | IP binding mode and the bound address |
Rate Limit | Max probes per second — carried by the shared identity row, unused by a resolver |
Active Errors | Open job-error alarms attributed to this identity |
Created By | The user who provisioned the resolver |
Created | When the identity was provisioned |
How to
Add a resolver to a vantage point
- Create the resolver group first (Config › Resolver Groups) if it does not exist.
- Click "Add Resolver", name it, pick the resolver group and save — you receive the standard one-time install command (the same install.sh a scanner uses).
- Run the command on a host inside that network segment that does not already run a scanner; the host enrolls and heartbeats as a resolver identity.
Gotchas
- The installer enrolls the identity in mTLS during provisioning. Use the row's enrollment-token action only to re-enroll an existing host, exactly as you would for a scanner.
- No lookups run yet. The DNS queue runs (R1a): an execution that requests reverse DNS gets lookup tasks bundled into jobs for its resolver group, and closes incomplete on schedule while nothing can claim them. The claim surface (R1b), the resolver runtime (R2) and hostnames in results (R3) follow. A resolver installed today heartbeats and enrolls in mTLS but performs no lookups and is refused port work.
- The role is fixed by the identity, not by the binary: the same mipo-scanner build will run as a resolver when its identity says so. The separate resolver service unit that lets one host run a scanner and a resolver side by side arrives with the R2 installer — until then plan one identity per host.
- A resolver identity is invisible on the Scanners page and cannot be driven through the scanner API — a scanner id is likewise invisible here. Every row action here writes to the resolver mount, so the same action on the wrong page answers 404 rather than touching another fleet.
- Release Binding is the one scanner-only action: it is not offered here, because the release-binding route exists only on the scanner mount. Change the binding mode instead.
- Add, delete, disable, enable, the binding-mode change and every token or key action require step-up re-authentication (the same trust tier as scanners); the inline name, description and resolver-group edits do not.
- Moving a resolver to another group (the dropdown in the Resolver Group column) changes which executions it may serve from then on; executions already started keep the group they snapshotted. Once resolvers can claim DNS jobs (R1b), a move is refused while the resolver holds assigned work.
API calls (10)
| Method | Path | Description |
|---|---|---|
| GET | /api/config/resolvers | List resolver identities with their resolver group |
| POST | /api/config/resolvers | Create a resolver and mint a one-time provisioning token (requires resolverGroupId) |
| PUT | /api/config/resolvers/:id | Update name, description, rate limit or resolver group |
| PATCH | /api/config/resolvers/:id | Change the IP binding mode |
| POST | /api/config/resolvers/:id/disable | Disable a resolver (revokes its live certificates) |
| POST | /api/config/resolvers/:id/enable | Re-enable a disabled resolver |
| POST | /api/config/resolvers/:id/regenerate-token | Issue a fresh provisioning token |
| POST | /api/config/resolvers/:id/rotate-key | Rotate the API key with a 24-hour grace period |
| POST | /api/config/resolvers/:id/enrollment-token | Mint a one-time mTLS enrollment token |
| DELETE | /api/config/resolvers/:id | Delete a resolver identity |
Related
- Resolver Groups — The vantage point a resolver belongs to
- Scanners — The same identity lifecycle, for the port-scan role
- Nameserver Groups — The servers a resolver may be told to query