Apple working to make Bonjour compatible with enterprise networks

Proposed mDNS extensions can make going wireless in offices and schools easier.

Apple engineer Stuart Cheshire has proposed extending the existing multicast DNS (mDNS) specifications to make Bonjour work better with enterprise networks. Cheshire, the man behind Apple's Bonjour and its underlying Zeroconf zero-configuration networking technologies, made his proposal during a meeting of the Internet Engineering Task Force in Atlanta, Georgia this week, according to Network World.

Cheshire's proposal responded to complaints from EDUCAUSE and numerous network administrators from colleges and universities all across the US. EDUCAUSE, a non-profit association for IT professionals that work in higher education environments, created a petition in August to pressure Apple to improve and expand its Bonjour technology so it can work better on enterprise networks like those used on college campuses.

Bonjour, along with underlying standards like DNS-Based Service Discovery (DNS-SD) and mDNS, enable AirPrinting from iPads to wireless printers, or streaming video from devices to Apple TVs. However, these technologies are designed to only work over a single local network subnet.

That limitation is no problem for most homes with a single wireless router, but it can be a headache for corporate or education networks which might have multiple wireless routers covering large areas like office spaces, classrooms, and lecture halls. For instance, an iPad connected to the wireless network might not be able to show a presentation via AirPlay to an Apple TV connected to a lecture hall's projector that is wired to a different router. Or, an executive in a conference room might not be able to print a document via AirPrint to the printer located a few doors down.

Furthermore, Bonjour can also create a lot of unnecessary traffic on large networks, flooding it with multicast data from dozens or hundreds of devices broadcasting services like network printing, file sharing, and AirPlay streaming.

"We targeted Bonjour at home networks, but over the last 10 years multicast DNS—what Apple calls Bonjour—has become very popular," Cheshire told Network World. "Every network printer uses Bonjour. TiVo, home video recorders, and cameras use it. iPads and iPhones use it, and we are starting to get a lot of demand from customers [who are concerned] that they won't be able to print from iPads to a printer in the next building."

Cheshire, along with Kerry Lynn of the IEEE, has submitted a draft proposal to create the DNS-SD/mDNS Extensions Working Group, which would extend those protocols and "enable service discovery beyond the local link." Doing so within the framework of the IETF allows all interested parties, including network admins and router vendors, to "cooperate and develop efficient and scalable solutions."

"The software that already exists in Apple Bonjour, and Linux Avahi, has some wide-area capabilities. We have some tools to build with, but we have not put it together right," Cheshire admitted. "The question is whether there is interest in the IETF to step in and do it better."

Representatives from Xirrus, Cisco, CheckPoint, and IBM support the measure.

"There's a recognition of the problem and a willingness to work on it," IBM's Thomas Narten told Network World. He expects the IETF will make significant progress on defining an improved standard before the IETF meets next in March 2013.

55 Reader Comments

"Furthermore, Bonjour can also create a lot of unnecessary traffic on large networks, flooding it with multicast data from dozens or hundreds of devices broadcasting services like network printing, file sharing, and AirPlay streaming."

Is there the slightest truth to this statement nowadays?

People were complaining about this 15 yrs ago, but both mDNS and networks have improved a lot since then. Certainly I see ZERO evidence of problems from "floods of unnecessary traffic" on my home network of maybe 12 devices.

""We targeted Bonjour at home networks, but over the last 10 years multicast DNS—what Apple calls Bonjour—has become very popular," Cheshire told Network World. "Every network printer uses Bonjour. TiVo, home video recorders, and cameras use it. iPads and iPhones use it, and we are starting to get a lot of demand from customers [who are concerned] that they won't be able to print from iPads to a printer in the next building.""And guess what? A lot of things don't. Specifically non Apple products. Make a push for more devices to support it and I will care about zeroconfig working across subnets. Until then it useless data on the wire taking up bandwidth.

I hope this takes off. I have been impressed with Bonjour for nearly a decade. However, a lot of people only know Bonjour as "that shit Apple installs with iTunes for no reason".

Ahh. So its perfectly OK for software to install a service that is always running on your computer that you do not use and have no easy way of shutting off?

I use bonjour a fair amount. But I can see why people want it gone (or at least an easy way to not install it). Hell in some respects I think Apple relies on it TO much.

Example: I use WiFi syncing on my iPhone. Works great at home. I also have a Synology NAS that doubles as my VPN. But guess what? WiFi syncing ONLY works over bonjour. This means if I bring up a VPN connection on my phone I can not sync with iTunes running on my computer at home. But if it just allowed me to enter an IP address it would work perfectly fine. And no, you can not bounce Bonjour over the VPN. I have tried it seven ways from Sunday. Even some articles say its flat out impossible to do mDNS on a VPN tunnel. Or at least the kind of tunnel most people use for VPN.

"Furthermore, Bonjour can also create a lot of unnecessary traffic on large networks, flooding it with multicast data from dozens or hundreds of devices broadcasting services like network printing, file sharing, and AirPlay streaming."

Is there the slightest truth to this statement nowadays?

The Apple haters were using this same argument back in the 90's. Except then, the technology was AppleTalk.

My company installed an industrial control device with an embedded ethernet controller at a remote customer site. The device would lose its IP connection every few hours to a day or two at the most, and had to be power cycled. The engineers were baffled, and being as this thing had an RJ-45 jack and a power cord, they of course asked IT (hi!) for advice. The embedded device ran a stripped down Linux OS. It didn't even have logging enabled so there wasn't much to go on.

So we setup packet capture.

Holy fuckety fuck fuck fuck there was soooo much broadcast and multicast traffic! Unbelievable. A thousand packets every millisecond if I remember correctly. The customer fessed upfront that their entire network only had one IP subnet and everything was a flat VLAN, and our device was supposed to be on that. But they swore they only had a couple of hundred hosts on that network, so my company didn't think it would be a problem.

It was a school.

The couple of hundred hosts were Macs.

The multicast traffic was from Bonjour. Broadcast traffic was also from Macs, but not sure what/why. We confirmed it by running the MAC addresses we got from the packet capture log. They were Apple's.

So our device got it's own IP subnet with a router in front. It never crashed again.

BTW the "crashing" was the network buffer overflowing and crashing the driver.

So, the only thing in this petition that is actually Bonjour-related is the fact that it doesn't work well across subnets? (Apparently the authors are unaware of the possibility of having mDNS requests forwarded between networks?)

Also, how are "we want it to work across subnets," "we don't want to allow multicast" and "it must be efficient" supposed to go together, exactly?

Holy fuckety fuck fuck fuck there was soooo much broadcast and multicast traffic! Unbelievable. A thousand packets every millisecond if I remember correctly. The customer fessed upfront that their entire network only had one IP subnet and everything was a flat VLAN

My company installed an industrial control device with an embedded ethernet controller at a remote customer site. The device would lose its IP connection every few hours to a day or two at the most, and had to be power cycled. The engineers were baffled, and being as this thing had an RJ-45 jack and a power cord, they of course asked IT (hi!) for advice. The embedded device ran a stripped down Linux OS. It didn't even have logging enabled so there wasn't much to go on.

So we setup packet capture.

Holy fuckety fuck fuck fuck there was soooo much broadcast and multicast traffic! Unbelievable. A thousand packets every millisecond if I remember correctly. The customer fessed upfront that their entire network only had one IP subnet and everything was a flat VLAN, and our device was supposed to be on that. But they swore they only had a couple of hundred hosts on that network, so my company didn't think it would be a problem.

It was a school.

The couple of hundred hosts were Macs.

The multicast traffic was from Bonjour. Broadcast traffic was also from Macs, but not sure what/why. We confirmed it by running the MAC addresses we got from the packet capture log. They were Apple's.

So our device got it's own IP subnet with a router in front. It never crashed again.

BTW the "crashing" was the network buffer overflowing and crashing the driver.

So, we can agree that a lot of broadcast traffic is not good. But, that should never cause your system to crash. Sounds like you need to fix that damned driver.

Also sounds like that organization was pretty fucked up in that it had Bonjour services enabled on all the Macs. Unless you turn one of the sharing services on explicitly, a Mac won't be broadcasting anything.

Also sounds like that organization was pretty fucked up in that it had Bonjour services enabled on all the Macs. Unless you turn one of the sharing services on explicitly, a Mac won't be broadcasting anything.

If nothing else, it will sporadically broadcast ARP requests (or NDP for v6), like any other host with an IP stack.

My company installed an industrial control device with an embedded ethernet controller at a remote customer site. The device would lose its IP connection every few hours to a day or two at the most, and had to be power cycled. The engineers were baffled, and being as this thing had an RJ-45 jack and a power cord, they of course asked IT (hi!) for advice. The embedded device ran a stripped down Linux OS. It didn't even have logging enabled so there wasn't much to go on.

So we setup packet capture.

Holy fuckety fuck fuck fuck there was soooo much broadcast and multicast traffic! Unbelievable. A thousand packets every millisecond if I remember correctly. The customer fessed upfront that their entire network only had one IP subnet and everything was a flat VLAN, and our device was supposed to be on that. But they swore they only had a couple of hundred hosts on that network, so my company didn't think it would be a problem.

It was a school.

The couple of hundred hosts were Macs.

The multicast traffic was from Bonjour. Broadcast traffic was also from Macs, but not sure what/why. We confirmed it by running the MAC addresses we got from the packet capture log. They were Apple's.

So our device got it's own IP subnet with a router in front. It never crashed again.

BTW the "crashing" was the network buffer overflowing and crashing the driver.

So, we can agree that a lot of broadcast traffic is not good. But, that should never cause your system to crash. Sounds like you need to fix that damned driver.

Quote:

industrial control device

I've got this feeling that "fix that damned driver" just isn't in the cards.

MDNS is great for zeroconf networks, where there are no DNS servers. That's the whole point of it. Once you move to a network that has infrastructure, that existing infrastructure is in a much better place to deal with name queries and registrations than MDNS.

The biggest issue that I can currently see is that MDNS tends to shift the trust perimeter from a DNS server to the whole local network. If you do name resolution using MDNS, you're trusting that every host on that local network won't respond maliciously. Being broadcast, it's got nearly as much security as NetBIOS. Yes, MDNS does support encrypted queries and responses, but as far as I know doesn't offer any key management, so you need to have a shared secret across all the devices.

Apple provide source code for the MDNS responder, but I've never managed to find a changelist of what's been fixed or changed. Sure, you can diff the code and spent your time figuring it out, but to me, it smacks of providing the minimum possible so they can claim it's "open".

They have their own. I forget what it is called right now. I was implementing printer discovery in an embedded Linux device and I was trying to decide whether to add Bonjour or Microsoft's protocol first. So, I took my new Canon printer with the MS protocol enabled and my wife's new Dell with Windows 7 to try it out. It didn't work. No default firewalls or anything like that, the printer didn't show up. Bonjour just works on lans. The other advantage of bonjour is that if you make a consumer device, it's easy to advertise your device on the network allowing for easy discovery from desktop software a la iTunes library sharing.

Unfortunately, we support iPhones for email and people load iTunes to manage the phone or whatever (especially in the past since there were no over the air updates). We got hit by the issue shown the KB quite a bit because our packaging lab didn't turn off the Bonjour service. So more than "that shit that apple installs with iTunes" it is that shit that breaks machines. Fortunately we have the service disabled now and everything works fine.

My company installed an industrial control device with an embedded ethernet controller at a remote customer site. The device would lose its IP connection every few hours to a day or two at the most, and had to be power cycled. The engineers were baffled, and being as this thing had an RJ-45 jack and a power cord, they of course asked IT (hi!) for advice. The embedded device ran a stripped down Linux OS. It didn't even have logging enabled so there wasn't much to go on.

So we setup packet capture.

Holy fuckety fuck fuck fuck there was soooo much broadcast and multicast traffic! Unbelievable. A thousand packets every millisecond if I remember correctly. The customer fessed upfront that their entire network only had one IP subnet and everything was a flat VLAN, and our device was supposed to be on that. But they swore they only had a couple of hundred hosts on that network, so my company didn't think it would be a problem.

It was a school.

The couple of hundred hosts were Macs.

The multicast traffic was from Bonjour. Broadcast traffic was also from Macs, but not sure what/why. We confirmed it by running the MAC addresses we got from the packet capture log. They were Apple's.

So our device got it's own IP subnet with a router in front. It never crashed again.

BTW the "crashing" was the network buffer overflowing and crashing the driver.

So, we can agree that a lot of broadcast traffic is not good. But, that should never cause your system to crash. Sounds like you need to fix that damned driver.

Quote:

industrial control device

I've got this feeling that "fix that damned driver" just isn't in the cards.

As a practical matter that may be true. But, I've worked in embedded devices--medical devices. If you choose to use Commercial Off-the-Shelf (COTS) software as part of your device YOU are still responsible for the whole ball of wax. In medical devices, for example, the FDA doesn't look kindly on "it's not our software". In fact, there are whole processes to ensure that these devices are safe and effective, requiring testing and monitoring of suppliers (including software). If they can't ensure that their device doesn't work that's THEIR problem.

Zeroconf (Apple calls their implementation 'Bonjour') is primarily two protocols: multicast-DNS (mDNS) and DNS Service Discovery (dns-sd). There's a third, a protocol for link local addressing, but it's already been integrated into pretty much all IP implementations and is a part of the IPv6 specification. It's where those 169.254 addresses come from.

dns-sd is actually independent of the particular DNS provider, so it can work with a DNS server that implements dynamic DNS update extensions, mDNS, or even just a standard DNS server (but of course the DNS admin has to manually add service records). dns-sd does actually use the dynamic DNS protocol in order to add service records and register for updates in DNS records (via long lived queries, LLQ).

mDNS is an implementation of DNS that does not require a server. It works in a peer-to-peer fashion with each host responding to DNS queries it has records for. mDNS is for unmanaged networks where there is no server is running. So mDNS and DDNS are really complimentary systems that don't serve the same use case; one makes zero configuration, serverless networking work and the other allows clients in a dynamic but managed environment update the DNS records that apply to them.

Nice to see that Stuart is still working at Apple, and also that I'm not the only one who remembers Bolo. Stuart always was skilled when it came to computer networking, the way that Bolo's multiplayer worked to keep it responsive with 8+ players was clever.

"Furthermore, Bonjour can also create a lot of unnecessary traffic on large networks, flooding it with multicast data from dozens or hundreds of devices broadcasting services like network printing, file sharing, and AirPlay streaming."

Is there the slightest truth to this statement nowadays?

People were complaining about this 15 yrs ago, but both mDNS and networks have improved a lot since then. Certainly I see ZERO evidence of problems from "floods of unnecessary traffic" on my home network of maybe 12 devices.

I'd like to see evidence of this claim before I give a damn about it.

The militant networking regime I worked with a few years announced that they considered Bonjour to be a threat that they were investigating. They were unable to find any issues associated with it -- and these folks find issues with anything.

"Furthermore, Bonjour can also create a lot of unnecessary traffic on large networks, flooding it with multicast data from dozens or hundreds of devices broadcasting services like network printing, file sharing, and AirPlay streaming."

Is there the slightest truth to this statement nowadays?

People were complaining about this 15 yrs ago, but both mDNS and networks have improved a lot since then. Certainly I see ZERO evidence of problems from "floods of unnecessary traffic" on my home network of maybe 12 devices.

I'd like to see evidence of this claim before I give a damn about it.

I am sorry, what evidence did you look for? And did you ever study computer theory of any sort at any point in your life? Do you even know how to look for unnecessary traffic? Even the guy that created admits it is not a good protocol. You think you know better than him?

As every decent network admin would know, Bonjour is a pain in the backside, taking up bandwidth by chunks and slowing down everything else.

Certainly I see ZERO evidence of problems from "floods of unnecessary traffic" on my home network of maybe 12 devices.

I'd like to see evidence of this claim before I give a damn about it.

Seesh, you are so cute: 12 devices, "no evidence on your HOME network", ROFL

We're talking 10 of THOUSANDS of devices entering and leaving (each time telling to every other node: "Hey, I'm here... and I'm off again..." multiple/different WLANs on a campus here, boy! Not THAT'S what we're talking here...

So, instead of adopting to the standard protocols rest of the world uses, Apple is arrogant enough to shove their muddy protocol as a standard on to rest of the world? I hope IETF has enough smart people left to realize this and say no to this nonsense