DNS Service Discovery allows machines running appropriate software to automatically configure themselves with information about local network services. This is done based on search domains applied using DHCP configuration. E.g. our network is configured to give machines the search domain of entropy.me.uk, machines running Service Discovery software (e.g. Apple’s Bonjour, or Avahi) will query special DNS records on entropy.me.uk for information about available services.

The DNS records in question are:

b._dns-sd._udp PTR @
lb._dns-sd._udp PTR @

(The @ symbol is substituted for the current domain, in this case entropy.me.uk.)

These are for “browse” and “legacy browse”, records can also be added to tell clients to set this domain as their default as well as to activate dynamic DNS updating for this zone. See http://www.dns-sd.org/ServerSetup.html for more.

These records tell querying machines that entropy.me.uk has available services. The querying machine will next check for records like this one:

_services._dns-sd._udp PTR _afpovertcp._tcp

There can be many of these, each with a different pointer, so you can have AFP shares, printers, web pages etc. etc. available on your domain as services. The “_services._dns-sd._udp” entries act as a kind of directory to allow machines to look up a directory of services.

These PTR records are just pointers, there is one more in the chain:

_afpovertcp._tcp PTR singularity._afpovertcp._tcp

Again, this is a directory, there could be multiple _afpovertcp._tcp entries to refer to multiple AFP shares available on the domain.

The last entry in the chain is:

singularity._afpovertcp._tcp SRV 0 0 548 singularity.entropy.me.uk.

This is a SRV record, letting the requesting client know where it can find a service hosted on this domain. In this case the endpoint is our file server, singularity. The SRV record indicates that port 548 should be used. A standard A or AAAA lookup gives the IPv4 or IPv6 address of the server to use for communication.

The upshot of all of this is that when a computer running Service Discovery connects to our network and gets the entropy.me.uk search domain it can automatically discover a directory of services offered on that domain. This includes a list of AFP servers, one of which, singularity, is offered via a SRV record.

Further power is afforded to DNS-SD through the use of dnsextd, this implements the idea of DNS leases which can be used by dynamic DNS clients to notify in near-realtime that they are available (and to notice when they aren’t anymore). This allows servers to advertise their availability to clients. This has dynamic DNS as a prerequisite, and there are security implications to that. I haven’t yet implemented this for our network.

There is one slight downside to advertising AFP shares this way, on Mac OSX in Finder (at least in 10.6) a list of available shares is shown under the “Shared” item in the left-pane. This shows local shares (found using multicast DNS, or “local” Bonjour) directly by name (e.g. it shows Photon, our Mac Mini). Servers discovered via a search domain and DNS-SD appear under a single “All…” item, which you have to click through to get to the lower levels. This isn’t the end of the world of course, but it doesn’t quite have the same simple “one-click” appeal that mDNS seems to.

Further work needed on this of course, to add all the other domain services to DNS.


So I’m not sure whether to be annoyed at Apple, Mikrotik, Atheros or Broadcom this time. Probably a little of each.

The WAP works, it’s quite a nice little box and once you get used to it RouterOS is very nice to use, easy to set up and generally peachy. However, my MBP apparently doesn’t like to talk to it using 802.11n. There are two slightly odd issues, the first being that IPv6 autoconf seems to get into an endless loop of sending router solicitations every 60 seconds or so. The interface seems to lose its IPv6 address during this process, causing loss of connectivity for a second or two.

The other issue is that every 5-20 minutes the interface will go into a non-responsive state. OSX continues to show the WLAN interface as connected but IP traffic ceases to function as desired.

This only happens on 802.11n, if the AP is set to use g-only mode then it works flawlessly. It only happens on this AP, the crappy Edimax ones work fine (though with their own IPv6 issue). It doesn’t happen with this AP and another Macbook (though that has an Atheros WLAN card, whereas mine is a Broadcom).

Currently I have it configured in g-only mode, which works but of course not at the blindingly fast speeds to which we have become accustomed.

Further work on it is needed.

In other news I’ve decided to return the Netgear switch. It’s not a terrible bit of kit, and if I really needed VLANs for some reason it’d not be a bad choice. However I really don’t. I’m going to implement the guest network using an IPsec tunnel back to the router and spend the money that the switch cost on getting some old Cisco kit for a networking lab.