☰

dig는 DNS 서버에서 올바른 결과를 얻었지만 이름은 여전히 ​​확인되지 않습니다.

tag-icon • tag-icon domain-name-system mac-osx
dig는 DNS 서버에서 올바른 결과를 얻었지만 이름은 여전히 ​​확인되지 않습니다.

어떤 조건에서 다음이 발생합니까? 내부 네트워크의 특정 OSX 머신에서:

$~ cat /etc/resolv.conf
nameserver 10.102.120.7
nameserver 10.102.120.2

동일한 머신에서:

$~ dig @10.102.120.7 in.local
<snip> ...
;; QUESTION SECTION:
;in.local.                      IN      A

;; ANSWER SECTION:
in.local.               43200   IN      A       10.102.123.30
<snip> ...

그러나 이 워크스테이션은 in.local을 핑할 수 없으며 해당 시스템의 Apache가 호스팅하는 페이지를 로드할 수도 없습니다. 10.102.123.30은 확실히 작동 중입니다(내가 아는 OSX 시스템 2대는 in.local에서 해결되지 않지만 네트워크의 다른 시스템에서는 가능함). 또한 /etc/hosts를 검사하여 간섭할 수 있는 것이 있는지 확인했습니다. 그 밖에 무엇을 확인해야 할지 잘 모르겠습니다...

답변1

tld .local는 MacOS X에서 Multicast DNS Bonjour/Rendezvous에 의해 먼저 확인됩니다. 즉, tld와 함께 DNS 서버를 사용하려고 하면 .localDNS 서버를 사용하여 해결되지 않습니다.

일부 개인 네트워크에서는 공용 인터넷에서 유효한 최상위 도메인이 아니더라도 내부 DNS 서버에 등록된 호스트에 대해 ".local" 도메인을 사용하기도 합니다. Mac이 이러한 네트워크에 연결된 경우 "www"와 같은 호스트 이름을 조회하는 것과 같은 방식으로 유니캐스트 DNS를 사용하여 DNS 서버와 통신하여 ".local"로 끝나는 호스트 이름을 조회하도록 할 수 있습니다. .apple.com"을 인터넷에서 사용하세요.

보다:http://support.apple.com/kb/HT3473 그리고:http://support.apple.com/kb/TA20999

답변2

OS X에는 Solaris/linux/bsd의 nscd와 같이 플러시해야 할 수 있는 OS 수준 DNS 캐시가 있습니다.

dscacheutil -flushcache(Leopard에서) 또는 (10.5.1 및 이전 버전에서)을 시도해 보세요 lookupd -flushcache.

답변3

방금 그 이유를 발견했습니다..LOCAL을 사용하는 것은 나쁜 생각입니다..

답변4

내가 생각할 수 있는 유일한 것은 이름 서비스에 DNS를 사용하지 않거나 이름이 캐시된다는 것입니다.

저는 Linux에 더 익숙하지만 OSX의 /etc/에 해당하는 파일이나 캐싱 데몬(Linux의 nscd) 구성(nscd.conf) 또는 상태에서 nsswitch.conf(또는 이에 상응하는) 파일을 찾고 있을 수도 있습니다.

nsswitch.conf는 이름 확인 방법을 제어합니다. DNS는 하나의 메커니즘일 뿐입니다. 다른 것에는 파일(/etc/host), LDAP 및 (제 생각에는) NIS가 포함됩니다.

nscd는 동일한 이름에 대한 반복 요청을 받을 때(예: 웹 서버에서 300페이지를 로드하는 경우) 적절한 시간 동안(예: dig 출력 예에서 43200초) 응답을 캐시하여 이름을 더 빠르게 확인하는 데 도움이 되는 이름 캐시입니다.

관련 정보