river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Lookup Service Discovery using DNS?
Date Thu, 28 Jan 2010 02:16:36 GMT
I've attached an excerpt from: http://www.dns-sd.org/ServerSetup.html

I thought it especially relevant to Jini Events and Leases:

Shared secrets is relevant to security (will have to utilise better than 
an 128 bit md5 keys though)

N.B. To complement Core Security Patterns, I've added a new book to my 
library: Beginning Cryptography with Java, published in 2005, it is 
relatively up to date.  It has some good reviews and includes examples 
utilising the Bouncy Castle API's.  Hopefully it'll turn up Saturday, it 
should assist me to build security by default into a Global Service 




Wide-Area Bonjour uses DNS Service Discovery [DNS-SD 
<http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt>] along with 
DNS Update [RFC 2136 <http://www.ietf.org/rfc/rfc2136.txt>] and TSIG 
security [RFC 2845 <http://www.ietf.org/rfc/rfc2845.txt>]. Mac OS X 
Tiger (and most Linux distributions) include the standard BIND DNS 
Server <http://www.isc.org/index.pl?/sw/bind/> (named), which supports 
DNS Update. It's also recommended that you run the dnsextd daemon (also 
included in Mac OS X Tiger). The dnsextd daemon implements two DNS 
extensions that enhance service discovery:

   1. DNS Long-Lived Queries [DNS-LLQ
      <http://files.dns-sd.org/draft-dns-llq.txt>] allow clients to be
      immediately notified when new services are added or removed from
      the server. Without Long-Lived Queries, clients would have to poll
      periodically (e.g., once an hour) to find out when services become
   2. DNS Update Leases [DNS-UL
      <http://files.dns-sd.org/draft-dns-update-leases.txt>] impose a
      time limit on record updates, so that service registrations are
      automatically deleted if the client crashes or goes away
      unexpectedly. Using standard DNS Update without Update Leases,
      records remain on the server forever, until deleted manually by
      the server operator.

You can use wide-area Bonjour without running dnsextd, and it will still 
work, but with the two limitations above.

The instructions below should be enough for someone experienced with DNS 
to set up a DNS server configured for Wide Area Bonjour, but if you've 
never set up a DNS server at all before and you find it a little 
confusing, DNS and BIND, Fourth Edition 

is a great guide that tells you everything you need to know about 
setting up and configuring /named/, the Berkeley Internet Name Daemon 

      Service Registration Zone for Wide-Area Bonjour

First, you need to pick a name for your wide-area Bonjour zone, the 
domain in which clients will browse and register. This should be a 
subdomain of your organization's domain. For example, if your 
organization's domain is "apple.com", your service registration zone 
could be "bonjour.apple.com".

      Shared Secrets

Without a shared secret, anyone who has access to your Bonjour name 
server can make registrations. This may be acceptable in some 
situations, like behind a firewall when you trust all the people who 
have access to your server. You may also want to run this way if you're 
just experimenting with the technology to get a feel for how it works, 
but normally when running an operational Wide-Area Bonjour service 
you'll want to set up your name server to accept updates only from 
authorized clients. The way a client proves it's authorized is by using 
a DNS TSIG record to sign its update packets using the proper shared 
secret for that domain [RFC 2845 <http://www.ietf.org/rfc/rfc2845.txt>].

You can use the dnssec-keygen command-line tool to generate a random 
shared secret. This command creates two files. We'll pull the shared 
secret from the .key file. After we copy and paste this key into our 
BIND configuration file, delete the files generated by the tool so that 
you don't accidentally leave them lying around for someone to find. 
Execute the command with the following arguments, substituting your own 
zone name:

dnssec-keygen -a HMAC-MD5 -b 128 -n ZONE <your zone>

The following shows how to generate a shared secret for the 
"bonjour.example.com" domain.

ice-cube:~ root# dnssec-keygen -a HMAC-MD5 -b 128 -n ZONE bonjour.example.com.
ice-cube:~ root# cat Kbonjour.example.com.+157+55295.key
bonjour.example.com. IN KEY 256 3 157 CnMMp/xdDomQZ4TelKIHeQ==
ice-cube:~ root# rm Kbonjour.example.com.+157+55295.*

For the domain "bonjour.example.com", our shared secret is 
"CnMMp/xdDomQZ4TelKIHeQ==". For more information about the dnssec-keygen 
command, please see the manual page.

View raw message