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.