Publish an SRV record when an application specifies DNS-based service discovery. PD Google Cloud DNS presents the relevant fields so the destination, port, priority and weight can be checked individually.

Get the application’s requirements

Collect the requested service/protocol name, priority, weight, port and target. The application must actually support that discovery mechanism. A DNS record does not open a firewall or start the service.

Open Google Cloud DNS → Zones → Records for the authoritative managed zone, or use the enabled DNS Manager navigation link or Manage DNS on a linked domain/service. Confirm the project and public nameservers before changing data.

Enter and verify

1. Search for the full intended SRV name and review existing targets.
2. Select SRV in the editor.
3. Complete the requested service/protocol name and TTL.
4. Enter priority, weight, port and target in the appropriate fields.
5. Save, reload and compare the entire record set with the application instructions.
6. Check the authoritative SRV answer and the application’s discovery result.

Use a hostname for the target rather than a full web URL. Preserve an intentional multi-target set and its priority/weight relationship. Values in the same Google Cloud name/type set share one TTL.

Check service reachability separately

The target’s own address, requested port and application service must also work. If DNS is correct but the application fails, investigate its discovery support, target connection and firewall before adding another SRV entry.

If the save was refused, keep the exact provider, policy, lock or quota result. If the saved values differ, inspect the typed fields rather than replacing unrelated records. Your hosting team should retain the assembled name, individual SRV fields, original action time and redacted result while checking DNS and application behaviour. Use the address-record guide if the target’s A or AAAA record needs attention.

See the PD Google Cloud DNS WHMCS guide for related tasks, or explore the module.