Subject: Re: RFC 2782: SRV naming convention

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 09 Jul 2001 08:42:57 -0700

Christian Huitema wrote:
> 
> > How about "_smtp._http.example.com"? (Mail tunnelled over http)

> Another extension that has been suggested is to take account some form
> of locality, as in "I am in subnet number X, in domain example.com, and
> I want to find an LDAP server; which is the most appropriate one?"

Couple of ways to do this that I can see. The most obvious is to use
subdomains within the org, so that users in the ny.corp.example.com zone
always get the right SRV RR.

A more-dynamic but also more-difficult method would be to tie SRV RRs to
IN-ADDR.ARPA zones, such that _smtp._tcp.0.1.192.168.in-addr.arpa. has
different data than the _smtp._tcp.0.2.192.168.in-addr.arpa. zone. This
would require that [a] clients know their subnet mask, [b] that the
resolver is able to find the container in-addr.arpa. zone for their subnet
(using classless delegation lookups, and then sticking the SRV query
labels onto that), and [c] that the applications were configured to
perform adddress-based lookups. But it is doable in a highly-managed
environment.

> -- Christian Huitema=20

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 09 Jul 2001 12:46:40 -0700

Christian Huitema wrote:

> Something like that might limitations of the SRV format perceived by
> several WG -- notably SIP and IMPP. The problem occurs when a service
> can run on several protocols. For example, SIP can run over UDP, TCP
> and possibly SCTP or TLS; IMPP services can be provided through SIMPLE,
> APEX, PRIM and possibly others. How can we discover not just a server
> name and a port, but also a transport protocol and possibly an
> application protocol?

PTR records?

     Q:    _sip.example.com.

     A:    PTR     _sip._tcp.example.com.
     A:    PTR     _sip._udp.example.com.

> If a given client only supports some of the options, how do we
> restrict the discovery to the server that support common options?

Given that this is application-specific functionality, it would seem to be
outside the scope of the DNS locator service. You'd have to use SrvLoc I
would think. But, one possible solution would be to have the client walk
through the weighted list of responses until it finds one that it is
willing to work with. Or you could combine the above technique with other
techniques (like in-addr.arpa. matching) to hone in on the right server
for the specific client.