Lotus DNSObservability
Public reference · read-only

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.

Public referenceRead-only patternImplementation examples included
01 · Product overview

Four views, each with one clear job

Start with current state, move into bounded evidence, then inspect historical context or the reusable design.

01Live

Five decision-ready indicators followed by query rate, authoritative zones, response profile, client mix, and telemetry health.

02Signals

Four focused views: operations digest, query sources, transfers, and trends. Each view keeps investigation bounded and read-only.

03History

Coverage-aware historical aggregates and capacity context. Partial evidence is labelled instead of being presented as complete.

04Design

This public reference explains the reusable pattern, information boundaries, and failure behaviour without publishing operational detail.

02 · Reference architecture

Private evidence, bounded adapter, public presentation

Each layer has one responsibility and the public layer has no control path back into DNS operations.

Authoritative service

The production service remains independent from the presentation layer and exposes no browser control path.

Private telemetry

Collectors observe service, traffic, zone, and host signals inside a restricted network boundary.

Bounded summaries

Raw events become capped counters, time buckets, and ranked aggregates before they reach the application.

Read-only adapter

Server-side APIs apply freshness, reconciliation, allowlists, and response shaping.

Public presentation

The browser receives only the minimum aggregate evidence required to explain current state.

03 · Trust and data boundaries

Only minimal aggregate evidence crosses to the browser

Public usefulness comes from deliberate shaping, not from publishing the monitoring backend.

Private operations
  • Service control remains separate
  • Raw telemetry remains private
  • Credentials never enter page content
Application boundary
  • Aggregate-only reads
  • Bounded result sizes
  • Freshness and coverage labels
  • Fail-closed access checks
Public browser
  • Read-only views
  • No raw logs or addresses
  • No backend query language
  • No mutation or administration
Data principles

Evidence stays useful because its limits stay visible

01Aggregate before presentation

Counts and time buckets are produced before ranking or truncation, so charts remain mathematically complete.

02Separate status from investigation

Live answers “what needs attention now”; Signals and History provide bounded context without turning the public UI into an operator console.

03Make uncertainty visible

Waiting, stale, partial coverage, and unavailable states are first-class outcomes rather than silent gaps.

04Publish roles, not topology

The reference names responsibilities and safeguards while withholding environment-specific routes, addresses, paths, and credentials.

04 · Example implementation shape

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.

Educational reference
ExamplePrivate statistics listener

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.

ExampleMetrics collector target

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-dns

Safety boundaryThe browser never receives this target or the metrics query interface.

ExampleDashboard runtime contract

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.

ExampleSanitized response model

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.

05 · Live signal model

Five indicators for a fast first read

OverallA concise attention state derived from current evidence and freshness.
Query rateA recent bounded rate series with accessible data-table equivalent.
Queries · 24hA windowed aggregate paired with an explicit coverage label.
Authoritative zonesPublished counts and ranked aggregate activity, never zone administration.
TelemetryFreshness and collection-path state that explains confidence in the page.
Privacy-safe classification

Client mix that reconciles

InternalTraffic classified within approved private or local address scopes.
ExternalTraffic classified as public network sources.
UnknownMalformed or unclassified sources kept visible so totals still reconcile.
Security and privacy

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.
Reusable technology roles

Replaceable building blocks

Authoritative DNS servicePrivate metrics and event collectorsBounded aggregate and time-series storageServer-side read adapterReact-based public interfaceAnti-abuse session gateContainerized application runtimeTLS reverse proxy
06 · Failure and adoption

Honest states are part of the interface

Design failure language and rollback expectations before exposing the page to readers.

Telemetry unavailable

Show degraded or waiting state and retain the last safe context; never invent healthy data.

Aggregate incomplete

Omit the chart bucket or label coverage rather than deriving totals from a truncated Top N list.

Session absent

Keep the public design reference available while protected live-data APIs continue to fail closed.

Live stream interrupted

Reconnect safely and use bounded polling during recovery.

Historical coverage partial

State the available range and avoid unsupported forecasts or completeness claims.

A source is unclassified

Count it as Unknown so the public total remains auditable without exposing the source.

Adoption path

Copy the pattern, adapt the implementation

  1. Define the public questions the page must answer.
  2. Keep collection and control interfaces private.
  3. Aggregate and cap data before the web boundary.
  4. Design waiting, stale, partial, and unavailable states.
  5. Test the browser and API boundaries independently.
  6. Deploy with a reversible backup and verify the actual runtime.