Hi Clay, Clay Baenziger wrote: > Hi Jan, > I'm fuzzy on the proposal but wanted to see if I understand > correctly. You're planning that the admin will add the PTR and SVR > records to the organization's domain right? Not to a fictitious domain > like ai-caiman.org?
The plan is that there will be no restrictions as far as domain is concerned - different organization domains as well as other one can be used. For example, for machines in boulder.Central.Sun.COM you could use either default one as you mention below or pick up different one (like czech.sun.com). > For example, I would expect to add it to boulder.Central.Sun.COM > since I'm in BRM. (I would do this by running my own caching DNS > server which would just serve my modifications and pass queries to an > authoritative server otherwise - since I don't have change access to > my IT department's servers.) I would also expect that > dig/nslookup/dns-sd would try this domain first, as I give it in my > DHCP responses (using the DNSdmain macro value). I think this would be the default behavior - but you will be allowed to specify non-default domain if you would like to. > Let me know if I'm confused. I am still coming up to speed on this stuff, so please feel free to let me know, if it seems we are making things too complicated :-) The general intent here is not to introduce constraints, if it is not necessary. Thank you, Jan > Thank you, > Clay > > On Thu, 19 Feb 2009, jan damborsky wrote: > >> Hi Rishi, >> >> couple of month ago, we were discussing if we might take advantage of >> service discovery in Automated Installer (AI) project [1]. >> Maybe you remember :-) >> >> We have implemented the first phase which uses service discovery over >> multicast DNS and now we are in process of enhancing the prototype with >> support for service discovery over unicast DNS. >> >> At the time being, we use dns-sd(1M) utility for multicast DNS: >> * On AI server side, it is used for registering/advertising the service >> * On AI client side, it is used for looking up the service >> >> It is sufficient for proof of concept, but since dns-sd(1M) is only >> recommended to be used as testing/debugging tool, as a long term >> solution, >> we would like to create dedicated daemon directly consuming >> libdns_sd(3LIB) >> library taking care of all service discovery tasks. >> >> Meanwhile, we are thinking about how we might implement support for >> unicast >> DNS for now. As far as server side is concerned, we will ask user to >> manually >> add appropriate PTR and SRV records to the DNS server database. Later >> we might be thinking about dynamic DNS update. >> >> With respect to client side, we are thinking if we can continue to use >> dns-sd(1M) for looking up the service over unicast DNS. >> >> I have gone through your presentation about Service Discovery and >> multicast DNS [2] and in examples, dns-sd(1M) is only used >> for testing multicast DNS, dig(1M) and nslookup(1M) are utilized >> for testing unicast DNS part. >> >> Since dns-sd(1M) takes domain to browse as parameter, I was wondering >> if we could do something like following to look up '_test_service' >> instance of '_OSInstall._tcp' service in 'ai-caiman.org' domain. >> >> $ dns-sd -L _test_service _OSInstall._tcp ai-caiman.org >> >> I have tried, but snoop(1M) didn't report any traffic on net >> which might be related to this. >> >> I was able to successfully query appropriate PTR and SRV records >> using dig(1M) or nslookup(1M) commands. I have added following >> records to DNS database for created 'ai-caiman.org' domain: >> >> ... >> _OSInstall._tcp PTR _test_service._OSInstall._tcp >> >> _test_service._OSInstall._tcp SRV 0 0 46511 tio-nb.ai-caiman.org. >> TXT >> aiwebserver=tio-nb.ai-caiman.org:46511 >> ... >> >> dig(1M) reports: >> >> $ dig @192.168.100.2 -t ptr _OSInstall._tcp.ai-caiman.org >> ;; ANSWER SECTION: >> _OSInstall._tcp.ai-caiman.org. 86400 IN PTR >> _test_service._OSInstall._tcp.ai-caiman.org. >> >> >> $ dig @192.168.100.2 -t any _test_service._OSInstall._tcp.ai-caiman.org >> ... >> ;; ANSWER SECTION: >> _test_service._OSInstall._tcp.ai-caiman.org. 86400 IN SRV 0 0 46511 >> tio-nb.ai-caiman.org. >> _test_service._OSInstall._tcp.ai-caiman.org. 86400 IN TXT >> "aiwebserver=tio-nb.ai-caiman.org:46511" >> ... >> >> >> I have couple of questions here in order to clarify what approach >> we might take. Could I please ask you if you might help us understand >> what the limitations are and what approach we might take ? >> >> * Can we use dns-sd(1M) for browsing domains/looking up services which >> are available over unicast DNS ? If we can, what are the prerequisites >> we need to meet in order to make it work ? >> >> * If dns-sd(1M) can't be used, could we take advantage of dig(1M) or >> nslookup(1M) commands instead ? >> >> * As far as long term solution is concerned, does libdns_sd(3LIB) >> support >> unicast DNS ? What kind of operations are supported (look up, >> register, ...) ? >> >> >> Thank you very much for your help, >> Jan >> >> >> [1] http://www.opensolaris.org/os/project/caiman/auto_install/ >> [2] http://atlantic.east/~rs200217/bonjour/mdns-sd.pdf (available >> only internally) >> >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>
