요약

  • 2007년 8월의 RFC 5001은 DNS 이름 서버 식별자, NSID를 정의했다. 리졸버는 비어 있는 EDNS 옵션으로 요청하고, 요청을 받아들이는 서버는 자신을 식별하는 바이트를 바로 그 응답에 넣는다.
  • 이 표식은 한 번의 질의와 한 네트워크 구간에 적용된다. 재귀 리졸버에게 물으면 재귀 리졸버가 자신을 밝힌다. 그 뒤의 권한 서버는 별도 통신에서 확인해야 한다. 표식의 내용은 운영자가 정한다.
  • L-Root의 2014년 운영 기록은 응답한 노드의 완전한 호스트 이름을 NSID로 내보낸 사례를 남겼다. IANA DNS 매개변수 등록부는 NSID를 EDNS 옵션 번호 3으로 기록한다.

재시험은 다른 기계를 심문했을 수 있다

장애 신고에는 IP 주소와 틀린 DNS 답이 붙어 있다. 담당자가 같은 주소를 다시 조회하자 정상이다. 그러면 첫 신고를 일시적 착오로 넘기기 쉽다. 애니캐스트 주소는 한 기계의 명찰이 아니라 여러 노드의 공동 접수 창구다. 네트워크 경로가 어느 노드에 질의를 전달할지 정한다. 로드 밸런서 뒤에서도 하나의 주소가 여러 프로세스를 가리킬 수 있다. 두 번째 정답은 첫 서버가 고쳐졌다는 증거가 아니다.

2006년 애니캐스트 운영 지침은 고장을 진단하려면 노드 식별 수단이 도움이 된다고 설명했다. 뒤늦게 특별한 질의를 보내 서버 이름을 물을 수도 있다. 그 사이 경로가 바뀌면 새 질의에 답한 노드만 나타난다. 사고 당시의 기계는 이미 자리를 비웠는데, 다음 교대자가 출석부에 이름을 쓰는 셈이다.

RFC 5001은 식별 질문을 원래 DNS 왕복 안으로 옮겼다. 문서는 애니캐스트와 부하 분산 때문에 여러 이름 서버가 같은 IP를 쓸 수 있다고 적는다. DNS 질의에는 뒤의 재시도를 같은 기계에 묶는 지속 세션이 없다. 특정 답을 누가 보냈는지 알아내려면 그 답을 내는 서버가 정보를 응답에 실어야 한다. 결과와 응답자 표식이 같은 시점의 하나의 증거가 된다.

빈 칸으로 묻고 바이트로 답한다

리졸버는 EDNS의 OPT 가상 레코드에 빈 NSID 옵션을 넣어 보낸다. 요청에 NSID 데이터가 들어가서는 안 된다. IANA가 정한 옵션 코드는 3이다. 이를 이해하고 응하기로 한 서버는 응답의 OPT에 식별 바이트를 넣는다. 요청에 잘못 담긴 데이터는 무시해야 하며, 요청하지 않은 리졸버에게 먼저 NSID를 보내서도 안 된다. 캡처한 쪽은 질의, 답, 표식, 시각을 함께 보관할 수 있다.

표식이 꼭 읽기 쉬운 호스트 이름일 필요는 없다. RFC는 이를 해석 방식이 정해지지 않은 바이트열로 다룬다. 실제 기계 이름, 관리 주소, 유지되는 난수, 계산된 가명, 계속 바뀌는 값, 서명 또는 암호화된 데이터가 가능하다. 규격은 어디에 질문하고 어디에 담아 답할지만 통일한다. 운영자가 무엇을 드러낼지 고른다. 공개 이름은 외부 장애 신고를 쉽게 한다. 안정된 가명은 내부 관리 주소를 숨기면서 복제 노드를 구별하게 해 준다. 자주 바뀌는 표식은 외부 추적을 줄이지만 뒤늦은 신고를 내부 기록과 맞추기 어렵게 한다.

운영 방식에 따른 비용도 있다. 공동 주소 뒤에 숨겨 둔 모든 관리 IP를 NSID에 적으면 그 주소가 가리던 노드 지도를 스스로 공개한다. 아무 표식도 돌려주지 않으면 고객은 같은 IP에서 나온 서로 다른 답만 제출할 수 있다. RFC 5001의 보안 논의는 NSID를 DNSSEC의 DNS 데이터 보호와 구분되는 통신 채널 신호로 본다. 표식이 진짜인지 따져야 하는 사건이라면 채널 보호나 운영 기록과의 대조가 필요하다.

L-Root는 읽을 수 있는 이름을 골랐다

L-Root 운영자들은 2014년 1월 애니캐스트 노드 식별에 실제로 사용한 방법을 설명했다. 그 서비스에서 NSID는 응답한 노드의 완전한 호스트 이름을 담았다. 문서의 dig 예시는 십육진수 바이트가 ytz01.l.root-servers.org 같은 이름으로 읽히는 모습을 보여 준다. 규격의 자유로운 필드에 공개 식별자를 넣은 운영 결정이다.

같은 기록에는 HOSTNAME.BIND와 ID.SERVER 질의도 있다. 이들은 추가 질의에 답한 노드를 알려 준다. 원래의 잘못된 답과 그 추가 질의 사이에 경로가 바뀌면 두 노드는 다를 수 있다. 문제의 질의에 NSID를 함께 요청하면 문제의 답과 그때의 응답자 표식이 한 왕복에서 나온다. 고객의 신고가 공동 IP 하나가 아니라 특정 노드의 로그로 이어질 수 있다.

그 문서는 2014년에 문서화된 L-Root 운영을 보여 준다. 지금의 모든 루트 서버 현황을 말하지는 않는다. 개별 사고에서는 원본 질의와 응답, NSID 원시 바이트, 출처, 전송 방식과 시간을 남긴다. 표식을 실제 장비나 프로세스에 연결하는 일은 운영자의 노드 대장과 로그가 맡는다.

재귀 리졸버는 자기 이름만 답한다

NSID는 각 홉에서 끝난다. 단말이 재귀 리졸버에 NSID를 요청하면 그 재귀 리졸버의 정체를 묻는 것이다. 재귀 리졸버가 상위 권한 서버에 별도로 NSID를 물을 수는 있다. 그때는 새로운 요청과 응답이다. 단말로 돌아온 표식이 상위 권한 서버의 이름으로 자동 전환되지는 않는다. 요청하지 않은 단말에 서버가 NSID를 임의로 붙이는 것도 RFC가 금지한다.

재귀 응답 뒤에 어느 권한 서버가 있었는지 찾으려면 상위 질의의 캡처나 로그가 있어야 한다. 단말이 받은 한 개의 응답에 방문한 모든 서버의 명단은 없다. 이 경계는 책임을 정확히 나눈다. 재귀 서버의 표식을 보고 권한 서버의 잘못이라고 단정할 수 없다. 한 홉 안에서도 표식은 서버가 스스로 밝힌 식별자이며, 실제 데이터 차이의 원인은 설정과 기록으로 확인한다.

공동 주소에도 개별 응답자는 있다

RFC 5001은 서비스 주소를 바꾸지 않았다. 특정 서버가 내보내는 답에 선택적으로 표식을 붙일 공간을 만들었다. IANA는 번호를 관리하고, 운영자는 내용과 공개 범위를 정하고, 리졸버는 요청하고 보관한다. 작은 필드지만 “이 답을 누가 냈는가”라는 질문에 필요한 책임을 나누었다.

서버는 표식을 돌려주지 않을 수도 있다. 추가 바이트가 큰 DNS 응답의 잘림에 영향을 줄 수 있어서 반환은 언제나 선택 사항이다. NSID가 없는 캡처는 그 왕복에서 표식이 돌아오지 않았다는 뜻이다. 노드를 찾는 일에는 다른 기록이 필요하다. 빈 칸 하나가 공동 IP를 개별 기계의 이름으로 바꿔 주지는 않는다.

애니캐스트에는 하나의 주소가 편리하다. 사고 조사에는 어느 기계가 그 답을 보냈는지가 중요하다. L-Root는 읽을 수 있는 이름을 택했고 다른 운영자는 내부 코드로 답할 수 있다. 어느 쪽이든 표식이 바로 문제가 된 답과 함께 오기 때문에 쓸모가 있다. 다음 재시도는 이미 다른 기계의 이야기일 수 있다.