Omdat hierboven nogal veel reacties staan die kant nog wal raken, even een korte uitleg.
Bonjour is Apple's implementatie van Zero configuration networking (ZeroConf) en heette oorspronkelijk Rendezvous (totdat het in 2005 ivm legal dispute over de naam moest worden veranderd). ZeroConf is een set tools/protocollen die het mogelijk maken om zonder configuratie andere devices (computers, printers, servers) op je netwerk te zien, én om services op die devices te kunnen zien (Apple Talk, SMB, web server, ssh, iTunes/DAAP, etcetera) en dus snel te kunnen openen. Het bestaat met name uit DNS-Based Service Discovery (DNS-SD) en Multicast DNS (mDNS) en biedt het in feite de toegevoegde mogelijkheid om zónder configuratie een IP netwerk te gebruiken, héél gebruiksvriendelijk maar de horror van elke
BOFH
Met name Apple gebruikt ZeroConf, en dat is natuurlijk niet gek omdat Usability en gebruiksvriendelijkheid hoog in 't vaandel staan bij Apple. Als je wel eens een Mac hebt gebruikt, dan zie je computers en printers in de Finder verschijnen of verdwijnen zodra ze respectievelijk aan of uit worden gezet. Zo hoef je in feite als gebruiker niets te doen want alle andere devices op het netwerk zijn gewoon beschikbaar (mits ze ook Bonjour / ZeroConf gebruiken). Maar, zoals de auteur ook beschrijft, dit werkt alleen in één netwerk en niet over subnetten. Dat kan nogal een gemis zijn, óók in de wat geavanceerdere thuis situaties (denk aan WiFi op een ander subnet, vpn connecties, etcetera).
Er is ook een implementatie voor Linux:
Avahi, wat je in staat stelt om services op je Linux server te broadcasten en dus te laten discoveren door Bonjour / ZeroConf gebruikers. Zo kan je bijvoorbeeld
mt-daapd / Firefly Media Server (DAAP is het iTunes protocol) in combinatie met Avahi gebruiken op je Linux server met veel storage om een media bibliotheek op te zetten die via het netwerk gevonden kan worden, én in iTunes zichtbaar is als gedeelde muziek bibliotheek (en dus te streamen). mt-daapd implementeerde vroeger zelf mDNS en ik weet niet of Firefly dat ook nog steeds doet (al jaren niet meer gebruikt), maar je kan het in ieder geval uit zetten en Avahi de Bonjour taken laten waarnemen.
En voor werk situaties kan het handig zijn om test, development en continuous integration -servers te broadcasten, als ze tenminste niet (zoals de meeste grotere bedrijven) ergens in een ander subnet / colo staan
In ieder geval zou een nieuwe standaard die over subnetten werkt (vanuit gebruikers oogpunt) een welkome uitbreiding zijn zodat je ook servers, computers, printers etcetera kan discoveren die zich op andere subnetten of zelfs over vpn bevinden

Al kan ik me voorstellen dat hoe groter het netwerk is, hoe meer netwerk vervuiling op kan gaan treden als alle Bonjour devices blijven broadcasten. Wellicht dat bij de revisie van de standaard ook deze potentiële toegenomen vervuiling is meegenomen.
ps. een quote van de introduction van het
voorstel van de mdnsext standaard voor de mensen die niet op het linkje hebben geklikt:
The DNS-SD/mDNS Extensions Working Group (MDNSEXT) will develop
extensions to DNS-Based Service Discovery [DNS-SD] and Multicast DNS
[mDNS] protocols to enable service discovery beyond the local link.
DNS-SD/mDNS is widely used today for discovery and resolution of
services and names on a local link. In principle DNS-SD can also be
used in conjunction with conventional unicast DNS to enable wide-area
service discovery, but in practice this capability is not widely
used. This disconnect between customer needs and current practice
has led to calls for improvement, such as the Educause petition [EP].
In response to this and similar evidence of market demand, several
companies have recently announced "Bonjour gateway" products that
allow service discovery beyond the local link. However, these were
brought to market rapidly and it's unclear whether they represent the
best long-term direction for service discovery protocol development.
Similarly, DNS-SD/mDNS in its present form is not well suited for
emerging technologies such as multi-link subnets like 6LoWPAN where
"link local" is defined as a node's first-hop neighbors, subnet-
scoped multicast is problematic, and battery powered devices may be
offline for significant periods of time.
For these and other reasons, it is therefore beneficial for end
users, network operators, vendors, and for the long-term health of
the Internet to bring this work into the IETF where all interested
parties can cooperate to develop efficient and scalable solutions.
This document defines the problem statement and gathers requirements
for DNS-SD/mDNS Extensions.
[Reactie gewijzigd door Anoniem: 75167 op 24 juli 2024 04:15]