On Mon Sep 21 13:10:10 2009, Matthew Wild wrote:
2009/9/21 Dave Cridland <[email protected]>:
> 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 [email protected]
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:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
