Handling of DNS SRV types (XMPP) with HTTP challenge?

[petercooperjr]

@aarongable

Beyond that, I'm slightly confused as to why this request would be relevant at all. SRV records are useful for service discovery. You might perform a DNS query for an identifier like _xmpp._tcp.example.com, and the response would be something like IN SRV 5 0 5223 example.com. The original query _xmpp._tcp.example.com is not a "real" domain name, it is a combination of domain + protocol + service which is used as a lookup key, and the response tells you what domain name to actually perform A record lookups on to find the relevant IP address.

I think the concern is, and I also may not be following completely, the case where _xmpp._tcp.example.com has a SRV record for some-other-host.example.net, along with a client that when trying to connect to XMPP for example.com looks up the some-other-host.example.net server and connects to it, but expects it to present a certificate for example.com rather than a certificate for its own hostname.

I'm not clear on whether that's actually the "standard" behavior for the client, or if clients are supposed to be expecting a certificate for the pointed-to hostname instead (like the analogous way MX records work). But if that's the way clients work, that they need the name on the certificate to match the original name instead of the actual hostname, then one may need to get two certificates for example.com, one for any main services running on the A/AAAA record for it, and one for the some-other-host.example.net server. And it can a bit awkward with ACME to set up multiple clients on different systems to fulfill separate DNS-01 challenges (which I think is what the draft-ietf-acme-scoped-dns-challenges proposal is supposed to help with?). And it can be really awkward with HTTP-01, since the servers need to coordinate somehow and probably redirect one server to the other for at least some of the time, or distribute the certificate separately, or the like.

All solvable problems, and I don't think compelling enough to actually get an update to the BRs/RFCs/etc., but I can see how they're annoying. If I do in fact understand it correctly, which again I'm not sure I do.

@_wojtek

I'm aware that there is DNS-01 challenge (which also gives wildcard certificate) but that would require user providing access/credentials to their DNS service to add relevant ACME TXT entries and given that would mean access to complete zone I'd say only a few (or even none) would decide to do that.

More and more DNS providers (especially the business-oriented big "cloud" ones) allow for limited-scope credentials that can only be used to update a specific TXT record. And you can do a lot with an acme-dns type solution of a custom DNS server for the problem you're trying to solve. But those kinds of features may not be pervasive enough quite yet, no.