10월 12일 DNS 보안키 교체, 이용자보다 운영기관이 확인할 일입니다

10월 12일 새벽 인터넷의 보안키가 바뀐다는 안내를 보고 휴대전화 비밀번호부터 바꿀 필요는 없다. 이번 일정의 핵심은 개인 계정이 아니라, 도메인 이름을 실제 인터넷 주소로 바꿔 주는 DNS 서버의 검증 설정이다. 한국인터넷진흥원(KISA)이 사전 점검을 요청한 대상도 국내 캐시 DNS 운영기관이다.

KISA의 9월 7일 안내에 따르면 루트 존의 키서명키(KSK) 교체는 한국 표준시로 2026년 10월 12일 오전 1시에 예정돼 있다. 국제인터넷주소기구(ICANN)와 인터넷주소관리기구(IANA)의 자료에 적힌 10월 11일은 한국 날짜와 충돌하지 않는다. 한국에서 운영 일정을 잡는다면 시간대까지 함께 적어야 한다.

10월 7일 확인한 공식 자료상 이번 교체는 아직 예정된 작업이다. 전국 인터넷 장애가 이미 발생했다는 소식도, 모든 이용자가 접속 설정을 바꿔야 한다는 공지도 아니다. 대부분의 이용자는 영향을 받지 않을 것으로 예상되지만, 준비되지 않은 검증 서버를 쓰는 경우에는 주소 조회 실패가 발생할 수 있다는 것이 안내의 요지다.

바뀌는 것은 내 비밀번호가 아니라 DNS 신뢰의 기준이다

웹 주소를 입력했을 때 DNS는 해당 도메인의 주소 정보를 찾는 역할을 한다. 그 조회 체계의 맨 위인 루트 존에는 .kr, .com 같은 최상위도메인을 찾아가는 데 필요한 정보가 있다. DNSSEC는 DNS 응답의 서명을 검증해 정보가 변조되지 않았는지 확인하도록 하는 확장 기술이다.

여기서 KSK는 이름 그대로 다른 키에 서명하는 키다. ICANN의 기술 안내는 루트 존의 일반 데이터를 서명하는 존서명키(ZSK)와, 이 키들을 포함한 루트 키 집합에 서명하는 KSK를 구분한다. 따라서 이번 교체를 웹사이트 로그인 암호나 와이파이 비밀번호를 일괄 변경하는 일로 이해하면 대상부터 달라진다.

DNSSEC 검증 서버는 신뢰 앵커라고 부르는 기준 키 또는 키 식별 정보를 가지고 검증을 시작한다. 새 KSK를 신뢰하도록 준비돼 있어야 교체 뒤에도 이 연결을 이어갈 수 있다. 이용자가 암호키를 따로 내려받아 휴대전화에 넣는 절차가 아니라, 해당 검증 서버의 운영자가 확인해야 하는 설정이다.

38696이 보이는지, 실제로 신뢰하는지가 핵심이다

새 키의 이름은 KSK-2024, 키 태그는 38696이다. IANA는 이 키가 2025년 1월 11일부터 루트 존에 미리 공개됐다고 설명한다. 기존 KSK-2017의 키 태그는 20326이다. 두 이름의 연도는 이번 교체가 이미 그해에 끝났다는 뜻이 아니다.

특히 “새 키가 기존 키와 함께 있었다”와 “새 키가 이미 서명을 맡고 있었다”는 구분해야 한다. 사전 공개 기간에는 새 키를 미리 알아보고 신뢰할 시간을 제공한다. 이번 예정 시점부터 루트 키 집합의 서명을 KSK-2024가 맡고 기존 키는 그 역할을 넘기는 것이 교체의 핵심이다.

ICANN이 9월에 배포한 운영자 안내는 자동 신뢰 앵커 갱신이 성공했을 것이라고 가정하지 말라고 강조한다. 자동 갱신 기능을 켜 놓았거나 소프트웨어를 한 차례 업데이트했다는 기록만으로 점검을 끝내지 말고, 현재 사용 중인 서버에 새 키가 반영돼 있는지 확인해야 한다는 뜻이다.

IANA에 따르면 신뢰 앵커는 자동 갱신 방식, 소프트웨어 공급업체의 업데이트, 운영자의 수동 설정 등 서로 다른 경로로 전달될 수 있다. 어떤 경로가 적용되는지는 제품과 구성에 따라 다르다. 파일 하나의 이름을 모든 장비에 공통으로 적용하거나, 검색으로 찾은 키 문자열을 그대로 붙여 넣는 방식은 이 확인을 대신하지 못한다.

운영자가 남겨야 할 근거도 구체적인 편이 낫다. 어떤 서버와 제품 버전을 확인했는지, 그 서버의 유효한 신뢰 앵커 상태는 무엇인지, 자동 갱신에 필요한 저장 경로와 권한에 문제가 없는지 기록한다. ICANN의 7월 운영자 설명도 새 키가 없을 때 자동 갱신 설정과 저장 디렉터리의 쓰기 권한을 확인하라고 안내한다.

지금 자동 갱신을 켜면 바로 끝나는 것은 아니다

IANA는 RFC 5011 방식이 기존 키로 서명된 새 키를 일정 기간 관찰하면서 신뢰를 형성한다고 설명한다. ICANN의 7월 설명에 따르면 이 관찰 기간은 30일이다. 이미 오래전부터 정상적으로 갱신돼 온 서버와, 교체를 며칠 앞두고 새로 설정을 시작한 서버는 같은 상태가 아니다.

따라서 새 키가 빠져 있는 서버에서 자동 갱신 스위치만 켰다고 이번 일정 전에 준비가 끝난다고 단정할 수 없다. 운영자는 자신의 제품과 버전에 맞는 공식 신뢰 앵커 갱신 절차를 확인해야 한다. 수동 반영이 필요한 경우에도 출처가 검증된 키 자료와 공급업체 지침, 조직의 변경 승인이 먼저다.

KISA는 국내 운영기관에 제품별 차이를 살피라고 당부했고, IANA 역시 공급업체마다 키 배포 방식과 시점이 다르다고 밝힌다. 이 기사는 모든 서버에 통하는 명령어 한 줄을 제시하지 않는다. 같은 이름의 소프트웨어라도 패키지와 운영 환경에 따라 실제 적용 경로가 달라질 수 있기 때문이다.

48시간은 복구 대기 시간이 아니다

교체 직후 웹페이지가 열린다고 해서 준비가 확인된 것은 아니다. DNS 서버는 이전에 받은 정보를 정해진 시간 동안 캐시에 보관한다. ICANN의 기술 안내는 루트 키 집합의 TTL, 즉 캐시 유효기간을 48시간으로 설명한다. 교체 직전에 검증해 둔 정보가 남아 있다면 새 키를 다시 조회하는 시점까지 문제를 드러내지 않을 수 있다.

공식 안내의 “약 48시간 이내”는 이런 지연 가능성을 설명하는 말이다. 장애가 나더라도 이틀만 기다리면 자동으로 고쳐진다는 보증이 아니다. 실제 실패 시점은 캐시와 조회 발생 시점, 서버의 TTL 제한 등 설정에 따라 달라진다. ICANN도 언제 첫 실패를 알아차릴지 정확히 예측할 수 없다고 설명한다.

여러 DNS 서버를 쓰는 환경에서는 증상이 더 헷갈릴 수 있다. 하나는 준비됐고 다른 하나는 준비되지 않았다면 다른 서버로 넘어가면서 지연이 생기거나 접속이 간헐적으로 실패할 수 있다. 같은 주소를 같은 시각에 열어도 어떤 검증 서버를 거쳤는지에 따라 결과가 다를 수 있다는 뜻이다.

이 때문에 운영기관의 확인 범위는 대표 서버 한 대로 끝나지 않는다. 주 DNS와 보조 DNS를 함께 점검하고, 교체 뒤에는 검증 오류와 조회 실패가 늘어나는지 관찰해야 한다. 한 번 성공한 접속 화면은 그 순간의 한 경로가 작동했다는 증거이지 전체 환경이 준비됐다는 증명은 아니다.

노트북은 되는데 업무 프로그램만 안 될 수도 있다

ICANN 안내는 컨테이너 기반 서비스나 별도 DNS-over-HTTPS 설정을 사용하는 프로그램이 운영체제와 다른 DNS 경로를 쓸 수 있다고 설명한다. 회사 노트북의 브라우저가 정상이라는 사실만 확인하면, 다른 서버를 바라보는 업무 프로그램이나 자동화 작업을 놓칠 수 있다.

국내 기업이나 기관이 외부 사업자에게 DNS 운영을 맡겼다면 담당자를 정하고 확인 결과를 받아 두는 방식이 현실적이다. 자체 운영 구간과 위탁 구간을 구분하고, 실제 업무 서비스가 어느 경로를 쓰는지 정리한다. 여기서 필요한 것은 이용자 전원에게 설정 변경을 요구하는 공지가 아니라 관리 책임과 확인 범위가 분명한 운영 점검이다.

• 대상: DNSSEC 검증을 수행하는 서버와 위탁 사업자, 주·보조 경로를 파악한다.
• 상태: 새 키 KSK-2024, 키 태그 38696이 해당 서버에서 유효한 신뢰 앵커로 반영돼 있는지 제품별 공식 방법으로 확인한다.
• 차이: 컨테이너·업무 프로그램·별도 보안 DNS 설정처럼 운영체제와 다른 경로를 쓰는 곳을 점검한다.
• 기록: 점검 시각과 담당자, 적용 상태와 필요한 조치를 남긴다. 교체 직후뿐 아니라 이후의 검증 오류와 조회 실패도 관찰한다.
• 대응: 이상이 생기면 공급업체와 운영기관의 절차를 따른다. 원인 확인 없이 DNSSEC 검증을 상시 꺼 두는 것으로 점검을 대체하지 않는다.

일반 이용자는 무엇을 하면 되나

DNSSEC 검증을 하지 않는 서버나 새 키를 이미 신뢰하도록 준비한 서버를 이용하는 경우, ICANN은 이번 교체에 따른 영향을 예상하지 않는다. 이번 일정만을 이유로 휴대전화·PC를 초기화하거나 로그인 비밀번호를 바꾸고 공유기의 DNS 주소를 임의로 바꿀 필요는 없다. 기관망에서는 관리자의 공식 안내를 우선한다.

실제로 접속 문제가 생겼다면 발생 시각, 영향을 받는 서비스, 이용 중인 네트워크를 기록해 통신사나 기관의 지원 창구에 알리는 것이 도움이 된다. 웹사이트가 열리지 않는다는 증상만으로 이번 키 교체가 원인이라고 단정하지는 않는다. 회선 문제나 서비스 자체 장애 등 다른 원인도 구분해야 한다.

이번 일정은 불특정 이용자에게 새 암호키 설치를 요구하는 계기가 아니라, 운영기관이 평소의 자동 갱신을 실제 상태로 검증할 기회다. 한국 시각 12일 새벽이라는 달력과 38696이라는 식별자를 확인하되, 준비 완료의 근거는 날짜를 아는 데 있지 않다. 자신이 맡은 조회 경로가 새 키를 신뢰하고 있다는 확인에 있다.