dumping Avahi & Bonjour, file di zona DNS-SD

Question

Sto cercando di apportare miglioramenti alla libreria Go per mDNS: https://github.com/davecheney/mdns/

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 

Answer 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

• MDNSRecon
• avahi-browse
• mdns-scan
• Bonjour Dumper
• dns-sd Z e gli amici

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à.