낮은 DNS 대기 시간은 빠른 인터넷 검색의 핵심입니다. 이를 최소화하려면 DNS 서버를 신중하게 선택하고 익명 릴레이. 하지만 첫 번째 단계는 쓸모 없는 쿼리를 제거하는 것입니다.

이것이 바로 DNS가 원래 캐시 가능성이 높은 프로토콜로 설계된 이유입니다. 영역 관리자는 개별 항목에 대해 TTL(Time to Live)을 설정하고 확인자는 불필요한 트래픽을 피하기 위해 항목을 메모리에 저장할 때 이 정보를 사용합니다.

캐싱이 효과적인가요? 몇 년 전 제가 실시한 작은 연구에 따르면 그것이 완벽하지 않은 것으로 나타났습니다. 현재 상황을 살펴보겠습니다.

내가 패치한 정보를 수집하기 위해 암호화된 DNS 서버 응답의 TTL 값을 저장합니다. 이는 들어오는 각 요청에 대한 레코드의 최소 TTL로 정의됩니다. 이는 실제 트래픽의 TTL 분포에 대한 좋은 개요를 제공하고 개별 요청의 인기도도 고려합니다. 패치된 서버 버전은 몇 시간 동안 작동했습니다.

결과 데이터 세트는 1개의 레코드(이름, qtype, TTL, 타임스탬프)로 구성됩니다. 전체 TTL 분포는 다음과 같습니다(X축은 초 단위의 TTL입니다).

86(주로 SOA 레코드의 경우)의 사소한 충돌을 제외하면 TTL이 낮은 범위에 있다는 것이 매우 분명합니다. 자세히 살펴보겠습니다.

좋습니다. 1시간을 초과하는 TTL은 통계적으로 유의하지 않습니다. 그런 다음 0−3600 범위에 초점을 맞추겠습니다.

대부분의 TTL은 0~15분입니다.

대부분은 0~5분입니다.

별로 좋지 않습니다.

누적 분포는 문제를 더욱 분명하게 만듭니다.

DNS 응답의 절반은 TTL이 1분 이하이고, 5분의 XNUMX은 TTL이 XNUMX분 이하입니다.

하지만 실제로는 더 나쁩니다. 결국 이것은 권한 있는 서버의 TTL입니다. 그러나 클라이언트 확인자(예: 라우터, 로컬 캐시)는 업스트림 확인자로부터 TTL을 수신하며 매초 감소합니다.

따라서 클라이언트는 새 요청을 보내기 전에 평균적으로 원래 TTL의 절반 동안 각 항목을 실제로 사용할 수 있습니다.

이렇게 매우 낮은 TTL은 인기 있는 웹사이트와 API가 아닌 비정상적인 요청에만 적용되는 것이 아닐까요? 살펴보자:

X축은 TTL, Y축은 검색어 인기도입니다.

불행하게도 가장 인기 있는 쿼리는 캐시하기에 최악의 쿼리이기도 합니다.

확대해 보겠습니다.

평결 : 정말 나쁩니다. 예전에도 나빴지만 더 심해졌습니다. DNS 캐싱은 사실상 쓸모가 없게 되었습니다. ISP의 DNS 확인자를 사용하는 사람이 줄어들수록(타당한 이유가 있음) 대기 시간의 증가는 더욱 두드러집니다.

DNS 캐싱은 아무도 방문하지 않는 콘텐츠에만 유용해졌습니다.

또한 소프트웨어가 다른 방법으로 낮은 TTL을 해석합니다.

왜 그럴까요?

DNS 레코드가 이렇게 낮은 TTL로 설정되는 이유는 무엇입니까?

• 레거시 로드 밸런서는 기본 설정으로 남겨졌습니다.
• DNS 로드 밸런싱이 TTL에 의존한다는 신화가 있습니다. (이것은 사실이 아닙니다. Netscape Navigator 시대 이후로 클라이언트는 RR 세트에서 임의의 IP 주소를 선택하고 연결할 수 없는 경우 투명하게 다른 IP 주소를 시도했습니다.)
• 관리자는 변경 사항을 즉시 적용하기를 원하므로 계획하기가 더 쉽습니다.
• DNS 서버 또는 로드 밸런서의 관리자는 자신의 임무가 사용자가 요청한 구성을 효율적으로 배포하는 것이지 사이트와 서비스 속도를 높이는 것이 아니라고 생각합니다.
• 낮은 TTL은 마음의 평화를 제공합니다.
• 사람들은 처음에 테스트를 위해 낮은 TTL을 설정한 다음 이를 변경하는 것을 잊어버립니다.

"장애 조치"는 점점 관련성이 낮아지고 있기 때문에 목록에 포함하지 않았습니다. 다른 모든 것이 완전히 손상되었을 때 오류 페이지를 표시하기 위해 사용자를 다른 네트워크로 리디렉션해야 하는 경우 1분 이상의 지연은 허용될 수 있습니다.

또한 1분 TTL은 권한 있는 DNS 서버가 XNUMX분 이상 차단되면 다른 누구도 종속 서비스에 액세스할 수 없음을 의미합니다. 원인이 구성 오류나 해킹인 경우 중복성은 도움이 되지 않습니다. 반면에 합리적인 TTL을 사용하면 많은 클라이언트가 이전 구성을 계속 사용하고 아무 것도 눈치 채지 못할 것입니다.

CDN 서비스 및 로드 밸런서는 낮은 TTL에 대한 책임이 크며, 특히 CNAME을 낮은 TTL과 결합하고 동일하게 낮은(그러나 독립적인) TTL을 가진 레코드를 결합할 때 더욱 그렇습니다.

$ drill raw.githubusercontent.com
raw.githubusercontent.com.	9	IN	CNAME	github.map.fastly.net.
github.map.fastly.net.	20	IN	A	151.101.128.133
github.map.fastly.net.	20	IN	A	151.101.192.133
github.map.fastly.net.	20	IN	A	151.101.0.133
github.map.fastly.net.	20	IN	A	151.101.64.133

CNAME 또는 A 레코드가 만료될 때마다 새 요청을 보내야 합니다. 둘 다 TTL이 30초이지만 동일하지는 않습니다. 실제 평균 TTL은 15초입니다.

하지만 기다려! 더 나쁩니다. 일부 확인자는 두 개의 낮은 TTL이 관련된 상황에서 매우 잘못 작동합니다.

$ 드릴 raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 CNAME github.map.fastly.net. github.map.fastly.net. 1 151.101.16.133에

Level3 해석기는 아마도 BIND에서 실행될 것입니다. 이 요청을 계속 보내면 항상 TTL 1이 반환됩니다. 기본적으로 raw.githubusercontent.com 캐시되지 않습니다.

다음은 매우 인기 있는 도메인의 이러한 상황에 대한 또 다른 예입니다.

$ drill detectportal.firefox.com @1.1.1.1
detectportal.firefox.com.	25	IN	CNAME	detectportal.prod.mozaws.net.
detectportal.prod.mozaws.net.	26	IN	CNAME	detectportal.firefox.com-v2.edgesuite.net.
detectportal.firefox.com-v2.edgesuite.net.	10668	IN	CNAME	a1089.dscd.akamai.net.
a1089.dscd.akamai.net.	10	IN	A	104.123.50.106
a1089.dscd.akamai.net.	10	IN	A	104.123.50.88

CNAME 레코드가 60개 이상입니다. 아아. 하나는 괜찮은 TTL을 가지고 있지만 완전히 쓸모가 없습니다. 다른 CNAME의 초기 TTL은 XNUMX초이지만 도메인의 경우 akamai.net 최대 TTL은 20초이며 어느 것도 위상이 일치하지 않습니다.

Apple 장치를 지속적으로 폴링하는 도메인은 어떻습니까?

$ drill 1-courier.push.apple.com @4.2.2.2
1-courier.push.apple.com.	1253	IN	CNAME	1.courier-push-apple.com.akadns.net.
1.courier-push-apple.com.akadns.net.	1	IN	CNAME	gb-courier-4.push-apple.com.akadns.net.
gb-courier-4.push-apple.com.akadns.net.	1	IN	A	17.57.146.84
gb-courier-4.push-apple.com.akadns.net.	1	IN	A	17.57.146.85

Firefox와 동일한 문제 및 TTL은 Level1 리졸버를 사용할 때 대부분 3초에서 멈추게 됩니다.

드롭 박스?

$ 드릴 client.dropbox.com @8.8.8.8 client.dropbox.com. 7 CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ 드릴 client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1에 162.125.64.3

녹음 중 safebrowsing.googleapis.com TTL 값은 Facebook 도메인과 마찬가지로 60초입니다. 그리고 다시 클라이언트의 입장에서는 이 값들이 반으로 줄어듭니다.

최소 TTL을 설정하는 것은 어떻습니까?

이름, 요청 유형, TTL 및 원래 저장된 타임스탬프를 사용하여 만료된 캐시 항목으로 인해 전송된 불필요한 요청의 양을 추정하기 위해 캐싱 확인자를 통과하는 1,5만 개의 요청을 시뮬레이션하는 스크립트를 작성했습니다.

요청의 47,4%는 기존 기록이 만료된 후에 이루어졌습니다. 이는 터무니없이 높은 수치입니다.

최소 TTL이 설정된 경우 캐싱에 어떤 영향을 미치나요?

X축은 최소 TTL 값입니다. 이 값을 초과하는 소스 TTL이 있는 레코드는 영향을 받지 않습니다.

Y축은 이미 캐시된 항목이 있지만 만료되어 새 요청을 보내는 클라이언트의 요청 비율입니다.

최소 TTL을 47분으로 설정하면 "추가" 요청 비율이 36%에서 5%로 줄어듭니다. 최소 TTL을 15분으로 설정하면 이러한 요청 수가 29%로 줄어듭니다. 최소 TTL이 1시간이면 TTL이 17%로 줄어듭니다. 확연히 다른!

서버 측에서 아무것도 변경하지 않고 대신 클라이언트 DNS 캐시(라우터, 로컬 확인자)에서 최소 TTL을 설정하는 것은 어떻습니까?

필요한 요청 수는 최소 TTL 47분의 경우 34%에서 5%, 최소 25분의 경우 15%, 최소 13시간의 경우 1%로 감소합니다. 아마도 40분이 최적일 것이다.

이 작은 변화가 미치는 영향은 엄청납니다.

결과는 무엇입니까?

물론 서비스를 새로운 클라우드 제공업체, 새로운 서버, 새로운 네트워크로 이전할 수 있으며, 이때 클라이언트는 최신 DNS 레코드를 사용해야 합니다. 그리고 상당히 작은 TTL은 이러한 전환을 원활하고 눈에 띄지 않게 만드는 데 도움이 됩니다. 그러나 새로운 인프라로 전환하면서 클라이언트가 1분, 5분 또는 15분 이내에 새로운 DNS 레코드로 마이그레이션할 것이라고 기대하는 사람은 아무도 없습니다. 최소 TTL을 40분이 아닌 5분으로 설정해도 사용자가 서비스에 액세스하는 데 방해가 되지 않습니다.

그러나 이렇게 하면 불필요한 요청을 방지하여 대기 시간을 크게 줄이고 개인 정보 보호 및 안정성을 향상할 수 있습니다.

물론 RFC에서는 TTL을 엄격하게 준수해야 한다고 명시하고 있습니다. 하지만 현실은 DNS 시스템이 너무 비효율적이 되어버렸다는 것입니다.

권한 있는 DNS 서버로 작업하는 경우 TTL을 확인하세요. 그렇게 터무니없이 낮은 값이 정말로 필요합니까?

물론 DNS 레코드에 대해 작은 TTL을 설정하는 데는 타당한 이유가 있습니다. 그러나 사실상 변경되지 않은 75%의 DNS 트래픽에는 해당되지 않습니다.

그리고 어떤 이유로든 DNS에 대해 낮은 TTL을 사용해야 하는 경우 동시에 사이트에 캐싱이 활성화되어 있지 않은지 확인하십시오. 같은 이유로.

다음과 같은 로컬 DNS 캐시가 실행 중인 경우 dnscrypt-프록시최소 TTL을 설정할 수 있는 기능을 사용하세요. 이건 괜찮아. 나쁜 일은 일어나지 않을 것입니다. 최소 TTL을 약 40분(2400초) 1시간으로 설정합니다. 상당히 합리적인 범위입니다.

출처 : habr.com