Hi Jan,
Thank you for the clarification. It sounds like a solid design so
far.
Thank you,
Clay
On Mon, 23 Feb 2009, Jan Damborsky wrote:
> 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
>>>
>
>
