Dangling Dns in Aspnet (Csharp)

Dangling DNS in ASP.NET with C# refers to a scenario where an application uses DNS names that are no longer valid or resolvable, creating potential attack surfaces during API endpoint resolution. This commonly occurs when ASP.NET applications dynamically resolve hostnames for outgoing HTTP requests, service discovery, or callback URLs without proper validation. If the application trusts user-controllable or attacker-influenced DNS names, or if it fails to validate DNS resolution results before using them in HTTP calls, it creates vulnerabilities such as SSRF (Server-Side Request Forgery). In ASP.NET applications written in C#, this risk is amplified when using HttpClient with programmatically resolved endpoints or when binding to configuration values that reference unvalidated DNS entries.

For example, consider an ASP.NET Core API that receives a redirect URL or an external service callback address from user input and parses it into a Uri object. If the application does not validate that the resolved IP address matches an expected internal range or that the hostname resolves to a trusted domain, an attacker can manipulate the DNS input to resolve to an internal service or external malicious server. This can lead to SSRF attacks where the application makes unauthorized internal network requests.

In C#, developers often use System.Net.Dns.GetHostAddressesAsync() or rely on DNS resolution through HttpClientHandler without explicit validation. When DNS names are sourced from configuration files, database entries, or user-supplied headers like X-Forwarded-Host, the application may resolve to attacker-controlled infrastructure. This is particularly dangerous in containerized environments or cloud deployments (e.g., Kubernetes services or serverless functions) where DNS names are dynamically assigned and may be reused across tenants.

Additionally, ASP.NET applications that use DNS-based service discovery (e.g., with Consul, Eureka, or Kubernetes DNS) can be vulnerable if they do not pin to specific service instances or validate service health before making requests. A dangling DNS entry — such as a service name that was decommissioned but still referenced in configuration — can cause resolution failures or, worse, resolve to an unintended endpoint that an attacker may have spun up to intercept traffic.

The core issue lies in the trust boundary between user-supplied or dynamically configured DNS names and the application's reliance on their resolution. Without explicit validation, DNS-based attacks can bypass traditional network security controls and lead to data exfiltration, internal reconnaissance, or privilege escalation within the network.

Remediation of dangling DNS vulnerabilities in ASP.NET with C# requires explicit validation of DNS-resolved endpoints before use. Developers should never trust DNS resolution outcomes directly and must enforce strict allowlists or network boundary checks. Below is a C# code example demonstrating secure DNS handling in an ASP.NET Core application.

using System.Net.Http; using System.Net.Security; using System.Threading.Tasks; using Microsoft.AspNetCore.Http; using System.Dns; using System.Net; using System.Collections.Generic;

public async Task HandleExternalRedirect(string providedHost, string providedPath)
{
    // Define trusted domains explicitly
    var trustedDomains = new List { "api.partner.com", "callback.internal.local" };
    
    // Parse the provided host
    if (!Uri.TryCreate($"https://{providedHost}{providedPath}", UriKind.Absolute, out var uri))
    {
        return BadRequest("Invalid URL format");
    }
    
    // Validate hostname against trusted list
    if (!trustedDomains.Contains(uri.Host, StringComparer.OrdinalIgnoreCase))
    {
        return Forbid("Domain not allowed");
    }
    
    // Optional: Resolve DNS and validate IP is internal
    IPAddress[] addresses;
    try
    {
        addresses = await Dns.GetHostAddressesAsync(uri.Host);
    }
    catch (Exception)
    {
        return BadRequest("Unable to resolve hostname");
    }
    
    // Ensure resolved IP is within expected internal range
    var allowedIpRange = new[] { IPAddress.Parse("10.0.0.1"), IPAddress.Parse("10.0.0.254") };
    bool isAllowedIp = false;
    foreach (var address in addresses)
    {
        if (allowedIpRange.Any(ip => ip.Equals(address)))
        {
            isAllowedIp = true;
            break;
        }
    }
    
    if (!isAllowedIp)
    {
        return BadRequest("Resolved IP is outside allowed range");
    }
    
    // Proceed with safe HttpClient call
    using var handler = new HttpClientHandler();
    using var client = new HttpClient(handler);
    
    try
    {
        var response = await client.GetAsync(uri.ToString());
        return Ok(await response.Content.ReadAsStringAsync());
    }
    catch (Exception ex)
    {
        return StatusCode(500, $"Request failed: {ex.Message}");
    }
}

This C# example enforces a strict allowlist of trusted domains, validates DNS resolution, and checks that resolved IPs fall within an expected internal range. It avoids relying on user input directly for DNS resolution and prevents SSRF by rejecting unexpected or external DNS names.

Another mitigation strategy is to disable DNS resolution for internal service discovery when possible and instead use dependency injection or configuration-driven endpoints. For example, use IConfiguration to inject known service URLs rather than dynamically resolving them at runtime. Additionally, ASP.NET applications should run with minimal outbound network permissions and use network segmentation to limit the impact of any successful SSRF attack.