CentOS에서 로컬 DNS 캐시를 플러시하는 방법


20

CentOS 6에서 로컬 DNS 캐시를 플러시하는 방법을 찾고 있습니다.

시스템에서 DNS 서버 또는 아무것도 실행하지 않고 있으며 모든 DNS 쿼리가 중복 된 네임 서버에 대해서도 구성된 네임 서버로 보내지도록하고 싶습니다.

내가 온라인에서 찾은 것의 대부분은 나에게 service nscd restart, 재 장전 또는 할 것을 말해줍니다 nscd -i hosts. 그러나 아무도 캐시를 플러시하지 않습니다.

그래서 누군가 내가 어떻게 할 수 있는지에 대한 아이디어가 있는지 궁금합니다. 커널에 뒤집어 야 할 스위치가 있습니까? 모든 종류의 해결 방법도 좋습니다.


캐시가 플러시되었는지 확인하기 위해 무엇을하고 있습니까?
John

좋아, 그것은 조금 복잡하다. 나는 시스템에 포트 53을 수신하고 특정 방식으로 DNS 쿼리를 전달하는 프로그램을 가지고 있으며 localhost를 'DNS 서버'로 사용하는 http 프록시를 가지고있다. 첫 번째 쿼리 (예 wget -e 'http_proxy=localhost:3128' xxx.com:)에서 쿼리가 올바르게 전달되는 것을 볼 수 있지만 모든 후속 쿼리는 그렇지 않습니다. 오래 기다릴 경우 (캐시 만료) 다시 작동합니다.
zee

또한 프록시 (오징어)가 객체를 캐시하지 않도록 구성 했으므로 시스템이 여전히 응답을 캐싱하고 있다고 가정합니다.
zee

1
nscd -i hosts-> 항상 작동합니다. nscd를 3 번 ​​연속으로 다시 시작했는데 캐시를 지우고 싶지 않았습니다.
Danie

nscd는 CentOS 7에서 최소한의 것으로 보이지 않습니다. 질문에 CentOS 6이 필요하다는 것을 알고 있지만 제목에는 일반적으로 CentOS가 있습니다. CentOS 7 방식은 무엇입니까?
duct_tape_coder

답변:


11

DNS 요청을 캐싱하는 로컬 상자가 아니라 캐싱하는 /etc/resolv.conf사람 에서 사용하는 DNS 확인자입니다 .

캐시 된 쿼리가 응답하지 않도록하려면 다음을 수행하십시오.

  1. 리졸버를 변경하십시오.

    $ dig @<resolve-ip> www.google.com

  2. DNS 서버에 액세스 할 수있는 경우 확인자에서 DNS 캐시를 플러시하십시오.

    $ sudo /etc/init.d/bind restart


흠하지만 dns_nameservers 127.0.0.1프록시 구성 파일에 설정 했으며 리스너는 쿼리를 미리 구성된 이름 서버로만 전달합니다. resolv.conf를 참조하지 않아도됩니까?
zee

4
"bash : /etc/init.d/bind : 해당 파일 또는 디렉토리가 없습니다"그리고 OP의 메소드는 "nscd.service를 다시 시작하지 못했습니다 : nscd.service 장치를로드하지 못했습니다 : 해당 파일 또는 디렉토리가 없습니다." 나는 이것들이 움직 였거나 바뀐 것 같아요. 왜 제대로 작동하는 것을 그대로 두거나 최소한 별칭을 유지할 수 없는가? 단순히 리눅스 박스를 사용하기 위해 OS 전문가가되어야 할만큼 나쁘다. 모든 릴리스에서 OS를 다시 학습해야 할 때 더 나쁩니다.
JosephK

3

클라이언트 시스템에서 DNS 캐시를 새로 고치거나 플러시 한 후에도 작동하지 않으면 서버 또는 클라이언트 시스템이 NIS 서버에 바인드되어 있으면 "hosts : files nis dns"를 "hosts : files dns nis"로 변경하십시오. /etc/nsswitch.conf 파일에 항목을 입력하고 NIS 마스터 서버 호스트 목록에서 IP 주소를 변경해야합니다.


이것은 나의 해결책으로 이끌었다. 내부 / etc / hosts는 이전에 정적으로 구성된 이전 IP 주소였습니다. 내가 다시 한 일. 해당 줄을 삭제하거나 새 IP로 바꾸면 문제가 해결되어 호스트 이름을 사용하여 내 컴퓨터를 ping 할 수있었습니다.
Paul

3

나는 그것이 시스템이 응답을 캐싱하는 것이 아니라고 확신합니다. 그 부분 (시스템 캐싱)은 nscd데몬 에서만 처리됩니다 . 데몬을 재시작 (또는 완전히 중지)하면 이름 서비스 요청 응답의 OS 캐싱이 재설정되거나 제거됩니다.

포트 53에서 설정 한 커스텀 리스너가 물을 상당히 진흙탕으로 만들지 만 두 가지 가능성을 제공합니다.

  • A) 시스템이 쿼리 업스트림을 발행하고 있지만 즉시 업스트림 이름 확인자가 설정 또는 레코드의 TTL을 기반으로 응답을 캐싱합니다.
  • B) 사용자 정의 리스너는 내부적으로 응답을 캐싱하고 캐시 시간이 만료되기 전에 다시 요청을 받으면 해당 응답을 시스템에 다시 전달합니다.

입력 주셔서 감사하지만 리스너는 쿼리와 응답을 전달하는 것 외에는 아무것도하지 않습니다. 결국 200 줄의 코드와 같습니다. 따라서 두 번째 사례가되어서는 안됩니다. 또한 청취자는 수신 된 모든 것을 인쇄하므로 실제로 아무것도 얻지 못할 것이라고 확신합니다. ||
zee
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.