Rozdzielczość DNS nie działa w przypadku pingowania i zwijania, ale nie kopie

Używam DNSMasq jako lokalnego serwera DNS, więc mogę to rozwiązać *.local.pcfdev.io(jak omówiono tutaj Korzystanie z PCF Dev Offline w systemie Mac OS X ). Wszystko działało, kiedy pierwszy raz konfigurowałem.

Kilka dni później, po kilku restartach mojego MacBooka, w trybie offline nie mogę już rozwiązać takich problemów, jak api.local.pcfdev.ioużywanie curllub ping. Jednak digrobi to dobrze.

$ dig api.local.pcfdev.io

; <<>> DiG 9.8.3-P1 <<>> api.local.pcfdev.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46877
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;api.local.pcfdev.io.       IN      A

;; ANSWER SECTION:
api.local.pcfdev.io.    0       IN      A       192.168.11.11

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep  6 10:17:44 2016
;; MSG SIZE  rcvd: 53

$ curl api.local.pcfdev.io
curl: (6) Could not resolve host: api.local.pcfdev.io

Próbowałem dodając -AlwaysAppendSearchDomainsjako argument /usr/sbin/mDNSResponderw /System/Library/LaunchDaemons/com.apple.mDNSResponder.plisti ponownym uruchomieniu mDNSResponder z launchctl, ale bez skutku.

AKTUALIZACJA 1

Z pewnością lokalny adres IP nasłuchuje:

$ nslookup api.local.pcfdev.io
Server:     127.0.0.1
Address:        127.0.0.1#53

Name:   api.local.pcfdev.io
Address: 192.168.11.11

$ ping api.local.pcfdev.io
ping: cannot resolve api.local.pcfdev.io: Unknown host

$ telnet 192.168.11.11 80
Trying 192.168.11.11...
Connected to 192.168.11.11.
Escape character is '^]'.

HTTP/1.1 400 Bad Request

Connection closed by foreign host.

AKTUALIZACJA 2

Po wypróbowaniu poniższej sugestii usunięcia wszystkich serwerów DNS z Preferencji sieciowych, z wyjątkiem tego 127.0.0.1, że nic nie mogę rozwiązać. Udało mi się wylogować z mDNSResponder:

mDNSResponder[91]:  74: DNSServiceCreateConnection START PID[32612](ping)
mDNSResponder[91]:  74: Error socket 75 created 00000000 00000001
mDNSResponder[91]:  74: DNSServiceQueryRecord(15000, 0, api.local.pcfdev.io., Addr) START PID[32612]()
mDNSResponder[91]:  74: Error socket 75 closed  00000000 00000001 (0)
mDNSResponder[91]:  74: DNSServiceQueryRecord(api.local.pcfdev.io., Addr) ADD    0 api.local.pcfdev.io. Addr
mDNSResponder[91]:  74: Cancel 00000000 00000001
mDNSResponder[91]:  74: DNSServiceQueryRecord(api.local.pcfdev.io., Addr) STOP PID[32612]()
mDNSResponder[91]:  74: DNSServiceCreateConnection STOP PID[32612](ping)

Zauważyłem również, jak wyjaśniono w proponowanej odpowiedzi, nslookupi dignie powodują rejestrowania niczego mDNSResponder, ale robią to inne narzędzia ( ping, curl).

Wygląda więc na to, że z jakiegokolwiek powodu albo dnsmasqnie działa (mogę nawiązać połączenie TCP 127.0.0.1:53), albo go mDNSRespondernie używa.

AKTUALIZACJA 3

etc/resolve.confprzestaje istnieć, gdy mój adapter Wi-Fi jest aktywny, ale nie mam połączenia z siecią. Czy to może dlatego narzędzia CLI nie używają lokalnego dnsmasqserwera?

macos yosemite dns

— EngineerBetter_DJ
źródło

Czy Twoja karta sieciowa nie działa przypadkowo? Jeśli przejdziesz do opcji „Sieć” w Preferencjach systemowych, czy obok karty, w której skonfigurowany jest program dnsmasq, znajduje się zielona kropka?

— mango

Cóż, jestem w pociągu bez Wi-Fi, więc prawdopodobnie.

— EngineerBetter_DJ

Czy adapter Wi-Fi jest wyłączony? Jeśli tak, spróbuj ponownie przy włączonym adapterze Wi-Fi (nawet jeśli tak naprawdę nie jest on podłączony do Internetu). Aby instalacja działała, dnsmasq musi być serwerem DNS używanego interfejsu sieciowego .

— mango

Dzięki za próbę wyśledzenia tego. Walczę również z tym, nie rozumiem, dlaczego „curl foo: 8989” nie może znaleźć hosta, ale „dig foo” może. Tak, „curl 172.20.0.17:8989” działa dobrze. Podobnie jak ty mam DNS sieci Wi-Fi ustawiony na 127.0.0.1 (dnsmasq działający w kontenerze dokera). FWIW w mojej obecnej sytuacji problem dotyczy sieci Wi-Fi, z którą się łączę - działa dobrze na moim osobistym hotspocie, problem dotyczy Wi-Fi w sklepie z kawą.

— jamshid

Nie poddałem inżynierii wstecznej omawianych programów, ale spodziewam się, że wywołują zupełnie inne podstawy kodu rozpoznawania DNS i dlatego widzisz uszkodzenie - niektóre wskazują lokalnie, inne nie. Pewnie bym kopać curllub wgetlub uzyskać je w instrumenty / profiler / debugger i zobaczyć, co się naprawdę dzieje, aby spowodować błąd nie mógł rozwiązać.

— bmike

Odpowiedzi:

Miałem ten sam problem. Myślę, że lokalna pamięć podręczna DNS miała złe dane z moich poprzednich testów. Zostało to szybko naprawione przez:

sudo killall -HUP mDNSResponder

— cmcginty
źródło

Zauważyłem to pingi digczasami zwracam różne adresy IP (zwykle ze DNS z podziałem horyzontu) i to polecenie to naprawia. Co nie jest podstawową przyczyną, nie jestem pewien.

— James

kop z jednej strony, a curl / ping z drugiej strony pobierają dane z różnych hostów:

dig wysyła zapytanie do serwera DNS - w twoim przypadku localhost (127.0.0.1) - o wpis w bazie danych: adres IP związany z FQDN api.local.pcfdev.io. Sam host nie musi wcale działać ani nawet istnieć.

curl / ping spróbuj rozwiązać adres IP za pomocą mDNSResponder lub w inny sposób, a na końcu działać na / współpracować ze zdalnym hostem. Jeśli host 192.168.11.11 nie działa lub w ogóle nie istnieje, oba kończą się niepowodzeniem.

Teraz wpis DNS jest nieprawidłowy (api.local.pcfdev.io ma inny adres IP niż 192.168.11.11) lub wpis DNS jest poprawny, ale host 192.168.11.11 nie jest uruchomiony.

Dodanie -AlwaysAppendSearchDomains jako argumentu do / usr / sbin / mDNSResponder w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist nie jest zalecane. Zamiast tego powinieneś dodać go do /Library/Preferences/com.apple.mDNSResponder.plist (źródło:) man mDNSResponder:

Aby mDNSResponder działał z tymi opcjonalnymi argumentami podczas uruchamiania w systemie OS X 10.11 (El Capitan) i nowszych, ustaw klucze logiczne AlwaysAppendSearchDomains lub NoMulticastAdvertisements na true w katalogu /Library/Preferences/com.apple.mDNSResponder.plist i uruchom ponownie.

W twoim przypadku nie ma potrzeby ustawiania tego klucza, ponieważ nie jest to przyczyną twojego problemu.

Po wkopaniu się w VirtualBox, PCF Dev (powtarzające się błędy z kilkoma „błędnymi poświadczeniami” próbującymi zalogować się do maszyny wirtualnej) i dnsmasq Polecam przekazanie zapytań DNS tylko do dnsmasq:

W Preferencjach systemowych> Sieć> Interfejs> Serwer DNS usuń wszystkie serwery DNS oprócz 127.0.0.1 i zastosuj zmiany. Możesz także skonfigurować drugą lokalizację z konfiguracją tylko 127.0.0.1 i zachować bieżący serwer DNS w innej konfiguracji.

dodaj plik /usr/local/etc/resolv.dnsmasq.conf z zawartością

#use your preferred DNS servers here. In the example I use some Google name servers
nameserver 8.8.8.8
nameserver 8.8.4.4

dodaj resolv-file=/usr/local/etc/resolv.dnsmasq.confw linii ~ 46 pliku /usr/local/etc/dnsmasq.conf
dodaj lub przenieś address=/.local.pcfdev.io/192.168.11.11w / do linii ~ 80 pliku /usr/local/etc/dnsmasq.conf

uruchom ponownie dnsmasq za pomocą:

sudo launchctl stop homebrew.mxcl.dnsmasq
sudo launchctl start homebrew.mxcl.dnsmasq

— klanomath
źródło

Dzięki za poświęcenie czasu na odpowiedź. Zdecydowanie coś nasłuchuje 192.168.11.11; rzeczywisty publiczny wpis DNS dla *.local.pcfdev.iozawsze wskazuje na ten sam lokalny adres IP, więc gdy tylko połączę się z informacjami, curlmusi uzyskać odpowiedź z tego serwera DNS i być w stanie dowiedzieć się, jakiego adresu IP użyć.

— EngineerBetter_DJ

Wygląda na to curl, że pingi inne pliki binarne, na które chcę trafić, używają jednego sposobu wyszukiwania wpisów DNS (który nie używa dnsmasqserwera na localhost) nslookupi digużywają innych środków. Chyba muszę dowiedzieć się więcej o mDNSResponder!

— EngineerBetter_DJ

@EngineerBetter Czy masz jakieś inne wpisy w Preferencjach systemowych> Sieć> Interfejs> DNS niż 127.0.0.1? - Zainstaluję cały pakiet (VBox, PCF Dev itp.) I sprawdzę to ... Jakaś specjalna konfiguracja?

— klanomath

Jeszcze raz dziękuję za poświęcenie czasu, aby mi w tym pomóc. Pytanie zostało zaktualizowane, nadal nie ma szczęścia.

— EngineerBetter_DJ

Rozwiązanie tego zajęło mi znacznie więcej czasu, niż powinno. Po kilkakrotnym ponownym uruchomieniu mDNSResolver zgodnie z zaleceniami dla innych wątków:

sudo killall -HUP mDNSResponder

W końcu spróbowałem czegoś innego. Wyłączyłem Wi-Fi i usunąłem wszystkie preferowane sieci. Następnie przywróciłem połączenie Wi-Fi i wszystko działało dobrze:

Menu Apple -> Preferencje systemowe -> Wi-Fi (po lewej)
„Wyłącz Wi-Fi”, a następnie wybierz „Zaawansowane”
Usuń połączenie Wi-Fi, z którym masz problem (lub wszystkie, jeśli chcesz). Zrób to, wybierając sieć Wi-Fi, którą chcesz usunąć, i naciskając „-”
Kliknij „Zastosuj” i „OK”
Ponownie włącz Wi-Fi.
Wybierz sieć Wi-Fi i zaloguj się ponownie.

YMMV, ale to w końcu dla mnie zadziałało. Prawdopodobnie powinna to być pierwsza rzecz, której spróbowałem.

— Joel Griffiths
źródło