[cost: external_io (DNS via Cloudflare + Google; TLS handshake to public sips/_sips._tcp targets when applicable) | read-only | rate-limited per IP: 10/min, 200/day] Walk DNS the same way a SIP UA does (RFC 3263 §4.1): NAPTR → SRV → A/AAAA. Given a SIP URI ("sip:example.com"), bare hostname ("exa...
Part of the SIPFlow server.
Free to start. No card required.
AI agents call dns_diagnose_sip_target to retrieve information from SIPFlow without modifying any data. This is common in research, monitoring, and reporting workflows where the agent needs context before taking action. Because read operations don't change state, they are generally safe to allow without restrictions -- but you may still want rate limits to control API costs.
Even though dns_diagnose_sip_target only reads data, uncontrolled read access can leak sensitive information or rack up API costs. An agent caught in a retry loop could make thousands of calls per minute. A rate limit gives you a safety net without blocking legitimate use.
Read-only tools are safe to allow by default. No rate limit needed unless you want to control costs.
{
"version": "1",
"default": "deny",
"tools": {
"dns_diagnose_sip_target": {}
}
}See the full SIPFlow policy for all 21 tools.
These attack patterns abuse exactly the kind of access dns_diagnose_sip_target gives an agent. Each links to the full case and the policy that stops it:
Other read tools across the catalogue. The same approach applies to each: allow, with a rate cap to control cost.
[cost: external_io (DNS via Cloudflare + Google; TLS handshake to public sips/_sips._tcp targets when applicable) | read-only | rate-limited per IP: 10/min, 200/day] Walk DNS the same way a SIP UA does (RFC 3263 §4.1): NAPTR → SRV → A/AAAA. Given a SIP URI ("sip:example.com"), bare hostname ("example.com"), or "host:port" string, return the records that exist and the resolution ladder a UA would try. When the queried target uses TLS (sips: URI, transport=tls/wss, or any _sips._tcp SRV record), the tool also performs a TLS handshake against each resolved sips target and reports the negotiated TLS version + cipher, the leaf certificate's subject / issuer / SANs / validity, the chain length and whether it validates against Node's default trust store, plus two cert-domain checks: RFC 5922 §7.2 strict (cert must cover the original SIP domain) and a lenient SAN match against the SRV target hostname. Egress safety: - Per-IP rate limited. - Hostnames that resolve only to RFC 1918 / loopback / link-local / documentation / multicast space are refused (SSRF guard). - Walk depth capped to prevent runaway NAPTR / CNAME chains. - TLS probes capped at 4 (host, port) tuples per call, 5 s handshake timeout each, public-IP only (we connect to the resolved IP, not the hostname, so the system resolver cannot redirect us into private space). Use to diagnose: - "carrier doesn't answer" / "wrong port" / "TLS instead of UDP" routing puzzles - "carrier rejects our target because no SRV is published" - when A/AAAA resolves but SRV is missing the tool synthesises a copy-pasteable suggested zone-record block pointing at the resolved canonical hostname - "TLS handshake works but cert isn't valid for the SIP domain" - RFC 5922 §7.2 compliance is checked separately from generic chain validation, since the SAN must cover the *original* SIP domain (not the SRV-redirected target) ACL caveat: this tool checks DNS + TLS only. Most carriers (Twilio, Telnyx, Bandwidth, …) authorize inbound SIP by source IP whitelist on the trunk (see https://www.twilio.com/docs/sip-trunking/api/ipaccesscontrollist-resource). Even if DNS resolves cleanly and the TLS cert is valid, INVITEs from any IP not on your trunk's IP ACL will be silently dropped or rejected. Verify reachability from the SBC itself. Pair with: troubleshoot_response_code when 503 / 408 / 480 are involved; search_sip_docs(vendor=...) for carrier-specific routing docs.. It is categorised as a Read tool in the SIPFlow MCP Server, which means it retrieves data without modifying state.
Register the SIPFlow MCP server in PolicyLayer and add a rule for dns_diagnose_sip_target: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches SIPFlow. Nothing to install.
dns_diagnose_sip_target is a Read tool with low risk. Read-only tools are generally safe to allow by default.
Yes. Add a rate_limit block to the dns_diagnose_sip_target rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for dns_diagnose_sip_target. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
dns_diagnose_sip_target is provided by the SIPFlow MCP server (sipflow/sipflow). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic rules across all 21 SIPFlow tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.