[Operators] On indirection in SRV record targets

[Dave Cridland]

On Mon Sep 21 13:10:10 2009, Matthew Wild wrote:
> 2009/9/21 Dave Cridland <dave at cridland.net>:
> > On Sat Sep 19 15:24:27 2009, Matthew Wild wrote:
> >>
> >> According to RFC 2782, SRV record targets are *not* allowed to be
> >> "alias" records, this includes CNAMEs and PTRs for example. I  
> just
> >> made a change (not yet checked in) to Prosody which  
> (unintentionally)
> >> would render domains configured in such a way unreachable. I  
> restarted
> >> my server with the new code for testing to find a handful of my
> >> contacts can no longer accessible.
> >
> > Wikipedia has a very good primer on CNAME (and DNAME, its scarier  
> cousin).
> >
> > I'd particularly refer you to  
> http://mengwong.com/misc/rfc1912-is-wrong.html
> > though, which refers to RFC 974:
> >
> > "
> >   Of course, by the robustness
> >   principle, domain software should not fail when presented with  
> CNAME
> >   chains or loops; CNAME chains should be followed and CNAME loops
> >   signalled as an error.
> > "
> >
> > So I'd say that settles your question of what the default should  
> be. :-)
> >
> 
> I'd read that in the RFC, but I noted that the 'should not' was not
> capitalised, and hence really means MAY :)
> 
> 
Not true, this predates the widespread use of capitalized BCP 14  
keywords - I'm not sure they were used much prior to the RFC 1122 and  
RFC 1123 cleanup work.


> There are valid reasons for not allowing CNAMEs as targets in SRV
> records. You make the requirements in the RFC pointless if you just
> pretend they aren't there.
> 
> 
Sure, but you have to deal with them. The robustness principle quoted  
is saying exactly that - IEN 111, later republished as RFC 760, says,  
in section 3.2:

  The implementation of a protocol must be robust.  Each  
implementation
  must expect to interoperate with others created by different
  individuals.  While the goal of this specification is to be explicit
  about the protocol there is the possibility of differing
  interpretations.  In general, an implementation should be  
conservative
  in its sending behavior, and liberal in its receiving behavior.   
That
  is, it should be careful to send well-formed datagrams, but should
  accept any datagram that it can interpret (e.g., not object to
  technical errors where the meaning is still clear).

RFC 1122 is a little more detailed in quite what this means in  
practise.

Note, though, that:

_xmpp-server._tcp SRV 0 0 foo.com 5269
foo.com CNAME bar.com
foo.com AAAA ::1

*is* a bad thing. If you have a CNAME for a record, that's the *only*  
record you can have.

RFC 1123, incidentally, makes no comment about CNAME records except  
that they cannot be the right-hand-side of an email address - that  
is, in the above case, one couldn't have postmaster at foo.com

FWIW, that latter is actually a very common error, since many people  
like to have:

foo.com CNAME www.foo.com
foo.com MX 1 mail.foo.com

Which is illegal on two counts.


> But technical arguments aside, people aren't going to use an IM  
> server
> if they can't contact their friends on badlyconfigured.example.net,
> over which they have no power to fix. This is what really makes my
> mind up. However that won't stop me correcting people who do the  
> Wrong
> thing :)

As with many things in the RFC series, there's a difference between  
"Shouldn't be doing that" and "Should be dealing with it".

But RFC 1122 is very clear that you should be logging these errors,  
and you're entitled to complain.

FWIW, I don't see the reasoning - unless you're trying to take  
advantage of the additional records section of the DNS response,  
you'll perform two queries - one to find SRV records, and one using  
the stock host lookup. The problem is that if additional records  
don't fit, then they're discarded with no indication, so it's  
impossible to tell whether you have the complete list - and this,  
incidentally, may mean you lose all A, or AAAA, records, and are  
fooled into thinking it's IPv6 or IPv4 only.

(Truncated SRV records, being in the answer section, will be  
indicated with a flag in the DNS packet, allowing you to retry over  
TCP).

Dave.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade