Dangling Dns in Echo Go (Go)

A dangling DNS reference in an Echo Go application occurs when the application resolves a hostname to an IP address for use in outbound requests, but does not re-validate or re-resolve that address after the original DNS response may have changed. In Go, this can happen when you resolve a hostname once, cache the net.IP or net.Addr, and then reuse that cached value across multiple requests or server restarts. If the DNS record for the target host changes (for example, a CNAME or A record is updated to point to a different backend), the cached IP remains in use, potentially directing traffic to an unintended host controlled by an attacker or to an infrastructure that no longer provides the expected service.

Echo Go, a popular HTTP router and middleware framework, often encourages clean handler patterns where dependencies like HTTP clients are composed into handlers or injected via context. When developers use a shared *http.Client with custom Transport settings or pre-resolved network addresses, and those settings are derived from a one-time DNS lookup, the application can exhibit dangling DNS behavior. This is especially risky when the resolved host is used for service-to-service calls, log shipping, or external API integrations where the caller assumes the endpoint identity is stable based on the initial name. An attacker who can influence DNS records (e.g., through compromised domain management or a recursive resolver attack) may cause the application to route sensitive traffic to a malicious endpoint without any code change on the server side.

Consider a scenario where an Echo Go service resolves api.partner.example.com once at startup to configure a backend URL for telemetry. The code uses net.LookupIP and caches the first A record. If the DNS record is later changed to point to a different server, the service continues to send data to the old IP, which may now be controlled by an adversary. This pattern maps to common web security concerns such as Server-Side Request Forgery (SSRF) and external data exposure when the dangling resolution leads to unintended internal or external endpoints. Because the scan categories include Input Validation and Data Exposure, middleBrick can detect such risks by correlating runtime behavior with the OpenAPI specification and active probes that validate endpoint identity across resolutions.

LLM/AI Security checks are relevant here when the application uses AI-driven components that construct or modify outbound requests based on model outputs. If a system prompt or generated configuration contains a hostname that is resolved once and cached, an attacker might attempt prompt injection to alter the intended target, leading to a dangling DNS condition where the model’s suggested endpoint no longer matches the expected trust boundary. middleBrick’s LLM/AI Security capabilities, including system prompt leakage detection and active prompt injection testing, help surface these risks by examining how dynamic hostnames are handled in AI-assisted workflows.

To detect this class of issue, middleBrick performs black-box scanning against the unauthenticated attack surface of your Echo Go service. It does not rely on internal architecture details but instead validates that endpoint identities remain consistent across requests and that DNS-derived configurations are either short-lived or re-validated. The scanner checks whether the application correctly handles potential changes in DNS resolution and flags scenarios where cached network addresses could lead to misrouted traffic or data exposure.

To mitigate dangling DNS in an Echo Go application, avoid caching resolved IP addresses for outbound calls. Instead, perform fresh DNS resolution for each request or use transport mechanisms that support re-validation. When constructing HTTP clients, prefer high-level abstractions that do not pin to a specific IP, and ensure that hostnames are not derived from unverified inputs or model outputs without additional checks.

Example of vulnerable code that caches a resolved IP:

package main

import (
    "net"
    "net/http"
    "time"

    "github.com/labstack/echo/v4"
)

var (
    cachedIP string
    client   = &http.Client{Timeout: 10 * time.Second}
)

func init() {
    ips, _ := net.LookupIP("api.partner.example.com")
    if len(ips) > 0 {
        cachedIP = ips[0].String()
    }
}

func TelemetryHandler(c echo.Context) error {
    url := "https://" + cachedIP + "/v1/telemetry"
    req, _ := http.NewRequest(http.MethodPost, url, c.Request().Body)
    req.Header.Set("Content-Type", "application/json")
    resp, err := client.Do(req)
    if err != nil {
        return c.String(http.StatusInternalServerError, "failed")
    }
    defer resp.Body.Close()
    return c.NoContent(http.StatusOK)
}

This pattern is risky because cachedIP may become stale. An improved approach is to resolve the hostname per request or use a custom http.RoundTripper that re-resolves on each use:

package main

import (
    "context"
    "net"
    "net/http"
    "time"

    "github.com/labstack/echo/v4"
)

func newDynamicTransport(host string) http.RoundTripper {
    return &dynamicRoundTripper{host: host, client: &http.Client{Timeout: 10 * time.Second}}
}

type dynamicRoundTripper struct {
    host  string
    client *http.Client
}

func (d *dynamicRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
    ctx := req.Context()
    ips, err := net.LookupIPHost(ctx, d.host)
    if err != nil {
        return nil, err
    }
    // Use the first resolved IP for this request; in production you may want smarter selection
    addr := ips[0].String() + ":443"
    req.URL.Host = addr
    req.URL.Scheme = "https"
    req.Host = d.host
    return d.client.Transport.RoundTrip(req)
}

func NewDynamicClient(host string) *http.Client {
    return &http.Client{
        Transport: newDynamicTransport(host),
        Timeout:   10 * time.Second,
    }
}

func TelemetryHandler(c echo.Context) error {
    client := NewDynamicClient("api.partner.example.com")
    url := "https://api.partner.example.com/v1/telemetry"
    req, _ := http.NewRequest(http.MethodPost, url, c.Request().Body)
    req.Header.Set("Content-Type", "application/json")
    resp, err := client.Do(req)
    if err != nil {
        return c.String(http.StatusInternalServerError, "failed")
    }
    defer resp.Body.Close()
    return c.NoContent(http.StatusOK)
}

In the remediation example, each request performs a fresh DNS lookup via net.LookupIPHost, reducing the window during which a stale or malicious IP can be used. For Echo Go handlers, you can further integrate this pattern by constructing clients at route initialization with a shared dynamic transport, rather than at package init time. This aligns with secure dependency management practices and helps the scan findings related to Input Validation and Data Exposure remain within acceptable risk profiles.

Additionally, review how hostnames are sourced. If they originate from user input or external configuration, validate and sanitize them before resolution. Combine these Go-specific practices with middleBrick’s CLI scans (using middlebrick scan <url>) and, for CI/CD integration, the GitHub Action to fail builds if risk scores exceed your threshold. For teams using AI coding assistants, the MCP Server can help keep scans and checks close to development workflows without introducing unsafe runtime dependencies.