DNS 프로토콜이 백업 이름 서버 또는 메일 서버 레코드와 같은 백업 A 레코드 서버 주소를 자연스럽게 보유 할 수있는 방법이 있습니까? 이것을 검색 할 때 백업 이름 서버 (NS 레코드)에서만 결과를 보았습니다.
DNS가 백업 A 레코드를 지원할 수있는 방법이 없다면 결과를 시뮬레이션하는 가장 좋은 방법은 무엇입니까?
DNS 프로토콜이 백업 이름 서버 또는 메일 서버 레코드와 같은 백업 A 레코드 서버 주소를 자연스럽게 보유 할 수있는 방법이 있습니까? 이것을 검색 할 때 백업 이름 서버 (NS 레코드)에서만 결과를 보았습니다.
DNS가 백업 A 레코드를 지원할 수있는 방법이 없다면 결과를 시뮬레이션하는 가장 좋은 방법은 무엇입니까?
답변:
예 ... 일종의.
여기서 수행 할 수있는 두 가지 작업이 있습니다. 주어진 이름에 대해 여러 개의 A 레코드를 DNS 서버에 저장하면 모두 해당 레코드가 클라이언트에 제공되며 해당 클라이언트는 연결할 세트에서 하나를 선택하여 트래픽이 발생합니다. 모든 사이트에 동시에 "공평하게"균등하게 분배하십시오. 이것은 실제로 당신이 묘사하는 것처럼 보이지는 않지만 일반적인 상황입니다 (다양한 이유로 그것을 믿지는 않지만).
다른 옵션은 DNS 서버에 하나의 A 레코드 만 넣고 DNS 서버 (또는 모니터링 스크립트와 같은 보조 항목)는 사이트의 기본 주소를 주시하고 실패하면 DNS 서버의 A를 감시하는 것입니다 레코드가 다른 사이트로 변경됩니다. 이는 한 번에 하나의 사이트 만 트래픽을 얻는다는 것을 의미합니다.
이 두 번째 전략의 단점은 DNS 캐싱입니다. 이전 사이트 주소를 가진 사람은 이전 주소가 포함 된 DNS 캐시 항목이 제거 될 때까지 SOL이됩니다. 따라서 TTL을 낮게 유지해야하지만 (실제 문제는 아니지만 DNS 인프라의로드를 늘려야하지만) TTL을 준수하지 않는 "악의적 인"DNS 캐시 문제가 여전히 남아 있습니다. 이들은 누구에게나 큰 고통입니다 DNS 항목을 변경해야하는 사람이 있지만 DNS 항목을 "종종"변경해야하는 사람에게는 백만 배나 더 나쁩니다 (귀하의 사이트가 하루에 여러 번 다운되지는 않지만 여전히 ...) 이러한 잘못 작동하는 DNS 캐시 중 하나를 사용하면 사이트가 매우 오랜 기간 동안 "작동 중지 된"것으로 인식되어 결함이있는 DNS 캐시라고 설명합니다 ... Eugh.
요컨대, 사이트에 대해서는 그렇게하지 않을 것입니다. 생각하고있는 모든 위험을 완화 할 수있는 더 좋은 방법이 있기는하지만이를 완화하는 방법에 대한 제안을 원할 경우 해당 위험을 설명해야합니다.
비록 당신이 명시 적으로 썼음에도 불구하고 누구나 WWW 서버에 대해 이야기하고 있다고 생각하는 것
간과되는 진실은 HTTP 서비스 가 예외 이며 이것이 올 때 표준이 아니라는 것입니다. 일반적인 경우에, 그래, 거기에 있다 그래서 그들은 제대로 대체 주 서버에서 백업 서버에 DNS를 통해 클라이언트에 정보를 게시하는 메커니즘. 이 메커니즘은백업 이름 서버 또는 메일 서버와 같은
SRV서비스 클라이언트 가 HTTP 이외의 다른 많은 프로토콜에 사용하는 리소스 레코드 입니다. RFC 2782를 참조하십시오.
SRV리소스 레코드를 사용하면 클라이언트에게 우선 순위와 가중치가있는 서버 목록이 제공되며 우선 순위에 따라 서버를 시도하여 가중치에 따라 동일한 우선 순위를 가진 서버 중에서 선택하고 가중치가 낮은 서버보다 가중치가 높은 서버를 더 자주 선택해야합니다 그들. 따라서 SRV리소스 레코드를 사용하여 서버 관리자는 클라이언트에게 대체 서버가 무엇인지, 우선 순위가 같은 서버 집합에로드를 분산시키는 방법을 클라이언트에 알릴 수 있습니다.
이제 콘텐츠 DNS 서버는 NS우선 순위 및 가중치 정보가없는 자체 리소스 레코드의 특수 유형의 리소스 레코드로 위치 합니다. 마찬가지로 SMTP 릴레이 서버 MX는 우선 순위 정보는 있지만 가중치 정보는없는 고유 한 특수 유형의 리소스 레코드로 위치 합니다. 따라서 콘텐츠 DNS 서버의 경우 대체 및로드 배포 정보를 게시 할 준비가 없습니다. MX리소스 레코드를 사용하는 경우 SMTP 릴레이 서버의 경우 부하 분산 정보를 게시 할 준비가 없습니다.
그러나 SRV현재 가능 MTS가 존재합니다. (첫 번째는 2005 년 이래로 가능해 exim졌습니다 SRV.) 그리고 다른 서비스 프로토콜의 경우, 수하물 MX및 NS자원 기록에 방해받지 않고 SRV채택이 훨씬 더 광범위하고 널리 퍼져 있습니다. 예를 들어 Microsoft Windows 도메인 이 SRV있는 경우 DNS에서 조회를 통해 전체 서비스 뗏목을 찾습니다 . 이 시점에서 10 년 이상이 그랬습니다.
문제는 모든 사람들이 HTTP에 대해 생각하고 있다는 것입니다. HTTP는 지금 2011 년에는 예외 일뿐입니다.
SRV레코드는 서비스를 찾는 정의 된 방법입니다. 또한 메커니즘이 존재하는지와 그것이 무엇인지에 대한 질문도있었습니다. 메커니즘이 존재하며 이것이 메커니즘입니다. 10 년 동안 널리 사용되었습니다.
동적 콘텐츠를 제공하고 있고 동시에 콘텐츠를 제공하는 두 대의 서버를 보유하는 것이 실용적이지 않은 경우 다른 옵션은 DNS에 여러 레코드를 보유하고 백업 서버를 구성하여 연결하려는 클라이언트가 ICMP 포트에 연결할 수 없도록하는 것입니다 ; 어느 시점에서든 주 서버가 다운되면 백업에서 포트 80 블록을 제거하기 만하면 트래픽이 유입되기 시작합니다.
당신이 그것을 할 수있는 유일한 다른 (예산) 방법은 요청에 대해 NAT를 수행하기 위해 별도의 기계 (또는 두 대)를 설정하는 것입니다. 따라서 웹 서버가 죽으면 간단히 NAT 규칙을 제거 할 수 있습니다.
백업 A 레코드는 없지만 임의의 순서로 제공되는 여러 A 레코드가있을 수 있습니다.
대부분의 브라우저는 실패하면 다른 서버를 시도 할 수 있습니다. ( 라운드 로빈 DNS를 통한 웹 복원력 참조 )
VRRP 또는 CARP 가있는 여러 서버가 지원하는 하나의 클러스터 IP 주소를 가질 수 있습니다 . 기본 서버가 실패하면 백업 서버가 주소를 인계합니다.
이것은 상당히 오래된 질문이지만 동적 DNS 및 CDN이라는 두 가지 중요한 기술이 답에 나오지 않았습니다.
DNS 레코드를 거의 실시간으로 수정할 수 있도록 동적 DNS가 설정되므로 서비스 가용성에 따라 모니터링 클라이언트가 퍼블릭 DNS A 레코드에 대한 변경을 트리거 할 수 있습니다. 물론 DNS 호스팅 서비스는 동적 DNS를 지원해야합니다.
CDN은 또한 Cloudflare와 같이 DNS를 전달하는 데 사용될 수 있습니다 (2010 년에 출시 된 것으로 생각합니다).