I’m trying to create an SRV record for _openpgpkey._tcp.example.com (domain name changed) which will point to my target port of 443 on a subdomain of the same domain, www.example.com. This all looks OK in the dash but I see that behind the scenes the target is being changed to dc-hexhexhex.example.com.
Now I assume that this is some kind of ‘direct’ hostname to bypass Clouflare but this isn’t what I want - I need it to be what I’ve defined. I’m using Cloudflare specifically to do SSL termination and present a valid SSL cert to the world because on the backend my certs are self-signed.
With the present implementation any service which is accessed via SRV record defn would appear to be broken to me.
Is there a toggle anywhere to say - ‘this SRV is what I say it is, and not what Cloudflare think it should be’?
It does look like the functionality you describe is correct - setting a SRV record pointing to a domain will create a dc-hex subdomain that points directly to an origin server, even if the port is set to 443 or 80. Whether or not this is intentional is beyond my knowledge.
What I would like to ask is why you need a SRV record. If this is for HTTP/HTTPS traffic, you shouldn’t need to create a SRV since browsers work fine with regular subdomains.
In my case the requirement is for an OpenPGP thing for the distribution of keys. So if someone emails [email protected] then a PGP-aware client will look for a public key file at https://example.com/.well-known/openpgpkey/hu/<somehashoftheemailaddress>. This allows messages to be encrypted without third-party key servers being involved.
However it is common that domains may not necessarily run a web server on the FQDN which matches the email FQDN - in my case my website is on www.example.com and not example.com. In the event that an OpenPGP lookup is to be made on am FQDN different to that of the email address FQDN, you use an SRV record _openpgpkey._tcp on the email FQDN to say where the https site hosting your keys actually resides.
So long story short, I have a valid requirement for an SRV record for a service called _openpgpkey to resolve to a Cloudflare proxied domain name, even though it’s on port 443.
It’s weird Cloudflare DNS should break behind-the-scenes without any thought that you might actually want what you say you want.
I guess Cloudflare assumes a SRV record is only meant for non-HTTP traffic and does this to prevent people from messing up their config and getting mad (since CF normally can’t proxy things like minecraft) but messes up when it is proxying HTTP traffic.
Yeah, I can kind of see why it’d be in place but a lot of Cloudflare users are pretty techie so there should at last be an option to just do what you say and not just insist on actively messing with config.
Hopefully someone in support will see this and see the merit in letting us define what we need instead of assuming we’re making a mistake.
Yeah, yesterday. No real reply as yet but the first line AI auto-reply bot did have a statement that staff can’t/won’t alter records so we’ll see how we get on.
In my eyes this is looking more like a bug. There’s no reason to change hostnames of targets just because they happen to be Cloudflare-enabled hosts if the port is one that Cloudflare happily proxy. I can half-see the wisdom in other cases such as people using an SRV record for their Minecraft server where keeping the target as a Clouflare-enabled host would cause the service to fail but not where Cloudflare can handle the traffic because it is on a valid port they proxy.
Actually even in the Minecraft example I don’t really see why Cloudflare would change targets, just let the thing fail and let the user see they need to create a new direct record themselves. Not sure ever messing with someone’s explicit record is ever be a good thing. I even tried updating via an API call in case this was just a front-end thing but same problem.
That’s correct. We don’t alter records. But that doesn’t mean that one of our support engineers won’t also be able to offer some guidance on what you can do or investigate if there might be a bug. If you have a ticket number I can try and get some additional eyes on it.
Cheers @ryan. It’s 1589737. Obviously this is not high-priority as this issue is presently just on my personal sandpit domain but this is definitely something that the more I look at it, the more I think it’s a bad design on Cloudflare’s part and should be altered.
Unless there’s very good reason those SRV records should return as they’ve been specified. And if the records really must be altered (personally I disagree with this but I can see the logic) then it shouldn’t be simply because the target is a Cloudflare-proxied host if Cloudflare are able to proxy that traffic (e.g. it’s one of your HTTP, HTTPS ports). I can half understand trying to be smart and prevent people shooting themselves in the foot but not at the expense of actually preventing knowledgeable users create a valid working config.
Presently if someone really needed what I’m trialling, they’d have to host DNS elsewhere.
Hi @ryan. Any chance you could give this a nudge (ticket 1589737)?
It’s absolutely not something I’m expecting support to fix in this ticket for me but I do honestly think it is something you guys need to change at some point as it’s an unnecessary hurdle and something I honestly believe Cloudflare is doing incorrectly for no good reason (other than not enough thought went into the initial implementation).
I created a Feedback - Usage & Design post for what I think needs to happen:
and I’d be happy to at least know that somewhere in the organisation it’s recognised and put on a roadmap for review or something. It’s a trivial change (actually undoing some unnecessary Cloudflare record tweaking) and will fix something that’s clearly broken when it’s looked at properly and objectively.
EDIT: One other thing - if I have two domains (example.com and example.org, say) both proxied by Clouflare then I can set an SRV record on example.com which points to port 443 on exmple.org just fine! So this is nothing to do with you not allowing SRV to point to Cloudflare-proxied hostnames, it’s just the logic as to when records are converted is screwy.