Pin Host to IP

Pin Host to IP (the card on Settings → Scanning) lets you tell Guard's web scanner to connect a hostname to a chosen IP instead of trusting public DNS.

Use it for split-horizon DNS, hosts with no public record, or hosts whose public DNS returns a private or wrong address from Guard's vantage point.

How the pin is applied

Only the TCP connection target changes. Above the socket:

• The hostname in the URL stays the same
• The HTTP Host header stays the hostname (virtual-host routing still works)
• TLS SNI stays the hostname (certificates still match)

The asset in Guard remains the hostname, not the pinned IP. A pin does not rewrite DNS anywhere else.

Ownership check

Before a pin is saved, Guard verifies the IP (POST /setting/host-overrides/verify):

• verified — the IP is in your cloud ranges or a connected integration. The pin is accepted.
• not_integrated — configure the matching cloud integration so Guard can prove ownership.
• not_in_account / unknown — you can still save if you acknowledge unverified pins. That acknowledgment is stored with the map.

You cannot save a roster that still has unverified rows unless the acknowledge box is checked.

Limits and validation

• Maximum 256 pins
• Hostnames are lowercased; duplicates are rejected
• Reserved names (localhost, metadata.google.internal, .local, .internal, .arpa, and similar) are blocked
• You can add rows one at a time or import a list

Who can edit

Anyone with manage settings (Admin). This is customer-self-serve; it does not require Praetorian.

Authenticated scanning (logging into a web app) is not this card. That is configured on the web application seed.