왜 보조 DNS 서버가 있어야합니까?


26

매우 혼란 스러워요.

기본적으로 DNS 작동 방식을 이해합니다. 다음은 내가 이해하는 데 어려움이있는 것을 설명하는 데 도움이되는 예입니다.

지금은 작은 웹 서버를 운영하고 있습니다. 공급자의 DNS 관리자를 사용하므로 컴퓨터에 호스트 된 DNS 서버가 없습니다.

호스트의 DNS를 사용하지 않고 서버에 DNS 서버를 설정하기로 결정했습니다. 가상 시나리오 : 내 서버 (전체) 서버가 다운 됨-DNS 포함 백업 DNS가 필요한 이유는 무엇입니까? 서버가 다운 된 경우 누가 DNS 서버가 다운 된 경우에도 DNS가 다운 된 경우 (충돌 된 서버에 있지 않은 경우에도) 서버가 중단되어 요청을 전달할 수 없다는 점을 고려하여 내려가는?

보조 DNS가 있어야 DNS 서버가 가리키는 IP 주소를 변경할 수 있으므로 웹 서버가 다운 된 경우 트래픽을 백업으로 리디렉션 할 수 있습니까? 주 DNS 공급자를 사용할 수없는 경우 보조 공급자로 어떻게 전환 하시겠습니까? 백업 DNS 시스템은 기본적으로 항상 가동됩니까? 어떻게 구성되어 있습니까? 서버에있는 DNS 서버의 정확한 복제본입니까? 그들은 동시에 실행됩니까?

잘만되면 누군가 내가 끊은 것을보고 지침을 제공 할 수 있기를 바랍니다.


답변:


26

보조 DNS 서버를 보유 할 때의 주요 요점은 도메인을 처리하는 기본 DNS 서버가 다운되는 경우 백업하는 것입니다. 이 경우, 서버는 여전히 가동 중이므로 백업을하지 않아도 서버에 접속할 수없는 고객은 손실 된 고객 (예 : 실제 돈)을 많이 소비 할 수 없습니다.

보조 DNS 서버는 항상 작동하며 서비스 할 준비가되었습니다. 정보를 얻을 수있는 권위있는 장소가 두 개 이상 있으므로 네트워크의로드 균형을 조정할 수 있습니다. 업데이트는 일반적으로 마스터 DNS에서 자동으로 수행됩니다. 따라서 마스터의 정확한 복제본입니다.

일반적으로 DNS 서버에는 단일 서버보다 많은 정보가 포함되어 있으며 메일 라우팅 정보, 많은 호스트에 대한 정보, 메일 스팸 키 등을 포함 할 수 있습니다. 따라서 복원력과 중복성은 도메인 보유자에게 확실한 이점입니다.

이것이 귀하의 이해를 돕기를 바랍니다.


일반적으로 메일 서버에서 MX 레코드가 해결되지 않으면 메시지가 완전히 거부되지 않고 다시 시도하기 위해 큐에 저장됩니다. 따라서 메일 서버 및 / 또는 MX DNS 레코드가 다운되면 메일 관점 ...하지만 여전히 다른 모든 방법으로 망했다!
William

13

보조 DNS가있는 시점

아주 작은 조직 만이 단일 서버에서 모든 것을 수행 할 수 있습니다. 서버가 많으며 웹 서버가 다운 되어도 전자 메일을 계속 작동시킬 수 있기를 원합니다. 인터넷 연결이 끊긴 경우에도 계속 유지하려는 외부 네트워크에 호스팅 된 서비스가 있습니다.

백업 DNS 시스템은 기본적으로 항상 가동됩니까?

보통.

어떻게 구성되어 있습니까?

DNS 서버 소프트웨어에 따라 다르지만 일반적으로 '백업 서버'에 따라 보조 서버로 설정됩니다. 그런 다음 마스터 서버의 IP와 복제하려는 영역을 알려줍니다.


11

RFC의 필수 요소입니다. 참조 http://www.ietf.org/rfc/rfc1035.txt를

4 페이지에서 중요한 내용을 인용하려면 :

DNS를 사용하려면 모든 영역을 둘 이상의 이름 서버에서 중복 지원해야합니다. 지정된 보조 서버는 DNS의 영역 전송 프로토콜을 사용하여 영역을 확보하고 기본 서버에서 업데이트를 확인할 수 있습니다.


10

백업 DNS 서버 (하나 이상)는 기본 DNS 서버의 슬레이브입니다. 기본 DNS 서버에 대한 변경 사항은 슬레이브에 의해 선택됩니다. 이는 정기적으로 또는 주 서버의 알림에 대한 응답으로 수행 될 수 있습니다. 인터넷을 통해 인식되는 DNS 변경이 지연되는 원인 중 하나입니다. 기본 및 백업 이름 서버가 도메인의 이름 서버로 표시됩니다.

DNS 알림 전에 슬레이브 네임 서버는 일정 기간 동안 이전 버전의 DNS 데이터를 가지고있었습니다. (이것은 일련 번호의 목적 중 하나입니다.) 모든 네임 서버가 동일한 버전 (동일한 일련 번호)으로 업데이트되면 모두 동일한 데이터를 가져야합니다. 일련 번호를 늘리지 않고 영역 파일을 편집하면 데이터가 일치하지 않을 수 있습니다.

백업 DNS 서버로 전환되지 않습니다. DNS 요청은 모든 네임 서버에 비교적 고르게 분배됩니다. 라운드 로빈 일정을 사용하여 서버를 쿼리하면됩니다. 하나 이상의 이름 서버가 다운되면 시간 초과 후 다른 이름 서버에서 요청이 재 시도됩니다. 네임 서버 중 하나가 가동되면 도메인이 (때로는 느리게) 해결됩니다. 모든 네임 서버를 항상 가동 시키길 원합니다.

귀하의 경우, ISP 또는 도메인 등록 기관을 사용하여 도메인을 호스트하는 것이 더 간단하다는 것을 알 수 있습니다. 여기에는 하나 이상의 백업 이름 서버가 있으며 이들을 계속 실행하기위한 전용 리소스가 있습니다.


웹 서버 만 실행하면 보조 DNS가 그렇게 중요하지 않을 수 있습니다. 그러나 서버가 다운되면 다음을 포함하여 백업 DNS 서버를 원하는 여러 가지 이유가 있습니다.

  • 호스트에 핑 또는 추적 경로를 설정하여 호스트가 다운되었는지 확인합니다.
  • 사용자와 크롤러가 도메인을 더 이상 사용하지 않는 것을 방지합니다.

도메인에서 이메일을 받거나 보내면 신뢰성을 설정하고 향후 이메일을 전달할 수 있도록 백업 DNS가 필요합니다. 메일 서버가 도메인을 조회하고 존재하지 않는 것을 발견하면 즉시 이메일을 반송합니다. 그러나 DNS 조회가 성공하고 서버가 다운 된 경우 나중에 배달 할 수 있도록 이메일이 대기합니다. 며칠 동안 다운 된 경우에만 이메일이 수신 거부됩니다. (잘 작동하지 않는 자동화 된 배달 시스템은 한 번만 시도하며 서버가 작동하더라도 메시지를 배달하지 못할 수 있습니다.)


1

자동 백업으로 전환 할 필요가 없습니다. 도메인 내 이름에 대한 DNS 요청이 서버에 쿼리 (DNS가 너무 많이 사용됨)되는 한 기본 NS 서버가 응답하지 않으면 보조 NS 서버가 쿼리됩니다.

귀하가 제공하는 서비스를 호스팅하는 서버에서 DNS를 호스팅하는 경우 2를 갖는 것이 합리적입니다. 하나가 다운되면 다른 하나가 픽업되고 도메인을 계속 사용할 수 있습니다.


나는 (ISP에 의해 사용되는 것과 같은) 많은 실제 DNS 캐싱 서비스를 나타냅니다 꽤 많은 코멘트를 읽었 하지 않는 첫 번째 서버가 응답하지 않는 경우 두 번째 이름 서버를 사용하여 다시 시도를, 그들은 단지 실패합니다. 예를 들어 serverfault에 대한 답변입니다 . 이 경우 두 개의 개별 네임 서버가있는 경우 중 하나가 작동 중인지 확인해야합니다. 중 하나가 다운되면 호스트 된 도메인의 가동 중지 시간이 발생할 수 있기 때문입니다. 이것은 일반적인 관행 RFC 에 위배 되지만 우려되는 것처럼 보입니다.
thomasrutter

1

위의 것 외에도 :

RFC에 두 번째 DNS 서버가 필요하다는 사실 외에도 업스트림 리졸버의 부정적인 캐싱을 피하는 것이 좋습니다. 요청이 어떤 레코드 (NXDOMAIN) 와도 일치하지 않았거나 dns 서버를 찾을 수 없다는 사실을 캐시하는 것이 일반적입니다.

일부 ISP는 캐싱 정책이 일반적이지 않으므로 웹 서버가 다운 된 경우에도 해당 요청에 응답하는 두 번째 DNS 서버를 사용하는 것이 좋습니다. 이렇게하면 서버가 다시 실행되면 부정적인 캐싱의 영향을 피할 수 있습니다.

참고 : 일반적으로 네거티브 캐시 간격은 최대입니다. 5 분이 제안됩니다 (그러나 일부 ISP는 실제로 미친 가치가 있습니다)


1

귀하가 옳습니다-귀하의 상황에서 제 3 자 보조 기관이 필요하지 않으며 다른 모든 서비스 (메일 포함)가 여전히 단일 상자에 단일 상자에 호스팅되어 있다면 개선이 거의 없습니다. 회로망.

예, 기본 및 보조는 서로 옆에서 실행됩니다. 둘 다 동일한 정보를 가져야하지만 실제로는 정보의 일관성이 보장되지는 않습니다. 외부인의 관점에서 볼 때 기본 서버와 보조 서버 사이에는 차이가 없으며 둘 다 동일하게 간주되며 일반적으로 주어진 해상도에 대해 하나만 사용됩니다. 하나가 다운되면 다른 하나가 시도됩니다. 모든 고객이 뉴욕에 있다면 도쿄에 서버 중 하나를 두는 것이 좋지 않을 것입니다. 서버가 예쁘기 때문에 평균 해상도 (예 : 나쁜 것)의 대기 시간이 증가하기 때문입니다. 훨씬 무작위로 선택되었습니다.

DNS 사양에서는 도메인에 대해 적어도 두 개의 NS 레코드가 제공되어야하므로 도메인에 대해 단일 NS 레코드 만 설정하는 경우 이름을 확인하지 못하는 일부 해결 프로그램이 실행될 수 있습니다.

보조 타사 DNS 서비스의 오해에 대한 좋은 개요는 djbdns의 작성자 인 DJB가 제공합니다.

http://cr.yp.to/djbdns/third-party.html

페이지에서 요약 인용문을 보자.

결론적으로, 대다수의 사이트에서 타사 DNS 서비스는 타사 HTTP 서비스 및 타사 SMTP 서비스와 마찬가지로 심각한 비용과 무시할만한 이점이 있습니다. 서비스 회사의 주장은 과장되어 상식을 대신 할 수 없습니다.


-6

실제로, 대부분의 세계에서 백업 DNS 서버는 기본 서버가 다운되면 쿼리되지 않습니다. 리졸버를위한 추가 단계이기 때문입니다. 그것은 그 일을하고 싶지 않으며, 그렇게하지 않을 것입니다.

그래서 우리를 쓸모없는 백업. 기본 서버가 다운되면 사용자 DNS 쿼리는 아무 것도 반환하지 않습니다 (사용 가능한 DNS 서버가 있고 이름 레코드에 나열되고 예비 서버가 대기중인 경우에도). 서버를 찾을 수없는 사용자

시도 해봐.


5
나는 당신이 무엇을 말하는지 정말로 모른다. 당신은 정말로 DNS가 어떻게 작동하는지 이해하지 못하는 것 같다. 클라이언트 시스템은 영역에 권한이있는 서버가 아닌 캐싱 DNS 서버를 가리켜 야합니다. 내가 알고있는 모든 일반적인 DNS 서버 서버는 기본 구성으로 기본 서버를 사용할 수없는 경우 다른 이름 서버에 액세스하려고 시도합니다. DNS 서버 중 하나가 잘못 구성되어 있으면 장애 조치되지 않을 수 있습니다.
Zoredache
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.