요약

  • RFC 1912는 레임 위임(lame delegation)을, 어떤 서버가 NS 레코드를 통해 존에 대해 지명되어 있으면서 실제로는 그 존의 이름 서비스를 제공하지 않는 상태로 정의했다. 상위 쪽 공개는 참조(referral) 주장이었지 원격 구성의 증거가 아니었다.
  • 이 장애는 서로 독립적으로 제어되는 단계들 너머로 이어졌다: 세컨더리의 동의, 존 로딩과 갱신, 상위·하위 NS 일관성, 캐시 노화, 엔드포인트 도달 가능성, 권위 있는 응답.
  • 나열된 서버들이 실제로 최신 데이터를 서비스할 때만 중복성이 존재했다. 따라서 NS 레코드 수를 세는 것은 회복력을 과장할 수 있었고, 불필요한 트래픽에서 호스트 미해석과 반송 메일까지 무엇이든 초래할 수 있었다.

깨진 위임의 성공한 절반

DNS는 위임을 하나의 소박한 거래처럼 보이게 만들었다. 존 경계에서 상위는 하위 서버를 이름으로 지목하는 NS 레코드를 공개했다. 서버 이름이 그 경계 아래에 속한다면, 도달에 필요한 glue 레코드가 주소 레코드로 공급되었다. 리졸버는 그러면 상위를 벗어나 하위를 향해 계속 나아갈 수 있었다.

RFC 1034는 이 메커니즘 주위에 중요한 순서를 두었다. 서버들을 먼저 설치하도록 했다. 위임 NS와 필요한 glue를 상위에 추가하는 것이 설치의 마지막 단계였다. 경계 양쪽의 관리자들이 레코드를 일관되게 유지해야 했다. 상위는 가리킬 수만 있고 자신이 이름 붙인 기계를 구성할 수는 없었기 때문에, 이 순서는 운영상 타당했다.

레임 위임은 이 시스템의 첫 번째 절반은 그대로 보존했다. 상위는 응답했다. 참조는 구문상 쓸모 있어 보였다. 주소가 실제로 도달 가능했을 수도 있었다. 균열은 선택된 서버가 다음 주장에서 실패할 때만 나타났다. 하위 존에 대한 권위자로서 응답하지 않았다는 것.

이 구분은 “DNS가 다운됐다”보다 정확하다. 그것은 접수 경계를 식별한다. NS 레코드는 상위 쪽 관리자가 서버 이름을 공개했다는 것만 증명했다. 원격 호스트마스터가 동의했는지, 존을 만들었는지, 데이터를 로드했는지, 최신 복사본을 전송받았는지, 서비스를 계속 운영하는지, 지금 물어진 질문에 권위 있는 응답을 돌려주는지는 증명하지 않았다.

서버는 멀리서 제3자에 의해 지명될 수 있었다

문제는 이미 1993년에 보였다. RFC 1537은 그 한 형태를 “세컨더리 서버 서프라이즈”라고 불렀다. 호스트들이 네임 서버 요청을 쏟아내듯 받았고, 나중에야 등록 정보에 자신들이 세컨더리 서버로 기재되어 있다는 사실을 발견했다. 그 관리자들은 물어보지도, 통지받지도 않았을 수 있었다. 조정 레코드가 그 작업을 실제로 만들 인적 합의를 완료하지 않은 채 다른 운영 도메인에 일을 배정한 것이다.

RFC 1713은 같은 간극을 디버깅을 통해 접근했다. 지목된 기계를 실제로 조회하고 그 행동을 검사해야 했다. 상위 레코드는 목적지를 지명할 수 있었지만, 실제로 그 존을 서비스하는지는 그 목적지에서의 관측이 결정했다. 이것은 문자 그대로의 실행 코드 증거였다. 권위는 경계 위쪽의 선언만으로 추정될 수 없었다.

RFC 1912는 1996년 2월에 이 운영 교훈을 정리했다. 이것은 인터넷 표준이 아니라 Informational 메모였고, 레지스트리 시스템을 입법하는 대신 반복되는 실수를 기술했다. 그 고전적 사례는 가상의 하위 존 안에 새로 구성된 서버와, 하위 쪽 호스트마스터가 제대로 된 세컨더리 구성을 끝내지 못했거나 어쩌면 시작조차 하지 않은 외부 서버를 짝지었다. DNS는 그 외부 서버가 존을 알아야 한다고 말했다. 서버는 그렇지 않았다.

이 메모는 또한 더 건방진 관행도 보도했다. 어떤 사이트들은 유명한 네임 서버들을 NS 목록에 넣고 그들이 어떻게든 추가 서비스를 공급해 주기를 바랐다. 이 진술은 당대의 운영 보고를 기록한 것이다. 검증된 사례를 특정하거나 그 관행이 얼마나 흔했는지를 확립하지는 않는다. 다만 공개가 동의를 대신할 수 없는 이유를 보여준다.

하나의 서버 이름 뒤에는 다섯 가지 상태가 숨어 있었다

NS 집합에 든 이름은 서로 다른 여러 상태에 있을 수 있었다.

첫째, 그것은지명되어있었다. 상위 또는 하위 데이터에 서버 식별자가 들어 있었다. 둘째, 그것은도달 가능했다. 패킷이 그 식별자에 연결된 주소로 도착할 수 있었다. 셋째, 하위 존에 대해구성되어있었다. 넷째, 존의 충분히최신인 복사본을 갖고 있었다. 다섯째,권위 있게응답했다.

이 상태들은 서로 연관되어 있지만 호환되지 않았다. 도달 가능한 DNS 프로세스가 다른 존들에 대해서는 권위자이고 이 존에 대해서는 아무것도 모를 수 있었다. 구성된 세컨더리가 갱신에 실패해 결국 자기 복사본을 만료시킬 수 있었다. 상위와 하위 NS 집합이 서로 일치하면서도 한 서버가 잘못 구성된 채 남을 수 있었다. 잘 작동하는 서버가 하위에서는 제거되었지만 다른 곳의 캐시에는 남아 있을 수 있었다. 권위 있는 응답은 그 한 관측에 대한 서비스만 증명했고, 나열된 모든 피어나 모든 미래의 쿼리를 보장하지 않았다.

RFC 2181은 나중에 경계 주변의 구조를 명확히 했다. 하위 apex에는 권위 있는 NS 집합이 들어 있고, 상위에는 리졸버를 아래로 보내는 데 쓰이는 위임 데이터가 들어 있다. 두 이름은 일치하는 것이 기대되지만, 역할과 권위는 동일하지 않다. RFC 8499는 수년 뒤 같은 어휘를 유지했다. 참조(referral)는 해석을 이끌고, 권위 서버는 어떤 존에 대해 응답하도록 구성된 서버다.

그래서 실무 감사는 집합 비교에서 멈출 수 없었다. 나열된 모든 엔드포인트에 하위 존 질문을 던지고, 권위 응답 상태를 검사하고, 쓸모 있는 존 증거를 비교하며, 갱신 및 장애 구간에 걸쳐 관측을 반복해야 했다.

서류상 두 대의 서버는 작동하는 두 복사본이 아니었다

최소 두 개의 네임 서버를 두라는 옛 권고는 회복력을 노린 것이었다. 다른 네트워크에 있는 세컨더리는 국지적 장애를 견디고 하나의 경로에 대한 의존을 줄일 수 있었다. 그러나 “두”라는 숫자는 의도된 다양성을 말했지 입증된 서비스를 말하지 않았다.

두 항목 중 하나가 레임이라면, 모든 리졸버가 하나의 안정된 결과를 겪지는 않았다. 각 리졸버의 서버 선택, 캐시된 주소, 재시도 논리, 타이밍이 달랐다. 일부 쿼리는 건강한 서버에 닿았다. 다른 쿼리는 먼저 시간과 트래픽을 고장 난 구성원에게 낭비했다. RFC 1912의 말대로, 최선의 경우 레임 위임은 DNS 트래픽을 늘렸다. 최악의 경우 호스트를 미해석으로 두고 메일을 반송시킬 수 있었다. 모든 리졸버와 모든 쿼리가 최악의 경로를 따른다고는 쓰지 않았다.

이 간헐적 성질 때문에 오류는 오독하기 쉬웠다. 운영자는 한 번 테스트해서 건강한 서버에 닿고 위임이 작동한다고 결론 내릴 수 있었다. 다른 곳의 사용자는 레임 구성원을 선택해 실패를 볼 수 있었다. 광고된 중복 집합에 실제로는 하나의 기능하는 권위자만 있다는 사실이 전체 가동률에 가려질 수 있었다.

회복력에는 독립적인 관측이 필요했다. 각 서버가 관련 네트워크에서 도달 가능하고, 각자 그 존에 대해 구성되어 있으며, 각자 충분히 최신인 복사본을 갖고, 각자 권위 있게 응답할 수 있어야 했다. 운영상의 수용 없이 이루어진 지리적 분리는 이름들의 지리적 분포일 뿐이었다.

제거에는 꼬리가 따랐다

원본 구성을 고치는 것이 오래된 경로 전부를 즉시 지우지는 않았다. RFC 1912는 캐시된 NS 레코드가 어떤 세컨더리가 이동하거나 제거된 뒤에도 그것을 최신인 것처럼 다루게 만들 수 있다고 경고했다. 편집 자체가 전환을 완성한다고 가정하기보다, 관련 캐시 노화 구간 동안 구 서버에서 서비스를 계속하도록 권했다.

이 변경은 최소 세 개의 관리 표면을 넘었다: 하위를 제어하는 사이트, 위임을 호스팅하는 상위, 세컨더리를 호스팅하는 조직. 프라이머리 이동은 세컨더리들이 구성을 갱신·재적재하도록 요구했다. 세컨더리 이동은 주소와 위임 레코드가 적절한 하위·상위 수준에서 바뀌도록 요구했다. 그 후 캐시는 미리 설정된 시간에 따라 만료되었다.

그래서 하나의 타임스탬프로는 완료를 증명할 수 없었다. 하위 존 편집 시각, 상위 공개 시각, 서버 재적재 시각, 성공적 전송 시각, 캐시된 옛 데이터의 마지막 만료는 서로 다른 사건이었다. 롤백 경로도 어느 단계가 실패했는지에 달렸다. NS 레코드 복원으로 구성되지 않은 세컨더리를 고칠 수 없었고, 서버 복원으로 모든 리졸버에서 낡은 주소를 씻어낼 수 없었다.

레코드는 서비스를 따라가야 했다

남는 교훈은 DNS 위임을 불신하라는 것이 아니다. 조정 레코드는 수용된 운영 관계를 기술하고 그 관계에 대해 검증 가능한 상태를 유지할 때 작동한다는 것이다.

이 비상하게 작은 규모에서는 레코드와 작동 중인 관계가 눈에 띄게 다른 것들이었다. 상위는 존 경계의 자기 쪽을 공개할 정당한 권한을 갖고 있었다. 그 권한은 원격 서버의 구성 안까지는 뻗지 않았다. 세컨더리 운영자는 그 기계에 대한 권한을 갖고 있었다. 그 통제가 상위를 갱신하지는 않았다. 리졸버들은 광고된 경로들 가운데서 국지적으로 선택했다. 어떤 참여자도 전체 결과를 통제하지 않았다.

좁은 공동 계층은 참조 형식과, 독립적으로 운영되는 시스템들이 상호 운용하게 하는 규칙이었다. 어떤 특정 호스트가 어떤 특정 존을 서비스할지라는 미래의 결정은, 호스트 운영자가 구성하고 작동 중인 서버가 응답했을 때에만 실재했다. 먼저 공개하고 수용을 따라오기를 바라는 것은 그 순서를 뒤집었다.

레임 위임은 인터넷에 반복되는 거버넌스 오류에 대한 이른바 구체적 이름을 주었다. 레코드는 그것이 이름 붙인 행위자가 책임을 수용하기 전에 결과를 지시할 수 있다. 수리는 레코드에 가치가 없다고 가장하는 것이 아니다. 그 주장을 좁게 만들고, 모든 인계를 검증하고, 그것이 기술하는 서비스 뒤에 장부를 유지하는 것이다.

출처