Google과 OpenDNS는 DNS 프로토콜에 대한 개선을 제시합니다.

Google 및 OpenDNS, 웹에서 가장 인기있는 두 가지 공개 이름 확인 서비스, 제안하고 구현했습니다 DNS 프로토콜 확장 허용 할 것 속도 향상 콘텐츠 배포 네트워크의 리소스를 사용할 때 탐색.

대규모 콘텐츠 배포 회사는 CDN (Content Delivery Network)이라는 시스템으로 전 세계에 서버를 배포하고 있습니다. 이에 대한 좋은 예는 타사의 파일 저장소 역할을하는 Akamai입니다.

CDN에 사용 가능한 모든 콘텐츠가 복제 된 국가에 서비스를 제공 할 전용 서버가 있다고 가정하면 모든 콘텐츠를 단일 위치에 중앙 집중화하는 것과 비교할 때 얻을 수있는 가장 큰 이점은 이론적으로 콘텐츠에 대한 액세스 시간이 최소화된다는 것입니다. 예를 들어 세비야에있는 사용자는 미국에있는 본사와 통신하는 대신 스페인에있는 서버를 사용하여 통신합니다.

이를 위해 CDN은 요청하는 컴퓨터의 IP 주소를 기반으로 해당 국가 또는 지역에 가장 가까운 콘텐츠 서버의 IP로 출처를 찾고 응답 할 수있는 DNS 시스템을 사용합니다.

그러나 이것은 운영자가 제공하는 DNS를 사용하지 않고 컴퓨터에 Google 또는 OpenDNS와 같은 공용 DNS를 구성하는 네트워크 사용자가 적지 않은 경우 더 이상 이상적이지 않습니다. 기사에 관련된 두 가지 예.

1. 브라우저 바에 웹 페이지 loquesea.eu를 작성합니다.
2. 이름에 해당하는 IP를 모르는 컴퓨터는 구성된 DNS 서버 (1) (운영자 또는 다른 서버)에서 변환을 요청합니다.
3. 이 서버에 캐시가 비어 있다고 가정하면 모든 주소 지정 .eu 공간 (2)을 담당하는 서버를 알려주는 소위 루트 서버에게 도움을 요청해야합니다.
4. 그런 다음 작업이 반복됩니다. 이 경우, 우리가 구성한 DNS 서버는 (3) loquesea.eu라는 이름과 하위 도메인 (예 : linebenchmark.loquesea.eu)을 제어하는 ​​서버에 대한 모든 .eu 이름을 담당하는 서버를 조사합니다. .
5. 마지막으로 마지막 DNS 요청이이 마지막 서버에 이루어지며,이 서버는 loquesea.eu (4)의 IP 주소를 반환하고 첫 번째 인스턴스 (5)에서 쿼리를 시작한 컴퓨터로 전달되어 마지막으로 HTTP를 엽니 다. 세션 및 웹 사이트 다운로드 (6).

보시다시피 네트워크 사용자의 눈에는 투명하게 발생하지만 상당히 복잡한 프로세스입니다.

CDN에 액세스 할 때 DNS 성능 향상

우리가 언급 한 기존 CDN에 대한 DNS 시스템의 문제는 다음과 같습니다. 원하는 목적지의 IP를 얻기위한 DNS 협상이 중간 서버에 의해 수행되기 때문에 CDN은 Google DNS 서버에 대한 요청의 출처로 감지합니다. United States United에 있습니다. 이 경우 CDN은 스페인이 아닌 미국 서버의 IP로 응답합니다. 지연 시간이 증가하여 성능이 저하됩니다.

이를 해결하기 위해에서 제안한 확장을 활용하는 DNS 프로토콜의 수정이 고안되었습니다. RFC 2671 이름 확인을보다 지능적으로 만들 수 있습니다.

라는 아이디어 글로벌 인터넷 속도 향상 그리고 그것은 여전히 초안 단계, 클라이언트의 원래 주소를 돕고 요청에 하나 이상의 데이터 필드로 추가합니다 ( "edns-client-subnet").

실제로 사용자의 프라이버시를 유지하기 위해 전송되는 것은 사용자의 공용 IP 주소 (끝에서 비트가 제거됨)의 일부이므로 1.2.3.4 (사용자의 공용 IP 인 경우)를 보내는 대신 잘립니다. 1.2.3.0 비트 넷 마스크와 함께 24 (모든 중간 DNS 서버가이 정보를 읽을 수 있음)

이를 통해 사용자의 정보가 요청에 데이터로 첨부 될 때 대상 서버가이 새로운 이니셔티브와 호환되면 실제로 원하는 위치를 정확하게 결정할 수 있기 때문에 Google의 DNS를 사용하는 것은 중요하지 않습니다. 콘텐츠에 액세스하고 클라이언트와 가장 가까운 서버로 응답하여 대기 시간을 최소화하고 검색 속도를 향상시킵니다.

프라이버시가 의심되는 사용자를 위해 사용자의 IP 주소의 일부가 전송되지 않도록 구성 할 수 있습니다 (0.0.0.0/0 전송). 이 경우 서비스가 CDN의 기존 DNS처럼 작동한다는 것을 이해합니다. 즉, 실제 출처에 대한 단서가없는 CDN은 요청을 만드는 DNS 서버에 가장 가까운 IP로 응답합니다.

현재 Google과 OpenDNS는 이미이 새로운 기능을 시스템에 설치했으며 CDNetworks, EdgeCast, BitGravity 및 Akamai 자체와 함께 개발하여 초안 작성에 도움이되었습니다.

이것이 네트워크의 실제 성능에 얼마나 큰 영향을 미칠지는 여전히 불분명 해 보이지만 IETF가 현재 초안 버전에서도이 기술을 운영자가 채택 할 수있는 표준으로 채택하는 것은 전혀 불합리하지 않습니다. , 또는 최종.

출처 : 광대역