Dangling Dns in Cockroachdb

CockroachDB frequently relies on external hostnames for components that are not part of the core cluster: SQL client connections via load balancers, admin UI endpoints, changefeed sinks (Kafka, cloud storage), backup/restore URLs, and external monitoring integrations. When a DNS record pointing to one of these services is left unresolved after the service is decommissioned, an attacker can register the same domain and present a malicious endpoint. This is known as a dangling DNS or subdomain takeover.

Example attack paths specific to CockroachDB:

• Client‑side credential theft: A connection string such as postgresql://[email protected]:26257/defaultdb?sslmode=verify-full resolves db.example.com to a load balancer. If the balancer is torn down but the DNS A record remains, an attacker can claim db.example.com, terminate TLS with a self‑signed certificate, and capture any credentials presented by applications that still trust the hostname.
• Changefeed data exfiltration: A changefeed configured with CREATE CHANGEFEED FOR TABLE orders INTO 'kafka://kafka-prod.example.com:9092/orders' WITH confluent_schema_registry = 'http://schema-reg.example.com:8081'; depends on the DNS names kafka-prod.example.com and schema-reg.example.com. If either record becomes dangling, an attacker can run a fake Kafka broker or Schema Registry and capture every row emitted by the changefeed.
• Backup/restore manipulation: The command cockroach backup bank INTO 'azure://account.blob.core.windows.net/container?account_key=...' uses a hostname like account.blob.core.windows.net. Should the Azure storage account be deleted while the DNS CNAME remains, an attacker could create a new storage account with the same name and receive backup files containing sensitive data.
• Admin UI impersonation: CockroachDB’s built‑in HTTP endpoint (default port 8080) is often exposed via a hostname such as admin.db.example.com. A dangling record lets an attacker host a fake admin UI that harvests cluster tokens or tricks operators into executing malicious SQL.

These scenarios map to OWASP API Security Top 10 items such as API6: Missing Authentication (attacker can pose as a legitimate service) and API3: Excessive Data Exposure (intercepting changefeed or backup streams). Real‑world analogues include CVE‑2020‑14156 (Azure subdomain takeover) and numerous reported takeover incidents affecting SaaS endpoints.

Because middleBrick performs unauthenticated black‑box scanning of any HTTP endpoint, it can discover dangling DNS issues that affect CockroachDB‑adjacent services without needing credentials or agents.

• Admin UI and HTTP endpoints: Supplying the admin UI URL (e.g., https://admin.db.example.com:8080) to middleBrick triggers the standard 12‑point scan, which includes a subdomain takeover check. If the hostname resolves to an IP address that is not associated with any known service, middleBrick reports a finding under the Inventory Management category with severity high.
• External sink endpoints: middleBrick can also scan the URLs used in changefeeds or backup configurations. For example, scanning https://kafka-prod.example.com:9092 (exposing the Kafka REST proxy if enabled) or https://account.blob.core.windows.net will surface a dangling DNS detection when the IP does not belong to the expected cloud provider.
• CLI usage: A developer can integrate the check into a CI pipeline with the middleBrick CLI:

  # Scan the CockroachDB admin UI
  middlebrick scan https://admin.db.example.com:8080 --format json
  
  # Scan a changefeed sink URL
  middlebrick scan https://kafka-prod.example.com:9092 --format json
  

  The JSON output includes a risk_score, letter grade, and a findings array where each entry contains category, severity, description, and remediation guidance.
• GitHub Action: Adding the official middleBrick action to a workflow automatically fails the build if the risk score drops below a defined threshold, providing early warning before a dangling DNS is exploited in production.

Importantly, middleBrick only detects and reports; it does not alter DNS records or block traffic. The remediation steps must be applied by the operator.

Fixing dangling DNS in a CockroachDB deployment involves eliminating reliance on mutable hostnames for critical external endpoints, enforcing strict DNS validation, and using cryptographic guarantees where hostnames must remain.

• Prefer static IP addresses or private endpoints: Where possible, replace DNS names with immutable IPs or cloud‑provider private endpoints that cannot be claimed by others. For a changefeed, use:

  CREATE CHANGEFEED FOR TABLE orders INTO 'kafka://10.0.4.25:9092/orders' WITH confluent_schema_registry = 'http://10.0.4.30:8081';
  

  If a hostname is unavoidable, ensure the IP is reserved (e.g., AWS Elastic IP, Azure Static IP) and never released while the DNS record exists.
• Enable DNSSEC and monitor DNS zones: Deploy DNSSEC‑signed zones and set up alerts for any A/AAAA/CNAME record that points to an IP address outside your approved ranges. Many cloud DNS providers offer change‑notification webhooks.
• Enforce TLS verification with certificate pinning: CockroachDB clients and server‑side components should validate the service certificate against a known CA or pin the expected leaf certificate. Example connection string with explicit root CA:

  cockroach sql --url "postgresql://[email protected]:26257/defaultdb?sslmode=verify-full&sslrootcert=/certs/ca.crt"
  

  For changefeeds that support TLS (e.g., Kafka with SSL), specify ssl.ca.location and ssl.verify.hostname=true in the sink URI or in the WITH options.
• Use managed identity or IAM roles instead of account keys: When integrating with cloud storage for backups, avoid embedding long‑lived keys in URLs. Instead, configure CockroachDB to use the cloud provider’s workload identity (e.g., Azure Managed Identity, AWS IAM Roles for Service Accounts). This removes the need for a DNS‑based endpoint that could be hijacked; the authorization is tied to the workload, not the hostname.
• Regularly audit external sinks: Run a periodic job that queries SHOW CHANGEFEEDS and SHOW BACKUPS to collect all sink URLs, then feed those URLs into middleBrick (via CLI or API) to verify none are dangling.

By combining immutable addressing, DNSSEC, TLS verification, and identity‑based access, the attack surface introduced by dangling DNS is substantially reduced. middleBrick’s findings give concrete, prioritized guidance on which specific hostnames require attention, allowing teams to remediate before an attacker can claim the abandoned domain.