Bering-uClibc 5.x - User Guide - Advanced Topics - Setting Up Zeroconf Networking

From bering-uClibc
Jump to: navigation, search
Advanced Topics - Setting Up Zeroconf Networking
Prev Bering-uClibc 5.x - User Guide Next


Zero Configuration Networking (or Zeroconf) refers to a set of standards for automatically configuring IP networks and for advertising services available to a particular network domain. Further information is available from the main Zeroconf web site.

Note that the Zeroconf standards are broadly similar to, but different from, the Universal Plug and Play (UPnP) standards which are managed by the UPnP Forum. For information about configuring Bering-uClibc 5.x for UPnP refer to the next section of this user guide.

Zeroconf can be confusing because a lot of different names are used to refer to the same or related things:

  • Bonjour, previously known as Rendezvous, is Apple's implementation of Zeroconf.
  • Avahi is an alternative implementation of Zeroconf for Linux and BSD.
  • mDNS or Multicast DNS is technology used for Zeroconf where regular (Unicast) DNS services are not available.
  • DNS-SD or DNS Service Discovery is technology used for Zeroconf where Unicast DNS services are available.
  • IPv4LL or IPv4 Link-Local Addressing (those addresses you sometimes see when DHCP is not working properly) can be used to support mDNS.
  • NAT-PMP or NAT Port Mapping Protocol can help to reduce the impact of a NAT router between a host and the Internet.

Implementing DNS-SD using Dnsmasq

DNS-SD (DNS Service Discovery) is a way of using a standard DNS server to advertise services which are available on a particular LAN or DNS domain. Dnsmasq, the DNS server used for Bering-uClibc 5.x can be configured to advertise such services. While the necessary configuration changes are relatively minor (just a few lines in /etc/dnsmasq.conf the syntax is somewhat cryptic. Most of the examples elsewhere on the Internet are for alternative DNS servers (mainly BIND) rather than Dnsmasq.

Configuring Static DNS-SD

The simplest case of DNS-SD is configuring Dnsmasq to advertise the details for services available on the local LAN. A DNS-SD client sends a number of standard DNS queries to the DNS server specified in its DHCP lease, so by configuring that DNS server (Dnsmasq) we can arrange for a list of services to be advertised.

In this example we advertise the Webconf HTTP service running on the Bering-uClibc 5.x machine itself but it must be emphasized that a service running anywhere on the local network can be advertised instead (or as well).

Service Definition

The first step is to define the service which will be advertised. The service definition is not actually specific to DNS-SD but a DNS SRV record as defined in RFC 2782 is required as the "target" of the DNS-SD configuration.

In summary, the service definition consists of a SRV record which specifies:

  • The service Name, e.g. "Bering-uClibc Webconf"
  • The service Type, e.g. HTTP (actually specified as "_http")
  • The service Protocol, e.g. TCP (actually specified as "_tcp")
  • The service Host, e.g. ""
  • The service Port on that Host, e.g. "80"
  • The service Priority (optional)
  • The service Weight (optional)

In addition to the SRV record there is a TXT record with additional information. In this example it is just the path component of the HTTP URL. The content of the TXT record varies considerably for different service Types.

The /etc/dnsmasq.conf syntax for this is:


If multiple host machines offer the same service there can be repeated srv-host lines, with the same service Name but different service Host values. Refer to the comments in /etc/dnsmasq.conf for details of the Priority and Weight syntax if you need to specify these.

Now for the actual DNS-SD configuration...

Domain Enumeration

A DNS-SD client asks for a list of domains to Browse for service advertisements by sending a PTR query for In principle we could specify a completely different domain to browse (such as but it is customary to specify the "same" domain, The /etc/dnsmasq.conf syntax for this is:,

Additional similar lines could be added if required.

Default Browse Domain

In the case that multiple Browse domains are specified the DNS-SD client needs to know which one to pick as the default. This is achieved by specifying a Default Browse domain. The /etc/dnsmasq.conf syntax for this is:,

This is optional if only a single Browse domain is specified.

Legacy Browse Domain

For maximum compatibility, also specify a single domain that Legacy DNS-SD clients should Browse for services. The /etc/dnsmasq.conf syntax for this is:,

Service Pointers

The main "glue" in the DNS-SD configuration is another PTR record which enumerates the Services by service Type. The /etc/dnsmasq.conf syntax for this is:,Bering-uClibc

Additional similar lines can be added if required.

Service Types List

While not required for normal DNS-SD operation, a DNS-SD client sometimes wants to query for a list of all the service Types available on the domain. It does this by sending a PTR query for The /etc/dnsmasq.conf syntax for this is:,_http._tcp.

Note that this correctly omits the suffix, as per the standard. Additional similar lines can be added if further service types are available.

Configuring Dynamic DNS-SD


  • Register domain list: PTR
  • Default Register domain: PTR

Implementing mDNS using Avahi

Some applications / devices only support mDNS, to query the .local DNS domain, and do not support full DNS-SD. For these an mDNS implementation like Avahi can be useful.

Installing the Packages

The main Package required is avahid.lrp which installs the avahi-daemon executable. Add avahid.lrp to the LRP= line in leaf.cfg. This in turn depends on libavahi.lrp, libdaemon.lrp and libexpat.lrp. Those will be loaded automatically.

Configuring Shorewall

mDNS operates using UDP port 5353 as the destination for mDNS queries. In principle this can be on top of IPv4, IPv6 or both, though IPv4 is obviously more common at the moment. Both Shorewall and Shorewall6 have mDNS macros defined, which should be used.

Entries should therefore be added to the Shorewall{6}.rules file similar to the following:

mDNS(ACCEPT)        loc        fw

Implementing NAT-PMP

Network Address Translation - Port Mapping Protocol, described here, is the component of Zeroconf which allows client machines to dynamically create NAT iptables entries so that traffic arriving from the External network (e.g. the Internet) is automatically forwarded to a client on the Internal network. This can be useful for applications like BitTorrent clients which need to accept traffic from the External network.

Warning: While NAT-PMP can be useful, it also permits a rogue client or application on the internal network to compromise the security of the whole network. It should only be used when the implications of the possible security vulnerabilities are understood.

NAT-PMP Software Candidates

There are two main candidate software packages for implementing NAT-PMP functionality on Linux:

  • Stallone, a small, secure, standalone NAT-PMP demon
  • MiniUPnPd which implements NAT-PMP as well as uPnP


Testing and Diagnosis Tools

Some systems have a utility called dns-sd which can be useful for testing Zeroconf implementations. This is installed as standard on Mac OS X and for other platforms the source code can be downloaded from here.

Further Reading

  • Zero Configuration Networking: The Definitive Guide, by Stuart Cheshire and Daniel H. Steinberg. Copyright 2006 O'Reilly Media, Inc. ISBN 0-596-10100-7.

Prev Up Next