APNIC · RIR 워치독
스토리
이 RIR과 관련된 BTW 기사와 배경 자료를 확인할 수 있습니다. 제안별 연혁, 관련 인물, 입장의 변화를 보려면 정책 섹션부터 시작하세요.
스토리
최신 스토리
91스토리
스토리
APNIC의 ASPA 인터페이스는 관측된 경로를 검사합니다. 대기(providers) 제공자는 검사할 경로 자체가 없습니다.
APNIC은 새 ASPA 인터페이스에 합리적인 안전장치를 마련했습니다. 보이는 라우팅 데이터에서 제공자를 제안하고, 편집이 BGP 관측자에게 보이는 경로에 미치는 영향을 보여줍니다. 문제가 되는 제공자는 바로 '일부러 아직 보이지 않도록' 계약된 제공자입니다. 대기 링크는 편집기를 경로 검사기에서 미래 권한의 기록으로 바꾸며, 이 변화에는 별도의 근거 기록이 필요합니다.
스토리
APNIC Prop-173, 모든 디렉터리 질의를 약관 동의로 만들지만 응답에는 버전이 없다
수용 가능 사용 정책은 바뀔 수 있지만, 그 정책의 적용을 받은 응답은 수년간 캐시에 남을 수 있다. APNIC의 prop-173은 일반 WHOIS·RDAP·웹 질의를 명확하고 버전 관리된 정책의 적용을 받도록 하고, 서비스를 질의하거나 사용하는 것이 약관 동의임을 밝히게 한다. 모호한 경계에 대한 유용한 수리다. 그러나 초안은 각 응답에 현재 정책 URL만 가리키게 하며, 데이터가 반환될 때 적용된 정책 버전을 응답이 식별하도록 하지는 않는다.
스토리
APNIC가 경로 기록 정렬을 자동화한다. 로드맵은 분쟁 우선순위를 명시하지 않았다
‘정렬(alignment)’은 데이터베이스 정리 작업처럼 들린다. 그러나 APNIC의 2026년 3분기 로드맵에서 이는 더 어려운 의미를 담는다. 자원 보유 기록, 경로 관리 템플릿, Whois 경로 객체, RPKI 인증이 서로 충돌할 때 어떤 상태가 이기는지 결정하고, 기계가 한 상태를 다른 상태보다 선택한 이유를 보여줄 증거를 충분히 남기는 일이다.
스토리
APNIC 62: 일곱 개 제안 중 두 개는 합의 호출 없이 논의 종료
APNIC 62 회의 보고서는 제안들을 승자와 패자로 단순히 나누지 않는다. 세 번째 상태를 유지한다. prop-165와 prop-172는 논의되었지만 합의 호출이 이루어지지 않았다. 이 사실을 허구적 거부로 만들지 않고 다음 공개 상태와 연결해야 한다.
스토리
APNIC, 아틀라스 프로브 60개 배포·23개 설치 보고 — 빠진 단위는 코호트다
상자 속 프로브는 인터넷을 측정할 기회다. 접속되고, 가용성을 유지하며, 사각지대를 메운 프로브는 측정 역량이다. APNIC의 2025년 보고는 배포된 기기 60대와 설치된 23대를 나란히 두지만, 하나가 다른 하나가 되는 과정을 회원에게 보여 줄 결합을 공개하지 않는다.
스토리
APNIC, CentOS 워크스트림 종료 선언. 증거 연쇄에는 여전히 열린 연결이 네 개 남아 있다
APNIC은 명확한 결말선을 내세울 수 있습니다. 2026년 2분기에 수명이 다한 CentOS 호스트에서의 수년에 걸친 이전을 완료했다는 것입니다. 그러나 전체 보안 기록은 그만큼 직선적이지 않습니다. 테스트, 취약점, 분류, 훈련이 각기 다른 보고서에 등장하지만, 공개 증거는 통제의 범위부터 처분과 재테스트까지 전 과정을 좇는 경우가 드뭅니다. 부족한 것은 더 많은 보안 쇼가 아니라 간결한 종료 영수증입니다.
스토리
APNIC 거버넌스 점수는 77%, 모름 평균은 20%
APNIC의 새 설문은 거버넌스에 대해 단 하나의 결론을 내지 않습니다. 여덟 개 문항을 판단할 수 있는 사람들 가운데서 나온 긍정 점수와, 회원들이 판단할 수 없었다는 답이 얼마나 자주 나왔는지를 보여주는 별도의 수치를 함께 제시합니다. 첫 번째 수치를 의사결정에 가져갈 때는 반드시 두 번째 수치도 함께 가져가야 합니다.
스토리
APNIC 허니넷이 기록한 127만 건은 이벤트이지 127만 건의 공격이 아니다
APNIC 62 발표는 의도적으로 노출된 서버 하나를 유용한 보안 도구로 만들었다. 그러나 그 헤드라인은 공격, 공격 이벤트, 이벤트 사이를 오가며, 세 가지 표현이 하나의 숫자를 안전하게 공유할 수는 없다.
스토리
APNIC 선거관리위원회 회피 보호장치, 블로그 댓글에만 존재한다
APNIC은 곤란한 거버넌스 질문에 합리적인 답을 갖고 있다: 재선에 나설 수 있는 집행위원회 위원은 선거를 감시하는 위원회 구성에 관여하지 않는다. 문제는 답이 아니다. 그 답이 어디에 놓여 있는가, 그리고 연례 기록이 최초 명단 작성부터 최종 임명까지 이 보호장치의 작동을 얼마나 보여 주는가이다.
스토리
백업 DNS 계획은 두 번째 리졸버가 아니다
9월 9일 APNIC 블로그의 한 기록은 가정용 장애를 정밀한 인프라 교훈으로 바꿉니다. 회복력은 대안 서비스가 실제로 구동되고, 의존하는 클라이언트에 도달하고, 통제된 실패를 견디고, 롤백될 수 있을 때에만 시작됩니다.
스토리
APNIC과 NIXI는 백분율 하나로 인도 ROV 계획을 닫을 수 없다
9월 8일, APNIC Labs는 인도의 관측된 ROV 필터링을 1.14%로도 6.03%로도 서술할 수 있었습니다. 두 수치는 모두 같은 날짜의 기록에서 나왔습니다. 차이는 창이었고, 바로 그것이 국가 라우팅 보안 약속에 헤드라인 숫자가 아닌 증명서가 필요한 이유입니다.
스토리
스캔으로 APNIC 지역에서 노출된 BGP 라우터 4,611대가 발견됐지만, 포트가 열린 이유는 알 수 없다
APNIC 62에서 연구진은 조용한 제어 평면 문제에 지역 단위 수치를 붙였다. 2026년 2월 IPv4 스캔에서 APNIC 지역 1,343개 AS에 속한 4,611대의 라우터가 요청하지 않은 BGP OPEN 교환에 응답했다. 이는 포트 배너보다 단단한 근거지만 침해 보고도 실시간 목록도 아니다. 빠진 단계는 통지, 운영자 설명, 비교 가능한 재스캔에 대한 기밀 기록이다.
스토리
APNIC의 WHOIS 아카이브, 같은 시간대에 두 개의 총계 기록
마지막으로 완료된 시간대 기록에 따르면 APNIC은 3,192,583건의 WHOIS 질의를 받았습니다. 그 총계 옆에 인쇄된 일곱 개 질의 유형을 모두 더하면 3,183,463이 됩니다. 빠진 다리는 반올림 오류가 아니라 측정의 의미입니다.
스토리
APNIC NIR SIG, 헌장 질문 4개에 답은 미표기 결과 1개
APNIC 62 헌장 검토 자료는 국가 인터넷 레지스트리 7곳에 서로 다른 질문 4개를 던지고, 어떤 질문에 대한 답인지 밝히지 않은 86% 지지 결과 1개만 나란히 제시한다. 제안된 헌장 자체는 여전히 지지받을 만하다. 그러나 NIR SIG가 집행이사회에 의견을 통합해 전달하려면, 독자가 보고된 의견을 그 의견을 만들어낸 조항까지 추적할 수 있는지가 첫 번째 시험이다.
스토리
APNIC 정의 문서 페이지는 초안을 보여주고, 공식 텍스트는 여전히 활성 상태
APNIC는 동일한 용어가 정책 문서를 넘나들며 다른 의미를 갖지 않도록 하나의 정의 문서를 만들었습니다. 그러나 이 문서는 이제 다른 문제에 직면해 있습니다. 웹 페이지의 본문은 버전 004를 초안(DRAFT)으로 제시하고, 안정된 공식 텍스트 주소는 여전히 버전 003을 활성(Active) 상태로 제시합니다. 권위 있는 문서를 재구성할 수는 있지만, 그 정의를 담당해야 할 페이지를 벗어나서만 가능합니다.
스토리
APNIC 재단 liaison 채택, 공개 기록은 프로토콜 이전에서 끊긴다
APNIC은 기관들이 흔히 회피하는 어려운 부분을 해냈습니다. 정해진 범위 없이 오래 방치된 역할을 확인하고, 그 주변의 거버넌스 리스크를 명명하고, 대체 역할을 공식 채택한 것입니다. 다음 단계는 의도적으로 분리되었습니다. 관찰자 참석, 기밀 유지, 정보 공유는 APNIC과 APNIC 재단 간의 운영 프로토콜에 맡겨졌습니다. 이는 타당한 설계일 수 있습니다. 그러나 검토된 공개 기록은 프로토콜이 초안 작성 중인지, 합의되었는지, 사용 중인지, 대체되었는지를 보여주지 않습니다. 얇은 상태…
스토리
APNIC의 NIR RDAP 리다이렉트, 운영자가 아닌 더 세분화된 기록을 가리키다
APNIC에서 NIR 전용 RDAP 호스트로의 리다이렉트는 등록 데이터가 어디에서 제공되는지 보여주는 증거 사슬입니다. 더 세분화된 기록으로 이어질 수 있지만, 현재 누가 네트워크를 라우팅하고 소유하며 운영하는지는 증명하지 않습니다.
스토리
APNIC 레지스트리 API는 각 결과를 요청 항목과 명시적으로 연결하지 않습니다
API 계약에서 작은 필드 하나의 부재가 많은 작업을 다른 곳으로 옮길 수 있습니다. APNIC은 생성·수정·삭제 배치를 받아 각 결과를 `status`와 `message`로 설명하지만, 공개 스키마는 어떤 응답 행이 어떤 요청 항목에 대응하는지 알려 주지 않습니다.
스토리
APNIC Whois에서 mnt-irt는 사고 대응을 가리킨다 — 네트워크 통제가 아니다
필수 연락처 포인터를 네트워크 운영 주체에 대한 선언처럼 보기 쉽습니다. APNIC Whois에서 `mnt-irt`는 더 좁고 더 유용한 의미를 지닙니다. 번호 자원 레지스트리를 보안·어뷰즈 처리에 쓰이는 Incident Response Team(IRT) 객체와 연결합니다. 이 연계는 책임성을 강화하지만, 라우터를 누가 통제하는지, 누가 BGP에서 프리픽스를 오리진하는지, 트래픽을 전송하는지, 법적 소유권을 보유하는지, 사고를 일으켰는지는 식별하지 않습니다.
스토리
APNIC의 API 장애 공지가 레지스트리 API를 명시하지 않은 이유
하이픈 하나가 `api.apnic.net`과 `registry-api.apnic.net`을 구분합니다. APNIC의 8월 5일 장애 공지는 전자와 회원 대면·공개 서비스 5개를 명시했지만, 인터넷 번호 자원 기록의 인증 기반 변경을 담당한다고 공개된 레지스트리 API 호스트는 이름에 넣지 않았습니다. 이 구분은 어느 쪽 서비스가 서로 독립적이었는지를 증명하지 못하며, 'API'라는 표현만으로는 운영 권한을 보고하기에 충분히 정밀한 단위가 아니라는 점만을 보여줍니다.