2013-07-18 22 views
6

Sto cercando di apportare miglioramenti alla libreria Go per mDNS: https://github.com/davecheney/mdns/dumping Avahi & Bonjour, file di zona DNS-SD

Ho parlato con l'autore, che dice semplicemente "ho preso ad un punto dove ha funzionato per me ", e va bene, ben nello spirito dell'open source.

Ha citato alcuni problemi di interoperabilità con gli strumenti di ricerca Avahi, Bonjour e dns-sd non trovando i servizi che ha esportato.

Sto cercando di capire quali documenti vengono pubblicati da Avahi quando si effettua un servizio semplice con una porta e un nome semplice.

mi aspettavo una versione appropriata di:

dig @localhost .local -t AXFR 

Potrebbe avere Avahi esportare è zona, ma non ha funzionato per me (! Cue "si sta facendo sbagliato") - mi piacerebbe per capire i record minimi esportati da un tipico servizio Avahi ed esaminare lo stesso dal Lee-Hambleys-Macbook.local esportato automaticamente dall'implementazione Apple sul mio notebook che potrei essere in grado di migliorare il supporto Go lang per mDNS.

Quando altre persone stanno lavorando con Avahi/Bonjour/mDNS, quali strumenti usano per scavare e controllare che le cose funzionino come previsto?

Il tipo gente di #avahi erano abbastanza gentile da darmi il seguente suggerimento:

killall -USR1 avahi-daemon 

che provoca avahi-daemon a discarica è file di zona al syslog.

Ma idealmente mi piacerebbe sapere il modo migliore per interrogare il server, tcpdump sembra promettente, ma è ancora mostrando solo i record che ottengono lookedup, non un dump completo di tutto ciò che è nella zona:

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 
+2

mDNS funziona sulla porta 5353 quindi è necessario filtrare per quello, non la porta 53. :-) –

+2

Non credo che il trasferimento di zona debba funzionare con mDNS. Penso che stai confondendo mDNS/DNS-SD con Avahi un po ', forse? Potrebbe valere la pena impiegare un paio d'ore per scremare le RFC: http://tools.ietf.org/html/rfc6762 e http://tools.ietf.org/html/rfc6763 –

+0

Grazie, sto quasi certianamente termini, per quanto ne so, dns-sd si aspetta che i record DNS vengano esportati su DNS standard e mDNS funzioni su una porta diversa, ma i record sembrano record DNS? –

risposta

1

mDNS semplicemente non supporta i trasferimenti di zona a causa del funzionamento del protocollo. Per quanto posso dire ci sono due possibili approcci:

1) Provare l'approccio della forza bruta, interrogando il target (server/sottorete). Puoi farlo con scavare, basta inviare la query all'indirizzo multicast e interrogare il tuo obiettivo, ad es.

dig -x 192.168.0.10 -p 5353 @ 224.0.0.251

Ci sono anche un paio di script e strumenti che aiutano a enumerare mDNS obiettivi pronti.Alcuni esempi includono

2) Forza il daemon per scaricare il suo file di zona (o impostazioni). È già scoperto che Avahi obbedisce

killall -USR1 avahi-daemon

Bonjour di Apple include mDNSResponder che non implementa informazioni di zona di dumping. Tuttavia è possibile aggiungere più di registrazione per i benefici simili

segnale A SIGUSR1 alterna la registrazione supplementare, con Avviso e Avviso abilitato di default:

% sudo killall -USR1 mDNSResponder 

Una volta che questa registrazione è abilitata, gli utenti possono inoltre usare syslog (1) a cambia il filtro di registro per il processo. Ad esempio, per abilitare il login livelli di emergenza - Debug:

% sudo syslog -c mDNSResponder -d 

segnale A SIGUSR2 alterna registrazione pacchetti:

segnale
% sudo killall -USR2 mDNSResponder 

Un SIGINFO scaricherà una sintesi un'istantanea dello stato interno in/var/log/system.log:

% sudo killall -INFO mDNSResponder 

Inoltre, Wireshark potrebbe essere utilizzato per d errori di protocollo ebug. Questo dovrebbe essere sufficiente per risolvere errori di interoperabilità.

+0

Non l'ho provato, ma sembra tutto un solido consiglio, in particolare 'dig'ing indirizzo multicast –