OIT filters mDNS (Multicast Domain Name Service) traffic as it tries to pass through the core of the legacy campus network for all legacy Ethernet networks. 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 Network Registration.
mDNS (Multicast Domain Name Service) is a related version of DNS, designed for use on small networks, especially in situations where there is no managed DNS server. 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 normally "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 hundreds 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 well-suited for use on relatively small networks, rather than across large enterprise 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 is part of the IETF ZEROCONF protocol suite, a set of networking standards. ZEROCONF's goal is is to permit devices to be networked without the need to configure each device's network settings, to operate central network information/configuration servers, or to administer network configuration information. It is best-suited for home and small office environments, or to permit impromptu networking among several nearby devices in the absence of a managed network. Popular implementations of the ZEROCONF protocol suite include Bonjour from Apple, and Avahi on a variety of UNIX systems.
mDNS is not well-suited for use on large enterprise 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 include mDNS capabilites in addition to normal DNS. They usually 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. It had grown to the point where it was causing noticable problems for those customer devices which listened to mDNS traffic. 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. Our measurements in Fall 2006 indicated that this filter reduced multicast/broadcast packet rates traffic by 52-63% on the largest campus networks.
We filter mDNS traffic because it degraded network service while at the same time was unnecessary for any of the network functionality OIT supports.
The filter is applied at the cores of the legacy campus network; it affects any traffic as it tries to cross the core of the legacy networks. 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 legacy network core), but the traffic is not blocked within the legacy networks within the building. We say usually because there may be some buildings that share a single legacy connection to the legacu campus core, and conversely some buildings that have more than one connection to the legacy core; the extant to which mDNS traffic can flow before it is blocked will vary depending on the topology. Also keep in mind that even within a single building, legacy OIT Ethernet Service and OIT Wireless Service are on different IP subnets, so mDNS has never worked between the two.
Our filter discards any UDP traffic destined to IPv4 multicast address 224.0.0.251.
On our wireless networks we have much broader filters, described in OIT Filters Most IPv4 Broadcast and Multicast Traffic on Wireless Networks . On the wireless networks, that filter blocks nearly all broadcast and multicast traffic; mDNS is only one kind of traffic included that filter. This is intentional; without that filter, the volume of mDNS traffic alone would (and has in the past) made the wireless network unusable. That filter applies not only at the network core, but also at all wireless access points. As a result, even traffic among wireless clients on the same network leg (and even on the same wireless access point) are subject to that filter.
The result of these filters is that if you use software that looks for services using mDNS, you will not see services advertised by mDNS. The only exception is that when you are attached via OIT Ethernet Service, you will see those services that happen to be offered by devices attached via OIT Ethernet Service presently on "your" side of the nearest filter.
In particular:
We recommend that you attach printer, file servers, and other kinds of servers to OIT Ethernet Service, and assign each a wired static IP address.
Clients specify these printers, file servers, or other servers by entering the servers' Internet hostnames (or IP addresses). This should present little inconvenience, as a client 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 recognize that some client operating systems unfortunately include a printing client which provides no ability for the client to enter a printer's Internet hostname (or IP address). (An example is Apple iOS' AirPrint.) Such clients, which can only "browse" to find nearby printers, will not be able to find those printers.
OIT recognizes that this means that customers will not be able to use the "AirPrint" feature in Apple iOS to print from iOS device to an AirPrint-compatible printer, even when both devices are attached via a wireless service provided by OIT.
We do not disapprove of "AirPrint." The feature simply happens to rely on a protocol (mDNS) that is not well-suited for use on a large enterprise network.
We feel this is an acceptable trade-off to keep the network usable.
We wish to emphasize that this does not indicate that OIT disapproves of Apple Music, or with its personal sharing feature (although we don't provide support for the latter). The Apple Music personal sharing feature simply happens to rely on a protocol (mDNS) that is not well-suited for use on a large enterprise network.
We do not disapprove of "AirPlay." The feature simply happens to rely on a protocol (mDNS) that is not well-suited for use on a large enterprise network.
Our filtering of mDNS does not indicate that OIT disapproves of mDNS, or that there is anything inherently wrong with mDNS. mDNS is an effective technology for use on small and medium-size networks; it just isn't well-suited for use on a large enterprise network. We don't tell customers to disable 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.