Subject: [xmpp] Regarding SRV records

From: Florian Jensen <[email-masked]>
Date: Tue, 8 Feb 2011 15:10:43 +0000

Hi,

as we talked about SRV records on monday, I quickly checked what is actually allowed to do with them.
I may have said that SRV records are allowed to point to CNAME's which is NOT true.

SRV records, just like MX records, have to point to a A or AAAA record.

Greets,

Florian Jensen

---

From: Dave Cridland <[email-masked]>
Date: Tue, 08 Feb 2011 15:21:44 +0000

> SRV records, just like MX records, have to point to a A or AAAA  

Right. I was suggesting:

_xmpp-server._tcp.enterprise.example CNAME  
_xmpp-server._tcp.isp.example
;; Enterprise.example's XMPP S2S service is delegated to ISP.example

_xmpp-server._tcp.isp.example SRV ...

I suspect that this is:

a) More useful to the Enterprise.example administrators.

b) More practical for us to handle, as then one RR - the CNAME - acts  
as a single delegation record.

However, Kurt seemed to suggest we should, instead do something more  
explicit - I suggest something like:

_xmpp-server._delegate.enterprise.example CNAME isp.example

... may be more useful.

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

---

From: Tory Patnoe <[email-masked]>
Date: Tue, 08 Feb 2011 09:32:08 -0700

In practice SRV records pointing to a CNAME is not rare at all.

-- Tory

---

From: Florian Jensen <[email-masked]>
Date: Tue, 8 Feb 2011 17:24:26 +0000

Hmm, I just checked RFC 2782:

Under "Overview and rationale", it says:

Note that where this document refers to "address records", it means A RR's, AAAA RR's, or their most modern equivalent.

Also see "Target" on Page 3 of the RFC:
There MUST be one or more address records for this name, the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181).  Implementors are urged, but not required, to return the address record(s) in the Additional Data section.

So yeah, I'd still say: No CNAME's allowed, or am I missing something here?

---

From: Justin Karneges <[email-masked]>
Date: Tue, 8 Feb 2011 09:37:36 -0800

On Tuesday 08 February 2011 09:24:26 Florian Jensen wrote:
> Note that where this document refers to "address records", it means A RR's,
> AAAA RR's, or their most modern equivalent.
> 
> There MUST be one or more address records for this name, the name MUST NOT
> be an alias (in the sense of RFC 1034 or RFC 2181).  Implementors are
> urged, but not required, to return the address record(s) in the Additional
> Data section.
> 

Not that this answers your question, but I don't see how "no CNAMEs" could be 
enforced practically.  I feel that it will always work regardless of what the 
recommendations are.

But, it would be interesting to know if there really is a recommendation to 
not set up your DNS this way, and why.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 08 Feb 2011 17:44:01 +0000

> not set up your DNS this way, and why.

Most obviously:

recursion.example.com CNAME recursion.example.com

Less obvious is a loop across multiple CNAMEs. This suggests that  
CNAME, at least, MUST NOT have an alias on the RHS.

Mostly, it's an efficiency thing - when asking for any record, you  
may get a CNAME or DNAME instead, but things on the RHS are always  
one query away. Some SMTP servers will choke on a CNAME on the RHS of  
an MX, though.

Dave.

---

From: Richard L. Barnes <[email-masked]>
Date: Tue, 8 Feb 2011 21:47:49 -0800

Fortunately, for the purposes of using DNSSEC to secure delegations, all of these redirection records look more or less the same.  My guess is that we'll end up saying something like "Any names you encounter in DNSSEC-protected delegations are OK".  Consider, for example, the following example:

_xmpp-server._tcp.example.com
--(SRV, DNSSEC)--> xmpp.provider.com
--(CNAME, no DNSSEC)----> box1.cluster2.provider.com

... then you could accept example.com or xmpp.provider.com, but not box1.cluster2.provider.com.

As had been mentioned before, this is probably a concept worth writing up in a form that would work for other applications as well.  Say for ENUM, which might do NAPTR to get to a service like SIP or XMPP, then do SRV to delegate the service to a provider.  

4.3.2.1.e164.arpa NAPTR "E2U+sip" "!^.*$!sip:[email-masked]!"
_sip._tcp.example.com SRV proxy.provider.com

But of course we'll work things out for XMPP first :)

--Richard

On Feb 8, 2011, at 11:44 AM, Dave Cridland wrote:

> Less obvious is a loop across multiple CNAMEs. This suggests that CNAME, at least, MUST NOT have an alias on the RHS.
> 
> Mostly, it's an efficiency thing - when asking for any record, you may get a CNAME or DNAME instead, but things on the RHS are always one query away. Some SMTP servers will choke on a CNAME on the RHS of an MX, though.
> 
> Dave.
> -- 
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Jehan Pagès <[email-masked]>
Date: Wed, 9 Feb 2011 23:30:41 +0900

Hi,

On Wed, Feb 9, 2011 at 12:21 AM, Dave Cridland <[email-masked]> wrote:
> _xmpp-server._tcp.enterprise.example CNAME _xmpp-server._tcp.isp.example

Hi don't get your example. If you do a SRV on the domain
enterprise.example, why a CNAME would be made first? No resolver will
do that because it does not make much sense.
The resolver to which you ask the xmpp-server service of the domain
enterprise.example will first make a SRV, and only after (depending on
the answer) will do other queries (A or AAAA queries).

> b) More practical for us to handle, as then one RR - the CNAME - acts as a
> single delegation record.
>

I don't think that a CNAME accepts a target in the form of a SRV
request. Moreover the second part of a SRV must be a valid protocol
registered by IANA (it must be listed here:
http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml
which is always the last version of the list). Hence "delegate" is not
a valid protocol, and cannot be used like this.

Anyway if we want to do something like this, the logical thing would
be to set it as a service (
http://www.iana.org/assignments/port-numbers ).
So we should rather register a service xmpp-delegate for instance.

Regards,

Jehan

---

From: Dave Cridland <[email-masked]>
Date: Tue, 15 Feb 2011 20:44:04 +0000

On Wed Feb  9 05:47:49 2011, Richard L. Barnes wrote:
> Fortunately, for the purposes of using DNSSEC to secure  
> delegations, all of these redirection records look more or less the  
> same.  My guess is that we'll end up saying something like "Any  
> names you encounter in DNSSEC-protected delegations are OK".   
> Consider, for example, the following example:
> 
In no small part because the CNAME is illegal (can't have a CNAME if  
there is any other record) - but I know what you mean.

The thing is, I think that:

_xmpp-server._tcp.enterprise.example CNAME  
_xmpp-server._tcp.hosting.example

is fundamentally what we want to express; that is, "My XMPP service  
is hosted by hosting.example".

Then we can use existing XMPP (and other) SANs identifying the  
service we connect to as hosting.example - irrespective of whether  
hosting.example itself has deployed SRV on the subsequent lookup.

In a past life as an ISP sysadmin looking after mail, I recall that  
changing the hostnames of the mail service was basically a giant  
no-no, because it was in so many customer DNS zones; it would be much  
more useful to both hosting providers and enterprises alike if we  
could couple as loosely as possible.

Dave.