Zum Inhalt springen

Zeroconf-issues: Unterschied zwischen den Versionen

Lfittl (Diskussion | Beiträge)
Keine Bearbeitungszusammenfassung
MiKa (Diskussion | Beiträge)
Keine Bearbeitungszusammenfassung
Zeile 39: Zeile 39:


--[[Benutzer:Lfittl|Lfittl]] 20:12, 14. Feb. 2007 (CET)
--[[Benutzer:Lfittl|Lfittl]] 20:12, 14. Feb. 2007 (CET)
== Details aus [http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt draft-cheshire-dnsext-multicastdns.txt] ==
Im Draft-Dokument steht explizit:
  A host sending Multicast DNS queries to a link-local destination
  address (including the 224.0.0.251 link-local multicast address)
  MUST only accept responses to that query that originate from the
  local link, and silently discard any other response packets. Without
  this check, it could be possible for remote rogue hosts to send
  spoof answer packets (perhaps unicast to the victim host) which the
  receiving machine could misinterpret as having originated on the
  local link.
D.h. dass mDNS prinzipiell nicht für Routing Umgebungen geeignet ist
== Wie wär's mit einem I-Tunes-Router Projekt? ==
Ich helfe gerne mit Design und Projektmanagement für einen I-Tunes Router ;) nur coden kann ich nicht - total aus der Routine.
Mögliches Design:
# Router mit mehreren Interfaces, in jedem Segment eine Link-Local Adresse (bzw. über DHCP oder andere Mittel konfigurierte unique-IP-Address)
# Auf jedem Interface wird eine mDNS-Implementierung gefahren, die Namen lokal auflöst und verwaltet und daraus eine globale Namens-Liste aufbaut.
# Auf jedem Segment wird für jeden Host, der in einem anderen Segment zuhause ist, eine IP-Adresse reserviert (über 169.254.0.0/16 autoconfig, DHCP oder andere geeignete Mittel und gleichzeitig eine NAT-Address-Translation eingerichtet.
# Für jedes Segment werden für Hosts, die auf anderen Segmenten zuhause sind, Proxy mDNS Antworten generiert und eine mDNS-Conflict-Resolution nach [http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt draft-cheshire-dnsext-multicastdns.txt], 9.2 Simultaneous Probe Tie-Breaking, 9.2.1 Simultaneous Probe Tie-Breaking for Multiple Records und 10. Conflict Resolution durchgeführt.
# Registrierte Hosts für mDNS werden zyklisch mit mDNS-Requests gepollt um zu sehen, ob sie noch on-line sind, falls nicht, wird der mDNS-Eintrag und die dazugehörige Adresse sowie die Address-Translation und IP-Address (sofern sie dynamisch konfiguriert wurde) freigegeben.
# Der Rest ist simples NAT
Grüsse, --[[Benutzer:MiKa|MiKa]] 20:30, 14. Feb. 2007 (CET)


[[Kategorie:Netzwerk]]
[[Kategorie:Netzwerk]]