DNS API Sources
DNS API Sources shows which successful external senders have recently authenticated and pushed DNS activity into SDM.
Where to find it: SDM root sidebar > API Sources.
Available to: root in the current navigation; the page is read-only.
What this page does
The registry groups successful public DNS API calls by observed public IP and normalized sender metadata. It helps root distinguish known SHM servers, generic API clients, heartbeat-only integrations, and actual zone or record writers.
Before you start
Remember that failed authentication is not recorded here as a trusted source. Use Audit and server logs for rejected attempts. Metadata headers are caller-supplied labels; the observed address and authenticated API user remain the stronger evidence.
Columns and status
- Source: server label and public address.
- Client type: normalized product type such as SHM or generic API.
- API user: identity that authenticated the successful calls.
- Last activity: most recent action and heartbeat time.
- DNS writes: zone pushes and record pushes.
- Seen: first and latest timestamps.
Active means activity within 15 minutes; stale covers activity older than 15 minutes but within 24 hours; inactive is older than 24 hours. These are recency labels, not proof that DNS is healthy.
Controls and fields
| Control, Field, Or Section | What It Does | What It Affects | Recommended Usage |
|---|---|---|---|
| Total sources | Counts successful external DNS API senders recorded by SDM. | Shows integration footprint. | Use as a quick signal that expected integrations are reporting. |
| SHM sources | Counts Synconix Hosting Manager integrations when the source declared itself as SHM. | Helps identify hosting-panel-driven DNS automation. | Use after connecting SHM to confirm SDM receives metadata. |
| Direct API | Counts direct customer API integrations. | Separates custom automation from SHM-originated traffic. | Investigate unexpected direct sources before expanding API permissions. |
| DNS writes | Aggregates recorded zone and record push activity. | Indicates how much write activity integrations are performing. | Use during change investigations to identify remote automation volume. |
| Refresh | Reloads the source inventory. | Does not alter integrations; it refreshes the report. | Use after enabling a new integration or rotating an API key. |
| Source column | Shows source label, public caller address, and capability text when supplied. | Identifies the remote system responsible for API calls. | Confirm unknown IPs before trusting their automation. |
| Client type | Classifies the source as SHM API, Direct API, Hosting API, or another declared type. | Helps support understand which integration path is in use. | Use this when deciding whether to troubleshoot SHM, custom API code, or network access. |
| API user | Shows the SDM API identity and authentication mode used by the source. | Connects integration activity to user permissions and IP restrictions. | Prefer dedicated API users for each remote system. |
| Last activity | Shows latest action, action time, and heartbeat time. | Reveals whether the source is currently alive and what it last did. | Use heartbeat gaps as a first clue for remote integration outages. |
| DNS writes column | Shows zone pushes, record pushes, and last DNS write time. | Measures how much DNS mutation came from that source. | Correlate with audit events before blaming manual users. |
| Seen column | Shows first-seen and last-seen timestamps. | Helps distinguish new integrations from long-running ones. | Investigate sudden new sources in production. |
Practical guidance
- Review this page after enabling a new integration to confirm heartbeats and DNS actions are recorded.
- Investigate unknown sources before granting broader API permissions.
How to use it
- Select Refresh.
- Find the API user or source IP associated with the integration.
- Compare last action, heartbeat, zone pushes, and record pushes.
- Open Audit for the exact request history when a count or timestamp needs explanation.
- Correct the sender's optional metadata headers in the integration, not in this read-only table.
Result and next check
You can identify the last successful sender and whether it only reported a heartbeat or performed DNS writes. Missing entries mean no successful tracked call, not automatically a network outage.
Theme color