‹ back home

DNS-based discovery for CalDav and CardDav

2023-04-30 #open-source #vdirsyncer

rfc6764 describes a mechanism for caldav service providers to expose exactly where their server is located while requiring minimal input from the user.

The main intent here is that if you are hosting your email and calendar for example.com, your users only need to provide their calendar application with the domain example.com and it can automatically figure out exactly where the caldav server is located. Let’s assume, for this example, that the caldav service is located at https://dav.example.com/caldav/.

First of all, a DNS record indicates the domain where the server runs. This can be another domain, or a subdomain:

_caldavs._tcp     SRV 0 1 443 dav.example.com.

And a separate record that indicates the path at which the caldav server runs on that host:

_caldavs._tcp    TXT path=/caldav

This prevents the user from having to figure out the exact path and port to provide to the calendar application.

Some real life examples:

_caldavs._tcp.posteo.de.	300	IN	SRV	0 0 8443 posteo.de.
_caldavs._tcp.posteo.de.	300	IN	TXT	"path=/"
_caldavs._tcp.fastmail.com.	2923	IN	SRV	0 1 443 d277161.caldav.fastmail.com.

Fastmail doesn’t have a TXT record. Instead it uses another approach specified in the RFC: the well-known path /.well-known/caldav redirects to the real path where the caldav server runs.

There’s nothing extremely complicated here, and this mechanism makes life a lot easier for end users. Without it, users would have to dig through their provider’s documentation to find the exact URL and port and copy-paste all that into their calendar application. It’s not terrible, but far from a pleasant experience.

If you are hosting a public caldav service and don’t have discovery set up, I encourage you to look into it. It’s a one-time kind of setup that will make life easier for many of your users (and even yourself when configuring new devices).

— § —