Ritardo di 10 secondi per .local TLD in Mac OS X Lion

La nostra rete aziendale utilizza xxx.companyname.localper tutti i server sulla nostra rete locale. Ogni volta che accedo a uno di questi server sul mio Mac, ho un ritardo di 10 secondi. Ho scoperto che questo ritardo è causato dalle ricerche DNS, perché apparentemente Lion risolve i domini .local nel seguente ordine:

controlla l' /etc/hostsindirizzo IPv6
controlla il server DNS per un record AAAA (indirizzo IPv6)
controllare tramite MDNS (Bonjour) per un record AAAA
controlla /etc/hostsun indirizzo IPv4
controlla il server DNS per un record A (indirizzo IPv4)
controlla MDNS per un record

Ora, il problema è che non abbiamo una rete IPv6. Tutti i xxx.companyname.localserver sulla nostra rete hanno solo indirizzi IPv4 e il server DNS ha solo record A. Ciò significa che l'indirizzo è stato risolto nel passaggio 5. Il problema è che il passaggio 3 richiede dieci secondi prima che scada! Ogni volta che mi collego al nostro wiki, al server SVN, al server Kerberos, ecc., C'è un ritardo di 10 secondi.

Sono riuscito a ingannare Lion aggiungendo linee come le seguenti /etc/hosts

::FFFF:10.99.99.99 xxx.companyname.local

Se lo faccio, Lion pensa che ci sia un indirizzo IPv6 per il dominio e si interrompe dopo il passaggio 1. Tuttavia, questa soluzione aggira totalmente tutte le funzionalità utili di DNS. Non voglio tenere traccia manualmente degli indirizzi IP di dozzine di domini interni! Potrei anche smettere di usare i nomi host e digitare solo gli indirizzi IP!

Quindi: qualcuno ha un'idea su come cambiare questo ordine di ricerca? O disabilitare la ricerca IPv6 dal momento che non abbiamo una rete IPv6 comunque?

dns osx-lion bonjour

— Jakob Egger
fonte

Grazie per la domanda - L'ho aggiunto come riferimento di risoluzione DNS per Mac;)

— Alex

Saresti molto meglio se cerchi di determinare perché i tuoi server DNS impiegano 10 secondi per inviare una risposta di set di record vuota per i AAAArecord quando (secondo quello che dici) non impiegano così tanto tempo per rispondere alle Adomande stessi nomi di dominio. Sembra che tu sia nel classico territorio RFC 4074, dove il problema è che i server sono rotti . Si noti inoltre che hai riscontrato uno dei numerosi motivi noti e discussi a lungo per non utilizzare local.il servizio DNS split-horizon. È anche meglio sistemarlo.

— JdeBP,

I server DNS nel passaggio due restituiscono immediatamente un record AAAA vuoto. Il problema è il passaggio 3: la query MDNS / Bonjour / Zeroconf. Lion attende 10 secondi dopo la trasmissione prima di scadere. Dopo aver cercato su Google un po 'sono ben consapevole che l'utilizzo local.è una cattiva idea, ma il dipartimento IT mi ha detto che pensano che l'uso local.companyname.sia perfetto e che non posso davvero farci nulla.

— Jakob Egger,

Le persone nel tuo reparto IT sono molto poco informate. Questo è stato conosciuto per essere molto non "benissimo" nei circoli di amministrazione della rete per circa la metà di un decennio. Potresti ... incoraggiare ... le conoscenze di rete delle persone del tuo reparto IT da portare nel 21 ° secolo. Potresti ... ricordare ... loro che il loro compito non è quello di organizzare le cose in modo tale che i computer aziendali non funzionino correttamente. ☺

— JdeBP

@JdeBP Eppure, Apple ha deciso che sarebbe una buona idea usarlo ... Noterai che anche Microsoft lo usa e lo consiglia come best practice. Quindi ... Chi dice che non lo sia ?

— Basic

Risposte:

Impedisci al tuo dipartimento IT di abusare `local.`.

Come discusso, abusare di un nome di dominio di cui la tua azienda non è proprietaria , e non dovrebbe quindi supporre che possa creare sottodomini aziendali, è sbagliato ed è la metà del problema qui. Se i computer aziendali includono Macintoshes (o qualsiasi altra cosa che utilizza DNSSD per quella materia), allora sicuramente non presumi che tu sia libero di scherzare local.in questo modo.

Aggiorna il tuo Macintosh.

MacOS 10.4 tratterà davvero xxx.companyname.local.come descritto. Ma questo è cambiato nelle successive revisioni del sistema operativo. MacOS 10.5 passa solo nomi con due etichette a Multicast DNS. Nomi a tre etichette come xxx.companyname.local.non sono gestiti da MDNS. MacOS 10.6 va oltre e cerca di rilevare se il server DNS è stato configurato in modo errato per avere una local. zona e agire di conseguenza.

Come minimo, è necessario configurare il Macintosh in modo che /etc/resolver/contenga un .localfile con il nome dell'aziendasearch_order 1 in cui siano elencati gli indirizzi IP correnti dei server DNS proxy. Ciò non funzionerà bene con gli indirizzi IP del server DNS assegnati da DHCP che cambiano, tuttavia, come afferma Apple.

Sulla mano avvincente ...

... questi sono semplicemente corpuscoli progressivamente più complessi per accogliere la testa sbagliata. Per citare Marc Krochmal di Apple, "ci sarà sempre qualche problema" quando le persone abusano local.del modo in cui la tua azienda sta facendo. È noto per essere stato sbagliato dal (una ricerca veloce mi dice) 2002, se non prima. Basta non farlo .

Ulteriori letture

dlove (2002-12-02). Dominio .local e problemi DNS . Macworld.
Apple Corporation (2010). Mac OS X v10.4, 10.5, 10.6: Come cercare i nomi host ".local" tramite Bonjour e DNS standard .
Stephen Hoffman (2010). Suggerimenti DNS: Combinazione di DNS unicast e multicast con .local . HoffmanLabs.
Apple Corporation (2008). Mac OS X 10.3: Come cercare i nomi host ".local" tramite Bonjour e DNS standard .

— JdeBP
fonte

Nessuna di queste informazioni risolve i miei problemi con la risoluzione DNS in Lion (Mac OS X 10.7). Inoltre, /etc/resolver/companyname.localsembra essere ignorato in Lion.

— Jakob Egger,

Non conosco Mac, quindi non posso davvero aiutarti, ma sono venuto con una soluzione alternativa intelligente: se ti installi da qualche parte su Internet, "somedomain.com DNAME companyname.local"catturerà DNAME al passaggio 2. Ora non sono sicuro di cosa accadrà poi, tornerà ancora al bonjour, o dal momento che è già nel mezzo di un processo DNS, forse si attaccherà al DNS.

— alex
fonte

Posso offrirmi volontario nella creazione del DNAME per te se lo desideri :)