On Sun, 2005-07-24 at 14:19 +0200, Fredrik Tolf wrote: > On Sun, 2005-07-24 at 14:01 +0200, Jeroen Massar wrote: > > On Sun, 2005-07-24 at 13:45 +0200, Fredrik Tolf wrote: > > > On Sun, 2005-07-24 at 12:28 +0200, Jeroen Massar wrote: > > > > - it also has a _service. domain for autoconfiguration of > > > > other services using SRV records. > > > > > > That's very nice. However, reading through it makes it seem extremely > > > similar to the mechanism described by DNS-SD. Is there any particular > > > reason to duplicate that effort? > > > > It *adds* to DNS-SD, which is why this draft is so short ;) > > > > dns-sd defines stuff like: > > _http._tcp.<domainname> SRV ...... <host> > > I'm sorry if I'm misunderstanding you now, but that example seems like > only DNS SRV, not DNS-SD.
SRV records only describe the record, while DNS-SD also describes that there for most protocols there is a TXT field that gives some extra configuration/option arguments on how to use that protocol. > > This defines: > > _website._service PTR _http._tcp.<domain> > > PTR _https._tcp.<domain> > > Precisely; that seems very similar to the _services._dns-sd facility > suggested by the DNS-SD document: > <http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt> But that one is only _services._dns-sd with a lot of PTR's, while there can be many different services. One can already do exactly that by querying the _http._tcp itself and hoping to get back pointers to the subtypes. > It is also worth noticing that that document makes another interesting > point: It is very seldomly (never?) interesting to find out all the > service names for "a website". Browsers will typically know that they > can handle e.g. HTTP, HTTPS and FTP, and there query the _http._tcp, > _https._tcp and _ftp._tcp pointer entries as defined by dns-sd. See > section 10 of the linked document for more info. Probing a lot of SRV records and findout out afterwards that they actually don't exist and are not in use or are not supposed to be used for that type of service is a bad thing due to latency, tryal-and-error etc. When the SRV records point to dead instances, that is another problem, but this way one at least avoids them. eg from unfix.org: _http._tcp PTR Unfix._http._tcp _http._tcp PTR Heaven._http._tcp _http._tcp PTR Purgatory._http._tcp Unfix._http._tcp SRV 13 100 80 unfix.org. Heaven._http._tcp SRV 42 100 80 heaven Purgatory._http._tcp SRV 42 100 80 purgatory Sheol._http._tcp SRV 42 100 80 sheol _https._tcp PTR Purgatory._https._tcp Purgatory._https._tcp SRV 42 100 443 purgatory _website._service PTR unfix._http._tcp When a webbrowser gets 'unfix.org', it will only ever try http://unfix.org with my proposal, while with the above way, it would also go to https://purgatory.unfix.org, which is wrong as that is not the same instance of the web service. This is also really important for the IPv6 Tunnel Service discovery, as then what would you want to do, try to do proto-41/ayiya/heartbeat/tsp/tic/... to a box which is going to drop your packets anyway? Users don't like latency, thus making this information available is quite useful. Port probing is a bad thing(tm). Greets, Jeroen
signature.asc
Description: This is a digitally signed message part
