SRV record question

[Chris Thompson]

On Jun 16 2010, Niobos wrote:

>Hi,
>
>I'm a bit confused on how exactly to implement the SRV records.
>At this moment, it's more an exercise for me, since client software
>doesn't use them (yet).
>
>I have a CALDAV server running on a vhost (apache config). Currently,
>DNS looks like this:
>caldav   CNAME  server
>server   A 1.2.3.4
>         AAAA dead:beef:cafe::1
>
>So in fact, I'm already abusing CNAME to map a service to a host. This
>is convenient, since the IP is only specified once. (So if it changes,
>there is no risk of overlooking an entry)

If that's "abuse", we are all guilty of it!

>The trouble starts when adding SRV records. Spontaneously, I'd add
>_caldav._tcp   SRV 10 10 80 caldav
>
>However, RFC2782 explicitly states that: the name MUST NOT be an alias
>Which would require me to change DNS to look like:
>caldav   A 1.2.3.4
>caldav   AAAA dead:beef:cafe::1
>server   A 1.2.3.4
>server   AAAA dead:beef:cafe::1
>_caldav._tcp   SRV 10 10 80 caldav
>
>In this configuration, the server's IP is present multiple times, which
>will lead to mistakes in the future. I can't let the SRV-record point
>directly to "server" either, since the vhost-configuration needs the
>correct Host:-HTTP header.
>
>Or am I missing something?

You are mixing up protocol names and service names. If CalDAV is
standardised to used the "caldav" protocol name in SRV records,
and you want to use the service name caldev.example.com, you would
put 

_caldev._tcp.caldev  SRV  10 10 80 server

in your (example.com) zone file. The first component is the protocol
specifier, the third is the (initial component of) the service name.

And such a SRV record can co-exist with your existing CNAME for
caldev.example.com, which is just as well while the applications
take umpty-ump years to make the transition...

-- 
Chris Thompson
Email: cet1 at cam.ac.uk