SRV records and port discovery — finding the port without an A record

SRV records in Kubernetes DNS expose the Service ports for clients that support SRV-aware discovery. The format is _port._proto.service.namespace.svc.cluster.local. The use cases are services that need to discover the port dynamically (Consul, Cassandra, gRPC). This lesson walks the SRV record, the format, and the operational discipline.

The SRV record format

The SRV record for a Kubernetes Service follows the DNS SRV format:

_<port>._<proto>.<service>.<namespace>.svc.cluster.local

For example:

_http._tcp.billing.prod-app.svc.cluster.local

The format is:

• _<port>: the port name (not the number).
• _<proto>: the protocol (tcp or udp).
• <service>: the Service’s name.
• <namespace>: the Service’s namespace.
• svc.cluster.local: the cluster’s domain.

The SRV record returns the priority, weight, port, and target:

# Substitute your own value before running:
POD=web-5f9c7d8b6c-2xk9p

kubectl exec "$POD" -- dig SRV _http._tcp.billing.prod-app.svc.cluster.local

;; ANSWER SECTION:
_http._tcp.billing.prod-app.svc.cluster.local. 30 IN SRV 10 50 80 billing.prod-app.svc.cluster.local.

The format is priority weight port target. The priority is 10, the weight is 50, the port is 80, the target is the Service’s DNS name.

The use cases

The SRV record’s use cases:

• Consul: Consul uses SRV records for service discovery. The Consul agent queries the SRV record for each Service.
• Cassandra: Cassandra uses SRV records for node discovery. The Cassandra client queries the SRV record for the cluster’s nodes.
• gRPC: gRPC clients can use SRV records for load balancing. The gRPC client queries the SRV record for the Service’s backends.
• Other SRV-aware clients: any client that supports SRV records can use the cluster’s DNS.

The SRV record is the right choice for clients that support SRV-aware discovery.

sequenceDiagram
    autonumber
    participant C as Client
    participant DNS as CoreDNS
    participant S as Service
    C->>DNS: SRV _http._tcp.billing.prod-app.svc.cluster.local
    DNS->>S: lookup Service billing
    S-->>DNS: port 80, ClusterIP
    DNS-->>C: SRV 10 50 80 billing.prod-app.svc.cluster.local
    C->>DNS: A billing.prod-app.svc.cluster.local
    DNS-->>C: 10.96.0.10
    C->>C: connect to 10.96.0.10:80

The client makes two DNS queries: one for the SRV record (returns the port) and one for the A record (returns the ClusterIP).

The port name

The SRV record uses the Service’s port name, not the port number. The Service’s port must be named:

apiVersion: v1
kind: Service
metadata:
  name: billing
spec:
  selector:
    app: billing
  ports:
    - name: http
      port: 80
      targetPort: 8080
      protocol: TCP

The port name is http. The SRV record is _http._tcp.billing.prod-app.svc.cluster.local.

A Service without named ports does not have SRV records. The cluster operator must name the ports.

The failure modes

The SRV record’s failure modes:

• Port not named: the Service has no port name; the SRV record is not generated. The fix is to name the ports.
• DNS service down: the cluster DNS service is unavailable. The fix is to verify the DNS service.
• Wrong port name: the SRV record uses the wrong port name. The fix is to verify the port name.
• Client does not support SRV: the client cannot query the SRV record. The fix is to use an SRV- aware client.

The operational discipline

The SRV record’s operational discipline:

• Name the ports in the Service manifest. The cluster operator must name the ports.
• Use SRV-aware clients for dynamic discovery. The client must support SRV records.
• Audit the SRV records for every Service. The cluster operator must verify the records.
• Test the SRV records in staging. The records must work for the workload.
• Document the SRV usage. The cluster operator must understand which Services use SRV.

Quiz

Production discipline

• Name the ports in the Service manifest. The cluster operator must name the ports.
• Use SRV-aware clients for dynamic discovery. The client must support SRV records.
• Audit the SRV records for every Service. The cluster operator must verify the records.
• Test the SRV records in staging. The records must work for the workload.
• Document the SRV usage. The cluster operator must understand which Services use SRV.
• Set up a CI check for the port names. The CI check can catch the missing port names at every deploy.
• Monitor the DNS service’s SRV records. The SRV records are the source of truth for the client.
• Plan the SRV evolution. The cluster operator must plan the migration to SRV-aware clients.