SRV response record contain invalid names

1. The problem I’m having:

Using a SRV dynamic resolver in reverse_proxy will not get the upstream because when Caddy looks up the SRV record it throws a “DNS response contained records which contain invalid names”

2. Error messages and/or full log output:

Apr 05 20:38:07 caddy caddy[305773]: {"level":"error","ts":1743885487.8432784,"logger":"http.handlers.reverse_proxy","msg":"failed getting dynamic upstreams; falling back to static upstreams","error":"lookup _http._tcp.test.ghastlylab.io: DNS response contained records which contain invalid names"}

3. Caddy version:

v2.9.1 h1:OEYiZ7DbCzAWVb6TNEkjRcSCRGHVoZsJinoDR/n9oaY=

4. How I installed and ran Caddy:

Custom caddy image


FROM caddy:2.9.1-builder AS builder

RUN xcaddy build \
    --with github.com/caddy-dns/desec \
    --with github.com/corazawaf/coraza-caddy \
    --with github.com/mholt/caddy-l4 \
    --with github.com/ueffel/caddy-brotli \
    --with github.com/caddyserver/cache-handler \
    --with github.com/porech/caddy-maxmind-geolocation \
    --with github.com/mholt/caddy-ratelimit \
    --with github.com/greenpau/caddy-security \
    --with github.com/darkweak/storages/otter/caddy

FROM caddy:2.9.1

COPY --from=builder /usr/bin/caddy /usr/bin/caddy

and managed with Ansible/systemd

- name: Caddy Container
  become: true
  become_user: podman-deploy
  containers.podman.podman_container:
    name: caddy
    image: git.ghastlylab.io/rheaalleen/caddy:latest
    state: created
    cap_add: "NET_ADMIN"
    label:
      io.containers.autoupdate=registry
      PODMAN_SYSTEMD_UNIT=container-caddy.service
    env:
      PUID: "0"
      PGID: "0"
      TZ: "Europe/Berlin"
    volume:
      - "/opt/podman/Caddyfile:/etc/caddy/Caddyfile"
      - "/container-data/caddy/data/:/data"
      - "/container-data/caddy/config/:/config"
      - "/container-data/lego/certificates:/certificates"
    ports:
      - "80:80"
      - "443:443"
    network: host

Caddyfile

test.ghastlylab.io {
        tls /certificates/ghastlylab.io.crt /certificates/ghastlylab.io.key
        reverse_proxy {
                dynamic srv _http._tcp.test.ghastlylab.io. {
                        resolvers 10.0.106.10
                }
        }
}

The SRV record is set in a PowerDNS server through the API, the servers accepts the record without any problem and I can query it with dig/nslookup

A record (test.ghastlylab.io) points to Caddy, then Caddy is supposed to resolve the SRV record for the internal reverse_proxy host/port

curl --request PATCH \
  --url http://10.0.106.10:8081/api/v1/servers/localhost/zones/ghastlylab.io \
  --header 'content-type: application/json' \
  --header 'X-API-Key: '' \
  --data '{"rrsets": [{"name": "_http._tcp.test.ghastlylab.io.", "type": "SRV", "ttl": 60, "changetype": "REPLACE", "records": [{"content": "10 10 8888 10.0.106.155.", "disabled": false}]}]}'

Screenshot from 2025-04-05 23-05-53

dig _http._tcp.test.ghastlylab.io SRV              

; <<>> DiG 9.18.33-1~deb12u2-Debian <<>> _http._tcp.test.ghastlylab.io SRV
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27191
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;_http._tcp.test.ghastlylab.io.     IN      SRV

;; ANSWER SECTION:
_http._tcp.test.ghastlylab.io. 60   IN      SRV     10 10 8888 10.0.106.155.

;; Query time: 0 msec
;; SERVER: 10.0.106.13#53(10.0.106.13) (UDP)
;; WHEN: Sat Apr 05 20:49:44 UTC 2025
;; MSG SIZE  rcvd: 86

The 10.0.106.13 is the recursor that forwards the ghastlylab.io to my auth DNS at 10.0.106.10, just for clarity, querying both work fine for SRV records

So whats the problem at this point with the record?

I don’t believe this is correct - you can’t use an IP address as an SRV target. According to RFC 2782:

Target
The domain name of the target host.

A valid SRV record would look more like this:

_http._tcp.test.ghastlylab.io. 60   IN   SRV   10 10 8888 test-server.ghastlylab.io.
test-server.ghastlylab.io.   7200   IN     A   10.0.106.155
2 Likes

Good catch, thanks

Was so deep into the Caddy and PowerDNS API that I forgot to check up on other side of the problem, it’s always DNS :melting_face: