보안 이점

소개: DNS 보안 위협 및 완화

도메인 이름 시스템의 개방된 분산형 설계와 UDP (사용자 데이터그램 프로토콜) 사용으로 인해 DNS는 다양한 형태의 공격에 취약합니다. 공개 또는 재귀 DNS 리졸버는 수신 패킷을 허용 가능한 소스 IP 주소 집합으로 제한하지 않으므로 특히 위험합니다. Google은 주로 다음과 같은 두 가지 일반적인 유형의 공격을 가장 우려합니다.

  • DNS 캐시 포이즈닝으로 이어지는 스푸핑 공격 합법적인 사이트에서 악성 웹사이트로 사용자를 리디렉션하는 다양한 유형의 DNS 스푸핑 및 위조 공격이 많습니다. 일명 Kaminsky 공격이 포함되며, 이 공격은 공격자가 전체 DNS 영역을 독점적으로 제어합니다.
  • 서비스 거부 (DoS) 공격. 공격자는 리졸버를 대상으로 DDoS 공격을 실행하거나 리졸버를 도용하여 다른 시스템에 DoS 공격을 실행할 수 있습니다. DNS 서버를 사용하여 대규모 DNS 레코드/응답 크기를 악용하여 다른 시스템에 DoS 공격을 시작하는 공격을 증폭 공격이라고 합니다.

각 공격 유형에 관해 아래에서 설명합니다.

중독 공격 캐시

캐시 중독으로 이어질 수 있는 여러 가지 DNS 스푸핑 공격이 있지만 일반적인 시나리오는 다음과 같습니다.

  1. 공격자는 서버가 신뢰할 수 없고 서버 캐시에 있을 가능성이 낮은 도메인 이름에 대해 대상 DNS 리졸버에 여러 쿼리를 전송합니다.
  2. 리졸버는 다른 네임서버(공격자가 예측할 수 있는 IP 주소)로 요청을 전송합니다.
  3. 그동안 공격자는 위임된 네임서버에서 보낸 것처럼 위장된 응답으로 피해자를 플러딩합니다. 응답에는 최종적으로 요청된 도메인을 공격자가 제어하는 IP 주소로 확인하는 레코드가 포함됩니다. 또한 확인된 이름에 대한 응답 레코드를 포함할 수 있고, 더 심각한 경우에는 공격자가 소유한 네임서버에 권한을 위임하여 전체 영역을 제어할 수 있습니다.
  4. 위조된 응답 중 하나가 리졸버의 요청 (예: 쿼리 이름, 유형, ID, 리졸버 소스 포트별)과 일치하고 정품 네임서버의 응답 전에 수신되면 리졸버는 위조된 응답을 수락하고 캐시하고 실제 응답을 삭제합니다.
  5. 보안 침해된 도메인 또는 영역에 대한 향후 쿼리에서는 캐시에서 위조된 DNS 변환으로 응답합니다. 공격자가 위조된 응답에 매우 긴 TTL(수명)을 지정한 경우 위조된 레코드는 새로고침 없이 최대한 오랫동안 캐시에 유지됩니다.

Kaminsky 공격에 관한 우수한 소개는 Kaminsky DNS 취약점에 관한 그림 가이드를 참고하세요.

DoS 및 증폭 공격

DNS 리졸버에는 네트워크 시스템을 저해하는 일반적인 DoS 위협이 적용됩니다. 하지만 증폭 공격은 특히 DNS 리졸버가 리졸버에 더 큰 추가 응답 대역폭을 얻기 위해 리졸버에 대응하는 큰 크기 비율을 사용하는 공격자에게 매력적인 대상이 되기 때문에 특히 중요합니다. EDNS0 (DNS용 확장 메커니즘)을 지원하는 리졸버는 반환할 수 있는 패킷 크기가 매우 크므로 특히 취약합니다.

증폭 시나리오에서는 공격이 다음과 같이 진행됩니다.

  1. 공격자는 위조된 소스 IP 주소를 사용하여 피해자 DNS 서버 쿼리를 전송합니다. 쿼리는 모두 동일한 위조 IP 주소를 사용하는 단일 시스템이나 시스템 네트워크에서 전송될 수 있습니다. 쿼리는 공격자가 원본보다 크기가 훨씬 더 큰 응답(최대 수십 배1)으로 이어진다는 것을 알고 있는 레코드의 쿼리입니다(따라서 이름이 '증폭' 공격).
  2. 피해자 서버는 위조된 요청에서 전달된 소스 IP 주소로 대규모 응답을 보내며, 시스템에 과부하를 주고 DoS 상황을 야기합니다.

완화

DNS 취약점의 표준 시스템 전체 솔루션은 DNSSEC입니다. 하지만 범용 DNS 리졸버가 보편적으로 구현될 때까지는 알려진 위협을 완화하기 위해 독립적으로 몇 가지 조치를 취해야 합니다. 여러 가지 기술이 제안되었습니다. 자세한 내용은 IETF RFC 5452: 위조된 답변에 대한 DNS 복원력 강화 조치를 참고하세요. Google 공개 DNS에서 다음 접근 방식을 구현했으며 사용을 권장합니다.

  • 버퍼 오버플로, 특히 DNS 메시지를 파싱하고 직렬화하는 코드를 기반으로 코드를 보호합니다.
  • 리졸버 자체에 대한 직접적인 DoS 공격으로부터 보호하기 위해 머신 리소스를 초과 프로비저닝합니다. IP 주소는 공격자가 위조하기 쉬우므로 IP 주소 또는 서브넷에 기반하여 쿼리를 차단할 수 없습니다. 이러한 공격을 처리하는 유일한 효과적인 방법은 부하를 흡수하는 것입니다.
  • 간단한 캐시 포이즈닝으로부터 보호하기 위해 응답 패킷 및 네임서버의 신뢰성에 대한 기본 유효성 검사를 구현합니다. 다음은 표준 호환 캐싱 리졸버가 실행해야 하는 표준 메커니즘 및 상태 점검입니다.
  • 메시지에 엔트로피를 추가하여 Kaminsky 공격과 같은 보다 정교한 스푸핑/캐시 포이즈닝 공격 가능성을 줄입니다. 엔트로피를 추가하는 다양한 기법이 있습니다. 아래에는 이러한 각 기법의 이점, 제한사항, 과제가 간단히 설명되어 있으며 Google 공개 DNS에서 이를 구현하는 방법에 관해 설명합니다.
  • 중복 쿼리 삭제: '생일 공격' 가능성을 방지합니다.
  • 비율 제한 요청 - DoS 및 증폭 공격 방지
  • 가장 많은 대역폭을 사용하는 클라이언트 IP의 서비스 모니터링과 요청에 대한 최대 응답 크기 비율을 경험합니다.

DNSSEC

DNSSEC(도메인 이름 보안 확장 프로그램) 표준은 여러 IETF RFC(4033, 4034, 4035, 5155)로 지정됩니다.

네임서버에서 수신된 응답의 진위 여부를 확인하여 DNSSEC 카운터 캐시 포이즈닝 공격을 구현하는 리졸버 각 DNS 영역은 비공개/공개 키 쌍 집합을 유지하며, 각 DNS 레코드에 대해 비공개 키를 사용하여 고유한 디지털 서명을 생성하고 암호화합니다. 그런 다음 해당 공개 키는 상위 영역에 속하는 키로 신뢰 체인을 통해 인증됩니다. DNSSEC 준수 리졸버는 올바른 서명이 없는 응답을 거부합니다. DNSSEC는 실제로 서명이 비공개 키에 액세스하지 않으면 위조가 거의 불가능하므로 응답이 조작되지 않도록 효과적으로 방지합니다.

2013년 1월부터 Google Public DNS는 DNSSEC를 완벽하게 지원합니다. Google은 DNSSEC 형식의 메시지를 수락 및 전달하고 올바른 인증을 위해 응답을 검증합니다. 다른 리졸버도 같은 방법을 사용하는 것이 좋습니다.

또한 IETF RFC 8198: DNSSEC 유효성 검사 캐시의 공격적 사용에 지정된 대로 NSEC 응답을 캐시합니다. 이렇게 하면 DNSSEC를 구현하고 부정적인 답변에 NSEC를 사용하는 네임서버에 대한 NXDOMAIN 쿼리를 줄일 수 있습니다.

클라이언트측 암호화 전송

Google Public DNS는 암호화된 전송 프로토콜인 DNS over HTTPS와 DNS over TLS를 지원합니다. 이러한 프로토콜은 조작, 도청, 스푸핑을 방지하여 클라이언트와 Google Public DNS 간의 개인 정보 보호와 보안을 강화합니다. DNSSEC를 보완하여 엔드 투 엔드 인증된 DNS 조회를 제공합니다.

기본 유효성 검사 구현

일부 DNS 캐시 손상은 의도치 않게 발생할 수 있으며, 악의적인 의도가 없는 경우 요청과 응답 간의 불일치로 인해 발생할 수 있습니다 (예: 네임서버가 잘못 구성되었거나 DNS 소프트웨어의 버그가 원인일 수 있음). 최소한 DNS 리졸버는 네임서버 응답의 신뢰도와 관련성을 확인하기 위해 검사를 수행해야 합니다. 다음 방어책을 모두 적용하고 구현하는 것이 좋습니다.

  • 발신 요청에 재귀 비트를 설정하지 말고 항상 위임 체인을 명시적으로 따라야 합니다. 재귀 비트를 사용 중지하면 리졸버가 '반복' 모드에서 작동하여 다른 네임서버에서 이러한 쿼리를 자동으로 수행하도록 허용하지 않고 위임 체인의 각 네임서버를 명시적으로 쿼리합니다.
  • 의심스러운 응답 메시지 거부 아래에서 '의심스러운' 것으로 간주되는 항목에 대한 자세한 내용을 참조하세요.
  • 이전 요청에서 캐시된 글루 레코드를 기반으로 클라이언트에 A 레코드를 반환하지 않습니다. 예를 들어 ns1.example.com에 대한 클라이언트 쿼리를 수신하면 .com TLD 네임서버에서 반환된 캐시된 글루 레코드를 기반으로 A 레코드를 보내는 대신 주소를 다시 확인해야 합니다.

필수 기준을 충족하지 않는 응답 거부

Google Public DNS는 다음을 모두 거부합니다.

  • 파싱할 수 없거나 잘못된 응답입니다.
  • 키 필드가 요청의 해당 필드와 일치하지 않는 응답입니다. 여기에는 쿼리 ID, 소스 IP, 소스 포트, 대상 IP 또는 쿼리 이름이 포함됩니다. DNS 스푸핑 동작에 대한 자세한 설명은 RFC 5452, 섹션 3을 참조하세요.
  • 요청과 관련 없는 레코드입니다.
  • CNAME 체인을 재구성할 수 없는 답변 레코드입니다.
  • 응답 네임서버를 신뢰할 수 없는 레코드 (답변, 권한, 추가 섹션)입니다. Google은 특정 도메인의 위임 체인에서 네임서버의 '신빙성'을 결정합니다. Google 공개 DNS는 위임 체인 정보를 캐시하며, 캐시된 정보에 대해 수신된 각 응답을 확인하여 특정 요청에 응답하는 응답 네임서버의 신뢰성을 확인합니다.

요청에 엔트로피 추가

리졸버가 기본 상태 확인을 시행하면 공격자가 합법적인 네임서버보다 쿼리 ID, UDP 포트(요청), IP 주소 (응답) 및 원래 요청의 쿼리 이름과 일치시키기 위한 응답으로 응답을 희생해야 합니다.

안타깝게도 이 방법은 어렵지 않습니다. 고유하게 식별할 수 있는 필드인 쿼리 ID는 길이가 16비트에 불과하기 때문입니다 (즉, 1/65,536의 경우 올바르게 일치함). 다른 필드도 범위로 제한되므로 고유한 조합의 총 개수가 비교적 적습니다. 관련 조합의 계산은 RFC 5452, 섹션 7을 참조하세요.

따라서 도전과제는 공격자가 기회 기간 내에 유효한 필드 조합을 성공시키기 어렵게 만들기 위해 DNS 메시지의 표준 형식 내에서 요청 패킷에 최대한 엔트로피를 추가하는 것입니다. 다음 섹션에 설명된 모든 기술을 권장 및 구현했습니다.

Google은 2022년 7월에 DNS OARC 38 컨퍼런스에서 여기에 언급된 기법의 업데이트된 검토를 발표했습니다. 이 프레젠테이션에는 네임서버 연산자를 위한 권장사항도 포함되어 있습니다.

소스 포트 임의 지정

기본 단계로, 발신 요청 패킷이 기본 UDP 포트 53을 사용하거나 여러 포트를 할당하기 위한 예측 가능한 알고리즘(예: 간단한 증분)을 사용하도록 허용하지 마세요. 시스템에서 허용되는 최대 1,024~65,535의 포트를 사용하고 안정적인 난수 생성기를 사용하여 포트를 할당할 수 있습니다. 예를 들어 Google Public DNS는 약 32,000개의 서로 다른 포트 번호를 허용하기 위해 15비트를 사용합니다.

서버가 방화벽, 부하 분산기 또는 네트워크 주소 변환 (NAT)을 실행하는 다른 기기 뒤에 배포되는 경우 이러한 기기는 발신 패킷의 포트를 무작위 순서 지정할 수 있습니다. 포트 무작위 순서 지정을 사용 중지하도록 NAT 기기를 구성해야 합니다.

무작위 네임서버 선택

일부 리졸버는 루트, TLD 또는 다른 네임서버에 요청을 전송할 때 최단 거리 (지연 시간)를 기준으로 네임서버의 IP 주소를 선택합니다. 대상 IP 주소를 무작위로 지정하여 발신 요청에 엔트로피를 추가하는 것이 좋습니다. Google Public DNS에서는 영역별로 구성된 네임서버에서 무작위로 네임서버를 선정하여 빠르고 안정적인 네임서버를 선호합니다.

지연 시간이 우려되는 경우 특정 왕복 지연 시간 (예: 30ms, 300ms) 미만의 주소 범위 내에서의 무작위 순서 지정으로 구성된 왕복 시간 (RTT) 밴딩을 사용할 수 있습니다.

DNS 쿠키

RFC 7873은 64비트 쿠키를 DNS 메시지에 추가하는 EDNS0 옵션을 정의합니다. 클라이언트 지원 DNS 쿠키에는 임의의 64비트 쿠키와 요청 시 (필요한 경우) 서버 쿠키가 포함됩니다. 지원 서버가 요청에서 유효한 쿠키 옵션을 찾으면 클라이언트 쿠키와 올바른 서버 쿠키를 응답에 반영합니다. 그러면 지원 클라이언트에서 응답의 클라이언트 쿠키를 확인하여 예상 서버에서 얻은 응답을 확인할 수 있습니다.

네임서버에서 DNS 쿠키를 지원하지 않으면 다음 두 가지 옵션을 사용하여 엔트로피를 추가할 수 있습니다.

쿼리 이름에서 사례 무작위 지정

DNS 표준에 따라 네임서버에서는 대소문자를 구분하지 않고 이름을 취급해야 합니다. 예를 들어 example.com와 EXAMPLE.COM는 동일한 IP 주소2로 확인됩니다. 또한 소수의 네임서버를 제외한 모든 네임서버가 요청에 표시된 대로 응답의 이름을 원래 사례와 동일하게 유지합니다.

따라서 요청에 엔트로피를 추가하는 또 다른 방법은 도메인 이름을 쿼리하는 대소문자의 문자를 무작위로 변경하는 것입니다. '0x20'이라고도 하는 이 기법은 US-ASCII 문자의 대소문자 표기에 비트 0x20이 사용되기 때문에 먼저 IETF 인터넷 초안 초안에 DNS 라벨에 비트 0x20을 사용하여 트랜잭션 ID를 개선했습니다. 이 기법을 사용하면 네임서버 응답은 쿼리 이름뿐 아니라 이름 문자열에 있는 모든 문자의 대소문자(예: wWw.eXaMpLe.CoM 또는 WwW.ExamPLe.COm)와 일치해야 합니다. 최상위 및 루트 도메인의 쿼리에 엔트로피가 거의 또는 전혀 추가되지 않을 수 있지만 대부분의 호스트 이름에서는 효과가 있습니다.

이 기법을 구현할 때 발견한 한 가지 중요한 문제는 일부 네임서버가 예상 응답 동작을 따르지 않는다는 점입니다.

  • 일부 네임서버는 대소문자를 구분하지 않고 응답합니다. 즉, 요청의 대소문자와 관계없이 동일한 결과를 올바르게 반환하지만 응답은 요청의 정확한 대소문자와 일치하지 않습니다.
  • 다른 네임서버는 완전한 대소문자 구분으로 응답합니다 (DNS 표준 위반). 요청의 대소문자에 따라 완전히 대응하지 않거나 요청에 있는 이름과 정확히 일치하는 잘못된 NXDOMAIN 응답을 반환하는 등 그에 따라 다른 이름을 처리합니다.
  • arpa 영역의 PTR 쿼리를 제외한 일부 네임서버가 올바르게 작동합니다.

두 가지 유형의 네임서버에서 모두 쿼리 이름의 대소문자를 바꾸면 바람직하지 않은 결과가 발생합니다. 첫 번째 그룹의 경우 응답이 위조된 응답과 구분되지 않으며 두 번째 그룹의 응답 (있는 경우)은 완전히 부정확할 수 있습니다.

이 문제를 해결하기 위한 현재의 해결책은 표준을 올바르게 적용하는 것으로 알려진 네임서버에만 무작위 순서 지정을 사용하는 것입니다. 또한 로그 분석을 토대로 각 하위 도메인에 적합한 예외 하위 도메인을 나열합니다. 해당 서버에서 전송된 것으로 보이는 응답에 올바른 대소문자가 포함되어 있지 않으면 응답을 거부합니다. 사용 설정된 네임서버는 Google 발신 트래픽의 70% 이상을 처리합니다.

쿼리 이름 앞에 nonce 라벨 추가

리졸버가 캐시에서 이름을 직접 확인할 수 없거나 권한 네임서버를 직접 쿼리할 수 없으면 루트 또는 TLD 네임서버의 추천을 따라야 합니다. 대부분의 경우 루트 또는 TLD 네임서버에 대한 요청은 이름을 IP 주소로 확인하려고 시도하는 것이 아니라 다른 네임서버를 참조하게 됩니다. 따라서 이러한 쿼리의 경우 존재하지 않는 이름을 확인하는 데 실패하지 않고 요청의 엔트로피를 늘리기 위해 쿼리 이름에 임의의 라벨을 연결하는 것이 안전해야 합니다. 즉, entriih-f10r3.www.google.com와 같은 nonce 라벨이 포함된 이름에 대한 참조 네임서버에 요청을 전송하면 www.google.com에 대한 요청과 동일한 결과가 반환됩니다.

실제로 이러한 요청은 발신 요청의 3% 미만이지만 (대부분의 쿼리는 캐시에서 직접 응답하거나 단일 쿼리로 응답할 수 있기 때문에) 이러한 트래픽은 공격자가 리졸버를 강제로 보내려고 시도하는 요청 유형입니다. 따라서 이 기법은 Kaminsky 스타일의 악용을 방지하는 데 매우 효과적일 수 있습니다.

이 기법을 구현하려면 추천으로 이어지는 것이 보장된 요청, 즉 응답 섹션에 기록이 포함되지 않은 요청에만 nonce 라벨을 사용해야 합니다. 그러나 이러한 요청의 집합을 정의하려고 할 때 다음과 같은 몇 가지 문제가 발생했습니다.

  • 일부 국가 코드 TLD (ccTLD) 네임서버는 실제로 다른 2차 TLD (2LD)에 대해 권한이 적용됩니다. 두 개의 라벨이 있지만 2LD가 TLD처럼 동작하기 때문에 ccTLD 네임서버에서 처리하는 경우가 많습니다. 예를 들어 .uk 네임서버는 mod.uk 및 nic.uk 영역에 대한 권한도 있으므로 이러한 영역에 포함된 호스트 이름(예: www.nic.uk, www.mod.uk)입니다. 즉, 이러한 호스트 이름의 해결을 위해 ccTLD 네임서버에 요청하면 추천은 발생하지 않지만 공신력 있는 답변으로 이어집니다. 호스트 이름에 nonce 라벨을 추가하면 이름을 확인할 수 없습니다.
  • 일반 TLD (gTLD) 네임서버는 네임서버에 대한 신뢰할 수 없는 응답을 반환하는 경우가 있습니다. 즉, 도메인의 영역이 아닌 gTLD 영역에 상주하는 일부 네임서버 호스트 이름이 있습니다. gTLD는 데이터베이스에 반환되는 모든 레코드 레코드를 사용하여 이러한 호스트 이름에 대한 신뢰할 수 없는 답변을 반환합니다. 예를 들어 네임서버 ns3.indexonlineserver.com는 indexonlineserver.com 영역이 아닌 .COM gTLD 영역에 있었습니다. Google에서 n3.indexonlineserver.com에 대한 gTLD 서버에 요청을 전송했을 때 추천 대신 IP 주소를 얻었습니다. 하지만 앞에 nonce 라벨을 추가한 경우 indexonlineserver.com을 추천하여 호스트 이름을 확인할 수 없습니다. 따라서 gTLD 서버의 확인을 요구하는 네임서버에는 nonce 라벨을 추가할 수 없습니다.
  • 영역 및 호스트 이름의 권한은 시간이 지남에 따라 변경됩니다. 이로 인해 위임 체인이 변경되면 한때 해결 가능했던 nonce가 추가된 호스트 이름이 결정되지 않을 수 있습니다.

이러한 문제를 해결하기 위해 nonce 라벨을 추가할 수 없는 호스트 이름의 예외를 구성했습니다. 서버 로그에 따라 TLD 네임서버에서 비참조 응답을 반환하는 호스트 이름입니다. Google은 예외 목록이 지속적으로 유효한지 확인하기 위해 지속적으로 검토합니다.

중복 쿼리 삭제

DNS 리졸버는 '생일 공격'에 취약합니다. 이 때문에 일치 가능성에 많은 입력값이 필요하지는 않는 수학적 패러다임은 악용되기 때문입니다. 생일 공격에는 피해자에게 위조된 응답뿐만 아니라 초기 쿼리도 플러딩하는 문제가 포함됩니다. 리졸버는 단일 이름 확인을 위해 여러 요청을 실행하는 리졸버를 활용합니다. 발신되는 요청 수가 클수록 공격자가 요청 중 하나를 위조된 응답과 일치시킬 가능성이 커집니다. 공격자는 위조된 응답과 일치하는 경우 50% 성공 확률로 300개의 요청, 100%에 가까운 성공 요청에 700개 요청만 필요합니다.

이 공격 전략을 방지하려면 아웃바운드 큐에서 모든 중복 쿼리를 삭제해야 합니다. 예를 들어 Google Public DNS에서는 동일한 쿼리 이름, 쿼리 유형, 대상 IP 주소에 대해 2개 이상의 미해결 요청을 허용하지 않습니다.

비율 제한 쿼리

서비스 거부 공격을 막으면 개방형 재귀 DNS 리졸버에 몇 가지 특별한 문제가 발생합니다.

  • 재귀 리졸버는 증폭 공격을 시작하는 데 효과적인 타겟입니다. 고용량의 안정적인 서버로, 일반적인 공신력 있는 네임서버보다 응답이 더 클 수 있으며 특히 공격자가 캐시에 대규모 응답을 삽입할 수 있는 경우 유용합니다. 개방형 DNS 서비스의 개발자는 서버가 다른 시스템을 공격하는 데 사용되지 않도록 해야 합니다.
  • 증폭 공격은 발생하는 동안 감지하기 어려울 수 있습니다. 공격자는 수천 개의 개방형 리졸버를 통해 공격을 시작할 수 있으므로 각 리졸버가 전체 쿼리 볼륨의 일부만 보고 보안이 침해되었다는 명확한 신호를 추출할 수 없습니다.
  • 일반 사용자에게 제공되는 DNS 서비스의 중단이나 억지 없이 악성 트래픽을 차단해야 합니다. DNS는 필수 네트워크 서비스이므로 공격을 차단하기 위해 서버를 종료하는 옵션도 없고, 특정 클라이언트 IP에 너무 오랜 시간 동안 서비스를 거부하는 것도 불가능합니다. 리졸버는 공격이 시작되는 즉시 빠르게 차단하고 공격이 종료되는 즉시 완전한 운영 서비스를 복원할 수 있어야 합니다.

DoS 공격을 퇴치하는 가장 좋은 방법은 비율 제한 또는 스로틀링 메커니즘을 적용하는 것입니다. Google Public DNS는 두 가지 종류의 속도 제어를 구현합니다.

  • 다른 네임서버로 전달되는 발신 요청의 비율 제어 리졸버 서버에서 실행될 수 있는 DoS 공격으로부터 다른 DNS 네임서버를 보호하기 위해 Google 공개 DNS는 각 네임서버 IP 주소에 대해 각 제공 클러스터의 발신 요청에 QPS 한도를 적용합니다.

  • 클라이언트에 대한 발신 응답의 비율을 관리합니다. 리졸버 서버에서 실행될 수 있는 증폭 및 기존의 분산 DoS (봇넷) 공격으로부터 다른 시스템을 보호하기 위해 Google 공개 DNS는 클라이언트 쿼리에 대해 두 가지 유형의 비율 제한을 적용합니다.

    • 기존의 볼륨 기반 공격으로부터 보호하기 위해 각 서버는 클라이언트별 IP QPS와 평균 대역폭 한도를 적용합니다.
    • 작은 쿼리에 대한 대규모 응답이 악용되는 증폭 공격을 방지하기 위해 각 서버는 클라이언트별로 IP별 최대 평균 증폭 계수를 적용합니다. 평균 증폭 계수는 서버 로그에서 관찰된 이전 트래픽 패턴에 따라 결정되는 쿼리 대 쿼리 크기의 비율입니다.

    한 소스 IP 주소의 DNS 쿼리가 최대 QPS 비율을 초과하면 초과 쿼리는 삭제됩니다. 한 소스 IP 주소에서 UDP를 통해 DNS 쿼리가 평균 대역폭 또는 증폭 한도를 일관적으로 초과하면(가끔씩 큰 응답이 통과함) 쿼리가 제외되거나 작은 응답만 전송될 수 있습니다. 작은 응답은 오류 응답 또는 잘린 비트가 설정된 빈 응답일 수 있습니다(따라서 대부분의 적법한 쿼리가 TCP를 통해 재시도되고 성공함). 모든 시스템 또는 프로그램이 TCP를 통해 재시도되는 것은 아니며 TCP를 통한 DNS가 클라이언트 측의 방화벽에 의해 차단될 수 있으므로 일부 애플리케이션은 응답이 잘릴 경우 올바르게 작동하지 않을 수 있습니다. 그럼에도 불구하고 잘림을 사용하면 대부분의 경우 RFC 준수 클라이언트가 올바르게 작동합니다.

  1. DNS 증폭 공격 자료를 참조하고 일반적인 문제에 대한 유용한 설명을 확인하세요. ↩

  2. RFC 1034, 3.5항에 설명된 내용은 다음과 같습니다. ಠ

    도메인 이름에서 대문자와 소문자를 사용할 수 있지만 대소문자를 구분하지는 않습니다. 즉, 철자는 같지만 대소문자가 다른 두 이름은 동일한 것처럼 취급됩니다.