요약

  • 1997년 7월에 BCP 16으로 공개된 RFC 2182는 서버 배치를 운영 신뢰성 문제로 다루었습니다.
  • 대부분의 조직 존에 세 대의 서버를 권고하면서도 중요한 조건을 포함했습니다. 최소 한 대는 다른 서버들과 충분히 떨어져 있어야 한다는 것입니다.
  • 이 표준은 지침이었을 뿐, 어떤 존에 나열된 서버들이 실제로 독립적인 전력, 트랜짓, 소유권 또는 실제 접근성을 갖추었는지를 증명하는 것이 아니었습니다.

한 존은 세 대의 네임서버를 나열하면서도 실제로는 답에 이르는 경로가 하나뿐일 수 있습니다. 세 서버가 모두 동일한 접속 링크 뒤에, 한 건물 안에, 또는 하나의 전원 공급에 있다면 단일 장애가 전체 세트를 무력화할 수 있습니다. 숫자상으로는 중복처럼 보였지만, 의존 관계는 그렇지 않았습니다.

Robert Elz, Randy Bush, Scott Bradner, Michael Patton이 RFC 2182 “Selection and Operation of Secondary DNS Servers”에서 다룬 것이 바로 이 운영 문제였습니다. IETF는 1997년 7월 이를 Best Current Practice 16으로 공개했습니다. 이는 새로운 DNS 프로토콜이 아니라, 기존 시스템의 중복성이 존 파일 밖에서도 작동하도록 만들려는 시도였습니다.

DNS는 이미 위임된 존에 대해 복수의 권한 네임서버를 요구하고 있었습니다. RFC 2182는 하나로 오해될 수 있는 두 가지 질문을 구분했습니다. 프라이머리는 로컬에서 구성된 존 데이터를 보유하고, 세컨더리는 그 데이터를 프라이머리로부터 취득합니다. 그러나 리졸버와 상위 존은 이 구분을 답의 우선순위 판단에 사용하지 않습니다. 더 넓은 DNS의 관점에서 이들은 단순히 나열된 권한 서버였습니다. 세컨더리는 다른 서버, 또는 그 서버가 공유하는 인프라에 접근할 수 없을 때 클라이언트가 그 세컨더리에 도달할 수 있을 때에만 도움이 됩니다.

저자들은 이미 드러나 있던 운영상 문제, 즉 세컨더리 서버의 부적절한 선택에서 출발했습니다. 지리적 배치와 네트워크 연결성의 다양성은 신뢰성과 성능을 개선할 수 있었습니다. 모든 서버를 동일한 로컬 사이트에 두는 것은 명시적으로 부적절한 관행으로 규정되었습니다. 하나의 링크, 사이트, 건물, 방 또는 전원 공급의 장애가 전부를 함께 끊을 수 있었습니다. 핵심은 멀리 떨어진 기계가 자동으로 안전하다는 것이 아니라, 운영자가 어떤 장애가 여러 네임서버를 함께 무력화할 수 있는지 물어야 한다는 것이었습니다.

RFC 2182는 대부분의 조직 수준 존에 대해 세 대의 서버를 권고했으며, 최소 한 대는 다른 서버들과 “충분히 떨어져(well removed)” 있어야 한다고 했습니다. 더 높은 신뢰성이 정당화할 때는 네 또는 다섯 대가 적절할 수 있었습니다. 많다고 항상 좋은 것은 아니었습니다. 더 큰 NS 세트는 DNS 패킷을 크게 만들고, 발견되지 않은 잘못된 구성의 가능성을 늘렸습니다. 이 개수는 보편적인 합격 기준이 아니라 배치 논의 안에서의 경험적 지침이었습니다.

이 조언은 또 하나의 실용적 의존 관계를 드러냈습니다. 원격 복제본을 누군가는 호스팅해야 한다는 것입니다. RFC는 규모가 비슷한 조직들이 세컨더리 서비스를 교환하는 방식을 설명했습니다. 교환되는 존 데이터는 이미 공개적으로 취득 가능했기 때문에, 이러한 합의는 비공개 정보를 노출하지 않고 존을 분산시킬 수 있었습니다. 이는 중복성을 운영자 간 협력으로 바꾸었고, 전송, 일련번호, 접근성을 지속적으로 유지해야 하는 의무를 수반했습니다.

이 BCP는 배포 현장이 그 조언을 따랐는지, 또는 장애를 견뎠는지 측정하지 않았습니다. 공개된 NS 세트는 두 제공자가 서로 다른 상위 연결을 사용하는지, 시설이 전력을 공유하지 않는지, 또는 스트레스 상황에서 경로가 독립적으로 유지되는지를 증명할 수 없습니다. 따라서 “세 대의 서버”는 개수에 대한 증거이지, 장애 경로에 대한 감사가 아닙니다.

1997년 문서에는 이후 시대와 어긋난 DNS 답변에 대한 경고도 담겨 있습니다. RFC 2182는 부정(negative) 답변이 일반적으로 캐시되지 않는다고 말했습니다. RFC 2308은 이듬해 부정 캐싱을 표준화했고, RFC Editor 오류 정정 보고 4631은 이후 이 일괄적 서술이 부정확하다고 표시했습니다. 이 정정은 운영 모범 관행조차 작성 시점과 유지보수 이력을 가진다는 사실을 상기시켜 줍니다.

RFC 2182의 지속적인 통찰은 마법의 숫자보다 좁고 더 유용한 것이었습니다. 중복성은 의존 관계의 속성이라는 것입니다. 세 번째 서버는 그것이 함께 실패할 수 있는 것들을 바꿀 때에만 의미가 있습니다.

출처