imported>Serols: Änderungen von ~2026-26082-72 (Diskussion) auf die letzte Version von BrunoBoehmler zurückgesetzt

2026-04-29T09:15:36Z

Änderungen von ~2026-26082-72 (Diskussion) auf die letzte Version von BrunoBoehmler zurückgesetzt

Neue Seite

'''Zeroconf''' oder '''Zero Configuration Networking''' ist ein Vorhaben für die selbständige [[Konfiguration (Computer)|Konfiguration]] von [[Rechnernetz]]en ohne Eingriffe durch Menschen. Es wird hauptsächlich in Netzwerken genutzt, in denen eine [[Systemadministrator|Administration]] des Netzwerkes unpraktisch ist, wie bei [[Local Area Network|Heimnetzwerken]] oder kleinen [[Corporate Network|Firmennetzwerken]].<ref name="IETF HP" />

== Hintergrund ==
Die entsprechende Arbeitsgruppe der [[Internet Engineering Task Force]] schloss mangels [[Konsens]] ohne Ergebnis.<ref name="IETF HP">{{cite web
|url = https://datatracker.ietf.org/wg/zeroconf/charter/
|title = Zero Configuration Networking (zeroconf)
|publisher = Internet Engineering Task Force
|accessdate = 2012-04-29
}}</ref> Sie arbeitete von 1999 bis 2004. Ihre Ziele waren:
* automatische Zuordnung einer eigenen [[IP-Adresse]], der [[Netzmaske]] und einer IP-Adresse eines [[Router]]s
* [[Namensauflösung]]
* Suchfunktion nach [[Dienst (Informatik)|Diensten]]
* Zuordnung von [[Multicast]]-Adressen
* unbeeinträchtigte Sicherheit.

Die Arbeitsgruppe relativierte ''Zero'' (Null) dahingehend, dass „wenig Konfiguration“ besser als „ohne Sicherheit“ sei.<ref name="IETF HP" />

2005 wurde nachträglich <nowiki>RFC 3927</nowiki> über die automatische Konfiguration von [[IPv4]] in [[Local Area Network]]s ohne das [[Dynamic Host Configuration Protocol]] veröffentlicht. Dieser Text wurde von Mitarbeitern der Unternehmen [[Apple]], [[Microsoft]] und [[Sun Microsystems]] verfasst und dokumentiert auch verwandte frühere [[Implementierung]]en von '''AutoIP''' oder [[#APIPA|Automatic Private IP Addressing]] (APIPA). Verbindungen in andere Netze als das [[Internet]] sind bei all dem ausgeschlossen. Die ''[[IPv6]] Stateless Address Autoconfiguration'' nach <nowiki>RFC 4862</nowiki> ist darin flexibler.

Das einfachste Einsatzszenario ist es, zwei Computer mit einem [[Crosskabel|Crossover-Kabel]] zu verbinden. Jedes Gerät sucht sich dann automatisch eine freie IP-Adresse und kann anschließend mittels [[Internet Protocol]] (IP) unter dieser Adresse angesprochen werden. Diese Aufgabenstellung ist nicht neu und wurde mit [[AppleTalk]] unter [[Mac OS (Classic)|Mac OS]] und [[NetBIOS]] unter [[Microsoft Windows|Windows]] schon weitgehend gelöst. Zur Nutzung muss man allerdings die IP-Adresse der Gegenstelle kennen, weshalb Zeroconf weiter zielt.

== Automatische IP-Zuweisung ==
Dabei handelt es sich um einen auf dem [[Address Resolution Protocol]] (ARP) aufbauenden Mechanismus, um für eine [[Netzwerkschnittstelle]] automatisch eine freie IP-Adresse auszuwählen. Für diesen Zweck ist von der [[Internet Assigned Numbers Authority|IANA]] der Adressbereich 169.254.0.0/16 vorgesehen, wobei die ersten und die letzten 256 Adressen in diesem Bereich für zukünftige Anwendungen reserviert sind. Der Dienst für die automatische IP-Adressierung heißt '''Internet Protocol Automatic Configuration''' ('''IPAC''').

Wenn ein Rechner eine Link-Local-IP-Adresse konfigurieren will, wählt er eine [[Zufallszahlengenerator|zufällige]] IP-Adresse zwischen 169.254.1.0 und 169.254.254.255 aus. Bei der Erzeugung der IP-Adresse sollte eine rechnerspezifische Information einfließen, wie etwa die [[MAC-Adresse]] der Netzwerkschnittstelle, damit möglichst jedes Mal dieselbe IP-Adresse generiert wird (sie wird also nur [[Pseudozufall|''pseudo''zufällig]] gewählt).

Nach der Auswahl seiner IP-Adresse muss der Rechner diese für sich beanspruchen und testen, ob diese nicht bereits von einem anderen Rechner verwendet wird. Dieser Test muss durchgeführt werden, bevor die IP-Adresse als Senderadresse in IP- oder ARP-Paketen verwendet wird, und genau dann, wenn eine Netzwerkschnittstelle aktiviert wird. Das kann etwa das [[Booten|Einschalten]] oder Rebooten des Rechners, das Aufwachen aus einem [[Sleep-Modus]], das Einstecken eines [[Ethernet]]-Kabels oder das automatische Einhängen eines Rechners in ein [[Wireless LAN|WLAN]] sein.

Explizit verboten ist, diese Überprüfung periodisch durchzuführen, da das eine Verschwendung von [[Netzwerkressourcen]] darstellen würde und im eigentlichen Test auf [[Adresskonflikt]]e schon eine Möglichkeit vorgesehen ist, eventuelle Konflikte auch passiv zu erkennen und darauf zu reagieren.

Die Überprüfung von Adressen auf Konflikte erfolgt mit Hilfe von ARP-probes. Ein ARP-probe ist ein ARP-Paket, bei dem die Absender-IP-Adresse auf [[0.0.0.0]] gesetzt wird und als Empfänger-IP-Adresse die zu überprüfende Adresse verwendet wird.

Sobald der Rechner bereit ist, mit der Konfliktüberprüfung zu beginnen, wartet er eine zufällig lange Zeit zwischen 1 und 2 Sekunden, und sendet dann drei ARP-probes mit einem zufälligen Zeitabstand von 1 bis 2 Sekunden aus. Empfängt der Rechner zwischen dem Testanfang und 2 Sekunden nach Versenden der letzten ARP-probe ein ARP-Paket, bei dem die Absender-IP-Adresse der zu überprüfenden IP-Adresse entspricht, so wurde ein Konflikt gefunden. Der Rechner muss diese Prozedur dann mit einer anderen generierten IP-Adresse wiederholen.

Wird in diesem Zeitraum ein anderes ARP-probe empfangen, das als Empfänger-IP-Adresse die zu testende IP-Adresse enthält, und deren Absender-MAC-Adresse keiner der MAC-Adressen der Netzwerkschnittstelle des Rechners entspricht, so muss vom Rechner ebenfalls eine neue IP-Adresse generiert und überprüft werden. Das kann beispielsweise passieren, wenn zwei oder mehrere Rechner gleichzeitig versuchen, dieselbe Link-Local-Adresse zu konfigurieren.

Um ARP-Stürme und damit eine Überlastung des lokalen Netzwerkes zu vermeiden, wenn es zu mehreren Konflikten kurz hintereinander kommt, muss jeder Rechner nach zehn Fehlversuchen die Geschwindigkeit, mit der er neue Adressen auswählt und überprüft, auf maximal eine Überprüfung pro Minute reduzieren.

Konnte der Rechner keinen Konflikt feststellen, so hat er erfolgreich die generierte IP-Adresse für sich beansprucht. Er muss diese dann bekannt machen, indem er zwei ARP-announcements mit einem Abstand von 2 Sekunden versendet. Ein ARP-announcement unterscheidet sich von einem ARP-probe nur dadurch, dass als Absender- und Empfänger-IP-Adresse die neu ausgewählte Link-Local-IP-Adresse eingesetzt wird.

Die Erkennung von Konflikten muss dauerhaft auch nach dem Auswählen einer verwendbaren IP-Adresse stattfinden. Empfängt der Rechner ein ARP-Paket, das von einem anderen Rechner versendet wurde, und als Sender-IP-Adresse die eigene IP-Adresse enthält, so handelt es sich um einen Adressenkonflikt.

Der Rechner hat nun zwei Möglichkeiten, nämlich eine neue IP-Adresse auszuwählen oder seine IP-Adresse zu verteidigen. Letzteres ist zu bevorzugen, wenn der Rechner noch [[Transmission Control Protocol|TCP]]-Verbindungen offen hat. Wurden noch keine kollidierenden ARP-Pakete empfangen, erfolgt die Verteidigung der Adresse durch den Rechner dadurch, dass dieser ein ARP-announcement aussendet. Konnte der Rechner jedoch in den letzten Sekunden schon einen Adresskonflikt feststellen, so muss er eine neue IP-Adresse auswählen, um eine Endlosschleife zu vermeiden, wenn zwei Rechner mit gleicher IP-Adresse versuchen, diese gegenüber dem anderen zu verteidigen.

== Multicast DNS ==
{| border="0" cellspacing="3" class="float-right" style="text-align:center;"
|+ Multicast DNS im [[TCP/IP-Referenzmodell|TCP/IP-Protokollstapel]]
|-
| bgcolor="#FFCC99" | '''Anwendung'''
| colspan="4" bgcolor="#9999FF" | '''Multicast DNS'''
|-
| bgcolor="#FFCC99" | ''Transport''
| colspan="4" bgcolor="#9999FF" | '''[[User Datagram Protocol|UDP]]'''
|-
| rowspan="1" bgcolor="#FFCC99" | ''Netzwerk''
| colspan="4" bgcolor="#9999FF" | '''[[Internet Protocol|IP]] (IPv6, IPv4)'''
|-
| rowspan="2" bgcolor="#FFEEBB" | ''Netzzugang''
| rowspan="2" bgcolor="#EEEEEE" | [[Ethernet]]
| rowspan="2" bgcolor="#EEEEEE" | [[Token Ring|Token<br />Ring]]
| rowspan="2" bgcolor="#EEEEEE" | [[Fiber Distributed Data Interface|FDDI]]
| rowspan="2" bgcolor="#EEEEEE" | …
|}

Das Protokoll ''Multicast DNS'' (mDNS) beschreibt ein Verfahren, Namen und IP-Adressen ohne [[Domain Name System|DNS]]-Server zu übersetzen.
mDNS beschreibt, wie [[Client]]s verfahren müssen, wenn sie DNS-Anfragen an [[Multicast]]-Adressen senden, und wie eine Gruppe von Rechnern damit umgeht, sodass die Anfrage richtig und ohne unnötige Last auf dem Netzwerk beantwortet wird.

[[DNS-Based Service Discovery]] (DNS-SD) beschreibt einen Mechanismus zum automatischen Veröffentlichen und Finden von Netzdiensten.
DNS-SD spezifiziert eine Konvention für die Verwendung von existierenden [[Resource Record|DNS-Record-Typen]], die das Browsen und Veröffentlichen von Netzwerkdiensten mit DNS ermöglicht.<ref>{{RFC-Internet |Autor=S. Cheshire, M. Krochmal |RFC=6763 |Titel=DNS-Based Service Discovery |Datum=2013-02}}</ref>

mDNS legt fest, dass die DNS-[[Top-Level-Domain]] „.local.“ link-lokal ist. Anfragen und Antworten, die mit „.local.“ zu tun haben, ergeben ähnlich IP-Adressen aus dem [[Private IP-Adresse#Link Local|169.254.0.0/16-]] bzw. [[IPv6#Link-Local-Unicast-Adressen|fe80::/10]]-Bereich nur im lokalen Netz Sinn. Alle DNS-Abfragen für Namen, die auf „.local.“ enden, müssen mit [[User Datagram Protocol|UDP]] und IP Multicast an die mDNS-Multicast-Adresse (IPv4: 224.0.0.251, IPv6: ff02::fb, UDP-Port 5353) gesendet werden. Ist kein anderer DNS-Server verfügbar, können auch Anfragen, die nicht auf „.local.“ enden, an diese Adresse gesendet werden.

Jedem Rechner steht es frei, sich einen eigenen Rechnernamen aus der „.local.“-Domain auszuwählen. Im Gegensatz zu anderen, öffentlichen Top-Level-Domains gibt es keinerlei Formalitäten, außer dass bereits vergebene Rechnernamen nicht mehr verwendet werden sollten. Natürlich kann es in der Praxis zu Konflikten kommen, von den Erfindern von mDNS wurde das aber als sehr unwahrscheinlich angenommen. Eine Konfliktlösung wird sogar bewusst nicht diskutiert, da es sinnvolle Anwendungen für den Fall geben kann, dass mehrere Rechner den gleichen Namen tragen – etwa für [[Lastverteilung (Informatik)|Lastverteilungs]]- oder [[Hochverfügbarkeit]]s-Lösungen.

Soll über eine Reverse-Mapping-DNS-Abfrage der [[Hostname]] zu einer link-lokalen IP-Adresse ermittelt werden, so muss auch diese an die mDNS-Multicast-Adresse (siehe oben) gesendet werden.

=== Vermeidung redundanten Netzwerkverkehrs ===
mDNS stellt einige Regeln auf, die mehrfache mDNS-Abfragen und -Antworten verhindern und so den Netzwerkverkehr möglichst gering halten sollen.

==== Known Answer Suppression ====
Eine Möglichkeit zur Unterdrückung von bereits bekannten Antworten besteht darin, dass der Client, der eine mDNS-Abfrage versendet, schon bekannte Antworten, die noch in seinem [[Cache]] zu finden sind, als Answer Records an seine Abfrage anhängt. Sieht nun ein anderer Client, der die Abfrage beantworten könnte, seine vorgeschlagene Antwort in der Liste der bereits gegebenen Antworten und ist die [[Time to Live|TTL]] (Time to live) noch mehr als die Hälfte der üblichen TTL, muss er diese nicht mehr versenden. Ist die TTL zu gering, muss der andere Client eine Antwort versenden, um die im Cache des ersten Clients gespeicherte TTL zu aktualisieren.

==== Duplicate Question Suppression ====
Wenn mehrere Clients in etwa zur selben Zeit dieselbe Abfrage versenden würden, käme es zu redundantem Netzwerkverkehr. Plant ein Client eine Anfrage zu versenden und sieht eine Abfrage eines anderen Clients desselben Inhalts, sollte er die fremde Abfrage als seine eigene betrachten und die Antwort darauf verwenden, anstatt eine eigene Abfrage zu versenden.

==== Duplicate Answer Suppression ====
Wenn ein Server, während er die Versendung einer Antwort vorbereitet, eine Antwort eines anderen Servers desselben Inhalts sieht und die [[Time to Live|TTL]] (Time to live) der fremden Antwort nicht kleiner als die der eigenen geplanten ist, dann sollte er seine Antwort als gesendet betrachten (also keine eigene Antwort senden).

== Implementierungen ==
Die erste Implementierung von Zeroconf wurde von Apple durchgeführt und heißt [[Bonjour (Apple)|Bonjour]] (früher ''Rendezvous''). Es ist seit der [[Mac OS X 10.2|Version 10.2]] („Jaguar,“ 2002) in Mac OS X – 2016 umbenannt in [[macOS]] – integriert, und Apple liefert die meisten Programme, soweit es sinnvoll ist, mit Bonjour-Funktionalitäten aus.

Eine Komponente von Bonjour ist das mDNSResponder-Projekt, das von Apple im Sourcecode unter der Apache-Lizenz veröffentlicht wurde. mDNSResponder implementiert dabei mDNS und DNS-SD. Es wurde von Apple portierbar entworfen und implementiert, so dass der Quelltext nicht nur unter Mac OS X ab 10.2, sondern auch unter [[Linux]], [[FreeBSD]], [[NetBSD]], [[OpenBSD]], [[Solaris (Betriebssystem)|Solaris]], [[VxWorks]], [[Mac OS 9]] und [[Microsoft Windows|Windows]] ohne Anpassungen übersetzt werden kann.

Ein bekannter Fehler in der mDNS-Implementierung von Apple führt unter [[Microsoft Windows 7|Windows 7]] häufig zu dem Problem, dass ein Default-Gateway von 0.0.0.0 eingetragen wird, der zeitlich vor dem per DHCP bezogenen Gateway herangezogen wird und damit die Internet-Verbindung des Rechners effektiv lahmlegt.<ref>{{Internetquelle |url=https://answers.microsoft.com/en-us/windows/forum/all/windows-7-network-system-tray-icon-displays/23375bdf-0927-44a9-843f-0dbf8ba72cfa |titel=Windows 7 network system tray icon displays "Internet access" when there is none |sprache=en-US |abruf=2019-10-13}}</ref> Eine einfache Lösung ist hier die Deaktivierung des Bonjour-Dienstes per Service-Manager.<ref>Microsoft Knowledge Base: [http://support.microsoft.com/kb/970313/en The Default Gateway may have been set to 0.0.0.0 on a Windows Vista-based or later OS running Apple’s Bonjour service]</ref>

Mit [[Avahi (Software)|Avahi]] existiert weiterhin eine freie ([[GNU Lesser General Public License|LGPL]]) und portierfähige Implementierung von mDNS/DNS-SD, die heutzutage in allen Linux-Distributionen Standard ist.

Damit unter Linux die Namensauflösung bei der Top-Level-Domain .local wie gewohnt über den DNS-Server (z. B. [[BIND]]) abgewickelt wird, ist bei älteren Implementierungen der Eintrag <code>mDNS off</code> in der Datei <code>/etc/host.conf</code> erforderlich.<ref>{{Internetquelle |url=https://support.microfocus.com/kb/doc.php?id=3794674 |titel=Support {{!}} Name Resolution Problems with ".local" Domains |abruf=2017-04-14}}</ref>

=== Microsoft ===
==== Microsoft APIPA ====
{{Anker|APIPA}}Microsofts APIPA soll es Heimanwendern ermöglichen, ein TCP/IP-Netzwerk zu betreiben, ohne sich mit der IP-Adressierung und deren IP-Parametern auseinandersetzen zu müssen. Das Betriebssystem versucht zuerst einen DHCP-Server zu erreichen. Ist ein solcher nicht erreichbar, so wird automatisch eine zufällige Adresse aus dem Bereich 169.254.x.x vergeben.<ref>{{Internetquelle |url=https://www.computerlexikon.com/definition-apipa |titel=APIPA – Computer Lexikon – Fachbegriffe verständlich erklärt {{!}} PC, EDV Glossar |abruf=2020-06-12}}</ref>

In Windows ist die automatische IP-Adressen-Vergabe APIPA seit [[Microsoft Windows 98|Windows 98]] implementiert. Sie entspricht jedoch nicht vollständig dem [[Request for Comments|RFC]] der [[Internet Engineering Task Force|IETF]].<ref>{{Internetquelle |url=http://msdn.microsoft.com/en-us/library/aa505918.aspx |titel=APIPA |sprache=en |offline=1 |archiv-url=https://web.archive.org/web/20101120224043/https://msdn.microsoft.com/en-us/library/aa505918.aspx |archiv-datum=2010-11-20 |abruf=2010-10-25}}</ref> Microsoft nennt dieses Verfahren ''Automatic Private IP Addressing'' oder kurz ''APIPA''.<ref>{{Internetquelle |url=http://support.microsoft.com/kb/220874/de |titel=Automatische TCP/IP-Adressierung ohne einen DHCP-Server |sprache=de |abruf=2010-10-25}}</ref>

==== DNS-SD ====
* Microsoft unterstützt teilweise DNS-SD in [[Microsoft Windows 10|Windows 10]]. Die Unterstützung wurde schrittweise eingebaut und diente ursprünglich nur innerhalb Windows dazu, dass ein Windows-10-Client [[Internet Printing Protocol|IPP]]-Drucker im lokalen Netz finden kann. Mittlerweile wird DNS-SD auch für das Ankündigen und Finden von drahtlosen Anzeigegeräten in einem lokalen Netzwerk verwendet.
* Für Programmierer ist DNS-SD über das ''Windows.Networking.ServiceDiscovery.Dnssd'' [[Programmierschnittstelle|API]] verfügbar.<ref>{{Internetquelle |url=https://docs.microsoft.com/en-us/uwp/api/windows.networking.servicediscovery.dnssd |titel=Windows.Networking.ServiceDiscovery.Dnssd Namespace |sprache=en |abruf=2020-08-31}}</ref>
* Ein Windows-10-Kommandozeilen-Werkzeug für DNS-SD ist nur von Fremdfirmen, zum Beispiel als Teil von Apples Bonjour für Windows, verfügbar.
* Im [[Windows-Subsystem für Linux]] (WSL) ist DNS-SD durch Avahi verfügbar.

==== mDNS ====
* In Windows 10 kann im Entwickler-Modus Device-Discovery aktiviert werden.<ref>{{Internetquelle |url=https://docs.microsoft.com/de-de/windows/uwp/get-started/enable-your-device-for-development#additional-developer-mode-features |titel=Weitere Features im Entwicklermodus |sprache=de |abruf=2020-08-31}}</ref> Dies aktiviert Multicast-Unterstützung im DNS-Client.
* Für [[Windows IoT]] ist ein mDNS-Antwortdienst von Microsoft im Quelltext verfügbar.<ref>{{Internetquelle |url=https://docs.microsoft.com/de-de/windows/iot-core/mdns |titel=Erste Schritte mit der Beispielquelle des mDNS-Antwortdiensts |sprache=de |abruf=2020-08-31}}</ref>
* In [[Windows-Subsystem für Linux|WSL]] ist mDNS über Avahi verfügbar.

==== Weitere Protokolle ====
Je nach Windows-Version und -Konfiguration sind weitere proprietäre Microsoft-Protokolle wie [[Link-local Multicast Name Resolution|LLMNR]], [[Windows Internet Naming Service|NBNS]] und [[Simple Service Discovery Protocol|SSDP]] verfügbar. Microsoft rät von der Verwendung von NBNS ab.

== Normen und Standards ==
* {{RFC-Internet |Autor=Stuart Cheshire, Bernard D. Aboba, Erik Guttman |RFC=3927 |Titel=Dynamic Configuration of IPv4 Link-Local Addresses |Datum=2005-05}}
* {{RFC-Internet |Autor=S. Cheshire, M. Krochmal |RFC=6762 |Titel=Multicast DNS |Datum=2013-02}}
* {{RFC-Internet |Autor=S. Cheshire, M. Krochmal |RFC=6763 |Titel=DNS-Based Service Discovery |Datum=2013-02}}

== Weblinks ==
* [http://www.zeroconf.org/ zeroconf.org] – Offizielle Webseite der IETF Zeroconf Working Group

* [https://avahi.org/ Avahi]
* [https://developer.apple.com/bonjour/ mDNSResponder]
* [https://www.jmdns.org/ JmDNS] (Java)
* [https://github.com/bk138/wxservdisc wxServDisc] (wxWidgets)

== Einzelnachweise ==
<references />

[[Kategorie:Netzwerkprotokoll]]
[[Kategorie:Apple]]

Zeroconf - Versionsgeschichte

imported>Serols: Änderungen von ~2026-26082-72 (Diskussion) auf die letzte Version von BrunoBoehmler zurückgesetzt