요약

  • University of Twente와 SIDN Labs 연구진이 .nl 질의를 재생해 보니 Falcon-512 압축 서명의 중앙값은 655바이트, 고정 길이 패딩 서명은 666바이트였다. 11바이트를 아껴도 완성된 DNSSEC 응답이 연구에서 정한 크기 문턱을 넘는 비율은 거의 달라지지 않았다.
  • 존재하지 않는 이름에 대한 응답에는 서명된 증명 여러 개가 실린다. 분석에 포함된 NXDOMAIN 응답은 모두 1,232바이트와 1,500바이트를 넘었다. 서명 하나의 무게만 재고 배송 성공을 선언할 수는 없다.

택배 상자에 붙인 스티커의 다이어트

문을 통과하지 못하는 대형 택배가 있다. 배송업체가 스티커 무게를 11그램 줄이고는 운송 혁신이라고 발표한다. 상자는 여전히 문 앞에 있다. DNSSEC의 양자내성 서명 형식 논쟁에서도 비슷한 일이 벌어질 수 있다. 서명이 짧아졌다는 수치는 정확해도, 네트워크가 운반하는 것은 이름과 레코드, 여러 서명된 증명까지 담은 응답 전체다.

University of Twente와 SIDN Labs 연구진이 2025년에 발표한 논문은 Falcon-512 서명의 두 형식을 비교했다. 압축 형식은 길이가 변하고 패딩 형식은 666바이트로 고정된다. 실험용 .nl 존에서 압축 서명의 중앙값은 655바이트였다. 11바이트 절약은 사실이다. 연구진은 그 다음 응답 전체를 재서, 1,232바이트와 1,500바이트라는 크기 기준 아래에 들어오는 답이 실제로 늘었는지 확인했다.

실험은 2025년 4월 3일의 .nl 존 파일과 그날 권한 서버에 도착한 질의에 기반했다. 기존 DNSSEC 자료를 제거하고 Falcon-512의 두 형식으로 별도 존을 서명한 뒤, 기록된 질의를 두 NSD 시험 서버에 다시 보냈다. 수집 때와 재생 때 모두 NOERROR였던 응답 59,312,128건과 모두 NXDOMAIN이었던 응답 113,348,878건을 비교했다. 질의 분포는 실제 운영에서 왔지만 Falcon 응답은 실험실에서 생성됐다. 이 구분 덕분에 크기 실험의 의미가 선명해진다. .nl의 실서비스가 이미 Falcon으로 전환했다는 이야기는 아니다.

NOERROR 응답은 대부분 두 형식 모두에서 이미 두 기준 안에 들어왔다. 다만 작지 않은 일부는 경계를 넘었다. 서명되지 않은 하위 도메인의 DS 레코드가 없다는 사실을 증명하려면 서명된 NSEC3 레코드가 추가될 수 있다. 서명 한 장을 조금 얇게 만들어도 증명 한 장이 사라지지는 않는다. 압축 형식은 전체 크기를 약간 줄였지만 경계 안으로 들어오는 응답 수를 의미 있게 늘리지 못했다.

없는 이름을 묻는 NXDOMAIN에서는 결과가 더 단호했다. 분석 대상 응답은 모두 1,232바이트와 1,500바이트를 초과했다. 서명된 NSEC3 레코드 두 개를 담은 응답은 2,2692,420바이트, 세 개를 담은 응답은 3,0753,767바이트였다. 서명이 여러 개면 압축으로 절약되는 총량도 늘어난다. 그러나 3천 바이트를 넘는 택배가 그 정도 절약으로 1천여 바이트짜리 문을 통과하지는 않는다. 배송 크기를 결정한 것은 스티커가 아니라 상자 속 증명의 개수였다.

‘압축’이라는 이름에도 작은 반전이 있다. 시험 존의 서명 9,912,711개 중 하나는 패딩하지 않은 길이가 667바이트였다. 고정 길이 666바이트보다 오히려 한 바이트 길다. 패딩 방식은 서명이 기준을 넘으면 다시 생성한다. 매우 드문 사례이지만, 가변 길이 형식을 구현하는 사람은 중앙값만이 아니라 분포의 끝도 처리해야 한다는 사실을 보여 준다.

논문 저자들은 이 재생 실험에서 압축의 경계 통과 이점이 거의 없으므로, 크기가 일정한 형식이 예측 가능성과 구현 오류 방지 면에서 나을 수 있다고 판단한다. 연구가 측정한 것은 메시지 크기다. CPU, 메모리, 하드웨어, 서명과 검증의 비용 전체를 계산한 것은 아니다. DNSSEC 표준이 이미 정해졌다는 뜻도 아니다. 대신 ‘서명이 작으니 응답 전송도 좋아진다’는 주장을 완성된 응답으로 검증하게 만들었다.

2026년 10월 27일 갱신된 NIST 공식 페이지는 Falcon을 표준화 대상으로 적고 FIPS 206은 개발 중이라고 밝힌다. ICANN의 Paul Hoffman이 낸 개인 Internet-Draft는 DNSSEC 선택에서 레코드 크기, 배포 속도, CPU, 프로토콜 변경, 하드웨어 보안 모듈, 암호 분석, 특허 허가를 함께 살펴야 한다고 적었다. 이 문서는 IETF 표준 절차에서 공식 지위를 갖지 않는다. 그래도 회의 탁자 위에 여러 비용 항목을 한꺼번에 올려놓는 역할은 한다.

RIPE 93 일정에는 Ginevra Fabrizio의 이 연구 발표가 10월 29일로 잡혀 있다. 오늘은 28일이므로 발표에서 무슨 결론이 나왔다는 식으로 앞질러 쓸 수 없다. 이미 공개된 논문만으로도 질문은 충분하다. 어떤 존과 질의를 썼나? 전체 응답이 몇 바이트였나? TCP로 돌아간 경우는 얼마나 되나? 구현 비용은 누가 감당하나? 스티커의 다이어트 광고를 보려면 상자를 먼저 문에 넣어야 한다.

무엇을 재느냐가 표준을 지배한다

표준 회의는 표에 깔끔하게 들어가는 숫자를 좋아한다. 서명 중앙값이 그렇다. DNS 응답에는 도메인 이름의 길이, 위임 상태, 질의 종류와 부존재 증명이 섞인다. 연구진은 이름 길이의 변동 폭이 압축 서명 길이의 변동 폭과 비슷한 규모라고 지적했다. 보기 좋은 단일 수치가 실제 응답의 대표 선수가 되기 어려운 이유다.

작동하는 네트워크를 우선한다는 말은 여기서 소박한 작업 지시다. 관측된 질의로 제안을 시험하고 완전한 응답 크기의 분포를 공개하라. 부품을 줄여도 전송 경계를 못 바꿨다면 성과의 범위를 그만큼만 말하라. 기술적 권위를 중앙값에만 맡기면, 운영자가 들고 가는 상자는 의사결정에서 사라진다.