UPDATE 2 4/8/2012: It’s been a year and a half (almost), but Apple finally fixed CalDAV SRV record discovery in, I believe, iOS 5.0.2 (and therefore 5.1). So all of this is now completely valid, and supported by Apple (finally)!
UPDATE 12/18/2010: It’s taken me a bit to post this (sorry), but I can say that iOS 4.2.1 (the released version of 4.2) supports discovery of CardDAV servers over SRV records. However, CalDAV does NOT work. I’ve been told by people in the know that it’s coming, it just didn’t make it into 4.2.1. Now, I have no idea why… one would think it’s the same back-end, but who knows. Anyway, CardDAV works, CalDAV doesn’t, but hopefully 4.3 (or whatever they call it) will fix that.
Part of being a systems administrator is making the life of your customers easier. Whether it’s having a file share auto-mount when they login, having to only remember a single password (or just having to login once via SSO), or in this case, not having to remember what server provides what services. So, over the past few days I’ve been playing with autodiscovery of CalDAV and CardDAV for Mac OS X and iOS.
Address Book and iCal in 10.6 use SRV records nicely. If I tell iCal that my server is www.example.com, and I have an SRV records that say:
_caldav._tcp.www.example.com. 86400 IN SRV 0 0 8008 caldav.example.com.
_caldavs._tcp.www.example.com. 86400 IN SRV 0 0 8443 caldav.example.com.
iCal magically figures out that my actual caldav server is caldav.example.com (it defaults to lookup caldavs first, then caldav if caldavs isn’t available). I have a similar SRV record set up for CardDAV:
_carddav._tcp.www.example.com. 86400 IN SRV 0 0 8800 carddav.example.com.
_carddavs._tcp.www.example.com. 86400 IN SRV 0 0 8843 carddav.example.com.
And once again, Address Book on 10.6 magically figures it out (again, defaulting to carddavs and falling back to carddav if carddavs isn’t available).
The PROBLEM is that iOS (iPhone 4, 4.1, and from what I can tell, 4.2b1) don’t pay attention to SRV records, at all (Submitted bug 8447498 with Apple). They look for http(s)://www.example.com/.well-known/caldav (or /.well-known/carddav). And if they can’t find those, it tries /, then /principals, then /principals/
Thing is, I’ve tried just about every type of redirect I can figure out that redirects www.example.com/.well-known/caldav to caldav.example.com, but no matter what, iOS keeps trying to login to caldav on www.example.com. So if it gets a 301, it doesn’t pay attention, it just keeps trying.
The RFC for /.well-known/ (here) just establishes a registry for .well-known. For all we know, iOS is looking for actual data inside that caldav or carddav file in /.well-known/ rather than just a 301 to the proper location.
I’m going to keep playing with this over the weekend, and in my free time for the next few weeks. I’ve emailed a couple Apple mailing lists, and I’ll probably shoot an email or two to some Apple employee friends and see if they can point me in the right direction. I think I need to find an iOS dev (or register myself) that can look up the discovery information in the dev docs (if it’s documented).
Some more discussion on this can be found: here. Will follow up when I know more…
On a related note, I also set up SRV records for imaps, pop3s, smtp, and submission, like the following:
_smtp._tcp.www.example.com. 86400 IN SRV 0 0 25 mail.example.com.
_imaps._tcp.www.example.com. 86400 IN SRV 0 0 993 mail.example.com.
_pop3s._tcp.www.example.com. 86400 IN SRV 10 0 995 mail.example.com.
_submission._tcp.www.example.com. 86400 IN SRV 0 0 587 mail.example.com.
Alas, nothing seems to support discovery this way yet. Tomorrow, I’ll post about how you can make Mail.app in 10.5 and above auto-configure mail accounts for users based upon their email address (like Mail.app does for @mac.com, @me.com, @gmail.com, etc).
Daniel says
Hi, have you figured out how to fix IN SRV records for iOS4.1 yet? 🙂
There is a discussion over at http://andrew.mcmillan.net.nz/blog/srv_records_with_dnsmasq#comment-1652 that could offer you some pointers.
I am going to look at this myself later today, but I would appreciate it if you could share any new discoveries before I spend much more time on it.
staze says
Daniel,
From what I can tell, iOS doesn’t look at SRV records at all. So, no love. I haven’t had a lot of chance to play around with it since this post, as the term has started up. But I hope to play more.
I’ve read that discussion, and it’s referenced in this article. Infact, I’m the “RS”. =) I should try his answer, but I’m pretty sure iOS just isn’t following the redirects. =/ But I’ll play with it tonight and see what I get.
Will keep you posted.
staze says
Haven’t played with this anymore, but I’m pretty sure it’s not working. From what I can tell, iOS doesn’t look at SRV records at all. And putting a 301 on /.well-known/ doesn’t seem to make the iOS device look at the redirect. It just continues on and looks at /principals.
Seems like it’s broken, and from what I hear, iOS dev is fairly insulated from other parts of Apple. So it may very well be that the RFC drafter has no reason to believe the iOS doesn’t support these things, but the iOS team hasn’t implemented them yet. Or maybe they think SRV records are a security risk. =/ Either way, putting this on hold until iOS 4.2 comes out, or I hear something from my bug reports. Might try beta 3 of 4.2 when it’s released, see if it fixes this.
Let me know if you figure out anything. =)
staze says
Daniel,
I have word back from Apple on my bug (not under NDA) that this is a confirmed issue, and should be addressed in iOS 4.2, but I cannot confirm/deny this due to NDA.
That said, I’d say hold off until 4.2 before putting much effort into this.