Dangling Dns in Hapi

Dangling DNS occurs when a DNS record (like a CNAME or A record) points to a resource—such as a cloud load balancer, serverless function endpoint, or legacy server—that has been decommissioned or repurposed. In Hapi applications, this often emerges in dynamic cloud deployments where infrastructure is ephemeral. For example, a Hapi API might originally be hosted behind an AWS Application Load Balancer (ALB) with DNS name api-prod.example.com. If the ALB is replaced but the old DNS record remains in your domain's zone, attackers can register the now-available resource (e.g., the old ALB's IP or a similar serverless function URL) and intercept traffic intended for your API.

Hapi's flexible routing can inadvertently expose this risk. Consider a route configured with a wildcard hostname to support multi-tenancy:

server.route({
  method: 'GET',
  path: '/api/{tenant}/data',
  host: '*.example.com',
  handler: (req, h) => { /* tenant logic */ }
});

If tenant-a.example.com is removed from DNS but the Hapi server still responds to that host header (because it's bound to a wildcard or default host), an attacker controlling the DNS record for tenant-a.example.com can route requests to their infrastructure. This is a classic subdomain takeover, classified under OWASP API Top 10: API10:2023 – Unsafe Consumption of APIs (when your API consumes attacker-controlled endpoints) and API02:2023 – Broken Authentication (if the dangling endpoint bypasses auth checks). Real-world CVEs like CVE-2021-44228 (Log4Shell) highlight how DNS-based exploitation can lead to remote code execution, though Hapi itself isn't vulnerable to Log4Shell; the pattern of dangling DNS as an initial access vector remains critical.

Detecting dangling DNS in Hapi requires two layers: infrastructure auditing and application-layer validation. Manually, you must enumerate all DNS records for your domain (using tools like dig, nslookup, or dnsrecon) and verify each resolves to an active service that returns your expected Hapi application. A red flag is any DNS record that resolves to an IP/hostname not under your control or returning a generic page (e.g., AWS S3 bucket, parking page).

middleBrick automates this check during its Inventory Management scan. When you submit your Hapi API's URL (e.g., https://api.example.com), middleBrick performs parallel DNS lookups for the hostname and its common subdomains (like staging-api.example.com if discovered in OpenAPI specs). It then compares the resolved IPs/hostnames against the live response from your endpoint. If the DNS points to infrastructure that doesn't serve your Hapi application (e.g., a default cloud provider page or a different service), it flags a dangling DNS finding with high severity.

To scan your Hapi API with middleBrick:

# Using the CLI (install via npm: npm install -g middlebrick)
middlebrick scan https://your-hapi-api.com

# Or via the web dashboard at middlebrick.com

The resulting report will include a breakdown under Inventory Management with specific DNS records that appear orphaned. For example:

• Finding: Dangling CNAME record old-api.example.com → elasticloadbalancing.amazonaws.com (resolves to an unused ALB)
• Severity: High
• Remediation Guidance: Remove the DNS record or ensure it points to an active Hapi instance.

This is distinct from generic DNS scanners because middleBrick cross-references DNS data with the actual HTTP response from your Hapi server, reducing false positives from CDN or load balancer fronts.

Remediation involves both DNS hygiene and Hapi application hardening. First, audit and clean DNS records: delete any CNAME/A records that point to decommissioned resources. Use cloud provider tools (e.g., AWS Route 53's list-resource-record-sets) to automate this.

Second, configure Hapi to reject requests with unexpected Host headers. This prevents an attacker's dangling DNS from routing traffic to your Hapi server if it's still reachable via the old IP. Hapi's server.route() supports a host option to bind routes to specific hostnames. Use explicit hostnames instead of wildcards where possible:

const server = Hapi.server({
  port: 3000,
  host: 'localhost' // binds only to localhost
});

// Define routes with specific hosts
server.route({
  method: 'GET',
  path: '/api/data',
  host: 'api.example.com', // only responds to this host
  handler: (req, h) => ({ message: 'Secure data' })
});

For APIs that must handle multiple subdomains (e.g., tenant isolation), validate the Host header against an allowlist in an onPreAuth extension point. This runs before authentication, ensuring only intended hostnames are processed:

const allowedHosts = new Set(['api.example.com', 'staging-api.example.com']);

server.ext('onPreAuth', (request, h) => {
  const host = request.headers.host?.split(':')[0]; // strip port
  if (!host || !allowedHosts.has(host)) {
    return h.response({ error: 'Invalid Host header' }).code(400);
  }
  return h.continue;
});

Additionally, if using a reverse proxy (nginx, Cloudflare), configure it to pass only valid Host headers to Hapi. In Hapi, you can also enable server.settings.routes.cors with origin: ['https://api.example.com'] to restrict browser-based access, though this doesn't replace host validation for non-CORS requests.

Finally, integrate middleBrick into your CI/CD pipeline (using its GitHub Action) to scan staging deployments before production. Set a threshold to fail builds if Inventory Management scores drop below 'A', catching dangling DNS before it reaches production. Remember: middleBrick detects and reports—you must update DNS and Hapi configs to remediate.