Dangling Dns in Axum with Basic Auth

A dangling DNS record occurs when a hostname (e.g., internal.service.local) resolves to an environment where the original service no longer exists or has moved. In Axum applications that rely on Basic Auth for access control, this combination can expose internal endpoints or authentication boundaries in unintended ways.

When an Axum service uses Basic Auth via middleware that validates credentials and then forwards requests internally—often using hostnames from configuration—a dangling DNS entry can redirect those internal calls to an unexpected host. Because Basic Auth credentials are typically passed along in headers during internal service calls, an attacker who can influence DNS resolution (e.g., through compromised internal DNS or a malicious actor who registers a formerly unclaimed domain) may cause the Axum app to send authenticated requests to a rogue endpoint.

Consider an Axum app that authenticates a request using Basic Auth, then calls an internal metadata service at http://metadata.internal.local. If metadata.internal.local becomes a dangling DNS record and resolves to a public host controlled by an attacker, the Axum service may forward authenticated requests there. The attacker can observe or manipulate traffic intended for the internal service, and because the Axum app trusts the internal network boundary, it may not re-validate the response’s authenticity. This scenario is particularly relevant when using OpenAPI/Swagger spec analysis to map runtime behavior: spec definitions may reference internal hostnames that no longer resolve correctly, and runtime findings can reveal mismatches between expected and observed endpoints.

In a black-box scan, middleBrick tests unauthenticated attack surfaces and can detect anomalies in how endpoints resolve and respond. If the Axum app does not enforce strict hostname verification and relies on DNS for internal service discovery, the dangling DNS vector becomes a pathway for information exposure or SSRF-like behavior. The 12 security checks, including Input Validation, Property Authorization, and SSRF, are designed to surface such risks by correlating spec definitions with observed network behavior without making assumptions about internal infrastructure.

To mitigate risks related to dangling DNS when using Basic Auth in Axum, ensure that internal service resolution does not rely on mutable DNS records and that credentials are not forwarded indiscriminately. Use explicit IPs or service discovery mechanisms that avoid DNS lookups for critical internal calls, and validate hostnames and responses rigorously.

Below are concrete Axum code examples demonstrating secure handling of Basic Auth and safe internal calls.

1. Basic Auth middleware with strict hostname verification

Use tower-http for Basic Auth and validate the request target before forwarding.

use axum::{routing::get, Router};
use tower_http::auth::{AuthLayer, Credentials};
use std::convert::Infallible;

async fn validate_host(req: &axum::http::Request<()>) -> Result<(), Infallible> {
    let host = req.uri().host().unwrap_or("");
    // Allow only specific, expected internal hostnames or IPs
    match host {
        "127.0.0.1" | "localhost" | "metadata.internal" => Ok(()),
        _ => Err(Infallible),
    }
}

fn auth_layer() -> AuthLayer {
    AuthLayer::basic("secure_realm", |username: String, password: String| async move {
        // Validate credentials against a secure store
        if username == "admin" && password == "S3cur3P@ss!" {
            Some(Credentials { username })
        } else {
            None
        }
    })
}

fn app() -> Router {
    Router::new()
        .route("/secure", get(|| async { "Authenticated and host-verified" }))
        .layer(auth_layer())
}

2. Safe internal HTTP client with hostname pinning

When making internal calls, avoid DNS-based discovery for sensitive endpoints and pin to a known address.

use reqwest::Client;
use std::net::IpAddr;

async fn call_internal_service() -> Result<(), reqwest::Error> {
    // Use an IP or a verified hostname that does not rely on mutable DNS
    let ip: IpAddr = "10.0.0.10".parse().expect("valid IP");
    let client = Client::new();
    let url = format!("http://{}/metadata", ip);
    let response = client
        .get(&url)
        .header("Authorization", "Basic YWRtaW46UzFjdXJlUDFAc3M=") // pre-verified credentials
        .send()
        .await?;
    // Validate response hostname in headers or body if needed
    Ok(())
}

3. Reject unexpected hosts in responses

Ensure that your Axum service validates any redirects or upstream responses to prevent leakage to unintended hosts.

use axum::{routing::post, http::StatusCode};

async fn proxy_handler(
    axum::extract::Request(req): axum::extract::Request,
) -> Result<axum::response::Response, (StatusCode, String)> {
    let target_host = "10.0.0.10"; // pinned internal target
    let uri = req.uri().clone();
    if uri.host() != Some(target_host) {
        return Err((StatusCode::FORBIDDEN, "Host mismatch".to_string()));
    }
    // Proceed with safe request handling
    Ok(axum::response::Response::new(req.into_body()))
}

These practices reduce the attack surface introduced by dangling DNS by limiting reliance on dynamic resolution and ensuring that Basic Auth credentials are only accepted and forwarded under strict hostname controls. Security findings from tools like middleBrick can help identify mismatches between spec-defined hosts and runtime behavior, supporting more precise remediation.