On 6/26/15 6:46 AM, Matthew Wild wrote:
On 26 June 2015 at 13:38, Peter Saint-Andre - &yet <[email protected]> wrote:
On 6/26/15 5:26 AM, Matthew Wild wrote:
On 26 June 2015 at 00:51, Peter Saint-Andre - &yet <[email protected]>
wrote:
Thus we need a way for a client to discover where it can authenticate as
an
ad-hoc or guest user. We don't want to use a DNS SRV Service name of
"xmpp-client" because that will point clients to the service endpoint for
registered users. What we came up with was to use a new DNS SRV Service
name
of "xmpp-guest", which would point to the service endpoint for guest
access.
Has anyone else deployed this kind of pattern? If so, how did you solve
the
problem of service endpoint discovery? Would you find it helpful to have
a
DNS SRV Service name for this kind of access?
Would a TXT record not be more appropriate?
Not according to IETF folks. There's a real animus against TXT records for
SRV-ish things (and this seems like one of them).
Containing the XMPP host
of a suitable place to authenticate anonymously? A SRV will tell you
where to connect to, but not which XMPP host to use.
Sure, you need to do the SRV two-step.
I'm not sure I understand completely, then. Are you proposing that the
target of the SRV record is the XMPP host (and thus ignore the port?)?
I'm not sure I understand completely either. :-)
We'll probably do something like this:
_xmpp-client._tcp.talky.io. 400 IN SRV 20 0 5222 auth.talky.io
_xmpp-guest._tcp.talky.io. 400 IN SRV 20 0 5222 anon.talky.io
Naturally the ports might not be 5222 and such, but the general idea is
that we want to point guest users at a different auth service. By "SRV
two-step" I mean that the client would still need to resolve
auth.talky.io or anon.talky.io in the normal ways (we're not necessarily
going to point directly to what in draft-ietf-dane-srv we called the
"connection endpoint").
Peter
--
Peter Saint-Andre
https://andyet.com/
