SRV Record Parser API

About the SRV Record Parser API

An SRV record parser API that breaks a DNS service record into its parts and explains what each one means. Paste an SRV record such as _minecraft._tcp.example.com. 3600 IN SRV 0 5 25565 mc.example.com. to see each field explained, including the service, protocol, port and target, along with the TTL and DNS class.

It is useful wherever SRV records are written by hand or read from a zone file: checking a record for a game server, VoIP or SIP trunk, XMPP chat, Kerberos or LDAP before it goes live, documenting existing records, or building a DNS management screen that shows records in plain language.

The Free plan returns the record name split into service, protocol and domain, plus the TTL, class and a validity flag. Paid plans add the priority, weight, port and target host, recognition of common services like HTTP, XMPP, SIP and the mail protocols with their usual default ports, and short plain-English explanations of the priority, weight and connection target.

How it works

SRV Record Parser splits the record string on whitespace and accepts three layouts: the full zone-file form (name TTL class SRV priority weight port target), the name followed only by the four values, or the four values alone. When the first token starts with an underscore it is taken as the record name. A number after it is read as the TTL only when a class or SRV keyword follows, or when three more numbers follow it, so _sip._tcp.host 10 60 5060 target is not mistaken for a TTL of 10. The class may be IN, CH or HS and defaults to IN.

priority, weight and port must be integers from 0 to 65535 or the call returns a 400 naming the bad field, as it does when fewer than four values remain. The name is split on dots into service (such as _http), protocol (with its underscore removed) and domain. When no name is given these are null. The trailing dot is stripped from target.

service_info looks up the service and protocol pair in a built-in list of 19 entries covering HTTP, HTTPS, FTP, LDAP, LDAPS, XMPP client and server, SIP and SIPS, SMTP, IMAP, POP3 and their TLS variants, Kerberos, CalDAV and CardDAV. It is null for anything else, such as _minecraft._tcp. interpretation turns the numbers into text: priority 0 is described as highest priority, weight 0 as no preference, and a target of . reports that the service is deliberately not available, as RFC 2782 defines.

is_valid is true on every successful parse; malformed input returns an error instead. On the Free plan priority, weight, port, target, service_info and interpretation are removed.

What people use it for

Service Discovery

Parse DNS SRV records for service discovery in distributed systems, microservices, and load-balanced environments

Network Diagnostics

Build network diagnostic tools that analyze SRV records for troubleshooting connectivity and service availability issues

Configuration Analysis

Analyze service configuration in DNS including priority, weight, port, and target information for optimization

Record Validation

Validate SRV record formatting and structure to ensure compliance with RFC 2782 standards and best practices

Ways to call it

One endpoint, many ways in — REST with JSON, XML, YAML and CSV, plus GraphQL and an MCP interface for AI agents.

JSON

Default REST response

XML

Markup format

YAML

Human-readable

CSV

Tabular export

Beta

GraphQL

Query language

New

MCP

For AI agents

Request parameters — POST /v1/srvparser

Sent as JSON in the request body. Premium parameters are accepted on every plan but only take effect on plans that include them. Anything not listed here is dropped rather than passed through.

Required

1
2
3
4

curl -X POST "https://api.apiverve.com/v1/srvparser" \
  -H "x-api-key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"record":"_http._tcp.example.com. 86400 IN SRV 10 60 80 server.example.com."}'

Authentication

Send your key in the x-api-key header. That is the only auth step — no token exchange, and no per-endpoint scope to configure.

Response — POST /v1/srvparser

Every APIVerve endpoint returns the same three top-level keys, so one response handler covers your whole integration: status, error and data. Only data changes shape.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

{
  "status": "ok",
  "error": null,
  "data": {
    "raw_record": "_http._tcp.example.com. 86400 IN SRV 10 60 80 server.example.com.",
    "parsed": {
      "name": "_http._tcp.example.com.",
      "service": "_http",
      "protocol": "tcp",
      "domain": "example.com.",
      "ttl": 86400,
      "class": "IN",
      "priority": 10,
      "weight": 60,
      "port": 80,
      "target": "server.example.com"
    },
    "service_info": {
      "name": "HTTP",
      "description": "Web service",
      "default_port": 80
    },
    "interpretation": {
      "priority_explanation": "Priority level 10 (lower is better)",
      "weight_explanation": "Weight 60 for load balancing",
      "target_explanation": "Connect to server.example.com:80"
    },
    "is_valid": true
  }
}

Response fields

Paths are relative to data. Premium fields are absent rather than zeroed on plans that do not include them, so check for presence instead of comparing to 0.

Response headers

Every response carries your balance, so your own code always knows where it stands without polling anything. All four are exposed to browsers through CORS.

Errors

Read the HTTP status first, then error for the specific reason. The body names the parameter that has to change.

What a call costs — 2 credits per call

Credits are shared across every APIVerve API — one balance, one key, one bill. Failed requests never count against it, so a rejected input costs nothing.

Calls are what the credits buy at this API's rate — spend them here, on any of the other APIs, or across both. Nothing is reserved per endpoint.

Zero-code embed — one snippet, no backend

Drop an interactive SRV Record Parser form onto any page. The widget calls the API for you, so no key ever appears in your markup and there is nothing to deploy.

Changelog — SRV Record Parser API

Every change to this endpoint, newest first. Breaking changes ship as a new version and the previous one keeps serving — response fields are added, never removed or retyped in place, so an integration written against v1 keeps working.

Currently v1