Multicast-DNS

Das ist der Eintrag dazu aus unserem IT-Kommunikationslexikon:


Multicast-DNS (mDNS) ist ein elementarer Bestandteil von Zeroconf. Die Zielstellung für mDNS ist es, die Funktion des DNS ohne zentrale DNS-Server umsetzen zu können.

mDNS ist dabei nichts anderes als eine Beschreibung, wie Clients 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 erhöhte Last auf dem Netzwerk beantwortet wird. In mDNS ist festgelegt, dass die DNS-Top-Level-Domain ".local." linklokal ist. Dies bedeutet, dass Anfragen und Antworten, die mit ".local." zu tun haben, ähnlich wie Linklokale IP-Adressen nur im lokalen Netz einen Sinn ergeben. Alle DNS-Abfragen für die ".local"-Domain müssen per UDP an die mDNS-Multicast-Adresse 224.0.0.251 Port 5353 gesendet werden. Ist kein dedizierter DNS-Server verfügbar, können auch Anfragen, die nicht auf ".local." enden, an diese Adresse gesendet werden.

Es gibt keine Formalitäten für die Namensvergabe in einer ".local"-Domain. Jeder Rechner kann sich selbst einen Namen registrieren. Dabei kann es natürlich zu Namenkonflikten kommen. Es sind aber bewusst keine technischen Konfliktlösungen vorgesehen, da es zum Beispiel in Cluster sinnvolle Anwendungen für eine Situation gibt, in der mehrere Rechner den gleichen Namen verwenden.

Um den Netzwerkverkehr möglichst gering zu halten, hat mDNS Verfahren, die redundante mDNS-Abfragen und Antworten verhindern sollen. Aufgrund des Multicast-Verfahrens bekommt ja jeder alle gestellten Anfragen und Antworten mit und kann diese in seinem eigenen Cache speichern. Außerdem kann ein anfragender Client an eine Anfrage gleich die ihm schon bekannte Antworten, die sich noch in seinem Cache befinden, als Antwort-Datensätze an seine Abfrage anhängen. Sieht nun ein weiterer Client, der eine andere Abfrage beantworten könnte, seine vorgeschlagene Antwort bereits in einem Antwort-Datensatz und ist die TTL noch mehr als die Hälfte der üblichen TTL, so muss er keine Antwort mehr versenden. Ist die TTL allerdings zu gering, so muss er trotzdem eine Antwort verschicken, um die TTLs in den anderen Clients zu aktualisieren. Durch diese intelligenten Multicast-Verfahren werden Zeit und Netzwerkressourcen gespart. Allerdings wird dafür in allen angeschlossenen Stationen Rechenzeit verbraucht, weil jede mDNS-Station möglichst alle mDNS-Anfragen verfolgen muss.

Aktuelle Beiträge

Gastkonten im Azure AD verwalten

Gastkonten im Azure AD ließen sich bisher nur recht grob und entweder manuell oder mit Skript­arbeit verwalten. Mit "Cross-tenant access settings" stehen dem Admin nun granularere Möglichkeiten zur Verfügung – über die Graph-API auch automatisiert. Wer das Aufräumen der Gastkonten zudem mithilfe von Access Reviews an die Anwender selbst delegiert, kann weitere wertvolle Zeit sparen.

Zero Trust über Workloads hinweg

Ein Zero-Trust-Ansatz ist am effektivsten, wenn er sich über alle Standorte und Umgebungen erstreckt, in denen Workloads auf verschiedene Anwendungen und Daten zurückgreifen. Aus diesem Grund unterstützt eine zeitgemäße Firewall-Plattform eine Zero-Trust-Architektur erheblich, indem sie die Netzwerksicherheit so nah wie möglich an die Workloads heranbringt. Wie dies gelingt und worauf es ankommt, erklärt Palo Alto Networks.

Maßnahmen gegen Tool-Sprawl und Schatten-IT

In vielen IT-Abteilungen wächst mit jeder neuen Aufgabe auch die Zahl der Tools – bis irgendwann der Überblick verloren geht. Was zunächst als Hilfe gedacht war, wird dann zum Hindernis. Doppelte Arbeit, Sicherheitsrisiken und Missverständnisse sind die Folge. Der Artikel veranschaulicht, wie dieser Toolwildwuchs entsteht, warum er Teams ausbremst und wie ein gemeinsamer, vereinfachter Ansatz die Kontrolle zurückbringt.