Dumping Avahi & Bonjour, DNS-SD-Zone Files

Ich suche nach mDNS Verbesserungen an der Go-Bibliothek zu machen: https://github.com/davecheney/mdns/Dumping Avahi & Bonjour, DNS-SD-Zone Files

ich mit dem Autor gesprochen habe, die einfach sagt: „Ich habe es bis zu einem Punkt wo es für mich funktionierte ", und das ist gut, ganz im Sinne von Open Source.

Er erwähnte einige Interoperabilitätsprobleme mit Avahi, Bonjour und DNS-SD Discovery-Tools, die nicht die Dienste finden, die er exportiert hat.

Ich suche zu verstehen, welche Datensätze von Avahi veröffentlicht werden, wenn Sie einen einfachen Dienst mit einem Port und einem einfachen Namen ausführen.

hatte ich eine entsprechende Version von erwartet:

dig @localhost .local -t AXFR

Könnte Avahi es Zone, aber es für mich nicht funktioniert haben exportieren (! Stichwort: „Sie es falsch machen“) - Ich mag würde um die von einem typischen Avahi-Service exportierten minimalen Datensätze zu verstehen und dieselben von der automatisch exportierten Lee-Hambleys-Macbook.local der Apple-Implementierung auf meinem Notebook zu untersuchen, könnte ich die Go lang-Unterstützung für mDNS verbessern.

Wenn andere Leute mit Avahi/Bonjour/mDNS arbeiten, mit welchen Tools graben sie ein und überprüfen, ob die Dinge wie erwartet funktionieren?

Die Art Leute von #avahi waren so freundlich, mir den folgenden Tipp zu geben:

killall -USR1 avahi-daemon

Der avahi-daemon es ist Zonendatei auf die syslog Dump verursacht.

Aber im Idealfall würde ich gerne wissen, wie man am besten den Server abzufragen, sieht tcpdump auch vielversprechend, aber es ist immer noch nur Datensätze, die lookedup erhält, nicht eine komplette Dump all das, was in der Zone ist:

sudo tcpdump dst port 53 
Password: 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode 
listening on en0, link-type EN10MB (Ethernet), capture size 65535 bytes 
09:43:28.883763 IP 192.168.178.41.50916 > resolver2.opendns.com.domain: 50479+ A? e3191.c.akamaiedge.net. (40) 
09:43:29.046201 IP 192.168.178.41.61989 > resolver2.opendns.com.domain: 55378+ PTR? 251.0.0.224.in-addr.arpa. (42) 
09:43:29.123784 IP 192.168.178.41.56659 > resolver2.opendns.com.domain: 26471+ A? p05-btmmdns.icloud.com.akadns.net. (51) 
09:43:29.819277 IP 192.168.178.41.53504 > resolver2.opendns.com.domain: 32010+ PTR? 220.220.67.208.in-addr.arpa. (45) 
09:43:47.379251 IP 192.168.178.41.50916 > resolver2.opendns.com.domain: 50479+ A? e3191.c.akamaiedge.net. (40) 
09:43:55.900406 IP 192.168.178.41.60511 > resolver2.opendns.com.domain: 32846+ AAAA? lc22.prod.livefyre.com. (40) 
09:44:04.115159 IP 192.168.178.41.50916 > resolver2.opendns.com.domain: 50479+ A? e3191.c.akamaiedge.net. (40) 
^C 
7 packets captured 
3187 packets received by filter 
0 packets dropped by kernel

Quelle

2013-07-18 Lee Hambley

mDNS arbeitet auf Port 5353, also muss man dafür filtern, nicht nach Port 53. :-) –

Ich glaube nicht, dass Zonenübertragung mit mDNS funktionieren soll. Ich denke du verwechselst mDNS/DNS-SD mit Avahi ein bisschen, vielleicht? Es könnte sich lohnen, ein paar Stunden zu brauchen, um die RFCs zu überfliegen: http://tools.ietf.org/html/rfc6762 und http://tools.ietf.org/html/rfc6763 –

Danke, ich bin fast zerbrechlich Terms up, soweit ich weiß dns-sd erwartet, DNS-Datensätze in Standard-DNS exportiert werden, und mDNS arbeitet an einem anderen Port, aber die Datensätze sehen aus wie DNS-Datensätze? –

mDNS unterstützt aufgrund der Funktionsweise des Protokolls einfach keine Zonentransfers. Soweit ich das beurteilen kann gibt es zwei mögliche Ansätze:

1) Versuchen Brute-Force-Ansatz, indem Sie das Ziel (Server/Subnetz) abfragen. Sie können dies mit dig tun, senden Sie die Abfrage an Multicast-Adresse und Abfrage für Ihr Ziel, z.

dig -x 192.168.0.10 -p 5353 @ 224.0.0.251

Es gibt auch ein paar bereit Skripte und Tools, die Ziele in Aufzählen mDNS unterstützen.Einige Beispiele hierfür sind

2) den Dämon erzwingen seine Zonendatei Dump (oder die Einstellungen). Sie fanden bereits heraus, dass Avahi

killall -USR1 avahi-Daemon

Apples Bonjour enthält mDNSResponder gehorcht, die nicht Dumpingzoneninformationen nicht implementiert. Sie können jedoch mehr Protokollierung für Ähnliche Vorteile hinzufügen

A SIGUSR1 Signal schaltet zusätzliche Protokollierung, mit Warnung und Hinweis standardmäßig aktiviert:
% sudo killall -USR1 mDNSResponder 
Sobald diese Protokollierung aktiviert ist, können Benutzer zusätzlich syslog verwenden können (1) zu ändern Sie den Protokollfilter für den Prozess. Zum Beispiel ermöglichen Ebenen Notfall log - Debug:
% sudo syslog -c mDNSResponder -d 
Ein SIGUSR2 Signal schaltet Paketprotokollierung:
% sudo killall -USR2 mDNSResponder 
Ein SIGINFO Signal wird eine Momentaufnahme Zusammenfassung des internen Zustands Dump /var/log/system.log:
% sudo killall -INFO mDNSResponder 

auch Wireshark könnte bis d verwendet werden Ebug-Protokollfehler. Dies sollte ausreichen, um Interoperabilitätsfehler zu beheben.

Quelle

2015-05-02 17:09:55 user918176

Ich habe das nicht ausprobiert, aber es scheint alles ein solider Rat zu sein, vor allem die Multicast-Adresse –

Dumping Avahi & Bonjour, DNS-SD-Zone Files

Antwort

Verwandte Themen