Five decision-ready indicators followed by query rate, authoritative zones, response profile, client mix, and telemetry health.
Public implementation concept
Authoritative DNS observability, explained
Lotus DNS turns private operational evidence into a calm, bounded public narrative. This page documents the reusable architecture and interface model while deliberately withholding deployment-specific detail.
Four views, each with one clear job
Start with current state, move into bounded evidence, then inspect historical context or the reusable design.
Four focused views: operations digest, query sources, transfers, and trends. Each view keeps investigation bounded and read-only.
Coverage-aware historical aggregates and capacity context. Partial evidence is labelled instead of being presented as complete.
This public reference explains the reusable pattern, information boundaries, and failure behaviour without publishing operational detail.
Private evidence, bounded adapter, public presentation
Each layer has one responsibility and the public layer has no control path back into DNS operations.
The production service remains independent from the presentation layer and exposes no browser control path.
Collectors observe service, traffic, zone, and host signals inside a restricted network boundary.
Raw events become capped counters, time buckets, and ranked aggregates before they reach the application.
Server-side APIs apply freshness, reconciliation, allowlists, and response shaping.
The browser receives only the minimum aggregate evidence required to explain current state.
Only minimal aggregate evidence crosses to the browser
Public usefulness comes from deliberate shaping, not from publishing the monitoring backend.
- Service control remains separate
- Raw telemetry remains private
- Credentials never enter page content
- Aggregate-only reads
- Bounded result sizes
- Freshness and coverage labels
- Fail-closed access checks
- Read-only views
- No raw logs or addresses
- No backend query language
- No mutation or administration
Evidence stays useful because its limits stay visible
Counts and time buckets are produced before ranking or truncation, so charts remain mathematically complete.
Live answers “what needs attention now”; Signals and History provide bounded context without turning the public UI into an operator console.
Waiting, stale, partial coverage, and unavailable states are first-class outcomes rather than silent gaps.
The reference names responsibilities and safeguards while withholding environment-specific routes, addresses, paths, and credentials.
Public-safe pseudo configuration
These examples are intentionally useful but environment-neutral. Copy the pattern, replace every placeholder, and validate it against your own security boundary.
Make service counters available only inside the management boundary.
statistics-channels {
inet 127.0.0.1 port <private-port>
allow { localhost; <management-network>; };
};Safety boundaryReplace every placeholder and keep the listener unreachable from public networks.
Attach a stable service role while keeping the collector target private.
scrape_configs:
- job_name: authoritative-dns
static_configs:
- targets: ["dns-exporter.internal:<metrics-port>"]
labels:
service_role: authoritative-dnsSafety boundaryThe browser never receives this target or the metrics query interface.
Separate public address, private data source, session signing, and anti-abuse configuration.
PUBLIC_BASE_URL=https://dns-status.example.net
METRICS_BASE_URL=http://metrics.internal:<api-port>
SESSION_SIGNING_KEY=<generated-strong-value>
ANTI_ABUSE_SITE_KEY=<public-site-key>
ANTI_ABUSE_SECRET=<server-side-secret>Safety boundaryGenerate secret values outside source control; only the public site key may enter client configuration.
Return only bounded status, freshness, traffic, and reconciled class aggregates.
{
"overall": "ok | degraded | unknown",
"generatedAt": "<ISO-8601 timestamp>",
"freshness": { "ageSeconds": 12, "stale": false },
"dns": { "queryRate": 42.1, "queries24h": 123456 },
"clientClassCounts": {
"internal": 120,
"external": 860,
"unknown": 4
}
}Safety boundaryDo not add raw logs, client addresses, backend selectors, internal paths, or upstream error bodies.
Five indicators for a fast first read
Client mix that reconciles
Observability remains separate from control
- No service-control or zone-edit action exists in the public application.
- Raw logs, client addresses, internal names, routes, and storage selectors stay server-side.
- Every public chart is based on bounded aggregates with reconciliation or coverage evidence.
- Protected data APIs reject missing or expired sessions.
- Operational failures are translated into restrained public states, not upstream error detail.
- Release validation includes desktop, mobile, dark theme, auth boundary, logs, alerts, and rollback evidence.
Replaceable building blocks
Honest states are part of the interface
Design failure language and rollback expectations before exposing the page to readers.
Show degraded or waiting state and retain the last safe context; never invent healthy data.
Omit the chart bucket or label coverage rather than deriving totals from a truncated Top N list.
Keep the public design reference available while protected live-data APIs continue to fail closed.
Reconnect safely and use bounded polling during recovery.
State the available range and avoid unsupported forecasts or completeness claims.
Count it as Unknown so the public total remains auditable without exposing the source.
Copy the pattern, adapt the implementation
- Define the public questions the page must answer.
- Keep collection and control interfaces private.
- Aggregate and cap data before the web boundary.
- Design waiting, stale, partial, and unavailable states.
- Test the browser and API boundaries independently.
- Deploy with a reversible backup and verify the actual runtime.