요약

  • 동일한 DNS 주소에 대한 후속 쿼리는 다른 인스턴스에 도달할 수 있습니다. NSID를 사용하면 서버가 검사 대상인 바로 그 응답 안에 진단 식별자를 포함할 수 있습니다.
  • 적용 범위는 단일 DNS 교환입니다. 재귀 리졸버는 이름 확인에 관여하는 모든 권위 서버가 아니라 자신의 클라이언트에게 자신을 식별합니다.
  • 공통 프로토콜은 불투명한 바이트를 보존합니다. 의미와 공개 정책은 운영자가 선택합니다. 식별자는 전역적으로 인증된 신원도, 자동 인증도 아닙니다.

나중에 물어봄의 문제

말이 나오는 순간은 낯선 응답 다음에 옵니다. 운영자는 조사할 가치가 있는 DNS 응답을 하나 가지고 같은 주소에 또 다른 쿼리를 보냅니다. 당신은 어느 서버입니까? 완전히 건강한 인스턴스가 자신의 이름을 알려줍니다. 그 로그에는 원래 문제의 흔적이 없습니다.

여기에 빠진 로그도, 불성실한 서버도 필요 없습니다. 두 번째 쿼리는 다른 인스턴스에 도달했을 수 있습니다. 이것은 측정된 장애가 아니라 설명을 위한 진단 시퀀스입니다. 그 중요성은 이 방법이 잘못된 질문에 대한 설득력 있는 답을 만들어낼 수 있다는 점에 있습니다. 운영자는 앞선 응답의 작성자를 식별하려 했지만, 그보다 늦은 교환에 참여한 주체를 식별했을 뿐입니다.

이 구분이RFC 4892, 즉 S. Woolf와 D. Conrad가 2007년 6월에 작성한 요구사항 문서를 추동합니다. 애니캐스트나 부하 분산은 연이은 DNS 쿼리를 서로 다른 서버로 보낼 수 있습니다. 다른 프로토콜로 프로빙하는 것은 응답한 시스템이 원래 쿼리를 처리했다는 보장을 더욱 약하게 만듭니다. 주소는 서비스에 도달하는 데 여전히 유용했지만, 작업을 수행한 인스턴스를 고유하게 이름 짓지는 못하게 되었습니다.

안정적인 주소, 가변적인 참여자

운영적 배경은 2006년 12월에 BCP 126으로 발표된RFC 4786에 이미 명확했습니다. 애니캐스트 서비스는 여러 독립 서비스 노드에서 광고되는 안정적인 주소를 사용합니다. 어떤 노드가 트래픽을 받는지는 라우팅이 결정합니다. 이는 지리적으로 가장 가까운 기계가 항상 이기거나, 연이은 모든 패킷이 반드시 새로운 곳으로 간다는 뜻이 아닙니다. 목적지 주소가 변하지 않는다는 사실만으로는 안정성을 가정할 수 없다는 뜻입니다.

이는 유용한 분리였습니다. 클라이언트는 뒤에 있는 모든 유지보수 주소를 알지 않고도 하나의 서비스 주소를 사용할 수 있었습니다. 운영자는 모든 클라이언트에게 변하는 목록을 유지하도록 요구하지 않고도 서비스를 분산할 수 있었습니다. 그러나 진단에는 변수가 하나 더 생겼습니다. 실제로 어떤 노드가 응답했는가?

RFC 4786은 서비스 프로토콜 내부의 식별과, 분산 모니터링 지점에서 성능 및 가용성 정보와 함께 노드 신원을 기록할 것을 권장했습니다. traceroute가 도움이 될 수도 있지만, 실행되기 전에 네트워크가 바뀔 수 있습니다. 이 문서는 당시 진행 중이던 NSID 작업을 언급했습니다. 최종 NSID RFC는 아직 존재하지 않았습니다. 운영적 필요는 완성된 옵션보다 앞섰습니다.

오래된 질문은 유용했지만 별개였다

DNS 운영자에게는 이미 서버에게 자신의 이름을 밝히도록 요청하는 관행이 있었습니다. CHAOS 클래스의 HOSTNAME.BIND.에 대한 TXT 쿼리는 관리자가 선택한 식별자를 반환할 수 있었습니다. ID.SERVER.는 구현별 이름을 제거했습니다. VERSION.BIND.는 같은 신원 문제를 푸는 것이 아니라 버전 정보를 보고하는 별도의 목적을 담당했습니다.

이러한 메커니즘에는 실용적 장점이 있었습니다. DNS를 사용하고, 구성이 간단하며, 공개 여부를 관리자에게 남겨두었습니다. 새 표준이 이들을 무용지물로 만들거나 사용을 금지한 것은 아닙니다. 결함은 더 좁았습니다. 별도의 쿼리는 여러 인스턴스가 공유하는 주소에서 온 이전 응답에 자신의 결과를 신뢰할 수 있게 붙일 수 없었습니다.

그래서 RFC 4892는 별도의 클래스나 진단 네임스페이스를 요구하지 않고 일반 운영 쿼리의 일부로서 식별을 추구했습니다. 또한 구현 중립성과 관리 통제도 추구했습니다. 운영자는 사설 유지보수 호스트명이나 유니캐스트 주소를 노출하지 않고도 유용한 참조를 제공할 수 있어야 했습니다. 더 나은 상관 분석이 설치 전체의 공개 디렉터리를 요구하지는 않았습니다.

안에 아무것도 없는 요청

R. Austein의 2007년 8월RFC 5001은 DNS 네임 서버 식별자 옵션을 정의했습니다. 요청자는 자신의 쿼리의 EDNS OPT 가상 리소스 레코드에 빈 NSID 옵션을 추가합니다. 요청은 NSID 페이로드 데이터를 포함해서는 안 되며, 그런 데이터가 그럼에도 도착하면 서버는 무시해야 합니다.

빈 요청이 중요합니다. 서버가 반향해야 하는 챌린지 값도, 이름이 지정된 기계를 선택하라는 지시도, 상대방에게 제안하는 신원도 아닙니다. 실제 수신자가 옵션을 지원하고 요청을 이행하기로 선택한다면, 자신의 식별자를 이 응답에 덧붙이도록 묻는 것입니다.

선택은 여전히 실질적입니다. 서버는 거부할 수 있으며, 요청 없이 NSID를 보내서는 안 됩니다. NSID 없는 일반 DNS 응답은 그 자체로 장애의 증거도, 애니캐스트의 부재도, 서로 다른 인스턴스의 부재도 아닙니다. 지원됨, 구성됨, 요청됨, 반환됨은 서로 다른 상태입니다.

IANA DNS 파라미터 레지스트리는 NSID EDNS 옵션 코드 3을 할당합니다. 슬롯 자체를 공유 슬롯으로 할당하는 것이지, 그 슬롯 안에 들어가는 값을 할당하지는 않습니다. 여기에 개별 서버 신원의 전역 할당은 없습니다. 공통 합의는 답을 요청하고 운반하는 방법에 관한 것이며, 그 답이 무엇을 의미하는지는 운영자가 결정합니다.

어느 서버가 “나”라고 말할 수 있나?

NSID는 명시적으로 비전이적입니다. 재귀 리졸버에게 질문하는 클라이언트가, 있다면, 받는 것은 그 리졸버 자신의 식별자입니다. 리졸버는 권위 서버에 자신의 쿼리를 보낼 때 독립적으로 NSID를 요청할 수 있습니다. 그것들은 서로 다른 응답 주체를 가진 서로 다른 교환입니다.

권위 서버의 식별자가 재귀 리졸버의 클라이언트 신원 요청에 대한 답인 것처럼 되돌려지지 않습니다. NSID도 확인 과정에서 상담된 모든 서버의 체인을 조립하지 않습니다. 여기서 "홉 바이 홉"은 패킷에 라벨을 붙이는 IP 라우터 행렬이 아니라 DNS 트랜잭션 종단을 설명합니다.

2013년 4월의 후속 EDNS 사양인RFC 6891은 이 경계를 강화합니다. OPT는 특정 질문-답변 트랜잭션을 위한 제어 정보를 운반하며, 존 데이터가 아닙니다. 일반 레코드처럼 캐시되거나 전달되거나 마스터 파일에 저장되어서는 안 됩니다.

이 규칙들에는 유용한 귀결이 있습니다. 재귀 리졸버는 캐시된 리소스 레코드를 반환하면서, 자신의 NSID는 지금 응답하는 인스턴스를 설명할 수 있습니다. 그 식별자는 캐시된 데이터를 이전에 어떤 권위 인스턴스가 공급했는지에 대한 증거가 아닙니다. 이 구분은 현재의 진단 관찰이 역사적 인증서로 가장하는 것을 막습니다.

복사 과정에서 살아남아야 하는 읽을 수 없는 값

페이로드는 불투명한 바이트 문자열입니다. 호스트명처럼 보일 수 있지만 클라이언트는 그렇다고 가정할 수 없습니다. 무작위일 수도, 인코딩되어 있을 수도 있고, 운영자의 사기록을 통해서만 의미를 가질 수도 있습니다. 사양은 도시 코드, 하드웨어 시리얼 번호 또는 공통 명명 문법을 요구하지 않습니다.

대신 RFC 5001은 표현 방식에 대해 드물게 세심합니다. 값을 16진수로, 옥텟당 두 자리로 읽고 씁니다. 기반이 되는 이진 데이터를 비교합니다. 0 바이트가 문자열의 끝이라고 가정하지 않습니다. 앞의 0과 중간의 0은 버려야 할 시각적 잡동사니가 아니라 증거의 일부입니다.

인터페이스가 읽기 쉬운 미리보기를 제공할 수 있지만, 그것은 정확한 표현을 대체할 수 없습니다. 16진수 글자의 대소문자를 바꾸는 것은 같은 바이트를 보존할 수 있지만, 디코딩된 페이로드 내에서 대소문자나 유니코드 정규화를 바꾸는 것은 그렇지 않을 수 있습니다. 임의의 식별자를 DNS 이름처럼 다루면 프로토콜이 의도적으로 유보한 규칙을 조용히 부과하게 됩니다.

이는 작지만 중요한 작업 할당입니다. 사용자는 식별자를 이해하지 않고도 지원 티켓에 복사할 수 있습니다. 티켓을 받은 운영자가 그것을 해석할 수 있습니다. 정확한 전달은 모든 관찰자가 모든 로컬 관행을 배우도록 만들지 않으면서 로컬 명명의 자유를 허용합니다.

불투명하다는 것이 비밀 또는 진실을 뜻하지는 않는다

로컬 선택에는 비용이 있습니다. 유지보수 주소는 애니캐스트 서비스가 평소 가리는 노드를 드러낼 수 있습니다. IPv4 주소를 해싱하는 것은 큰 비밀을 만들지 않습니다. 입력 공간이 여전히 32비트에 불과하기 때문입니다. 예측 가능한 호스트명도 추측될 수 있습니다. 지속적인 무작위 값에는 매핑과 연속성 정책이 필요하며, 동일한 값으로 구성된 플릿은 구성원을 구분할 능력을 잃습니다.

식별자가 바뀐다고 경로 변경이나 새 기계를 증명하는 것은 아닙니다. 같은 식별자가 하나의 영구적인 물리 장치를 확립하는 것도 아닙니다. 이런 결론은 운영자의 할당 규칙에 달려 있으며, 그 규칙은 와이어 포맷 밖에 있습니다. 프로토콜이 운반하는 것은 진단 참조이며, 그 작성자가 합리적으로 할당했다는 독립적 보장이 아닙니다.

RFC 5001은 완전한 보안 설계를 제공하지 않으면서 서명되거나 암호화된 값에 대해 논의합니다. 정적 블롭은 여전히 재생될 수 있습니다. 또한 NSID를 그 자체로는 DNSSEC 보호 밖에 둡니다. 리소스 레코드 세트를 인증한다고 해서 인접 채널 정보까지 자동으로 인증되지는 않습니다. 무결성이 필요할 때 TSIG 같은 채널 보호를 언급합니다. 그 역사적 경계는 일반 NSID 교환이 인증된다는 주장이 아닙니다.

두 개의 스위치, 체인 전체를 위한 하나의 설정이 아님

버전 9.20.27로 자신을 식별하는 캡처된BIND 구성 참조는server-id와request-nsid를 구분합니다. 전자는 NSID나 ID.SERVER를 통해 반환되는 로컬 식별자를 제어하며 기본값은none이고, 호스트명 사용은 옵션입니다. 후자는 반복 쿼리 동안 업스트림 식별자를 요청하며 기본값은no입니다. 반환된 업스트림 값은nsid카테고리로 로깅될 수 있습니다.

이 구분은 구성으로 표현된 프로토콜의 범위입니다. 하류 쪽에서 자신을 공개하는 것과 상류 쪽에서 다른 서버에게 요청하는 것은 독립적인 결정입니다.BIND 매뉴얼 페이지는 요청을 포함하는 방법으로dig +nsid를 문서화합니다. 이 명령은 답변을 강제하지도, 반환된 바이트를 신뢰할 수 있게 만들지도 않습니다. 문서화는 구현 경로를 확립할 뿐, 활성화된 프로덕션 시스템의 센서스가 아닙니다.

여분의 진단 바이트에는 물리적 비용도 있습니다. NSID는 응답을 잘림 한계에 가깝게 만들 수 있지만, DNS 잘림 규칙을 바꾸거나 옵션 식별자를 수용하기 위해 잘림을 요구하지는 않습니다. 진단 보조 도구가 전달의 보장과 혼동되거나 일반 답변의 목적을 가리는 일은 없어야 합니다.

NSID의 성과는 올바른 증거가 올바른 교환과 함께 이동하도록 만든 것입니다. 모든 서버 이름을 통일하거나 그 뒤의 네트워크를 인증하지는 않았습니다. 더 작은 약속이 결과적인 모호성을 제거하기에 충분했습니다.