Use an SRV record when an application specifies DNS-based service discovery. PD AWS Route 53 DNS provides separate fields for the SRV values so the published name and destination can be checked deliberately.

Get the application requirements

Collect the requested service/protocol hostname, priority, weight, port and target from the application administrator. An SRV record is useful only when the application actually looks for it; it does not open a firewall port or start a service.

Open the correct zone’s records through AWS Route 53 DNS → Zones, or use My Tools in the client portal, then the DNS manager. Confirm that the domain’s delegation reaches this hosted zone.

Enter and save the record

1. Search for the intended SRV name and review any existing targets.
2. Choose SRV in the type-aware editor.
3. Enter the requested name and TTL.
4. Enter priority, weight, port and target in their corresponding fields.
5. Save and reload the record set.
6. Compare the resulting SRV values with the application’s instructions.

The service/protocol labels are part of the requested name. The target is a hostname rather than a web URL. Keep intentional multiple-target records and their priority/weight relationship; do not delete every matching row merely to change one server.

Check discovery and connectivity

Verify the authoritative SRV answer, then check whether the application discovers and reaches the target at the requested port. The target’s own address and service must also work.

If the published record differs, inspect the saved typed fields before adding another entry. If the module refuses a save, check the exact AWS permission, policy, quota or lock result. If DNS is correct but the application still fails, investigate its discovery support, firewall and service configuration separately.

Your hosting team should retain the full name, individual SRV values, original action time and redacted error while checking the actual DNS and application result. Use the address-record guide if the target hostname itself needs an A or AAAA record.

Check same-named hosted zones before changes

If your AWS account contains multiple hosted zones with the same domain name, do not assume choosing a same-named row selects a particular hosted-zone ID. This module resolves zones by name. Have your AWS administrator compare the exact hosted-zone ID, records and delegated nameservers before using module writes; use AWS’s native zone-specific controls if the target remains ambiguous. Do not create or delete another zone to diagnose that ambiguity.

Check the saved service record

Your hosting team and application administrator should compare the complete service/protocol name, priority, weight, port, target and shared TTL with the saved SRV set and authoritative answer. Check whether the application uses discovery and can reach the target service separately from publication. Inspect a refused write before another entry is added. Preserve intentional multiple targets rather than deleting them as an experiment.

See the PD AWS Route 53 DNS Blesta guide for related tasks, or explore the module.