요약

  • NSID 값은 한 DNS 응답기가 특정 응답에 특정 바이트를 붙였다는 사실을 보여줄 수 있지만, 프로토콜은 그 값이 호스트명, 물리적 기계, 위치, 소프트웨어 버전 또는 영구적 신원임을 증명하지 않습니다.
  • 따라서 유용한 사고 증거는 네 부분으로 구성됩니다. 원본 응답, 관측자의 관측 지점과 시각, 운영자의 현재 토큰 매핑, 그리고 증거가 통제할 수 있도록 허용된 운영 단위입니다.

주소는 더 이상 기계 이름이 아니었습니다

예전의 진단 직관은 단순했습니다. IP 주소로 쿼리를 보내고, 응답을 기록하고, 그 주소를 응답한 서버의 신원으로 취급하는 것이었습니다. DNS 운영자가 하나의 서비스 주소를 여러 인스턴스에 분산시키면서 이 지름길은 약해졌습니다. 애니캐스트는 하나의 안정적인 주소를 여러 자율적 위치에서 도달 가능하게 만들고, 라우팅은 특정 패킷에 대해 그중 하나를 선택합니다. 로드 밸런서도 하나의 목적지 뒤에서 비슷한 분할을 만들 수 있습니다.

그래도 주소는 여전히 중요합니다. 클라이언트가 사용한 서비스 목적지를 식별하기 때문입니다. 다만 더 이상 한 대의 기계를 가리키지 않을 뿐입니다. RFC 4786은 이 주소를 서비스 주소(service address)라고 부르고, 하나의 노드로 라우팅되는 위상적 영역을 캐치먼트(catchment)라고 부릅니다. 노드의 클라이언트 집단도, 특정 클라이언트를 위해 선택된 경로도 정적으로 유지된다는 보장이 없습니다. RFC 3258은 DNS에서의 귀결을 명확히 했습니다. 동일한 공유 주소로 보낸 두 개의 전용 쿼리는 같은 서버에 도달하지 않을 수 있으며, ping, traceroute 또는 별도의 TCP 연결은 DNS 트랜잭션을 처리한 프로세스에 도달할 가능성이 더 낮을 수도 있습니다.

이것이 바로 Suzanne Woolf와 David Conrad가 RFC 4892에서 제기한 운영 문제입니다. 그 문서는 표준이 아니라 Informational이며, 주제도 보편적인 호스트 신원보다 좁습니다. 응답이 잘못되었거나, 낡았거나, 비정상적으로 느리고, 쿼리된 주소 뒤에 여러 서버가 합법적으로 존재할 수 있을 때 DNS 관리자가 무엇을 필요로 하는지를 묻습니다.

이 구분은 사고 상황에서 중요합니다. “이 주소의 서비스가 낡은 데이터를 반환했다”는 방어 가능한 관측입니다. “이 물리적 기계가 낡은 데이터를 반환했다”는 두 번째 주장입니다. 첫 번째는 패킷 교환에서 나오고, 두 번째는 DNS 응답만으로는 담지 않을 수 있는 매핑을 필요로 합니다.

왜 두 번째 쿼리는 잘못된 영수증인가

BIND 배포판에는 이미 편리한 관례가 있었습니다.HOSTNAME.BIND.에 대한 CHAOS 클래스 TXT 쿼리는 구성된 호스트명을 반환할 수 있었고, 구현에 더 중립적인 레이블인ID.SERVER.도 비슷한 목적을 담당했습니다. 이 쿼리는 DNS이기 때문에 일반 DNS 트래픽과 같은 방화벽 정책과 대체로 같은 라우팅 체계를 통과할 수 있습니다. 운영자는 반환되는 문자열을 직접 선택하여 유지보수 주소의 노출도 피할 수 있습니다.

그러나 식별자는 두 번째 트랜잭션으로 도착합니다. 그것이 이 관례의 결정적 약점입니다. 문제가 되는 응답과 진단 쿼리 사이에 애니캐스트 경로가 바뀌거나, 로드 밸런서가 다른 백엔드를 선택하거나, 비정상 인스턴스가 사라질 수 있습니다. 조사자는 서로 다른 응답기의 두 개의 유효한 영수증을 손에 들고 그것을 하나의 거짓 이야기로 결합할 수 있습니다.

오류는 미묘합니다. 모든 구성 요소가 그럴듯해 보이기 때문입니다. 원래 응답은 실제로 공유 서비스 주소에서 왔습니다. 레이블도 실제로 그 주소에서 돌아왔습니다. traceroute도 실제로 광고된 서비스 근처에서 끝났습니다. 그러나 어느 것도 두 번째 응답기가 첫 번째였다는 것을 증명하지 못합니다. 주소만으로의 상관은 바로 이 분산 위상이 무효화한 방식입니다.

따라서 RFC 4892는 식별 정보가 정상적인 운영 응답 안에서 이용 가능하도록 요구했습니다. 전용 쿼리도 여전히 허용했지만, 그 쿼리를 동등한 대체물로 취급하는 것은 거부했습니다. 동일 응답 연관은 장식적 메타데이터가 아니라 첫 번째 증거 경계입니다.

RFC 4892가 요구한 것

Woolf와 Conrad는 단순히ID.SERVER.의 표준화된 철자를 요구한 것이 아니었습니다. 그들은 관례의 실패를 활용해 더 나은 메커니즘의 속성을 규정했습니다.

그 메커니즘은 DNS에 대해 인밴드(in-band)여야 하고, 조사 중인 응답에 동반될 수 있어야 했습니다. 식별만을 위해 하나의 서버 구현에 의존하거나 별도의 클래스와 의사(pseudo) 존을 소모해서는 안 되었습니다. 구현, 활성화, 비활성화가 쉬워야 했습니다. 접근 제어를 지원해야 했습니다. 운영상 유용한 레이블은 사적 위상도 드러낼 수 있기 때문입니다. 그리고 운영자가 실제 호스트명이나 유니캐스트 유지보수 주소를 강제로 공개하지 않고도 인스턴스를 구분할 수 있어야 했습니다.

요구 사항은 식별과 인증도 분리했습니다. 미래 설계는 인증된 데이터를 가능하게 할 수 있지만, 호스트명처럼 보이는 문자열은 스스로를 인증하지 않습니다. DNS에서 이는 특히 중요합니다. DNSSEC는 서명된 DNS 데이터와 부존재 증명 문장을 검증하지만, 응답기가 붙인 모든 채널 메타데이터를 자동으로 인증하지는 않습니다.

RFC 4892는 이러한 특성에서 멈추었고 IANA 조치는 제안하지 않았습니다. 두 달 뒤 Rob Austein이 집필한 RFC 5001이 NSID 옵션을 정의했습니다. Woolf는 그 문서에서 감사의 말을 받았지만, 표준의 저작권은 Austein에게 있습니다. 이 귀속을 정확히 유지하는 것은 본 글의 더 큰 주장과 맞닿아 있습니다. 레이블은 범위와 출처가 편의에 의해 확대되지 않을 때만 유용합니다.

NSID가 실제로 증명하는 것

NSID는 EDNS 옵션을 사용합니다. 리졸버가 쿼리에 빈 NSID 요청을 넣으면, 옵션을 이해하고 응답하기로 선택한 서버가 응답에 식별 바이트를 넣을 수 있습니다. 바이트가 그 응답과 함께 이동하기 때문에 관측자는 이 트랜잭션의 응답기가 그것을 제공했다고 신뢰할 수 있게 말할 수 있습니다. 이것이 후속ID.SERVER.쿼리가 만드는 시간적 간극을 수리합니다.

그러나 이 수리는 의도적으로 제한적입니다. RFC 5001은 페이로드를 불투명(opaque) 바이트 문자열로 정의하고 구문과 의미를 프로토콜 밖에 둡니다. 운영자는 호스트명, 유니캐스트 주소, 임의의 값, 확률적 영구 식별자, 암호화된 값 또는 임의의 옥텟을 사용할 수 있습니다. 사용자 인터페이스는 데이터를 16진수로 표시하는데, 예쁘지만 모호한 표현보다 정확한 전송이 더 중요하기 때문입니다.

따라서 레이블은 안정적인 기계 이름일 수 있지만, 그럴 필요는 없습니다. 프로세스, 컨테이너, 백엔드 풀 또는 사이트를 가리킬 수 있습니다. 재시작을 거쳐도 안정적일 수도 있고, 매 재시작마다 바뀔 수도 있습니다. 전체 플릿에서 고유할 수도 있고, 구성 오류로 인해 어디서나 동일할 수도 있습니다. 운영자에게 의미 있는 토큰은 공개적으로는 의도적으로 무의미할 수 있습니다. 프로토콜은 봉투를 제공하고, 의미는 운영자가 제공합니다.

NSID는 또한 전이적이지 않습니다. 클라이언트가 재귀 리졸버에게 NSID를 요청하면 그 값은, 리졸버가 반환하기로 선택한 경우, 그 쿼리를 받은 재귀 서버를 식별합니다. 재귀 리졸버가 consult한 권위 서버가 어느 것인지 자동으로 드러내지 않습니다. 리졸버가 수집한 상류 NSID는 별도의 홉이자 별도의 영수증입니다. EDNS 자체가 홉 단위(hop-by-hop)이므로 이는 아키텍처적 속성이지 빠진 사용자 인터페이스 기능이 아닙니다.

마지막으로 NSID는 자동으로 인증되지 않습니다. RFC 5001은 그것을 DNSSEC의 정상 보호 범위 밖의 채널 신호로 취급합니다. 무결성에 의존하는 사용 사례는 TSIG 같은 명시적 채널 보안을 필요로 하며, 서명되거나 암호화된 블롭을 사용한다면 재전송을 고려한 설계도 여전히 필요합니다. 암호학적으로 보이는 바이트는 신선도, 물리적 위치 또는 운영 소유권을 확립하지 않습니다.

네 개의 영수증

서버 레이블을 가장 잘 사용하는 방법은 그 주장을 줄이고 증거를 풍부하게 만드는 것입니다.

첫 번째 영수증은 응답 연관입니다. 원본 쿼리와 응답, 원본 NSID 바이트를 포함해 보존하십시오. 복사된 텍스트 레이블이나 두 번째 쿼리는 패킷 수준의 결합을 대체할 수 없습니다. 트랜잭션에서 NSID가 요청되지 않았다면 조사자는 나중에 확실성을 만들어내는 대신 응답기 신원이 미해결이라고 명시해야 합니다.

두 번째 영수증은 관측 지점과 경로입니다. 관측자, 목표 서비스 주소, 전송 방식, 시각을 기록하십시오. 애니캐스트 응답은 한 클라이언트가 네트워크의 한 지점에서 무엇에 도달했는지를 서술합니다. 두 번째 관측 지점은 첫 번째와 모순되지 않으면서도 다른 캐치먼트를 드러낼 수 있습니다.

세 번째 영수증은 운영자 매핑입니다. 운영자는 토큰을 의도된 운영 단위에 매핑하고 그 매핑이 언제 유효했는지 말할 수 있어야 합니다. 매핑 버전, 활성 시각, 폐지 시각은 불투명한 그룹핑 키를 증거로 바꿉니다. 그것들이 없으면 재구축 후 재사용된 토큰이 서로 다른 두 인스턴스를 연속된 것처럼 보이게 만들 수 있습니다.

네 번째 영수증은 조치 범위입니다. 사고 기록은 매핑된 단위가 프로세스, 컨테이너, 호스트, 로드 밸런서 풀, 사이트 또는 애니캐스트 노드 중 무엇인지 명시해야 합니다. 그것이 운영자가 안전하게 드레인, 재시작, 격리 또는 검사할 수 있는 대상을 결정합니다. 프로세스를 식별하는 레이블만으로는 전체 사이트의 경로 철회를 승인할 수 없습니다.

이 영수증들은 함께 프로토콜이 더 많은 것을 전달했다고 가장하지 않으면서 신원의 유용한 부분을 보존합니다. 운영자가 응답을 비교하고 이상치를 찾고 올바른 팀에 연락할 수 있게 합니다. 또한 서버가 응답을 거부하거나, 중개자가 옵션을 제거하거나, 매핑이 만료되었을 때 불확실성을 가시화합니다.

출처