10-sekundowe opóźnienie dla .local TLD w Mac OS X Lion

Nasza sieć firmy korzysta xxx.companyname.local dla wszystkich serwerów w naszej sieci lokalnej. Ilekroć uzyskuję dostęp do jednego z tych serwerów na moim Macu, mam 10 sekund opóźnienia. Odkryłem, że to opóźnienie jest spowodowane wyszukiwaniem DNS, ponieważ najwyraźniej Lion rozwiązuje domeny .local w następującej kolejności:

czek /etc/hosts dla adresu IPv6
sprawdź serwer DNS pod kątem rekordu AAAA (adres IPv6)
sprawdź za pośrednictwem MDNS (Bonjour), czy istnieje rekord AAAA
czek /etc/hosts dla adresu IPv4
sprawdź serwer DNS w poszukiwaniu rekordu A (adres IPv4)
sprawdź MDNS dla rekordu A.

Problem polega na tym, że nie mamy sieci IPv6. Wszystko xxx.companyname.local serwery w naszej sieci mają tylko adresy IPv4, a serwer DNS ma tylko rekordy A. Oznacza to, że adres zostanie rozwiązany w kroku 5. Problem polega na tym, że krok 3 trwa dziesięć sekund, zanim upłynie czas! Za każdym razem, gdy łączę się z naszą wiki, serwerem SVN, serwerem Kerberos itp., Opóźnienie wynosi 10 sekund.

Udało mi się oszukać Lwa, dodając linie podobne do poniższych /etc/hosts

::FFFF:10.99.99.99 xxx.companyname.local

Jeśli to zrobię, Lion myśli, że istnieje adres IPv6 dla domeny i zatrzymuje się po kroku 1. Jednak to obejście całkowicie omija wszystkie przydatne funkcje DNS. Nie chcę ręcznie śledzić adresów IP dziesiątek domen wewnętrznych! Równie dobrze mogę przestać używać nazw hostów i po prostu wpisywać adresy IP!

Więc: Czy ktoś ma pomysł, jak zmienić kolejność wyszukiwania? Lub wyłącz wyszukiwanie IPv6, ponieważ i tak nie mamy sieci IPv6?

dns osx-lion bonjour

— Jakob Egger
źródło

Dziękuję za pytanie - dodałem do zakładek jako odniesienie do rozdzielczości DNS systemu Mac;)

— Alex

Lepiej by było, gdybyś próbował ustalić, dlaczego twoje serwery DNS potrzebują 10 sekund na wysłanie pustej odpowiedzi zestawu rekordów AAAA nagrywa, gdy (zgodnie z tym, co mówisz) nie zabierają czasu na odpowiedź A zapytania o te same nazwy domen. Wydaje się, że jesteś w klasycznym terytorium RFC 4074, gdzie problem polega na tym serwery są zepsute . Zauważ też, że trafiłeś na jedną z kilku znanych i od dawna omawianych przyczyn nie za pomocą local. dla usługi DNS split-horizon. Lepiej to naprawić.

— JdeBP

Serwery DNS w kroku drugim natychmiast zwracają pusty rekord AAAA. Problemem jest krok 3 - zapytanie MDNS / Bonjour / Zeroconf. Lew czeka 10 sekund po transmisji, zanim upłynie limit czasu. Po tym jak googluję, jestem tego świadomy local. to zły pomysł, ale dział IT powiedział mi, że myślą local.companyname. jest w porządku i nie mogę nic z tym zrobić.

— Jakob Egger

Ludzie w twoim dziale IT są znacznie niedostatecznie poinformowani. Wiadomo, że jest bardzo dużo nie „idealnie w porządku” w kręgach administracji sieci przez około pół dekady. Możesz… zachęcić ludzi do informowania pracowników działu IT w XXI wieku. Możesz… przypomnieć im, że ich praca jest nie zorganizować sprawy w taki sposób, aby komputery firmowe nie działały prawidłowo. ☺

— JdeBP

@JdeBP A jednak Apple zdecydowało, że warto go użyć ... Zauważysz, że Microsoft również z niego korzysta i zaleca go jako najlepszą praktykę. Więc ... Kto mówi, że tak nie ?

— Basic

Odpowiedzi:

Zatrzymaj dział IT przed nadużywaniem `local.`.

Jak omówiono, nadużywanie nazwy domeny że twoja firma nie jest właścicielem i nie powinno się zakładać, że może tworzyć korporacyjne poddomeny, jest błędne i stanowi połowę problemu. Jeśli komputery firmowe zawierają komputery Macintosh (lub cokolwiek innego, co używa DNSSD), to zdecydowanie nie zakładaj, że local. jest twój swobodny bałagan w ten sposób.

Zaktualizuj komputer Macintosh.

MacOS 10.4 rzeczywiście by się potraktował xxx.companyname.local. jak opisujesz. Ale zmieniło się to w późniejszych wersjach systemu operacyjnego. MacOS 10.5 przekazuje tylko nazwy dwóch etykiet do Multicast DNS. Trzy nazwy etykiet, takie jak xxx.companyname.local. nie są obsługiwane przez MDNS. MacOS 10.6 robi to dalej i próbuje wykryć, czy serwer DNS został źle skonfigurowany, aby mieć local. strefa i działać odpowiednio.

W minimum należy skonfigurować komputer Macintosh tak, aby posiadał /etc/resolver/ Nazwa firmy .local plik z search_order 1 w nim znajduje się aktualny adres (adresy) IP serwera (serwerów) DNS proxy. Nie zadziała to jednak z adresami IP serwera DNS przypisanymi przez DHCP, które zmieniają się, jak mówi Apple.

Na chwytnej dłoni…

… Są to po prostu coraz bardziej skomplikowane ciała, aby dostosować się do złego myślenia. Cytując Marca Krochmala z Apple, „zawsze będzie jakiś problem”, gdy ludzie będą nadużywać local. w sposób, w jaki robi to Twoja firma. Wiadomo, że jest źle traktowany od czasu (szybkie wyszukiwanie mówi mi o tym 2002), jeśli nie wcześniej. Właśnie nie rób tego .

Dalsza lektura

dlove (2002-12-02). Domena .local i problemy z DNS . macworld.
Apple Corporation (2010). Mac OS X 10.4, 10.5, 10.6: Jak wyszukać nazwy hostów „.local” za pośrednictwem Bonjour i standardowego DNS .
Stephen Hoffman (2010). Porady DNS: Mieszanie unicast i multicast DNS z .local . HoffmanLabs.
Apple Corporation (2008). Mac OS X 10.3: Jak wyszukać nazwy hostów „.local” za pomocą Bonjour i standardowego DNS .

— JdeBP
źródło

Żadna z tych informacji nie rozwiązuje moich problemów z rozpoznawaniem DNS w Lion (Mac OS X 10.7). Ponadto, /etc/resolver/companyname.local wydaje się być ignorowane w Lionie.

— Jakob Egger

Nie znam Maca, więc naprawdę nie mogę pomóc, ale przyszedłem z pomysłowym rozwiązaniem problemu: jeśli ustawisz się gdzieś w Internecie, "somedomain.com DNAME companyname.local" - złapie DNAME w kroku 2. Teraz nie jestem pewien, co będzie dalej, czy nadal powróci do bonjour, czy też jest już w trakcie jakiegoś procesu DNS, może pozostanie przy DNS.

— Alex
źródło

Jeśli chcesz, mogę dobrowolnie utworzyć dla ciebie nazwę DNAME :)