Chromium의 기능 중 하나가 루트 DNS 서버에 막대한 로드를 생성합니다.

Google Chrome 및 새로운 Microsoft Edge의 번성하는 오픈 소스 상위 버전인 Chromium 브라우저는 좋은 의도로 의도된 기능으로 인해 상당한 부정적인 관심을 받았습니다. 즉, 사용자의 ISP가 존재하지 않는 도메인 쿼리 결과를 "훔치고" 있는지 확인합니다. .

인트라넷 리디렉션 감지기통계적으로 존재할 가능성이 없는 임의의 "도메인"에 대한 가짜 쿼리를 생성하는 는 전 세계 루트 DNS 서버에서 수신하는 전체 트래픽의 약 절반을 담당합니다. Verisign 엔지니어 Matt Thomas는 다음과 같은 장문의 글을 썼습니다. 게시 APNIC 블로그에서 문제를 설명하고 그 규모를 평가합니다.

DNS 확인이 일반적으로 수행되는 방법

이 서버는 .com, .net 등을 해결하기 위해 연락해야 하는 최고 기관입니다. 그러면 frglxrtmpuf가 TLD(최상위 도메인)가 아님을 알려줄 것입니다.

DNS(도메인 이름 시스템)는 컴퓨터가 arstechnica.com과 같이 기억하기 쉬운 도메인 이름을 3.128.236.93과 같이 사용자 친화적이지 않은 IP 주소로 변환할 수 있는 시스템입니다. DNS가 없다면 인터넷은 사람이 사용할 수 있는 방식으로 존재하지 않을 것입니다. 즉, 상위 수준 인프라에 불필요한 부하가 발생하는 것은 실제 문제입니다.

단일 최신 웹 페이지를 로드하려면 엄청난 수의 DNS 조회가 필요할 수 있습니다. 예를 들어, ESPN의 홈페이지를 분석했을 때 a.espncdn.com에서 z.motads.com에 이르는 93개의 개별 도메인 이름을 계산했습니다. 페이지가 완전히 로드되려면 이들 모두가 필요합니다!

전 세계에 서비스를 제공해야 하는 검색 엔진에 대해 이러한 유형의 작업 부하를 수용하기 위해 DNS는 다단계 계층 구조로 설계되었습니다. 이 피라미드의 맨 위에는 루트 서버가 있습니다. .com과 같은 각 최상위 도메인에는 그 아래의 각 도메인에 대해 가장 높은 권한을 갖는 자체 서버 제품군이 있습니다. 한 단계 위로 이들 서버는 루트 서버 자체입니다. a.root-servers.net 에 m.root-servers.net.

이런 일이 얼마나 자주 발생합니까?

DNS 인프라의 다단계 캐싱 계층 덕분에 전 세계 DNS 쿼리 중 아주 적은 비율이 루트 서버에 도달합니다. 대부분의 사람들은 ISP로부터 직접 DNS 확인자 정보를 얻습니다. 사용자의 장치가 특정 웹사이트에 액세스하는 방법을 알아야 할 경우 먼저 해당 로컬 공급자가 관리하는 DNS 서버로 요청이 전송됩니다. 로컬 DNS 서버가 응답을 모르는 경우 요청을 자체 "전달자"(지정된 경우)로 전달합니다.

로컬 공급자의 DNS 서버나 해당 구성에 지정된 "전달 서버" 모두 캐시된 응답이 없는 경우 요청은 권한 있는 도메인 서버로 직접 제기됩니다. 이상 당신이 변환하려는 것. 언제 домен.com 이는 요청이 도메인 자체의 권한 있는 서버로 전송됨을 의미합니다. com, 위치는 다음과 같습니다. gtld-servers.net.

체계 gtld-servers은(는) 요청이 이루어진 도메인 domain.com에 대한 권한 있는 네임서버 목록과 그러한 네임서버 중 하나의 IP 주소가 포함된 하나 이상의 링크 레코드로 응답합니다. 다음으로, 응답은 체인 아래로 이동합니다. 각 전달자는 응답이 최종적으로 로컬 공급자의 서버와 사용자의 컴퓨터에 도달할 때까지 이러한 응답을 요청한 서버로 전달합니다. 이들 모두는 더 높은 수준의 시스템을 불필요하게 방해하지 않도록 이 응답을 캐시합니다.

대부분의 경우 네임서버 레코드는 다음과 같습니다. domain.com 이러한 전달자 중 하나에 이미 캐시되어 있으므로 루트 서버가 방해받지 않습니다. 그러나 지금은 우리에게 익숙한 URL 유형, 즉 일반 웹사이트로 변환되는 유형에 대해 이야기하고 있습니다. Chrome 요청 수준입니다. 이상 이것은 클러스터 자체의 단계에서 root-servers.net.

Chromium 및 NXDomain 도난 확인

Chromium은 "이 DNS 서버가 나를 속이고 있는 걸까요?"를 확인합니다. Verisign의 루트 DNS 서버 클러스터에 도달하는 모든 트래픽의 거의 절반을 차지합니다.

Google Chrome의 상위 프로젝트인 Chromium 브라우저, 새로운 Microsoft Edge 및 잘 알려지지 않은 수많은 브라우저는 사용자에게 '검색주소창'이라고도 불리는 단일 상자에서 검색의 용이성을 제공하려고 합니다. 즉, 사용자는 브라우저 창 상단에 있는 동일한 텍스트 필드에 실제 URL과 검색 엔진 쿼리를 모두 입력합니다. 단순화를 향한 또 다른 단계를 수행하면 사용자가 URL의 일부를 입력하도록 강요하지 않습니다. http:// 또는 https://.

편리한 만큼 이 접근 방식을 사용하려면 브라우저가 URL로 간주되어야 하는 것과 검색어로 간주되어야 하는 것을 이해해야 합니다. 대부분의 경우 이는 매우 분명합니다. 예를 들어 공백이 있는 문자열은 URL이 될 수 없습니다. 그러나 실제 웹사이트를 해결하기 위해 개인 최상위 도메인을 사용할 수도 있는 개인 네트워크인 인트라넷을 고려하면 상황이 더욱 까다로워질 수 있습니다.

회사 인트라넷 사용자가 "마케팅"을 입력하고 회사 인트라넷에 동일한 이름의 내부 웹사이트가 있는 경우 Chromium은 사용자에게 "마케팅"을 검색할지 아니면 다음으로 이동할지 묻는 정보 상자를 표시합니다. https://marketing. 그렇지 않을 수도 있지만, 많은 ISP와 공용 Wi-Fi 제공업체는 철자가 틀린 모든 URL을 "하이재킹"하여 사용자를 배너가 가득한 페이지로 리디렉션합니다.

무작위 생성

Chromium 개발자는 일반 네트워크의 사용자가 단일 단어를 검색할 때마다 의미를 묻는 정보 상자를 보는 것을 원하지 않았기 때문에 테스트를 구현했습니다. 브라우저를 시작하거나 네트워크를 변경할 때 Chromium은 세 개의 네트워크에서 DNS 조회를 수행합니다. 무작위로 생성된 "도메인" 최상위 수준, 길이는 XNUMX~XNUMX자입니다. 이러한 요청 중 두 개가 동일한 IP 주소로 반환되면 Chromium은 로컬 네트워크가 오류를 '하이재킹'하고 있다고 가정합니다. NXDOMAIN를 수신해야 하므로 브라우저는 추가 공지가 있을 때까지 입력된 모든 단일 단어 쿼리를 검색 시도로 간주합니다.

불행하게도 네트워크에서는 아니 DNS 쿼리 결과를 훔치는 경우, 이 세 가지 작업은 일반적으로 루트 이름 서버 자체까지 맨 위로 올라갑니다. 로컬 서버는 해결 방법을 모릅니다. qwajuixk, 따라서 이 요청을 전달자에게 전달합니다. 전달자는 최종적으로 a.root-servers.net 또는 그의 "형제" 중 한 명이 "죄송하지만 이것은 영역이 아닙니다"라고 말하도록 강요받지 않습니다.

길이가 1,67~10자인 대략 21*XNUMX^XNUMX개의 가짜 도메인 이름이 있기 때문에 가장 일반적인 각 "정직한" 네트워크에서 수행된 이러한 테스트를 통해 루트 서버에 도달합니다. 이 정도다. 반 클러스터의 해당 부분의 통계에 따라 루트 DNS의 총 로드에서 root-servers.net, 이는 Verisign 소유입니다.

역사는 반복된다

최선의 의도로 만들어진 프로젝트는 이번이 처음이 아니다. 실패한 또는 불필요한 트래픽으로 인해 공공 리소스가 넘칠 뻔한 상황은 2000년대 중반 D-Link와 Poul-Henning Kamp의 NTP(Network Time Protocol) 서버의 길고 슬픈 역사를 즉시 상기시켰습니다.

2005년에 덴마크의 유일한 Stratum 1 Network Time Protocol 서버를 소유하고 있는 FreeBSD 개발자 Poul-Henning은 전송된 트래픽에 대해 예상치 못한 대규모 청구서를 받았습니다. 간단히 말해서, 그 이유는 D-Link 개발자가 Kampa 서버를 포함한 Stratum 1 NTP 서버의 주소를 회사의 스위치, 라우터 및 액세스 포인트 제품군의 펌웨어에 썼기 때문입니다. 이로 인해 Kampa의 서버 트래픽이 즉시 9배 증가하여 덴마크 인터넷 교환소(덴마크의 인터넷 교환 지점)의 요금이 "무료"에서 "연간 000달러"로 변경되었습니다.

문제는 D링크 라우터가 너무 많아서가 아니라 '라인 아웃'에 있었다는 점이다. DNS와 마찬가지로 NTP는 계층적 형식으로 작동해야 합니다. Stratum 0 서버는 정보를 Stratum 1 서버에 전달하고, Stratum 2 서버는 정보를 계층 구조 아래로 전달합니다. NTP 서버 주소로 프로그래밍된 D-Link와 같은 일반적인 홈 라우터, 스위치 또는 액세스 포인트는 Stratum 2 또는 Stratum 3 서버에 요청을 보냅니다.

아마도 최선의 의도로 Chromium 프로젝트는 DNS 문제에서 NTP 문제를 복제하여 결코 처리할 수 없는 요청을 인터넷 루트 서버에 로드했습니다.

빠른 해결이 기대됩니다

Chromium 프로젝트에는 오픈 소스가 있습니다. 버그, 이 문제를 해결하려면 기본적으로 인트라넷 리디렉션 감지기를 비활성화해야 합니다. Chromium 프로젝트에 대한 공로를 인정해야 합니다. 버그가 발견되었습니다. 전에Verisign의 Matt Thomas가 어떻게 그의 작품으로 그에게 많은 관심을 불러일으켰는가? 단식 APNIC 블로그에서. 이 버그는 XNUMX월에 발견되었지만 Thomas가 게시할 때까지 잊혀진 채로 남아 있었습니다. 금식 후 그는 면밀한 감독을 받기 시작했습니다.

문제가 곧 해결되어 루트 DNS 서버가 더 이상 매일 약 60억 건의 가짜 쿼리에 응답할 필요가 없기를 바랍니다.

광고의 권리에

에픽 서버 -가요 Windows의 VPS 또는 강력한 AMD EPYC 제품군 프로세서와 매우 빠른 Intel NVMe 드라이브를 갖춘 Linux. 서둘러 주문하세요!

출처 : habr.com