DNS 서버가 실패 할 때 DNS 시간 초과 방지

약 100 개의 호스트가 3 개의 내부 DNS 서버 (바인드 9)를 가리키는 작은 데이터 센터가 있습니다. 내부 DNS 서버 중 하나를 사용할 수 없게되면 문제가 발생합니다. 이 시점에서 해당 서버를 가리키는 모든 클라이언트의 성능이 매우 느리게 시작됩니다.

문제는 주식 리눅스 리졸버가 실제로 다른 DNS 서버로 "장애 조치"라는 개념을 가지고 있지 않은 것 같습니다. 사용하는 시간 제한과 재시도 횟수를 조정할 수 있고 (목록을 통해 작동하도록 회전을 설정할 수 있음) 기본 DNS 서버를 사용할 수없는 경우 서비스를 사용하는 설정이 훨씬 느리게 수행됩니다. 현재 이것은 우리에게 가장 큰 서비스 중단 요인 중 하나입니다.

나의 이상적인 대답은 "RTFM : tweak /etc/resolv.conf like this ..."와 같은 것이지만, 이것이 옵션이라면 그것을 보지 못했습니다.

다른 사람들이이 문제를 어떻게 처리했는지 궁금했습니다.

가능한 3 가지 유형의 솔루션을 볼 수 있습니다.

• linux-ha / Pacemaker 및 장애 조치 IP를 사용하십시오 (dns IP VIP는 "항상 사용 가능"). 아아, 우리는 좋은 펜싱 인프라가 없으며 펜싱 장치가 없으면 맥박 조정기가 잘 작동하지 않습니다 (제 경험에 따르면 Pacemaker는 펜싱없이 가용성을 낮 춥니 다).

• 각 노드에서 로컬 dns 서버를 실행하고 resolv.conf가 localhost를 가리 키도록합니다. 이것은 효과가 있지만 모니터링하고 관리 할 수있는 더 많은 서비스를 제공 할 것입니다.

• 각 노드에서 로컬 캐시를 실행하십시오. 사람들은 nscd를 "깨진"것으로 생각하지만 dnrd는 dns 서버를 작동 또는 중지 상태로 표시하고 '작동 중지'dns 서버를 사용하지 않는 올바른 기능을 설정 한 것으로 보입니다.

모든 캐스팅은 IP 라우팅 수준에서만 작동하는 것으로 보이며 서버 오류에 대한 경로 업데이트에 따라 다릅니다. 멀티 캐스팅은 완벽한 해답 인 것처럼 보였지만 bind는 브로드 캐스트 또는 멀티 캐스팅을 지원하지 않으며, 발견 할 수있는 문서는 멀티 캐스트 DNS가 일반 DNS 해결보다는 서비스 검색 및 자동 구성에 더 중점을 둔 것으로 보입니다. .

확실한 해결책이 없습니까?

몇 가지 옵션. 둘 다 DNS로드를 DNS 서버에 분산시킵니다.

• 사용해보십시오 options rotateresolv.conf에서 . 이는 기본 서버 작동 중지의 영향을 최소화합니다. 다른 서버 중 하나가 다운되면 작업 속도가 느려집니다.
• 다른 클라이언트에서 다른 이름 서버 순서를 사용하십시오. 기본 DNS 서버가 다운 된 경우 일부 클라이언트가 정상적으로 실행될 수 있습니다. 이는 서비스 외부 DNS 서버의 영향을 확산시킵니다.

이 옵션들은 options timeout:1 attempts:5 . 시간 초과를 줄이면 시도를 증가시켜 느린 외부 서버를 처리 할 수 ​​있습니다.

라우터 구성에 따라 기본 DNS 서버의 IP 주소가 다운 될 때 DNS 서버를 구성하도록 DNS 서버를 구성 할 수 있습니다. 이것은 위의 기술과 결합 될 수 있습니다.

참고 : 예약되지 않은 DNS 중단없이 몇 년 동안 실행됩니다. 다른 사람들이 지적했듯이, 나는 DNS 서버의 고장을 일으키는 문제를 해결하기 위해 노력할 것입니다. 위의 단계는 연결할 수없는 이름 서버를 지정하여 잘못 구성된 DNS 서버에 도움이됩니다.

"man resolv.conf"를 확인하십시오. resolv.conf에 시간 초과 옵션을 추가 할 수 있습니다. 기본값은 5이지만 resolv.conf에 다음을 추가하면 1 초가됩니다.

옵션 타임 아웃 : 1

하트 비트 또는 페이스 메이커 / corosync와 같은 클러스터링 소프트웨어가 여기에 있습니다. 예를 들어, 다음과 같이 페이스 메이커 / 동기화를 설정했습니다.

• 모든 서버를 다른 서버와 페어링
• 한 쌍당 2 dns Vips, 보통 각각 하나씩
• 바인드 또는 서버가 실패하면 vip는 밀리 초 내에 다른 서버로 이동합니다.

생산 시간은 연중 무휴 24 시간이지만 고객에게 영향을주지 않고 모든 서버가 실패 할 수 있다고 믿습니다. 옵션 회전은 해결 방법 일뿐입니다.

각 노드에서 로컬 dns 서버를 실행하고 resolv.conf가 localhost를 가리 키도록합니다. 이것은 효과가 있지만 모니터링하고 관리 할 수있는 더 많은 서비스를 제공 할 것입니다.

FWIW, 이것은이 문제에 대해 찾은 유일한 실행 가능한 솔루션입니다. 서버가 로컬 호스트에서만 수신하도록 제한해야하지만, 환경에서 DNS 중단을 감지하는 사용자를 완전히 제거했습니다.

한 가지 흥미로운 부작용은 어떤 이유로 로컬 호스트 서버가 다운되면 표준 리졸버 라이브러리가 표준 서버보다 훨씬 빠르게 다음 서버로의 장애 조치를 처리하는 것 같습니다.

지금까지 약 3 년 동안이 작업을 수행해 왔으며 localhost에서 실행중인 DNS 서버의 장애 / 중단과 관련된 단일 문제는 보지 못했습니다.

이름 서버가 유지 보수를 위해 중단되는 경우 유지 보수가 발생할 때 유지 보수 전에 NS 레코드를 제거하고 유지 보수 후에 다시 배치하는 것과 같이 해당 도메인에 대한 SOA의 시간 초과를 미리 줄이는 것이 일반적인 절차입니다 )가 빠르게 전파됩니다. 이것은 서버 측 접근 방식입니다. 리졸버 변경은 클라이언트 측 접근 방식입니다. ... 각 클라이언트와 대화하고 컴퓨터 에서이 조정을 수행 할 수 없다면 ... 올바른 접근 방식. 글쎄, 당신은 내부 DNS 서버를 사용하는 데이터 센터에서 백 클라이언트를 모두 말했지만 실제로 영역을 변경할 수있을 때 백 클라이언트에서 구성을 변경하고 싶습니까?

SOA에서 어떤 값을 조정해야하는지 말씀 드리지만,이 질문에 부딪쳤을 때 정확한 정보를 찾기 위해 웹을 서핑하고있었습니다.

아마도 DNS 서버를로드 밸런서 뒤에 둘 수 있습니까? 분명히 LVS는 UDP의 균형을 맞출 수 있습니다. LB를 고 가용성으로 만들어 단일 장애 지점이되지 않도록하십시오.

나는 이것이 사소한 것처럼 들릴지 모르지만 문제에 대한 영구적 인 해결책으로보다 안정적이고 탄력적 인 DNS 인프라를 구축하는 것은 어떻습니까.

보다 네트워크 중심적인 솔루션은 동일한 (전용) IP 및 Anycast 라우팅을 가진 두 개의 DNS 서버를 사용하는 것 입니다. (지금 까지이 스레드 에서이 답변을 보지 못했지만 여기에서 사용됩니다.)

둘 다 작동하는 한 가장 가까운 서버가 사용됩니다. 하나가 중단되면 해당 IP에 대한 트래픽은 다시 나타날 때까지 다른 노드로 라우팅됩니다. 두 개 이상의 위치 또는 데이터 센터가있는 경우 특히 적합합니다.