Zone Transfer in Actix with Mutual Tls

A DNS zone transfer is a replication mechanism where secondary nameservers query a primary nameserver for a full copy of DNS records. When this functionality is accidentally exposed over an Actix web service, and mutual TLS (mTLS) is in use, the combination can create a misleading sense of security while still enabling data exposure.

mTLS ensures both the client and the server present valid certificates, which Actix can enforce by configuring an HTTPS acceptor with rustls or similar TLS backends. However, mTLS does not by itself enforce authorization. If an Actix route that performs DNS queries is reachable only over mTLS, an attacker who possesses a valid client certificate (e.g., obtained through compromise or misissuance) can still trigger a zone transfer if the endpoint does not apply strict source restrictions and record-level checks.

In practice, this means an endpoint like /dns/zone might verify client identity via mTLS but then perform an unsigned, unauthenticated AXFR/IXFR query to an internal primary DNS server. Because the request appears authorized (mTLS client cert validated), the DNS server may return the full zone file. The Actix service then reflects this data to the caller, effectively exposing the zone transfer over a seemingly secure channel. The risk is compounded if the endpoint lacks rate limiting, IP allowlists, or query-type restrictions, which are independent of TLS client authentication.

Furthermore, if the Actix application parses and logs incoming certificate details, an attacker can probe for differences in responses (e.g., HTTP 200 with zone data vs 403) to infer zone contents. Even with mTLS, the unauthenticated query to the DNS backend means the transport security between Actix and DNS server might be missing, allowing internal interception. This illustrates that mTLS secures the client-to-Actix hop, but does not prevent zone transfer if the application logic does not restrict queries, validate requestors, and limit record exposure.

To mitigate zone transfer risks in Actix while using mTLS, combine transport security with strict authorization, input validation, and query controls. Below are concrete, realistic code examples that show how to configure mTLS in Actix and enforce additional guards to prevent unauthorized zone transfers.

1. Configure mTLS in Actix with rustls

Ensure the Actix server requires and validates client certificates. This example sets up an HTTPS server using actix-web and rustls, requiring client auth and loading trusted CA certificates.

use actix_web::{web, App, HttpServer, Responder};
use std::sync::Arc;
use rustls::{Certificate, PrivateKey, ServerConfig};
use rustls_pemfile::{certs, pkcs8_private_keys};
use std::io::BufReader;
use std::fs::File;

async fn zone_handler(client_cert: Option) -> impl Responder {
    // Authorization check should happen here, not just mTLS presence
    format!("Zone request with client cert: {:?}", client_cert)
}

#[actix_web::main]
async fn main() -> std::io::Result<()> {
    // Load server certificate and key
    let cert_file = &mut BufReader::new(File::open("server-cert.pem").unwrap());
    let key_file = &mut BufReader::new(File::open("server-key.pem").unwrap());

    let cert_chain: Vec = certs(cert_file).unwrap().into_iter().map(Certificate).collect();
    let mut keys: Vec = pkcs8_private_keys(key_file).unwrap().into_iter().map(PrivateKey).collect();

    let mut server_config = ServerConfig::builder()
        .with_safe_defaults()
        .with_no_client_auth()
        .with_single_cert(cert_chain, keys.remove(0))
        .expect("invalid server certificate or key");

    // Require client authentication
    server_config.client_auth_root_subjects = vec![]; // populate with allowed subject DNs or hashes if needed
    server_config.client_auth = Arc::new(|_end_entity, _intermediates| {
        // Implement custom verification if needed; returning Ok indicates acceptance
        Ok(rustls::server::ClientCertVerified::assertion())
    });

    HttpServer::new(move || {
        App::new()
            .route("/dns/zone", web::get().to(zone_handler))
    })
    .bind_rustls("0.0.0.0:8443", server_config)?
    .run()
    .await
}

2. Enforce authorization and query restrictions

Even with mTLS, add role/attribute checks and limit allowed query types. Do not allow AXFR/IXFR from arbitrary authenticated clients.

use actix_web::{web, HttpRequest, HttpResponse};
use trust_dns_resolver::Resolver;
use trust_dns_resolver::config::{ResolverConfig, ResolverOpts};

async fn secure_zone_transfer(
    req: HttpRequest,
    web::Path(domain): web::Path,
) -> HttpResponse {
    // Example: extract client certificate info from request extensions (set by middleware)
    let client_subject = req.extensions().get::(); // Assume set after mTLS validation
    let allowed_subjects = vec!["CN=allowed-dns-client.example.com"];

    if let Some(subject) = client_subject {
        if !allowed_subjects.contains(&subject.as_str()) {
            return HttpResponse::Forbidden().body("Unauthorized client");
        }
    } else {
        return HttpResponse::Forbidden().body("Client certificate required");
    }

    // Do not allow zone transfers by default; only permit specific, controlled endpoints
    // and enforce query-type restrictions (e.g., only SOA, NS)
    let resolver = Resolver::new(ResolverConfig::default(), ResolverOpts::default()).unwrap();
    // Perform a controlled query, not a full zone transfer
    match resolver.lookup(domain.as_str(), trust_dns_proto::op::QueryType::SOA) {
        Ok(response) => HttpResponse::Ok().body(response.to_string()),
        Err(e) => HttpResponse::InternalServerError().body(format!("DNS error: {}", e)),
    }
}

3. Defense-in-depth: network and application controls

Apply network-level restrictions (firewalls, VPC peering) so that the DNS backend is not reachable from general internet-facing endpoints. Combine with input validation to prevent SSRF-style redirection to internal DNS servers and enforce strict CORS if the endpoint is browser-accessible. mTLS ensures client identity, but the application must still enforce per-request authorization and query constraints to prevent zone transfer abuse.