v654321
오리지널 포스터- 2011년 8월 6일
- 벨기에 빌보르데
- 2021년 5월 22일
문제 설명: 내 MBP는 바인딩되지 않은 DNS 확인자와 함께 Pi-hole을 사용하여 DHCP를 통해 할당된 IP 주소를 받고 있습니다. 나는 내부 도메인 이름 'home.arpa'를 사용하고 내 DNS 서버의 IP(192.168.1.4)를 포함하여 DNS 검색 도메인으로 추가됩니다. 내 네트워크의 각 장치에는 호스트 이름이 있습니다.
내 Linux 및 Windows 시스템에서 검색 도메인이 자동으로 추가될 때 FQDN(예: ap12.home.arpa 또는 kodi.home.arpa)과 호스트 이름 자체(예: ap12 또는 kodi)를 모두 사용하여 동일한 장치에 완벽하게 ping할 수 있습니다. . 그러나 내 MBP에서는 검색 도메인이 존재하지 않거나 무시되는 것처럼 작동하지 않습니다. FQDN을 완벽하게 ping할 수 있지만 호스트 이름 자체는 항상 실패합니다. DNS 구성에서 처리해야 하기 때문에 이 호스트 이름 또는 FQDN을 사용하여 /private/etc/hosts 파일을 프로비저닝하지 않았습니다(내 비 MacOS 컴퓨터에서도 수행). 고정 IP 구성(고정 IP, DNS 및 DNS 검색 도메인 모두)으로도 시도했지만 차이는 없습니다.
이것이 감사하지 않다면 사과하지만 구성 및 핑 결과와 함께 Windows, Linux 및 MacOS Big Sur의 일부 스크린샷을 추가했습니다.
윈도우 10:
미디어 항목 보기 '>
리눅스:
미디어 항목 보기 '>
MacOS 빅서:
미디어 항목 보기 '>
내 인터넷 검색에서 밝혀진 바에 따르면 검색 도메인은 과거에 여러 사용자에게 발생한 문제인 것으로 보이지만 이것을 구조적 문제로 만든 스레드를 찾지 못했습니다. VPN(분할 터널링 DNS) 또는 누락/잘못된 검색 도메인에 연결된 경우가 대부분이었습니다. 적절한 구성으로 모든 것이 작동하는 것으로 간주된다는 결론을 내렸습니다.
나는 당신 중 일부가 내가 무엇을 잘못했는지 또는 이것을 완화하기 위해 무엇을 할 수 있는지 알아낼 수 있도록 안내/도움을 줄 수 있기를 조용히 바랍니다. 분명히 호스트 이름/FQDN을 /private/etc/hosts 파일에 하드코딩할 수 있지만 많은 컴퓨터와 VM을 가지고 놀기 때문에 완전히 자동화된 DNS 확인에 의존할 수 있기를 바랍니다.
잠재적인 관심/참여에 미리 감사드립니다!
헨리AZ
- 2010년 1월 9일
- 사우스 콩그레스 AZ
- 2021년 5월 22일
v654321은 다음과 같이 말했습니다: 문제 설명: 내 MBP는 바인딩되지 않은 DNS 확인자와 함께 Pi-hole을 사용하여 DHCP를 통해 할당된 IP 주소를 받고 있습니다. 나는 내부 도메인 이름 'home.arpa'를 사용하고 내 DNS 서버의 IP(192.168.1.4)를 포함하여 DNS 검색 도메인으로 추가됩니다. 내 네트워크의 각 장치에는 호스트 이름이 있습니다.
192.168.1.4에서 바인딩되지 않은 home.arpa에 대해 구성된 로컬 영역이 있습니까? V
v654321
오리지널 포스터- 2011년 8월 6일
- 벨기에 빌보르데
- 2021년 5월 23일
home.arpa 내부 도메인은 파이홀 웹 인터페이스에서 구성됩니다. 원래 설정 설명이 완전하지 않았을 수 있습니다. 이에 대해 사과드립니다.
내 모든 컴퓨터에 구성된 DNS 서버는 파이홀 IP 주소이며, 캐시에 요청된 도메인이 없고 사전 구성된 차단 목록에도 없는 경우 이를 언바운드 서비스(파이홀의 localhost에서 실행)로 전달합니다. 그런 다음 외부 도메인에 필요한 IP가 수신될 때까지 DNS 루트 서버에 연락하여 TLD DNS 서버 등을 식별합니다. 이것은 파이홀 웹 인터페이스에서 수행되기 때문에 언바운드에는 로컬 영역 구성이 필요하지 않습니다. 나는 다음을 사용했다 설정 가이드 그리고 그 편지를 따랐다. MBP만 호스트 이름 조회에 실패하고 다른 모든 시스템은 완벽하게 작동합니다.
Linux에서 다음 명령을 실행하면 완벽하게 작동합니다(kodi는 검색 도메인과 함께 자동으로 확장되므로 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 그 결과 파이홀에 다음과 같은 로그가 생성됩니다.
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 그러나 내 MBP에서 동일한 작업을 수행합니다.
% 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 그 결과 파이홀에 다음과 같은 로그가 생성됩니다.
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 이는 두 번째 요청이 올바르게 처리되는 동안 검색 도메인이 자동으로 FQDN(kodi.home.arpa)이 되도록 추가되지 않기 때문에 MBP에서 첫 번째 ping 시도가 실패함을 보여줍니다. 두 요청 모두 파이홀에 도달하지만 DHCP에서 제공하는 IP 구성에 있음에도 불구하고 검색 도메인이 적용되지 않습니다.
다른 것을 놓치고 있지 않다면 감히 Linux 호스트와 MBP가 모두 동일한 DHCP에서 IP 및 DNS 정보를 동일하게 가져오고 동일한 DNS 서버(파이홀)에 연결하고 완벽하게 작동한다고 결론지을 수 있습니다. 내 Linux 호스트(파이홀 아님)에서는 MBP가 아닌 호스트 전용 ping 명령에 DNS 검색 도메인이 적용되지 않습니다. 이 작업을 수행하기 위해 무엇을 변경할 수 있는지 정말 모르겠습니다.
헨리AZ
- 2010년 1월 9일
- 사우스 콩그레스 AZ
- 2021년 5월 23일
v654321은 다음과 같이 말했습니다: 다른 것을 놓치고 있지 않는 한, Linux 호스트와 MBP가 모두 동일한 DHCP에서 IP 및 DNS 정보를 동일하게 가져오고 동일한 DNS 서버(파이홀)에 연결하고 내 Linux 호스트(파이홀 아님)에서는 완벽하게 작동하지만 MBP에서는 작동하지 않습니다. DNS 검색 도메인은 호스트 전용 ping 명령에 적용되지 않습니다. 이 작업을 수행하기 위해 무엇을 변경할 수 있는지 정말 모르겠습니다.
macOS의 NetBIOS 구현은 호스트 이름만 주어진 상태에서 해결할 수 있는 다른 두 가지만큼 강력하지 않다고 추측할 위험이 있습니다. Mac에서 NetBIOS가 활성화되어 있습니까? 기본 설정입니다. Windows와 Linux가 DNS가 아닌 IP 주소를 얻기 위해 호스트 이름의 NetBIOS 이름 확인을 수행하고 있다는 점에서 검색 경로가 실제로 중요하다고 생각하지 않습니다.
언바운드를 사용하면 요청을 전달할 필요 없이 외부 영역에 대해 검증 확인자로 사용할 수 있습니다. 그리고 로컬 영역에 대한 리졸버로.
인기 게시물