feat: register DNS in the service catalog

[kevwilliams]

Summary

The DNS component needs to be integrated into the Datum Cloud service catalog to enable discovery, activation, and billing. Mirrors the work done for Network Services (datum-cloud/network-services-operator#155), but with metering tailored to DNS consumption signals. Three core components:

1. Service Registration

Create a Service resource establishing DNS visibility in the catalog with relevant metadata — display name, description, and Published phase designation. Group/resources live under dns.networking.miloapis.com/v1alpha1 (DNSZone, DNSRecordSet, DNSZoneClass).

2. Metering Configuration

Establish a ServiceConfiguration resource specifying billable metrics for DNS. Unlike the edge proxy (request/byte counts), DNS consumption is driven by authoritative query traffic and managed inventory:

• DNS queries resolved — primary consumption metric; count of authoritative queries answered by the backend (PowerDNS), ideally broken down by rcode (NOERROR / NXDOMAIN / SERVFAIL) and optionally by record type.
• Hosted zones — number of active DNSZone resources (per-zone footprint charge).
• Record sets managed — count of DNSRecordSet resources (inventory metric).
• Query types / advanced routing (future / optional) — distinguish standard lookups from any premium routing (geo/latency/alias-style) if/when introduced.

We already emit zone/recordset inventory and status metrics via config/milo/resource-metrics/policies/dns-metrics.yaml (dns_zone_info, dns_record_set_info, etc.). The inventory metrics here can build on that; the query-volume metric is the new signal that needs a source (see below).

3. Usage Pipeline Integration

Investigate mechanisms for extracting DNS query signals and integrating with the billing pipeline:

• Query-volume source: PowerDNS exposes query statistics via its API (/api/v1/servers/localhost/statistics) and Prometheus metrics; evaluate scraping these from the agent sidecar vs. a dedicated exporter. Determine how to attribute queries back to a tenant/zone (per-zone counters, log-based attribution, or dnsdist tagging).
• CloudEvents emission for billing-pipeline compatibility.
• Buffering, batching, and reliability for data-plane-to-pipeline transmission (the authoritative servers are in the downstream/agent role).

Both resources should be packaged as a Kustomize component following existing compute/network-services patterns, located in config/components/ (this repo does not have a config/components/ dir yet — it will be created).

---

Acceptance Criteria

• DNS service appears in the platform catalog in Published phase
• Metering covers query volume + hosted-zone and record-set inventory
• Resources packaged as a service-catalog Kustomize component under config/components/
• DNS query-usage collection source (PowerDNS stats/exporter) identified and per-tenant attribution approach documented
• Usage event collection and CloudEvents emission approach documented

[kevwilliams]

Progress update

Phase 1 — Service registration ✅ (merged, #45)

• services.miloapis.com/Service dns-networking-miloapis-com (serviceName: dns.networking.miloapis.com), phase: Published, packaged as the config/components/service-catalog Kustomize component.
• Wired into the milo control plane via infra (datum-cloud/infra#2688). DNS is live in the staging service catalog.

Phase 2 — Metering configuration ✅ (PR #48)

• services.miloapis.com/ServiceConfiguration declaring three signals:
  • dns.networking.miloapis.com/zone/queries (Delta, {query}) — primary consumption; dims rcode/record_type/location
  • dns.networking.miloapis.com/zone/hosted (Gauge, {zone}) — hosted-zone footprint
  • dns.networking.miloapis.com/recordset/active (Gauge, {recordset}) — record-set inventory
• Monitored resource types DNSZone + DNSRecordSet, billing routing wired. Ships in the same bundle, so infra's Flux Kustomization picks it up automatically.

Phase 3 — Usage pipeline integration → split out to #49

• Declaring zone/queries is the metering contract; actually extracting query stats from PowerDNS, attributing per-tenant, and emitting CloudEvents is the remaining data-plane work. Tracked separately in feat: DNS usage pipeline — emit zone/queries events from PowerDNS to billing #49.

Acceptance criteria status

• Service appears in the platform catalog in Published phase
• Metering covers query volume + hosted-zone and record-set inventory
• Resources packaged as a service-catalog Kustomize component
• Usage event collection and emission approach documented → feat: DNS usage pipeline — emit zone/queries events from PowerDNS to billing #49

Once #48 merges, the catalog/metering portion of this issue is complete; #49 carries the pipeline work.