요약

  • APNIC에 따르면 2026년 1월 27일 15시 45분부터 1월 28일 09시 45분(UTC+10)까지 Cloudflare 설정의 의도하지 않은 변경이 RDAP에 더 엄격한 브라우저 무결성 검사를 적용했습니다.
  • 그 18시간 동안 일반적인 브라우저 User-Agent 문자열과 유사하지 않은 RDAP 요청의 약 10%가 차단되었습니다.
  • DDoS 및 봇 보호는 정당한 통제입니다. 더 좁은 문제는 RDAP이 머신 클라이언트를 위해 설계되었는데, 브라우저 유사성은 단지 자기 선언적인 소프트웨어 신호일 뿐이라는 점입니다.
  • 9월의 네 건의 저빈도 요청 — User-Agent 없음, 명명된 자동화 문자열, curl 문자열, 브라우저 유사 문자열 — 은 모두 동일한 RDAP JSON을 반환했습니다. 이는 현재 시점의 카나리아이며, 모든 클라이언트나 1월 사건에 대한 증명은 아닙니다.
  • 작은 엣지-오리진 접수증은 WAF 규칙이나 우회 임계값을 공개하지 않고도 지원되는 클라이언트 클래스, 응답 의미론, 롤아웃 및 롤백을 검증할 수 있습니다.

서비스의 잘못된 쪽에 놓인 18시간

APNIC의 서비스 공지는 이례적으로 직접적입니다. 사건은 2026년 1월 27일 화요일 15시 45분에 시작해 1월 28일 수요일 09시 45분에 끝났으며, 모두 UTC+10 기준입니다. 영향을 받은 서비스는 RDAP이었고, 지속 시간은 18시간이었습니다. APNIC은 이 사건을 Cloudflare 설정 변경이 의도치 않게 더 엄격한 브라우저 무결성 검사를 수행한 데서 비롯된 것으로 돌렸습니다. 그 기간 동안 일반적인 브라우저 User-Agent 문자열과 일치하지 않는 User-Agent 문자열을 포함한 요청의 약 10%가 차단되었습니다.

이 설명은 "중단"이라는 단어보다 더 정확하게 하나의 통제 경계를 식별합니다. 어떤 요청은 구문상 RDAP에 적합하고, 올바른 서비스로 향했으며, 소프트웨어답게 행동하는 소프트웨어에 의해 이루어졌음에도, 레지스트리 애플리케이션이 프로토콜 응답을 제공하기 전에 실패할 수 있었습니다. 판별 증거는 자원 보유자의 권한도, 인증된 신원도, 쿼리의 의미적 타당성도, 심지어 그 빈도도 아니었습니다. 호출자의 소프트웨어 레이블이 브라우저처럼 보이는 정도였습니다.

이 구분이 중요한 이유는 엣지 차단과 오리진 오류는 서로 교환할 수 없는 관찰이기 때문입니다. 전자는 요청이 레지스트리 서비스가 판단하기 전에 분류되었음을 말하고, 후자는 서비스가 요청을 받아 결과를 반환했음을 말합니다. 브라우저 형태의 클라이언트만을 검증하는 합성 모니터는 자동화 형태의 클라이언트가 다른 서비스를 보는 동안 정상을 보고할 수 있습니다. 오리진 로그가 깨끗해 보이는 동안 중간 계층이 이미 수요의 일부를 제거했을 수도 있습니다.

APNIC은 이 추정 뒤에 있는 정확한 상태 코드, 챌린지 본문, 위치, User-Agent 값 또는 요청 수를 공개하지 않았습니다. 공지 어디에도 모든 비브라우저 클라이언트가 실패했다거나, 특정 도구가 영향을 받았다거나, 특정 네트워크 결정이 지연되었다는 증명은 없습니다. "요청의 약 10%"가 이용 가능한 분모입니다. 이를 사용자·운영자·애플리케이션 수로 바꾸는 것은 공지에 없는 사실을 만들어내는 일입니다.

가장 강력한 방어는 엣지에 있다

실패한 그 통제에는 강력한 정당성이 있습니다. 공개 레지스트리 조회 서비스는 자동화가 그 목적 중 하나이기 때문에 자동화를 끌어들이지만, 스크래핑, 학대적 빈도, 서비스 거부 트래픽도 끌어들일 수 있습니다. APNIC에는 엔드포인트를 이름으로 부르는 모든 패킷을 단순히 수용하는 것이 아니라 서비스를 사용 가능하게 유지할 의무가 있습니다.

APNIC의 2020년 RDAP 인프라 설명에 따르면rdap.apnic.net및 국가 인터넷 레지스트리 RDAP 서비스의 트래픽은 Cloudflare에 도달하며, Cloudflare는 요청을 Google Cloud의 인프라 쪽으로 프록시하기 전에 로드 밸런싱과 DDoS 보호를 제공합니다. 이 설계는 각 오리진이 모든 요청을 직접 흡수하지 않으면서도 APNIC에 도달성과 복원력을 제공합니다. 따라서 엣지 분류는 서비스 외부의 무관한 계층이 아니라 운영 중인 서비스의 일부입니다.

Cloudflare의 Browser Integrity Check 문서는 관련된 운영 목적을 설명합니다. 이 기능은 학대적 트래픽과 연관된 HTTP 헤더를 검사하고, User-Agent가 없거나 비표준인 요청에 챌린지를 부과할 수 있습니다. 보안 제품이 이상한 헤더 패턴을 하나의 위험 신호로 다루는 것은 합리적입니다. 또한 Cloudflare가 설정 규칙을 통해 이 기능을 선택적으로 범위 제한하거나 비활성화하는 방법을 문서화하고 있다는 점도 유용합니다.

결론은 APNIC이 Cloudflare를 제거하거나, 봇 통제를 끄거나, 필터를 공개하거나, 무제한 쿼리를 허용해야 한다는 것이 아닙니다. 어느 것도 사건에서 도출되지 않습니다. 타당한 질문은 더 작습니다: 머신 프로토콜을 서비스하는 호스트명에서 어떤 클라이언트 클래스가 프로토콜 판독 가능한 결과에 도달해야 하며, 어떤 검증이 브라우저 지향 휴리스틱이 모든 클래스의 입장 규칙이 되지 않았음을 증명하는가?

RDAP은 JSON을 걸친 웹사이트가 아니다

APNIC의 2021년 RDAP 논의는 클라이언트 집단을 브라우저로 환원할 수 없는 이유를 설명합니다. RDAP은 HTTP 또는 HTTPS 위에 구조화된 JSON을 전달합니다. 응답은 기계가 쉽게 파싱할 수 있습니다. 하나의 클라이언트가 대부분의 RDAP 서비스의 응답을 처리할 수 있는데, 이는 전통적 WHOIS에서 물려받은 변이와 대조됩니다. HTTP 캐싱은 반복 검색을 더 효율적으로 만들 수 있습니다.

IETF 사양도 동일한 운영 모델로 이어집니다. RFC 9082는 도메인, 네임서버, 엔티티, IP 네트워크, 자율 시스템 데이터에 대한 균일한 RESTful 조회 패턴을 정의합니다. RFC 7480은 RDAP이 HTTP를 사용하는 방식을 정의합니다. 브라우저도 가능한 클라이언트입니다 — HTTP 사양이 교차 출처 접근을 다루는 것은 바로 브라우저 내 애플리케이션이 존재하기 때문입니다 — 하지만 브라우저는 프로토콜의 특권적 형태가 아닙니다. 명령줄 도구, 라이브러리, 인벤토리 시스템, 어뷰즈 데스크, 레지스트리 간 프로세스는 모두 그래픽 브라우저를 흉내 내지 않고 HTTP를 사용할 수 있습니다.

바로 여기서 1월의 분류기가 서비스의 의미론을 넘어섰습니다. 브라우저 무결성 검사는 대화형 웹 트래픽의 정규 형태를 중심으로 만들어졌습니다. RDAP의 정규 형태에는 무인 프로그램이 포함됩니다. 전자를 후자에 적용하는 것이 반드시 잘못된 RDAP을 거부하는 것은 아닙니다. RDAP이 서비스하도록 만들어진 클라이언트 클래스의 정직한 기술을 거부할 수 있습니다.

"정직"이라는 말을 낭만화해서는 안 됩니다. 봇은 브라우저 유사 헤더를 보낼 수 있고, 선량한 도구는 성긴 헤더를 보낼 수 있습니다. 그것이 바로 요점입니다. 유사성은 정당한 사용의 필요·충분 증거가 아닙니다. 계층화된 점수에 기여할 수는 있지만, 분류 결과가 부여하는 권위를 짊어질 수는 없습니다.

User-Agent는 소프트웨어를 식별하지 권한을 식별하지 않는다

RFC 9110은 User-Agent 필드를 요청을 만드는 소프트웨어에 대한 정보로 기술합니다. 그 문법은 일련의 제품 식별자와 주석입니다. 이 필드는 서버가 응답을 조정하고 상호운용성을 진단하는 데 도움이 됩니다. 클라이언트가 제공하며, 일부 상황에서는 생략할 수 있고, 단순화할 수 있으며, 다른 제품으로 위장할 수도 있습니다.

이 필드는 운영자를 인증하지 않습니다. 그 운영자가 APNIC 회원인지, 연구자인지, 인시던트 대응자인지, 학대적 수집가인지 말해주지 않습니다. 동의, 쿼리 목적, 빈도 권리, 법적 권한을 확립하지 않습니다. 익숙한 브라우저 제품으로 시작하는 문자열이 그런 것들을 부여할 수 없듯이, 작은 스크립트를 명명하는 문자열이 그런 것들을 빼앗을 수도 없습니다.

그래서 User-Agent는 소프트웨어의 유용한 증거이자 권한의 약한 증거입니다. 보호 시스템은 여전히 빈도, 행동, 평판 등 다른 신호와 함께 사용할 수 있습니다. 그러나 엣지가 약한 신호를 하드 게이트로 전환하면, 클라이언트들은 역설적인 교훈을 배웁니다: 머신 프로토콜을 사용하는 신뢰할 수 있는 방법은 브라우저인 척 거짓말하는 것이다. 그러면 분류기는 활용하려던 증거 자체를 파괴합니다. 정직한 자동화는 레이블에서 사라지고, 위험한 트래픽은 허용된 코스튬을 배웁니다.

사건 공지는 이것이 APNIC의 의도된 정책이었다고 말하지 않습니다. 그 효과가 의도치 않았다고 말합니다. 이는 중요한 방어입니다. 이 사건을 동기에 대한 논쟁에서 설정 통제 문제로 전환합니다: 일반적인 보안 기본값 또는 변경이 서비스 계약보다 넓은 범위를 획득한 것입니다.

빈도 제한과 봇 챌린지는 서로 다른 접수증

RDAP은 무제한 사용을 약속하지 않습니다. RFC 7481은 가용성과 서비스 거부 저항을 보안 관심사로 명시적으로 다룹니다. 운영자는 클라이언트를 조절하고, 추가 접근이 적절한 곳에서 인증을 사용하며, 타인을 위한 서비스를 보존하는 통제를 설계할 수 있습니다. RFC 7480은 빈도 제한에 HTTP 429를 권고하며, 클라이언트는 빈도를 낮추고 서버가 제공할 때 Retry-After를 존중해야 합니다.

이러한 의미론은 기계가 그에 따라 행동할 수 있기 때문에 가치가 있습니다. 429는 호출자의 브라우저 유사성이 아니라 요청 빈도가 즉각적인 제약임을 말합니다. Retry-After는 언제 다시 시도하는 것이 합리적인지 말할 수 있습니다. 인증은 공개 접근을 실제로 권한이 확립된 서비스 등급과 분리할 수 있습니다.

이것이 RFC 7480이 APNIC이나 Cloudflare에게 1월 보안 설정의 영향을 받은 모든 요청에 대해 429를 반환할 것을 요구했다는 뜻은 아닙니다. 봇 챌린지와 빈도 제한은 서로 다른 통제이며, 사건 기록은 모든 차단을 분류할 만큼 충분한 응답 세부 정보를 노출하지 않습니다. 더 방어 가능한 추론은 기계 판독 가능한 결과가 클라이언트 클래스별로 가시적으로 유지되어야 한다는 것입니다. 유효한 자동화 요청이 엣지에서 챌린지를 받았다면, 오리진이 알지 못하더라도 서비스 소유자는 그 일이 일어났다는 것을 알아야 합니다.

네 요청은 복구된 순간을 보여줄 뿐

2026년 9월 5일, 작은 카나리아가https://rdap.apnic.net/ip/202.12.29.0을 저빈도로 네 번 조회했습니다. 각 요청은application/rdap+json을 요청했습니다. 하나는 명시적 User-Agent가 없었고, 하나는 목적을 명명한 자동화 User-Agent를 사용했으며, 하나는curl/8.7.1을 사용했습니다. 네 번째는 브라우저 유사의 Mozilla와 Safari 문자열을 사용했습니다.

네 요청 모두 HTTP 200, 콘텐츠 타입application/rdap+json, 3,857바이트 본문을 반환했습니다. 본문 다이제스트는 모든 경우에 동일했습니다:d6983abd9266f7ac6d6a23b8b5cf67c186aae673a64030fc04e4e457837bb853. 응답 헤더는 경로에 Cloudflare가 있음을 보여주었습니다.

이것은 유용한 현재 증거입니다. 그 엔드포인트에서, 그 네트워크 경로로, 그 시각에, 그 빈도로 네 선언된 클라이언트 클래스가 동일한 레지스트리 응답으로 수렴했습니다. 이는 표집된 조건이 현재 재현되지 않는다는 절제된 진술을 뒷받침합니다.

그러나 APNIC의 공지와 독립적으로 역사적 원인을 증명할 수는 없습니다. 모든 엔드포인트, 방법, 지역, 엣지 위치, 소스 네트워크 또는 쿼리 빈도를 검증하지 않았습니다. 클라이언트를 구분하는 다른 규칙이 없다는 것, 또는 미래의 설정 변경이 동등성을 유지할 것임을 증명할 수 없습니다. 카나리아는 타임스탬프가 찍힌 관찰이지 보편적 복구의 증명서가 아닙니다.

서비스 접수증은 보안 규칙보다 가벼울 수 있다

결여된 산출물은 WAF의 공개 사본이 아닙니다. APNIC은 정확한 규칙, 임계값, 평판 입력, 우회 저항 통제를 비공개로 유지할 수 있습니다. 사용자에게 필요한 것은 외부적으로 약속된 서비스 클래스에 대한 증거입니다.

레지스트리가 통제하는 네 개의 카나리아로 시작하십시오: User-Agent 없는 요청, 목적 명명 자동화 클라이언트, 흔한 명령줄 클라이언트, 브라우저. 실제 엣지를 통해 실행하고 엣지 결과와 오리진 결과를 모두 보존하십시오. 상태 클래스, RDAP 콘텐츠 타입, 빈도 제한이 적용되는 곳에서 표준 판독 가능한 재시도 지시의 존재 여부를 기록하십시오. 오리진 이전에 차단된 카나리아는 오리진 전용 성공률 속으로 사라져서는 안 됩니다.

변경 계보를 추가하십시오: 설정 식별자, 범위, 검토자, 롤아웃 시각, 롤백 시각, 검증 시각. 접수증은 민감한 표현식을 명명할 필요가 없습니다. 브라우저 지향 규칙이 RDAP 호스트명 또는 경로 전체를 의도치 않게 지배하지 않음을 증명할 만큼의 범위가 필요합니다. 공격자에게 임계값을 가르치지 않고 할 수 있는 경우, 지원되는 클라이언트 클래스별 집계 차단 비율을 공개하십시오.

APNIC에는 이미 사용자 관점 측정 어휘가 있습니다. 2025년 2분기 레지스트리 가용성 보고서는 RDAP 검사가 5초 미만에서 비오류 HTTP 응답을 생성할 때 성공으로 간주하고, 가용성을 성공 테스트 수를 총 테스트 수로 나눈 값으로 계산한다고 기술합니다. 클라이언트 클래스 차원은 기존 측정을 폐기하지 않고 그 관점을 더 대표적으로 만들 수 있습니다.

APNIC의 2026년 1분기 사무국 업데이트는 모든 핵심 레지스트리 서비스가 99.99% 이상의 가용성을 달성했거나 초과했다고 말합니다. 요약은 그 문장을 RDAP 요청의 추정 비율에 영향을 준 18시간 사건과 조정하는 데 필요한 분모나 상세 방법을 제공하지 않습니다. 그 진술을 거짓이라 선언하는 것은 잘못입니다. 유용한 대응은 측정 조인을 공개하는 것입니다: 어떤 클라이언트 클래스, 어떤 엣지 결과, 어떤 서비스 구간이 그 숫자에 들어가는가.

이 사건이 증명하지 않는 것

여기서 검토된 어떤 증거도 APNIC의 RDAP이 현재 이용 불가능하다는 것, 모든 머신 클라이언트가 차단되었다는 것, 또는 식별 가능한 운영자가 구체적 손실을 입었다는 것을 보여주지 않습니다. 어떤 공개 출처도 정확한 차단 응답, 영향받은 User-Agent 목록 또는 보안 임계값을 제공하지 않습니다. 9월 카나리아는 그 간극을 채우기에는 너무 좁습니다.

또한 이 사건은 APNIC이나 Cloudflare가 RFC를 무시했다는 것을 확립하지 않습니다. 표준은 프로토콜 행동과 유용한 오류 의미론을 정의하며, 운영 보안 통제는 그 주변에 위치하고 현지 판단을 요구합니다. APNIC이 인정한 운영 실패는 의도치 않은 설정 효과였습니다. 책임의 질문은 APNIC이 실행 중인 체인에서 그 효과가 유한하고 탐지 가능함을 입증할 수 있는가입니다.

이 정도면 진지한 결론에 충분합니다. 공개 머신 프로토콜이 자신의 첫 통제 지점을 통과하기 위해 대화형 브라우저로 분장해야 할 필요는 없습니다. 해법은 레이블에 대한 신뢰도, 엣지에 대한 적대감도 아닙니다. 보호, 클라이언트 클래스, 프로토콜 결과를 별도로 관찰 가능하게 유지하는 접수증입니다.

출처

  1. APNIC, 서비스 공지: 2026년 1월 28일
  2. APNIC Blog, A new infrastructure to serve RDAP
  3. APNIC Blog, Is RDAP ready to replace whois?
  4. APNIC Blog, APNIC 레지스트리 서비스 2025년 2분기 가용성
  5. APNIC Blog, APNIC 사무국 2026년 1분기 업데이트
  6. Cloudflare Docs, Browser Integrity Check
  7. RFC 7480, HTTP Usage in RDAP
  8. RFC 7481, Security Services for RDAP
  9. RFC 9082, RDAP Query Format
  10. RFC 9110, HTTP Semantics