요약
- RFC 3130은 1~2일짜리 DNSSEC 워크숍이 성과를 거두지 못하는 이유가 남은 문제들이 시간, 반복 검증, 롤오버, 기관 간 인계에 있기 때문이라고 기록했다.
- 배포 가능성에는 하나의 동작하는 코드베이스 이상이 필요했다. 표준화 절차에는 독립적인 상호운용성과 충분한 성공적 운영 경험이 요구되었는데, 당시 DNSSEC 전체를 진지하게 구현하던 것은 BIND뿐이었다.
- 이 메모는 DNSSEC을 하나의 균질한 도구 상자로 다루지 않았다. 영역 전송용 TSIG는 사용 준비가 될 수 있지만, 전역 서명 검증, 부모-자식 조율, 애플리케이션 활용은 여전히 미성숙할 수 있었다.
2001년, 가장 다루기 어려운 DNSSEC 패킷은 아직 만료되지 않은 패킷이었다.
짧은 테스트 행사에서는 영역을 서명하고, 레코드를 기기 간에 옮기고, 검증에 통과하는 응답을 만들어낼 수 있었다. 참가자들이 형식을 이해했고 구현체가 현행 사양을 따른다는 점을 보여줄 수도 있었다. 그러다 회의장은 비었다. 서명은 여전히 유효했다. 키는 아직 교체되지 않았다. 부모와 자식은 반복되는 인계를 겪어 보지 못했다. 캐시는 관련된 시간 구간을 통과하지 못했다. 시연은 시스템이 시간과 마주치기 전에 성공해 버렸다.
RFC 3130의 가치는 바로 그 증거 공백을 문서화한 데 있다. 이 문서는 제49차 IETF와 함께 진행된 상태 회의를 요약한 Informational 문서였으며, DNSSEC 프로토콜 사양도 아니고 축어록도 아니었다. 참가자들은 연구소, 레지스트리, 지역 주소 기관, 루트 서버 자문단, 정부 프로젝트, 벤더를 대표했다. 그들은 레코드를 인코딩할 수 있는가보다 더 절박해진 질문에 답하려 했다. DNSSEC을 배포할 수 있는가?
보고서의 대답은 예도 아니고 아니오도 아니었다. 기존 테스트가 더 이상 충분하지 않게 되었다는 것이었다.
1999년 이후 워크숍들은 개념과 초기 구현체를 점검해 왔다. RFC 2535가 논의의 핵심 정의를 제공했다. BIND 8.2는 그 일부를 구현했고, BIND 9는 최초의 전체 구현으로 묘사되었다. 그러나 DNSSEC은 널리 쓰이지 않았다. 집단적 묘사가 시사하는 바가 컸다. 중요하고, 유행어이고, 어렵고, 미성숙하다는 것이었다.
처음에는 1~2일짜리 워크숍이 프로토콜과 구현의 결함을 빠르게 발견했다. 제49차 IETF 무렵에는 같은 형식을 반복해도 새로 제기되는 문제의 수가 줄어들고 있었다. RFC 3130은 이를 준비 완성의 증거로 해석하지 않았다. 짧은 워크숍은 도움이 덜 되고 있다고 결론 내렸다. 다음 증거는 지속되는 테스트 구성에서 나와야 했다.
연속성은 관찰 가능한 것을 바꿔 놓았다. 장기 운영 환경은 서명과 키 검증의 만료를 만날 수 있었다. 영역 서명을 한 번 수행하는 대신 반복할 수 있었다. 롤오버 절차가 부모, 현재 영역, 자식 전반에 걸쳐 조율 상태를 유지하는지 시험할 수 있었다. 한 조직이 자기 단계를 완료하고 다른 조직이 완료하지 않을 때 무슨 일이 일어나는지 드러낼 수 있었다. 이것들은 단지 패킷 테스트의 느린 버전이 아니었다. 생명주기 테스트였다.
기관의 지형은 시간 문제를 더 어렵게 만들었다. 한 프로젝트는 네 가지 가능한 당사자를 제시했다. 레지스트리, 등록 대행소, 등록자, DNS 운영사다. 어떤 조직이 여러 역할을 겸할 수도 있고, 역할이 분리될 수도 있었다. 따라서 키 전환은 프로토콜 경계를 넘기 전에 계약, 데이터베이스, 운영 팀을 넘어설 수 있었다. 한 연구소 안에서는 간단해 보이는 절차가 서로 다른 시계와 이해관계를 가진 기관들의 조율을 요구할 수 있었다.
대규모 레지스트리들은 위임된 각 영역의 키에 대한 부모 검증을 어떻게 서비스로 만들 수 있는지 묻고 있었다. NLnet Labs는 롤오버 제안이 계층 전반에 걸쳐 너무 많은 조치를 요구하는지 검토하고 있었다. 루트 서버 자문단은 독립적인 층위에서의 반복 검증을 짧은 행사 안에서 이해할 수 없기 때문에 장기 테스트베드를 원했다. RIR들은 역방향 트리 서명을 고민하고 있었다. 애플리케이션과 일반 IT 부서의 활용은 여전히 증거가 얇은 영역이었다.
보고서는 또한 “DNSSEC”을 하나의 단일 기술로 다루는 관점을 거부했다. 도구 상자로 묘사했다. RFC 2535에 따른 인터넷 규모의 디지털 서명이 한 부분이었다. RFC 2845의 TSIG는 공유 비밀을 사용해 트랜잭션을 보호했고 영역 전송에 실용적 용도가 있었다. RFC 3007의 보안 동적 업데이트는 TSIG에 의존했다. CERT 레코드는 DNS를 통해 보안 데이터를 배포하는 방법을 제공했다. 이 묶음이 다소 인위적이라는 점도 인정되었다.
이 단서가 중요했던 이유는 구성 요소들이 서로 다른 속도로 성숙했기 때문이다. 영역 전송용 TSIG는 보고서가 요컨대 “정말 해볼 만한 좋은 아이디어” 단계에 도달했다고 불렀다. 그렇다고 전역 DNSSEC 검증도 똑같이 준비되었다는 뜻은 아니었다. 로컬 공유 비밀 트랜잭션과 공개된 서명된 위임 체인은 같은 조율 부담을 지지 않는다.
구성 요소의 성숙도는 그렇지 않으면 잘못된 확신을 만들 수 있었다. 운영자는 하나의 보안 전송이 성공한 것을 보고 서명, 부정 응답, 부모 검증, 리졸버 동작, 애플리케이션 활용이 모두 같은 문턱을 넘었다고 추론할 수 있었다. RFC 3130은 이 표면들을 분리해 두었다.
또한 구현과 상호운용성을 분리했다. RFC 2026에 따라 DNSSEC이 표준 트랙에서 앞서 나가려면 두 개 이상의 상호운용 가능한 구현과 충분한 성공적 운영 경험이 필요했다. 회의는 곤란한 사실과 마주했다. DNSSEC을 진지하게 장착 중인 구현은 BIND뿐이었다. 부분 구현은 부분적 상호운용성을 보여줄 수 있지만, 하나의 전체 코드베이스는 자기 자신과만 합의할 수 있었다.
보고서는 대략 18개월 안에 두 번째 구현이 필요하다는 요구를 기록했다. 그것은 필요의 진술이지, 구현이 나타났다는 증거가 아니었다. 여기서 역사적 주의가 필요하다. 회의 계획은 인도된 산물이 아니며, 성공한 워크숍이 배포된 인프라가 아니듯이.
클라이언트 측 활용은 또 하나의 빠진 고리를 드러냈다. 실험들이 secure shell과 다른 도구들이 DNSSEC 데이터를 사용하도록 적응하는 중이었지만,gethostbyname같은 일반 운영체제 인터페이스는 검증 결과를 어떻게 표현할지 아직 정하지 못했다. 애플리케이션이 이해하지 못하는 서명된 응답은 운영상 효과가 없는 인증된 레코드였다. 반대로 모든 서명 결과를 완전한 인가 결정으로 취급하는 애플리케이션은 DNSSEC에 실제 제공하는 것보다 더 큰 권한을 부여할 수 있었다.
일부 프로토콜 질문도 열려 있었다. NXT는 존재하지 않음에 대한 인증된 부정을 제공했지만, 참가자들은 그 비용과 공개 속성 때문에 제안된 해법이 문제보다 나쁜지를 두고 논쟁했다. 자식 서명에 대한 부모 검증은 레코드 수준에서는 명확해지고 있었지만 운영 절차는 여전히 미정이었다. 하드웨어가 반드시 제약은 아니었다. 실험들은 대형 영역의 서명이 CPU와 메모리 측면에서 관리 가능할 수 있다고 시사했지만, 기관적 롤오버는 여전히 비현실적일 수 있었다.
이 구분이 바로 이 메모의 핵심 역사적 기여다. 메커니즘은 계산적으로는 가능하면서 운영적으로는 준비되지 않을 수 있다. 사양은 구현 가능하면서 독립적 상호운용성이 결여될 수 있다. 서명된 영역은 오늘은 검증에 통과하다가 생명주기 이벤트 이후에는 실패할 수 있다. 보안 구성 요소는 배포 가능하면서 그것을 둘러싼 도구 상자는 여전히 미성숙할 수 있다.
이후의 문서들을 회의 계획의 자동적 실현으로 읽어서는 안 된다. RFC 4033, 4034, 4035는 RFC 2535 아키텍처를 DNSSEC-bis 사양으로 대체했다. RFC 6781은 이후 키, 서명, 롤오버를 둘러싼 운영 관행을 모았다. RFC 5011은 그 자체의 안전이 시간 상태에 의존하는 자동 신뢰 앵커 업데이트를 기술했다. 이 문서들은 사양과 운영이 계속 진화했음을 보여준다. 그러나 RFC 3130이 각 변화를 일으켰거나 2001년의 모든 프로젝트가 성공했다는 것을 증명하지는 않는다.
더 큰 교훈은 DNSSEC을 넘어선다. 테스트의 기간은 테스트 범위의 일부다. 권한이 만료되고, 교체되고, 캐시를 거쳐 전파되고, 조직을 넘는 프로토콜은 그 과정들보다 짧은 행사로는 증명될 수 없다. 빠른 시연을 몇 번 더 반복한다고 해서 빠져 있는 시간의 경과가 생겨나지는 않는다.
표준의 성숙 역시 독립적인 증인을 필요로 한다. 하나의 구현은 내부적 일관성을 드러낼 수 있다. 두 개의 구현은 사양 문장도 자체 테스트도 드러내지 못한 가정들을 폭로할 수 있다. 운영 경험은 작성자가 예정하지 않은 이벤트를 더한다. 놓친 인계, 오래된 캐시, 시계 오차, 인력 경계, 복구 같은 것들이다.
RFC 3130이 인터넷 역사에서 자리 잡는 이유는 한 커뮤니티가 증명에 대한 관념을 바꾸는 지점을 포착했기 때문이다. 초기 워크숍들은 유용한 일을 했다. 성과가 줄어든다고 해서 그 일이 끝났다는 뜻은 아니었다. 답하지 못한 질문들이 워크숍의 시간적·기관적 틀 바깥으로 옮겨 갔다는 뜻이었다.
따라서 만료되는 서명은 단순한 타이머 이상이었다. 증거가 자신이 검증한다고 주장하는 시스템을 만나기까지 충분히 오래 살아 있어야 한다는 요구였다.
출처
- https://www.rfc-editor.org/rfc/rfc3130.txt
- https://www.rfc-editor.org/info/rfc3130
- https://datatracker.ietf.org/doc/rfc3130/
- https://www.rfc-editor.org/rfc/rfc2535.txt
- https://www.rfc-editor.org/rfc/rfc2845.txt
- https://www.rfc-editor.org/rfc/rfc3007.txt
- https://www.rfc-editor.org/rfc/rfc3008.txt
- https://www.rfc-editor.org/rfc/rfc2026.txt
- https://www.rfc-editor.org/rfc/rfc4033.txt
- https://www.rfc-editor.org/rfc/rfc4034.txt
- https://www.rfc-editor.org/rfc/rfc4035.txt
- https://www.rfc-editor.org/rfc/rfc6781.txt
- https://www.rfc-editor.org/rfc/rfc5011.txt
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





