Kolejność wyszukiwania DNS w systemie Mac OSX Lion [zamknięta]


96

Po uaktualnieniu do Mac OSX Lion doszedłem do wniosku, że / etc / hosts nie jest już przeszukiwany na pierwszym miejscu pod kątem rozwiązywania nazw. Prowadzi to do pewnych skutków ubocznych, takich jak:

  1. Wpisy w / etc / hosts są rozwiązywane boleśnie powoli
  2. Nie możesz zastąpić istniejących domen, np. 127.0.0.1 www.google.com
  3. Jeśli otrzymujesz wpisy domeny wyszukiwania z DHCP, powiedzmy .lan, a jakiś zabawny facet skonfigurował localhost.lan na coś innego niż 127.0.0.1 w lokalnym DNS, nie możesz już połączyć się z lokalnym hostem.

Czy to zachowanie jest zamierzone? Czy to ma jakiś sens? A co najważniejsze, jak mogę wrócić do starego zachowania.


12
Super pomocne pytanie - niespodzianka, niespodzianka zamknięta jako poza tematem
Sebastian Patten

Przynajmniej nie usunęli wątku… jeszcze. To uratowało mój bekon. Zmieniłem wszystkie hosty z X.local na X.lhost i problem zniknął. Na marginesie, jestem wielkim fanem xip.io, np. Foo.127.0.0.1.xip.io
Tim

Odpowiedzi:


78

Myślę, że liczy się to, że Lion traktuje .local TLD inaczej, ponieważ jest zarezerwowany dla niektórych funkcji Multicast DNS (używanych przez Bonjour). Jedynym sposobem rozwiązania tego problemu jest użycie innego TLD dla hostów programistycznych (tj.: .Dev). U mnie działa dobrze, mam nadzieję, że pomoże innym!


Dziękuję Ci. Rzeczywiście bardzo pomocne.
Cade

5
Moja pierwsza myśl była „kiepska”. Jednak potem natknąłem się na ten inny post na stosie i zmieniłem swoje stanowisko: serverfault.com/questions/17255/ ...
Matt Beckman

Jedna uwaga - jeśli używasz chrome do programowania, niestandardowe domeny najwyższego poziomu będą interpretowane jako wyszukiwanie. Może być konieczne wykonanie czegoś takiego jak .dev.com, aby umożliwić rzeczywiste wyszukiwanie domeny. Nie jestem pewien, jak to zrobić elegancko.
bbrame

5
@bbrame: Można wprowadzić swoją domenę lokalną z systemem URL: http://foo.dev/; Po tym Chrome zda sobie sprawę, że foo.devjest to domena, a nie zapytanie.
działa

Alternatywnie możesz użyć narzędzia dscl, aby dodać wyjątek.
Artur Bodera

51

Jeśli chodzi o nadpisywanie domen w pliku hosts, odkryłem, że w pewnych okolicznościach Lion pyta o adres IPv6 dla domeny, jeśli wykryje, że domena jest nieosiągalna w sieci IPv4.

Odkryłem to, gdy zauważyłem reklamy, których nigdy wcześniej nie widziałem w Snow Leopard, ponieważ przekierowałem domeny reklam do 127.0.0.1. Uruchomiłem wireshark i zauważyłem AAAA(rekordy DNS IPv6) zapytania następujące po Azapytaniach IPv4 (IPv4). Serwery reklam rzeczywiście mają adresy IPv6 i były w stanie udostępniać mi swoją zawartość.

Rozwiązaniem tego jest mieć plik

::1 mydomain.com

wejście dla każdego

127.0.0.1 mydomain.com

wpis w pliku hosts.

Co ciekawe, jeśli zdarzy się, że masz uruchomiony lokalny serwer WWW, 127.0.0.1:80a Twoja przeglądarka otrzyma odpowiedź z serwera WWW (błąd lub inny błąd), nie AAAAzostanie wysłane żadne zapytanie, ponieważ wydaje się, że jest przekonane, że połączenie TCP było przynajmniej możliwe.


W związku z tym, jeśli intensywnie korzystasz z pliku hosts (do blokowania reklam, lokalnego tworzenia stron internetowych itp.), Możesz zajrzeć do uruchomienia własnego lokalnego resolwera DNS. Czytanie /etc/hostskażdego żądania powoduje znaczne uszkodzenie dysku / procesora , więc w twoim najlepszym interesie jest, aby ten plik był bardzo lekki.

Jedną z zalet uruchamiania czegoś takiego jak dnsmasqlokalnie (poza znacznym wzrostem wydajności) jest to, że możesz przekierować całe domeny najwyższego poziomu z powrotem na komputer lokalny. Dzięki temu możesz mieć całą przestrzeń nazw * .dev do programowania (na przykład), bez konieczności indywidualnego wprowadzania każdej domeny, która ma być lokalnie rozwiązana/etc/hosts


3
Wielkie dzięki za to. Czekanie 10-30 sekund na przetestowanie zmian w moim kodzie doprowadzało mnie do szału i zaoszczędziłeś mnóstwo czasu, nie musiałem sam tego rozgryzać.
Zack Angelo

1
Miałem ten sam problem, który natychmiast rozwiązał mój problem! Miły.
cstrat

1
+1 To świetna ciekawostka dla każdego, kto szuka „dlaczego plik moich hostów nie działa”. Mogę zadać to pytanie tutaj, abyś mógł tam umieścić tę samą odpowiedź i ułatwić znajdowanie go za pomocą wyszukiwarki!
peleryna1232

Od odczytu nie powinno być zauważalnego wzrostu we / wy dysku /etc/hosts- system operacyjny buforuje plik, jeśli jest często używany.
Dan Pritts

Użytkownicy, których sieci LAN obsługują protokół IPv6 (w końcu prawie 2016 r.!) Napotkają ten problem od teraz, aż do całkowitego zniknięcia protokołu IPv4… lub do czasu, gdy Apple podejmie problem i rozwiąże go wewnętrznie! Należy również wziąć pod uwagę odpowiedź Jean-Baptiste'a (np. Użyj .dev zamiast .local w swoich środowiskach deweloperskich).
unrivaledcreations

17

Problem polegał na tym, że dałem symboliczny plik / etc / hosts. Jeśli / etc / hosts jest zwykłym plikiem, wszystko jest w porządku.


1
Mam ten sam problem. Jednak mój plik / etc / hosts jest normalnym plikiem. Każda pomoc w tej sprawie byłaby mile widziana.
mat.

4
Wydaje się, że to też był mój problem. Miałem łącze symboliczne do pliku w folderze skrzynki referencyjnej, który kiedyś działał i który uważałem za bardzo sprytny. Wydawałoby się, że Apple nie uważa już tego sprytnego. Zrobiłem również pełny prawdziwy restart przy użyciu opcji restartu po przeniesieniu go z dowiązania symbolicznego do prawdziwego pliku. Wszystko wydaje się teraz szczęśliwe.
Tom S.,

2
Wpisy w pliku hostów z dowiązaniem symbolicznym są w porządku, jeśli nie można ich rozwiązać w inny sposób, oznacza to, że plik hostów z dowiązaniem symbolicznym jest sprawdzany tylko wtedy, gdy adres nie może zostać rozwiązany w inny sposób. Kiedy plik hosts jest zwykłym plikiem, jest sprawdzany przed jakąkolwiek inną formą rozwiązania. Więc jeśli chcesz zastąpić domeny, które faktycznie mają prawidłowe wpisy DNS, twój plik hosts musi być plikiem, a nie dowiązaniem symbolicznym.
cerberos

1
Dla przypomnienia, nadal tak jest w Mavericks (10.9), przydałoby się, gdyby ktoś mógł potwierdzić, co robi Yosemite…
William Turrell

1
Yosemite też to robi, właśnie napotkałem ten problem. To niezwykle dziwne zachowanie.
Vytautas Gimbutas

14

Aktualizacja (2): OSX 10.10.5 przynosi powrót mDNSResponder.

Aktualizacja: OSX 10.10 Yosemite zamieniło mDNSResponder na „discoveryd”. Nie zaktualizowałem, więc nie jestem pewien zachowania discoveryd w / r / t wyszukiwania DNS i /etc/hosts.

mDNSResponderProcesem jest systemowy przelicznik DNS w Lion .

Możesz pomyśleć „ale mDNSResponder jest respondentem multiemisji DNS”. Masz rację; do tego pierwotnie służył i nadal spełnia tę funkcję. Jednak w nowszych wersjach MacOS wykonuje również standardowe wyszukiwania hostów.

W Lion nie wydaje się, aby automatycznie ponownie czytał, /etc/hostsgdy się zmienia, przynajmniej nie zawsze. Zabijanie mDNSResponder(i pozwalanie na automatyczne ponowne uruchomienie) wydaje się rozwiązywać problem.

sudo killall mDNSResponder

powinien załatwić sprawę.

poniżej jest moja oryginalna odpowiedź dla potomnych. Przypuszczam, że w niektórych przypadkach może to nadal stanowić problem.

Upewnij się, że /etc/hostsplik jest plikiem tekstowym w stylu unixowym, z wysunięciami linii jako zakończeniem, a nie cr.

Edycja za pomocą TextWranglera lub uniksowego edytora tekstu powinna zachować plik.

Jeśli plik jest już popsuty, spróbuj to naprawić

tr '\015' '\012' < /etc/hosts > /tmp/hosts.$$
mv /etc/hosts /etc/hosts.bad
mv /tmp/hosts.$$ /etc/hosts
# fix up permissions while we are at it
chown root:wheel /etc/hosts
chmod 644 /etc/hosts

zasługa tej poprawki:

http://techpatio.com/2011/guides-how-to/fixed-mac-osx-lion-etc-hosts-bugs-dns


Może to rozwiązać problem z uszkodzonym demonem rozpoznawania nazw DNS, ale nie rozwiązuje problemu przekształcania hostów na adresy IP w sieci LAN, które często występują w środowiskach programistycznych. Odpowiedź @guns, poniżej, będzie właściwym rozwiązaniem dla większości osób, które znajdują to pytanie w wyszukiwaniu; chociaż Jean-Baptiste-MONIN ma również uzasadnioną odpowiedź.
unrivaledcreations

Może rozwiązać problem niezauważenia zmian w / etc / hosts.
Dan Pritts

Używam high sierra i ta odpowiedź rozwiązuje problem z aliasem, dzięki
Absolutkarlos

4

Przez jakiś czas miałem ten problem, ponieważ pracując z zespołem programistów, konieczne stało się używanie .local zamiast .dev lub .localhost. Ten artykuł okazał się bardzo przydatny.

iTand.me - domeny lokalne Lion i inne hosty.

W podsumowaniu;

Ale jeśli musisz użyć .local, najbardziej eleganckim rozwiązaniem, jakie znalazłem, jest narzędzie dscl. Korzystanie z niego jest bardzo proste. Aby dodać hosta o nazwie mydev.local i skierować go do hosta lokalnego, wykonaj następujące czynności:

sudo dscl localhost -create /Local/Default/Hosts/mydev.local IPAddress 127.0.0.1

Aby zobaczyć wszystkie aktualnie zdefiniowane hosty i ich adresy IP

sudo dscl localhost -list /Local/Default/Hosts IPAddress

Aby usunąć hosta:

sudo dscl localhost -delete /Local/Default/Hosts/mydev.local

Ogólnie rzecz biorąc, całkiem proste i działa dobrze. Nadal wolałbym mieć możliwość edycji / etc / hosts, ale jest to lepsza alternatywa dla konieczności zmiany nazw wszystkich naszych serwerów .local.


3
Dodając nazwę hosta w ten sposób, pozornie nic nie robi. Nie można pingować adresu. Przykład: sudo dscl localhost -create / Local / Default / Hosts / test1 Adres IP 127.0.0.1 ping test1 ping: nie można rozwiązać test1: Nieznany host
oligofren

3

Przed przejściem z Snow Leopard do Lion miałem kilka wpisów specyficznych dla aplikacji /etc/hosts, na przykład:

127.0.0.1 foo.bar.local

Po aktualizacji ładowanie lokalnych aplikacji było BARDZO wolne. Zauważyłem, że opóźnienie nastąpiło, zanim żądanie pojawiło się w pliku dziennika, a gdy to się stało, sama aplikacja działała tak szybko, jak zwykle.

Teraz mam dwa wiersze na aplikację, na przykład:

127.0.0.1 foo.bar.local
::1       foo.bar.local

... i znowu wszystko jest szybkie.

Najwyraźniej dodaje to adresy IPv6? Nie do końca rozumiem, ale to działa.


Nic innego nie zadziałało, ale zadziałało w jednej chwili - dzięki Nathan!
piątek

3

Moja sytuacja była podobna, ale opóźnienia, wynoszące dokładnie 5 sekund, występowały tylko w przypadku adresów URL kończących się na „.local”. Podczas przeglądania stron, które kończyły się na „.dev”, nie było opóźnienia.

Niektórzy inni programiści w moim biurze mieli ten problem, podczas gdy kilku nie. Liczyłem na prostą poprawkę i nie chciałem zmieniać nazwy witryny na „.local” z powodu innych zależności.

Uruchomiłem następujące polecenie w Terminalu i porównałem wyniki z kilkoma innymi użytkownikami w biurze.

scutil --dns

Ta sekcja była jedyną różnicą:

resolver #2
  domain   : 00000000.members.btmm.icloud.com
  options  : pdns
  timeout  : 5
  order    : 150000

Mój Mac był połączony z moim kontem iCloud i miałem włączoną funkcję Back To My Mac. Po wyłączeniu funkcji Back To My Mac dodatkowy resolver zniknął, a 5-sekundowe opóźnienie zniknęło.


1

Wow, co za koszmar. Przeczytałem absolutnie wszystko na ten temat i wszystko, co do tej pory zostało zasugerowane, było kusząco bliskie temu, czego doświadczałem, ale żadne z rozwiązań nie zadziałało.

I zorientowałem się, dlaczego.

W przeciwieństwie do innych nie używałem / etc / hosts do konfigurowania lokalnych domen. Mój plik / etc / hosts był w magazynie i zawierał tylko wpisy potrzebne dla interfejsu sprzężenia zwrotnego i hosta transmisji. Co więcej, był to poprawnie zakodowany plik unixowy, ponieważ jestem osobą, która edytuje go tylko z wiersza poleceń, używając emacsa. I, dzięki Bogu, nie musiałem uciekać się do uruchamiania własnego serwera DNS, takiego jak DNSmasq, aby obejść problem.

(Żeby było jasne, symptomem, który przywiódł mnie tutaj do tego problemu, było to, że emacs uruchamiał się około 10 sekund, ale tylko wtedy, gdy byłem w Wi-Fi. Gdybym wyłączył Wi-Fi, emacs uruchomiłby się natychmiast zgodnie z oczekiwaniami.)

Moje rozwiązanie: mój laptop ma nazwę „terminator”. (Tak, jego błyszcząca aluminiowa obudowa przywodziła mi na myśl postać Arnolda Schwarzeneggera.) Musiałem tylko dodać wpisy do / etc / hosts dla nazwy samej maszyny:

127.0.0.1   terminator
::1         terminator

Znalazłem nazwę mojego hosta, uruchamiając proste polecenie w terminalu:

hostname

... który wrócił z wyjściem: "terminator". Po zmianie / etc / hosts tak, aby zawierał te dwa wpisy, emacs może teraz szybko rozpoznać nazwę mojego laptopa.

Mam nadzieję, że to komuś pomoże.


1
wydaje się, że właśnie teraz zadziałało. Zobaczymy, czy to się utrzyma. Jestem podekscytowany, że to rozgryzłeś, ponieważ sporadycznie widziałem ten problem bez ostrzeżenia.
Jeremy Carlson

Strzelać. To nie jest dla mnie trwałe rozwiązanie. Problem z powrotem. Pamiętaj, że kiedy to ponownie czytam, mój numer nie jest twój ...
Jeremy Carlson

0

Miałem problemy z szybkością, używając OSX Lion jako narzędzia do tworzenia stron internetowych ... Korzystając z kombinacji sugestii, uciekłem się do wyłączenia sieci ipv6 i routingu ipv6 do localhost6 ... wszystko przyspieszyło trochę ...

sudo networksetup -setv6off Ethernet

/ etc / hosts ...

127.0.0.1    localhost
127.0.0.1    dev.aliasdomain.com
... 
::1          localhost6 

0

Myślę, że było kilka poprawek błędów. Widziałem wiele wspomnianych problemów i żaden z nich nie wydaje się mieć obecnie zastosowania (na przykład umieszczanie wielu aliasów w jednej linii teraz działa dobrze).

W każdym razie wydaje się, że w przypadku Lion Apple dokonał drastycznych zmian w mDNSResponder, który obsługuje wszystkie wyszukiwania DNS i (przynajmniej w przypadku Lion) obsługuje również buforowanie / etc / hosts. Dla mnie wyszukiwanie do przodu również teraz działa. Ale odwrotne wyszukiwania (np. Wyszukiwanie 1.2.3.4 zamiast google.com) nie działają.

Po wielu kłopotach wygląda na to, że mDNSResponder konwertuje to wyszukiwanie do 4.3.2.1.in-addr.arpa i wyszukuje nazwę. Może to być preferowany sposób działania DNS, ale w ogóle nie działa z / etc / hosts.

O ile oczywiście nie dodasz aliasu 4.3.2.1.in-addr.arpa dla każdego hosta, gdzie 4.3.2.1 to adres IP w odwrotnej kolejności, z której zwykłeś go widzieć. To wszystko naprawia dla mnie. Oto przykładowy wpis w / etc / hosts:

1.2.3.4 foo foo.example.com alias.example.com 4.3.2.1.in-addr.arpa

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.