3 ms·

DNS is basically for resolving the hostnames. You may recall that it originally evolved from a file containing all the hostnames on the Internet that people dow

by rumcajz 14y ago

DNS is basically for resolving the hostnames. You may recall that it originally evolved from a file containing all the hostnames on the Internet that people downloaded periodically. Resolution of service names is a different matter. The authors of the Internet have solved it in a cheap-and-ugly way by introducing well-known ports. Unfortunately, the problem wasn't solved in a systematic manner since.

petersabaini 14y ago
DNS has grown the SRV RR to address services. https://tools.ietf.org/html/rfc2782 https://tools.ietf.org/html/rfc2782
- rumcajz 14y ago
  Yup. The fact, however, is that it is not used widely. My guess here is that we are facing a problem where requirements differ depending on the scale. We may want local services to register with DNS automatically as they start and be reachable within seconds (DNS-SD use case). With the services facing the outside world, standard pre-defined records with 72hr propagation time are preferable (RFC2782 use case). Moreover, I would say there's a need for location-dependent resolving of service names to limit the availablity of local services, to return a topologically close instance of the service etc. All in all, the problem is far from being solved yet.
  - rumcajz 14y ago
    To put in simply: At the moment nobody is going to create a DNS record just to create a TCP connection. Once the following works out of the box on LAN, the problem can be considered solved: s = socket (AF_INET, SOCK_STREAM, 0); bind (s, "myApplication1"); ... s = socket (AF_INET, SOCK_STREAM, 0); connect (s, "myApplication1"); Propagation of the name outside of the LAN may require additional administrative work. I guess nobody will complain about that.
    - petersabaini 14y ago
      Semi-widely used I'd say. XMPP and SIP come to mind... What I like about DNS SRV is that it's standardized and relatively simple to handle, in contrast to some of the other naming schemes out there (eg. CORBA). I agree though that tools / libraries need to get better here.

by rumcajz 14y ago

petersabaini 14y ago

DNS has grown the SRV RR to address services. https://tools.ietf.org/html/rfc2782 https://tools.ietf.org/html/rfc2782

rumcajz 14y ago
Yup. The fact, however, is that it is not used widely. My guess here is that we are facing a problem where requirements differ depending on the scale. We may want local services to register with DNS automatically as they start and be reachable within seconds (DNS-SD use case). With the services facing the outside world, standard pre-defined records with 72hr propagation time are preferable (RFC2782 use case). Moreover, I would say there's a need for location-dependent resolving of service names to limit the availablity of local services, to return a topologically close instance of the service etc. All in all, the problem is far from being solved yet.
- rumcajz 14y ago
  To put in simply: At the moment nobody is going to create a DNS record just to create a TCP connection. Once the following works out of the box on LAN, the problem can be considered solved: s = socket (AF_INET, SOCK_STREAM, 0); bind (s, "myApplication1"); ... s = socket (AF_INET, SOCK_STREAM, 0); connect (s, "myApplication1"); Propagation of the name outside of the LAN may require additional administrative work. I guess nobody will complain about that.
  - petersabaini 14y ago
    Semi-widely used I'd say. XMPP and SIP come to mind... What I like about DNS SRV is that it's standardized and relatively simple to handle, in contrast to some of the other naming schemes out there (eg. CORBA). I agree though that tools / libraries need to get better here.