나는 NFS 클라이언트로 형성된 기계에 유령 DNS 검사의 극단적으로 괴괴망측한 문제를 직면했다. 그것은 그것을 해결하는 노력을 확실히 기울였다. 세부사항은 여기 있다.

윤곽
나는 데이타베이스이라고 지명된 NFS & NIS 서버로 형성된 기계가 있다. (인터넷이라고 지명되는) DNS 서버를 숨기기로 형성된 또 다른 기계가 국부적으로 기계를 또한 DNS 해결책을 제공하기 위하여 있고. 모든 NIS (& NFS) 클라이언트는 resolv.conf에서 놓인 정체되는 IP와 DNS 서버로 형성되었다

문제
NIS 클라이언트로 형성된 기계에서, 나는 resolv.conf에서 지정된 DNS 서버로 호스트 이름을 제대로 결심할 수 있었다. 불행히도 나는 데이타베이스 (NFS & NIS 서버) 기계를 위해 호스트 네임을 제대로 결심할 수 없었다. 그것은 guide.opendns.com의 외관상으로는 harcoded IP 주소에 항상 결심했다. 나는 어떤 이득도 없이 클라이언트 기계 뿐만 아니라 NIS 서버를, 재출발했다. 나는 또한 성공 없이 서버 및 클라이언트 기계 둘 다에 있는 호스트 네임 뿐만 아니라 IP 주소를 찾았다.

두번째 문제점은 훨씬 기괴했다. NIS 클라이언트 기계는 제대로 nameserver가 resolv.conf에서 설명될 때라도 yahoo.com 또는 google.com 같이 호스트 네임을 결심하고 있었다! 나는 이름이 시렁에 없고 또는 주인에서 신청하지 않는다는 것을 보증했다.

설명 & 해결책
NIS 클라이언트는 NIS 서버를 통해서 이름을 결심할 수 있다. 나는 이것을 어디에서든지 문서화되어 찾아낼 수 없었다. 나는 실험에 의하여 이 결론에 파생했다. 따라서 비록 당신의 DNS 서버는 resolv.conf에서 설명되더라도, NIS 서버를 사용하여 아직도 결심할 수 있다.

이차적으로 NIS 서버는 호스트 네임과 함께 자체적으로의 IP 주소를 숨긴다. 이 숨겨지은 정보는 DNS 검사에 조차 NIS 클라이언트에 있는 특혜를 얻는다.

해결책은 시렁을 회생하는 NIS 서버에 뒤에 오는 것에 (다시) 이다:
/usr/lib/yp/ypinit - m

PS. 다음 기사에서 나는 수년에 지속한 NIS에 있는 큰 안전 구멍에 대해서 이야기할 것이다. 마지막으로 나는 그것을 적발할 것이다.