Multicast DNS - oder eben nicht?

Geschrieben von Beat Rubischon (Link) am Dienstag, 11. Juli 2006, 19:12 aus dem to-be-or-not-to-be dept. Im April schrieb ich schon einmal über mDNS aka Multicast DNS aka Rendezvous aka Bonjour aka Zeroconf. Jetzt tauchte eine neue Herausforderung auf. Die Idee hinter mDNS ist ganz einfach - statt einen DNS Server zu fragen, wer welche Dienste anbietet, schickt man die Anfragen per Multicast hinaus und horcht auf die Antworten. Apple macht damit interessante Dinge wie beispielsweise dynamische Bookmarks mit allen Webservern in der Nähe. Alle $KOMMERZDISTRIBUTIONEN haben heute einen mDNS Responder am Laufen und ich habe mir sagen lassen, dass unter Gnome und KDE viele Dienste automagisch auftauchen. Eigentlich ein nettes Feature. Zuhause habe ich zwei Netzwerksegmente - einerseits ein public Netz (ich sage dem DMZ wenn mich jemand erstaunt anguckt warum ich meine Server und Workstations mit public IPs betreibe :-), andererseits ein LAN mit privaten IPs. Meine melone sitzt im privaten LAN, meist über Wireless angeschlossen. Würde es nun möglich sein, von der melone die Dienste von Priska's majorie zu sehen? Multicasting ist in solch einfachen Umgebungen keine Hexerei und so fand ich innert kürzester Zeit eine passende Anleitung, um meinem Cisco das Nötige beizubringen: conf t ip multicast-routing ip pim ssm default int eth0   ip pim sparse-mode   ip igmp version 3   exit int eth2   ip pim sparse-mode   ip igmp version 3   exit quit wr Ein Test mit ssmping bewies dass der Router das Multicastzeugs versteht. BTW: Mein IOS kennt zwar Multicast und IPv6, aber kein IPv6 Multicast *sniff* Jetzt die majorie booten und ping melone.local eintippen. Fehlanzeige. Viiiiiel später fand ich dann einen Artikel bei O'Reilly mit der Antwort. mDNS benutzt zwar Multicast als Transportmedium, verwendet aber mit 224.0.0.251 eine Gruppenadresse, die nicht weitergeleitet werden darf. Zusätzlich wird auch mit dem TTL (Time To Live) geschummelt: Anfragepakete haben eine TTL von eins, damit der erste Router, der sie in die Finger bekommt, gleich wegschmeisst. Die Antworten haben eine TTL von 255 und nur diese wird vom Client akzeptiert - sollte ein Router das Paket weiterleiten, so wird die TTL reduziert und damit der mDNS Request ungültig. Die Idee dahinter ist Security. Oder sagen wir dem besser Security through obscurity? mDNS announct den Dienst ja nur, der Dienst selbst ist eine ganz andere Baustelle. Umgesetzt auf normalen DNS heisst das, dass ich einfach meinem Webserver keinen Namen eintragen darf, dann wird er schon nicht gehackt *hüstel* Ein anderer Punkt wurde von einem Netzwerkadmin in einer Apple Mailingliste angesprochen. Er hat gut 4000 Mobile Rechner in einem einzigen Segment Wireless angeschlossen und seine Chefs mögen den Multicast Traffic nicht. Ich musste die Zahl mehrfach lesen. Eine derart grosse collision domain performt nie, egal ob mit oder ohne mDNS. Ich fragte mich natürlich schon, warum zum Geier Multicast und nicht simpler Broadcast verwendet wird. Aber damit kann ich leben - viel hässlicher finde ich die Tatsache, dass ich, selbst wenn ich will, keine Chance habe, zwei Segmente transparent zu verbinden. Mit einem Gateway unter Linux und ein paar iptables-Hacks sollte es möglich sein. An vielen Orten wird auch von einem Proxy geplaudert, der aber noch nicht programmiert wurde. Auch die Idee, mDNS Services in einen klassischen Bind zu packen, scheint nur angedacht aber nicht implementiert zu sein. Eigentlich schade - Apple machte es früher nämlich besser. Der gute alte AppleTalk war routebar - lange bevor die NetBIOS Leute überhaupt wussten, was Netzwerksegmente sind. Und über eben diesen AppleTalk fand man auch Rechner am anderen Ende des Campusses. Permalink

Das Kleingedruckte: Der Besitzer der folgenden Kommentare ist wer immer sie eingeschickt hat. Wir sind in keiner Weise für sie verantwortlich.