Why an SRV Record Only Helps a Client That Queries It

Adding an SRV record to your zone does not teach any VPN client to look it up. The client has to know the label, decide to send the query, and act on what comes back, and DNS cannot supply the first two of those. Most failed SRV plans are therefore client problems wearing a DNS costume. Read the client's discovery behaviour first, then publish only the label it actually queries.

A record nobody queries cannot help anyone

SRV publishes the location of a service; it does not announce one. Nothing pushes a record at a client, and no resolver volunteers a name that was never asked for. The lookup begins with the application deciding to make it, so the label has to come from the product's documentation or from watching the software on the wire. Where the client has no discovery step, a record changes the zone and nothing else.

That is why one product on a network can start working while another is unaffected by the same change. The variable is the software, and the DNS server is doing exactly what it was told. Read the zone back after the edit as well, because a mistyped label hides easily among records that all look alike.

Read the fields before you write them

A record carries four values, and each answers a different question: priority orders the targets a client may try, weight shares load between targets of equal priority, port names the transport port, and target names the host. The specification also permits a target of . to mean the service is deliberately unavailable, which is a useful answer rather than a broken one.

None of those fields carries credentials, a certificate policy or an application version, and a client that ignores weight still connects, just without the intended balance. The target needs address records of its own, and it should be a canonical name rather than an alias. Publishing a record that points at a host with no listener produces a connection error that reads like a DNS fault, which is the most expensive kind of misleading. Publish the whole chain or none of it.

Find the label the client actually sends

Establish the label from evidence rather than from a guess about the product's name. Either the documentation states the service name, or a capture shows the query leaving the client when it starts. Both routes end at the same place: an exact name and type to test against the resolver.

dig +short SRV _vpn._tcp.gw.example
dig +short A edge2.gw.example
tcpdump -ni any udp port 53

Compare the answer with the record you published, character by character, because the underscores and the trailing dot are part of the name. An empty answer to a query that was actually sent points at the zone, while no query at all points at the client, and those findings send you to different teams. A real answer looks like the line below, where priority 20 loses to any lower-priority record and the client dials port 8443 on the named target.

_vpn._tcp.gw.example. 600 IN SRV 20 10 8443 edge2.gw.example.

The target has to exist as well

A target that resolves is not the same as a service that answers. Check the address records for the target, then check that something is listening on the published port and protocol. A TCP record pointing at a UDP-only listener is a mismatch that no amount of zone editing repairs. Keep the TTL short while the target is in flux, and lengthen it once the name stops moving.

Clients that do implement discovery vary in how much of the record they honour. Some use priority only, some treat weight as advisory, and a few ignore the port and assume a default. Those differences belong in your notes beside the label, because they explain behaviour that otherwise looks like a resolver fault.

Discovery is not authentication

An SRV answer says where to connect, and it says nothing about whom to trust once you arrive. Keep the client's certificate validation and server-identity checks exactly as they were, since a record that somebody else can forge should not become a trust decision. DNS answers are cacheable and editable by whoever controls the zone, which makes them a poor place to encode policy.

For a client without discovery support, distribute the profile or gateway URL it does accept, and record which product uses which method. That note stops the next administrator from adding a record and expecting it to work everywhere. The SRV specification describes selection among targets, and reading it as an authorization mechanism is how a helpful record becomes a security assumption. Publish deliberately, name the label in your documentation, and treat the client as the component that decides whether any of it matters.