Per-Account DNS Pinning for Unresolvable Hosts

Configure host-to-IP overrides so Guard can scan hosts that do not resolve correctly from its scanning vantage point.

Per-Account DNS Pinning for Unresolvable Hosts

Some hosts cannot be reached from Guard's scanning infrastructure because they do not resolve from Guard's vantage point, or because Guard's resolver returns an incorrect IP. Common causes include split-horizon DNS configurations, internal address ranges that are only accessible via specific resolvers, and hosts whose public DNS records point to private or loopback addresses.

DNS pinning lets you define per-account host-to-IP overrides that allow Guard to scan these hosts without changing how the asset is represented or how scan traffic is structured.

How it works

When a hostname has a pinned IP configured, Guard's web scanning pipeline connects the underlying socket to the pinned IP instead of relying on DNS resolution. Everything above the socket layer is unchanged:

  • The hostname in the target URL is preserved.
  • The Host header sent in HTTP requests continues to use the hostname, maintaining virtual-host routing.
  • The TLS SNI value is the hostname, so certificate matching and TLS negotiation behave as expected.

The override is applied transparently beneath the URL- and hostname-keyed web pipeline, so the asset appears in Guard exactly as it would for any other host.

Supported scenarios

Scenario

Description

Unresolvable hosts

Hosts with no public DNS record, or whose records have been removed, but which are still reachable at a known IP.

Split-horizon DNS

Hosts that resolve to an internal IP on the customer network but return no record (or an unreachable record) from Guard's resolver.

Mis-resolving hosts

Hosts whose public DNS returns a private or incorrect IP from Guard's resolver vantage point.

Configure DNS pinning for your account

To add or update host-to-IP overrides, contact your Praetorian account team. Overrides are configured as a per-account map of hostname → IP address and take effect for all subsequent scans against the specified hostnames.

Provide the following for each override:

  • Hostname — the fully qualified domain name as it appears in your Guard asset inventory (e.g., internal.example.com).
  • IP address — the IPv4 or IPv6 address Guard should connect to when scanning that hostname.

Considerations

  • DNS pinning does not alter the asset record. The hostname, not the pinned IP, is the canonical identifier for the asset in Guard.
  • Overrides apply only to Guard's scanning pipeline. They have no effect on how your DNS is configured or how other systems resolve these hosts.
  • If the pinned IP becomes unreachable, the host will appear unreachable in scan results, the same as any other connectivity failure.
  • Supply only IPs that are within scope and that you are authorized to scan.