Allow the use of Cloudflare-proxied hostname/ports in SRV records

Feedback Usage & Design
1

Presently when one defines an SRV record where the target host is a Cloudflare-proxied hostname within the same domain, a client lookup returns instead an automatically generated host of dc-<id>.example.com in order to bypass the Cloudflare proxy for that service (a ‘shadow record’).

Although this may be advantageous in situations where users have set the record up without thinking about the nature of the traffic and whether Cloudflare will pass it upstream (e.g. SRV record for Minecraft server which Cloudflare clearly can’t proxy) there are situations where the defined record has been set to a Cloudflare-proxied hostname on purpose and you break things by simply changing it unnecessarily on us.

For example, an SRV record which is used to point to an HTTPS end-point could conceivably need to be set to target of port 443 on a Cloudflare-proxied host www.example.com. Changing this target to dc-<id>.example.com could yield an unusable record as the backend won’t necessarily serve a valid cert for dc-<id>.example.com, and the client may even drop all non-Cloudflare proxied traffic in the firewall, for example.

My opinion is that any SRV record where the target host/port combination may be proxied by Cloudflare should be returned completely as specified by the user, without any unnecessary conversion to a dc-<id.>example.com hostname.

It should be noted that this is already the behaviour where the target host is proxied by Cloudflare but is external to the domain hosting the SRV record: i.e. if I have two hosts (www.example.com and www.example.org) both proxied by Cloudflare then I can set an SRV record on example.com which points to port 443 on www.example.org just fine! So this is nothing to do with there being a technical reason restricting your ability to have an SRV to point to Cloudflare-proxied hostnames, it’s just the logic as to when records are converted to dc-<id>.example.com is screwy. Instead of converting record ‘when host is Cloudflare-proxied and in this domain’ (existing behaviour) it should be convert this record ‘when host is Cloudflare-proxied and port isn’t one we proxy’.

4 Likes
2

+1 for this.

Although most standard services that utilise service discovery based on SRV records cannot be proxied by CloudFlare, it’s also quite common to set up these records for CalDAV(s) and CardDAV(s) which can be proxied without any hiccup. For example, Google and Apple:

$ dig _caldavs._tcp.google.com srv

; <<>> DiG 9.16.0 <<>> _caldavs._tcp.google.com srv
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2545
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_caldavs._tcp.google.com.      IN      SRV

;; ANSWER SECTION:
_caldavs._tcp.google.com. 867   IN      SRV     5 0 443 calendar.google.com.

;; Query time: 0 msec
;; SERVER: 10.128.1.1#53(10.128.1.1)
;; WHEN: Tue Feb 25 00:09:17 AEDT 2020
;; MSG SIZE  rcvd: 92

$ dig _caldavs._tcp.icloud.com srv

; <<>> DiG 9.16.0 <<>> _caldavs._tcp.icloud.com srv
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61937
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_caldavs._tcp.icloud.com.      IN      SRV

;; ANSWER SECTION:
_caldavs._tcp.icloud.com. 3536  IN      SRV     0 0 443 caldav.icloud.com.

;; Query time: 0 msec
;; SERVER: 10.128.1.1#53(10.128.1.1)
;; WHEN: Tue Feb 25 00:09:24 AEDT 2020
;; MSG SIZE  rcvd: 90