OIT filters mDNS (Multicast Domain Name Service) traffic as it tries to pass through the core of the campus network. We began doing so in late November 2006. We do so because mDNS degrades campus network service yet is unnecessary for the network functionality OIT supports.
DNS (Domain Name Service) is a network protocol used to maintain a distributed database containing information about Internet hosts. Most commonly, DNS is used to translate between Internet hostnames (e.g. www.example.com) and IP addresses (e.g. 192.168.1.9). Other uses include translating between hostnames and mail exchangers, and to record services provided by a host so other hosts can discover those services.
DNS is a client/server based protocol. Organizations such as Princeton University that own Internet DNS name space (e.g. princeton.edu) or IP address space operate DNS servers containing the portion of the distributed database belonging to them. These organizations also arrange for redundant DNS servers to be operated (often by others organizations) around the Internet. DNS clients (most devices throughout the Internet) contact DNS servers when they need to look up information in this database. (E.g. to learn the IP address corresponding to the hostname www.example.com.)
OIT operates the DNS servers for Princeton University, and populates the DNS data from information stored in the Princeton University Host Database.
mDNS (Multicast Domain Name Service) is a related version of DNS, designed for use on small networks where there are no DNS servers. In mDNS, each device attached to the network (e.g. computers, printers, etc.) acts as a miniature DNS server. Each device multicasts packets to the network announcing information such as: My hostname is "Pat's Computer", my IP address is 169.254.8.7, I offer a shared printing service called "Pat's Printer", a shared file server, and I'm sharing the following seventeen music playlists..."
These packets are "multicast" to the network. Unlike unicast traffic (used by DNS), multicast packets are flooded to large segments of the network, so every device interested in the announcements can hear them.
Each device using mDNS also operates as an mDNS client. For example, when a computer wishes to use mDNS to locate all devices on the same IP subnet that offers a printing service, the computer multicasts an mDNS query to the network such as Who is offering a printing service? All the devices that hear the query and offer the requested service respond; e.g. I offer a printing service named "Pat's Printer" with the IP address 169.254.8.7. Depending on the way in which the query was sent, the responses are sometimes unicast only to the querier, but other times are multicast to the network.
mDNS's uses of multicast packets is designed to work within a single IP subnet. That is, mDNS traffic does not cross from one IP subnet to another. As a result, mDNS can be used among a set of devices that are all attached to a single IP subnet, but cannot be used among devices attached to different IP subnets. Princeton University's campus network is composed of dozens of IP subnets, so as designed, mDNS only allows a device to exchange mDNS information with devices that happen to be attached to the same IP subnet. This limitation is not a bug. This is part of the design of mDNS; it's intended for use on relatively small networks, rather than across large networks composed of multiple IP subnets.
In addition to being designed for use within a single IP subnet, mDNS was designed for use on relatively small networks, consisting of a few dozen (or perhaps a few hundred) devices. It is intended for use in an environment where there is no traditional DNS service provided. Examples of places for which mDNS is designed include homes, small private offices, and ad hoc collections of devices connected to each other but not to the Internet. In such locations, there may be no DNS servers installed; no staff, expertise, and hardware available to set up DNS servers; and no need for the security provided by central control of the data in DNS. In such environments, mDNS works to provide a "plug and play" environment; individuals can simply connect a set of computers, printers, and other devices together, then use mDNS to look up (or browse) the devices available on their local network.
mDNS was not designed for use on larger networks. Besides the fact that it does not span multiple IP subnets, mDNS is a much "chattier" protocol than DNS. As each device multicasts to the network announcements of the services it is providing, and each device multicasts queries for services, mDNS generates a significant volume of multicast traffic. (In normal DNS, traffic is unicast.)
Multicast (and broadcast) traffic is a vital part of the network; its existance is not inherently bad. However, when there are high rates of multicast traffic which most clients wish to receive (or high rates of broadcast traffic), this presents a problem. The network is forced to flood multicast traffic to all clients that wish to receive it (broadcast traffic is also flooded to all clients). And each client that receives the traffic is forced to examine these packets to decide what to do with each packet. Even when the actual bit rate for multicast (and broadcast) traffic may miniscule relative to the University's network capacity, our experience is that when the packet rate of such traffic gets too large, individual network-attached devices must consume excessive resources handling these packets. Workstations may be become unresponsive; network infrastructure may stop responding to management requests. Any networks with constrained bandwidth (e.g. wireless) may perform poorly. Eventually workstations become unusable and the network becomes unmanageable. As a result, we must take care that multicast (and broadcast) traffic on the network does not grow unecessarily large.
As the number of devices on a single IP subnet grows, and as those devices make increasing use of mDNS, the volume of multicast traffic on the network grows to a point that adversely affects network service for all devices on that network. This problem doesn't arise in the environment for which mDNS was designed (a small network), since that environment doesn't have many devices; it is a problem if many devices attached to single network try to use mDNS.
This in fact is the situation we find at Princeton University. Popular operating systems (e.g. Mac OS X and recent versions of Windows) along with some printers include mDNS capabilites in addition to normal DNS. They often have mDNS turned on by default, to make these devices easy to "plug and play" in the small network environments where mDNS was designed to function. When these devices are attached to the campus network, although they rely on DNS for nearly all services, they still have mDNS enabled, and some of the software on those devices uses mDNS. This results in excessive mDNS traffic on significant portions of the campus network.
mDNS is not a protocol OIT has ever recommended for use on campus, or has ever supported. While there are many OIT-supported uses of the campus network, none of them rely on mDNS.
mDNS is used by some applications to provide some functionality that OIT doesn't explicitly support. For example:
For several years years, mDNS was just one of many kinds of traffic that OIT didn't explicitly support; we didn't need to restrict because it wasn't causing any harm. As the volume of mDNS traffic on the campus network has grown, that's changed. By Fall 2006, the volume of mDNS traffic on some parts of the campus network had grown to the point where it was adversely affecting network performance in many locations. If the use of mDNS is left unchecked, we expect that network service in many locations will degrade further, eventually to the point of unusability.
OIT began filtering mDNS traffic in late November 2006. We filter mDNS traffic because it degrades network service while at the same time is unnecessary for any of the network functionality OIT supports.
OIT filters mDNS traffic at the core of the campus network. Specifically, any IP traffic destined to IP address 224.0.0.251 UDP port 5353 is discarded as it tries to cross the core of the network. Due to network topology, this usually means that the mDNS traffic is blocked as it tries to enter or leave a campus building (because to do so it must cross the network core), but the traffic is not blocked within the building. We say usually because there may be some buildings that share a single connection to the campus core, and conversely some buildings that have more than one connection to the core; the extant to which mDNS traffic can flow before it is blocked will vary depending on the topology. Also keep in mind that evenwithin a single building, OIT Ethernet Service and OIT Wireless Service are on different IP subnets, so mDNS has never worked between the two.
Our measurements in Fall 2006 indicate that this filter reduced multicast/broadcast traffic by 52-63% (measured by packet rates) on the largest campus networks.
The result of this filter is that if you use software that looks for services using mDNS, you will not see services advertised by mDNS on computers that are on the "other" side of the campus network core. You may continue to see services advertised by mDNS on computers that happen to be reachable by your computer without crossing the network core.
In particular:
We recommend that you specify these printers or file servers by entering their Internet hostnames (or IP addresses). This should present little inconvenience, as you normally need to "set up" a printer just once, and can create a shortcut to any file server you connect to regularly, obviating any need to manually enter an Internet hostname (or IP address) repeatedly.
We feel this is an acceptable trade-off to keep the network usable, given that iTunes content sharing is not something OIT supports. iTunes sharing continues to work among computers that happen to be connected to the same IP subnet on the same leg of the campus network.
We wish to emphasize that this does not indicate that OIT disapproves of iTunes, or with its personal sharing feature (although we don't provide support for the latter). The iTunes personal sharing feature simply happens to rely on a protocol (mDNS) that isn't designed for use on a large network.
Bonjour is Apple's name for the IETF ZEROCONF suite of communication protocols, which includes mDNS.
Customer can still use iChat to chat with peers with on those remote computers using the other protocols iChat supports, such as AOL Instant Messenger (AIM), Apple .Mac, and Jabber.
Our filtering of mDNS does not indicate that OIT disapproves of mDNS, or that there is anything inherently wrong with mDNS. We don't require customers to turn off mDNS on their devices, or forbid the use of mDNS. But we don't provide support for mDNS or any functionality that relies upon mDNS, and we filter it to limit its ability to degrade network performance.