v654321
Poster original- 6 august 2011
- Vilvoorde, Belgia
- 22 mai 2021
Declarație de problemă: MBP-ul meu primește o adresă IP atribuită prin DHCP, folosind un Pi-hole, cu un rezolutor DNS nelegat. Folosesc un nume de domeniu intern „home.arpa” și acesta este adăugat ca domeniu de căutare DNS, inclusiv IP-ul serverului meu DNS (192.168.1.4). Fiecare dispozitiv din rețeaua mea are un nume de gazdă.
Pe mașinile mele Linux și Windows pot face ping perfect pe același dispozitiv folosind atât FQDN-ul (de exemplu, ap12.home.arpa sau kodi.home.arpa) cât și numele de gazdă în sine (de exemplu, ap12 sau kodi), deoarece domeniul de căutare este adăugat automat . Cu toate acestea, pe MBP-ul meu pur și simplu nu funcționează, ca și cum domeniul de căutare nici nu ar exista/fi ignorat. Pot face ping perfect la FQDN, dar numele de gazdă în sine eșuează întotdeauna. Nu mi-am asigurat fișierul /private/etc/hosts cu aceste nume de gazdă sau FQDN, deoarece configurația DNS ar trebui să se ocupe de asta (și o face pe mașinile mele non-MacOS). Am încercat chiar și cu configurație IP fixă (atât IP static, DNS și domenii de căutare DNS), dar nicio diferență.
Scuze dacă acest lucru nu este apreciat, dar am adăugat câteva capturi de ecran atât pentru Windows, Linux, cât și pentru MacOS Big Sur cu rezultatele lor de configurare și ping:
Windows 10:
Vizualizați elementul media „>
Linux:
Vizualizați elementul media „>
MacOS Big Sur:
Vizualizați elementul media „>
Din ceea ce a dezvăluit căutarea mea pe Google, se pare că domeniul de căutare este o problemă care a apărut în trecut pentru mai mulți utilizatori, dar nu am găsit fire care să facă din aceasta o problemă structurală. A fost de cele mai multe ori legat de VPN-uri (DNS de tunel divizat) sau de domenii de căutare lipsă/greșite. M-a făcut să trag concluzia că, cu o configurație adecvată, totul a fost considerat a funcționa.
Sper în tăcere că unii dintre voi mă pot ghida/ajuta să îmi dau seama ce ar putea fi în neregulă sau ce pot face pentru a atenua acest lucru. Evident, pot codifica numele de gazdă/FQDN-urile în fișierul /private/etc/hosts, dar, deoarece mă joc cu o mulțime de computere și VM-uri, aș dori să mă pot baza pe rezoluția DNS care este complet automatizată.
Vă mulțumim anticipat pentru potențialul interes/implicare!
HenryAZ
- 9 ianuarie 2010
- Congresul de Sud AZ
- 22 mai 2021
v654321 a spus: Declarația problemei: MBP-ul meu primește o adresă IP atribuită prin DHCP, utilizând un Pi-hole, cu un rezolutor DNS nelegat. Folosesc un nume de domeniu intern „home.arpa” și acesta este adăugat ca domeniu de căutare DNS, inclusiv IP-ul serverului meu DNS (192.168.1.4). Fiecare dispozitiv din rețeaua mea are un nume de gazdă.
Aveți o zonă locală configurată pentru home.arpa în nelegat la 192.168.1.4? V
v654321
Poster original- 6 august 2011
- Vilvoorde, Belgia
- 23 mai 2021
Domeniul intern home.arpa este configurat în interfața web pihole. Este posibil ca descrierea mea inițială de configurare să nu fi fost completă. Scuzele mele pentru asta.
Serverul DNS configurat pe toate computerele mele este adresa IP pihole, care - dacă nu are domeniul solicitat în cache și nici nu se află pe listele de blocare preconfigurate - îl trimite către serviciul nelegat (care rulează pe localhost pe pihole) care va contacta apoi serverele rădăcină DNS pentru a identifica serverele DNS TLD etc., până când sunt primite IP-urile necesare pentru domeniile externe. Nu este necesară configurarea zonei locale pentru unbound, deoarece acest lucru se face pe interfața web pihole. Am folosit următoarele ghid de instalare și a urmat-o la literă. Doar MBP eșuează pentru căutările numai pentru nume de gazdă, toate celelalte mașini funcționează perfect.
Rularea următoarei comenzi pe Linux funcționează perfect (kodi se extinde automat cu domeniul de căutare, astfel încât devine kodi.home.arpa:
$ ping kodi PING kodi.home.arpa (192.168.1.35) 56(84) bytes of data. 64 bytes from kodi.home.arpa (192.168.1.35): icmp_seq=1 ttl=64 time=0.733 ms 64 bytes from kodi.home.arpa (192.168.1.35): icmp_seq=2 ttl=64 time=0.718 ms Rezultă următoarele bușteni pe pihole:
May 23 13:34:14 dnsmasq[10080]: query[A] kodi.home.arpa from 192.168.1.11 May 23 13:34:14 dnsmasq[10080]: /etc/pihole/custom.list kodi.home.arpa is 192.168.1.35 May 23 13:34:14 dnsmasq[10080]: query[PTR] 35.1.168.192.in-addr.arpa from 192.168.1.11 May 23 13:34:14 dnsmasq[10080]: /etc/pihole/custom.list 192.168.1.35 is kodi.home.arpa Totuși, fac același lucru de la MBP-ul meu:
% ping kodi ping: cannot resolve kodi: Unknown host % ping kodi.home.arpa PING kodi.home.arpa (192.168.1.35): 56 data bytes 64 bytes from 192.168.1.35: icmp_seq=0 ttl=64 time=4.889 ms 64 bytes from 192.168.1.35: icmp_seq=1 ttl=64 time=5.530 ms Rezultă următoarele bușteni pe pihole:
May 23 13:35:26 dnsmasq[10080]: query[A] kodi from 192.168.1.78 May 23 13:35:26 dnsmasq[10080]: config kodi is NODATA-IPv4 May 23 13:35:30 dnsmasq[10080]: query[A] kodi.home.arpa from 192.168.1.78 May 23 13:35:30 dnsmasq[10080]: /etc/pihole/custom.list kodi.home.arpa is 192.168.1.35 Acest lucru arată că pe MBP prima încercare de ping eșuează, deoarece domeniul de căutare nu este adăugat automat pentru a deveni FQDN (kodi.home.arpa), în timp ce a doua cerere este tratată corect. Ambele solicitări ajung la pihole, dar domeniul de căutare nu este aplicat, în ciuda faptului că este prezent în configurația IP, așa cum este furnizată de DHCP.
Dacă nu îmi lipsește altceva, aș îndrăzni să trag concluzia că, având în vedere că atât gazda Linux, cât și MBP își primesc informațiile IP și DNS identic de la același DHCP, că contactează același server DNS (pihole) și că funcționează perfect. pe gazda mea Linux (nu pe pihole), dar nu pe MBP, domeniul de căutare DNS nu este aplicat unei comenzi ping doar pentru gazdă. Chiar nu am idee ce altceva pot schimba pentru ca acest lucru să funcționeze.
HenryAZ
- 9 ianuarie 2010
- Congresul de Sud AZ
- 23 mai 2021
v654321 a spus: Dacă nu îmi lipsește altceva, aș îndrăzni să trag concluzia că, având în vedere că atât gazda Linux, cât și MBP își primesc informațiile IP și DNS în mod identic de la același DHCP, că contactează același server DNS (pihole) și că funcționează perfect pe gazda mea Linux (nu pe pihole), dar nu pe MBP, domeniul de căutare DNS nu este aplicat unei comenzi ping doar pentru gazdă. Chiar nu am idee ce altceva pot schimba pentru ca acest lucru să funcționeze.
Aș risca să ghicesc că implementarea NetBIOS de către macOS nu este la fel de robustă ca celelalte două, care sunt capabile să se rezolve doar având în vedere numele gazdei. Ai NetBIOS activat pe Mac? Este implicit. Nu cred că calea de căutare contează cu adevărat, că Windows și Linux fac rezoluția numelui NetBIOS pentru numele gazdei pentru a obține adresa IP, mai degrabă decât DNS.
Cu unbound, ai luxul de a-l folosi ca solutor de validare, pentru zonele exterioare, fără a fi nevoie să înaintați cereri. Și ca soluție pentru o zonă locală.
Posturi Populare