요약

  • 위임(delegate) 응답은 리졸버에게child.example을ns.child.example에 문의하도록 지시할 수 있는데, 그 서버의 주소를 찾으려면 원래는 아직 도달할 수 없는 같은 자식 존에 물어야 합니다.
  • DNS 글루(glue)는 부모의 레퍼럴에 제한된 주소 사본을 넣어 이 순환을 끊습니다. 글루는 도달 가능성을 제공할 뿐 권위는 제공하지 않으며, 이후의 규격들은 리졸버가 이를 어떻게 순위화하고 서버가 불완전한 글루를 어떻게 표시해야 하는지를 정교화했습니다.

불가능한 다음 단계

반복적(iterative) DNS 조회는 레퍼럴로 진행됩니다. 루트 서버는 최상위 도메인을 가리키고, 최상위 도메인은 자식을 가리키며, 리졸버는 다음 서버에 질의합니다. 이 연쇄는 자식의 서버 이름이 그 자식 존 내부에 있는 경우에만 비직관적으로 됩니다.

부모가child.example을ns.child.example이 서비스한다고 말한다고 가정해 봅시다. 리졸버는 이제 그 호스트의 A 또는 AAAA 레코드가 필요합니다. 그런데child.example하위 이름들에 대한 권위는 아직 도달하지 못한 그 서버 자신입니다. 지시가 순환하게 됩니다. 질문을 던지기 위해 필요한 주소를, 바로 그 주소를 알려주어야 할 기계로부터 얻어야 하는 것입니다.

이는 예외적인 문법 장난이 아닙니다. 존의 서버 이름을 존 내부에 두면 운영자에게 일관된 네임스페이스를 줍니다. 어려움은, 건너야 할 경계를 건너는 데 필요한 목적지가 그 경계의 반대편에 있을 때 발생합니다.

자식에게서 빌려온 하나의 주소

1987년 11월에 발표된RFC 1034는 존 컷(zone cut)을 정의했습니다. 부모는 위임된 자식의 서버를 지명하는 NS 레코드를 보관합니다. 이 레코드들은 리졸버를 다음 단계로 안내하지만, 이름만으로는 통신이 성립하지 않을 수 있습니다. 그래서 RFC는 부모가 컷 아래 서버들의 주소 레코드를 보유할 수 있도록 허용했고, 이를 글루(glue)라고 불렀습니다.

이 단어는 필요성과 한계를 동시에 설명합니다. 그 주소는 그렇지 않으면 서로 단절된 두 단계의 확인 과정을 연결합니다. 레퍼럴에 사용 가능한 다음 홉을 포함할 수 있도록 부모 존에 복사됩니다. 그러나 RFC 1034는 글루가 권위 있는 데이터가 아니라고 명시적으로 말합니다. 글루는 서버 이름이 컷 아래에 있고 레퍼럴의 일부로 사용될 때에만 필요합니다.

부모는 "이 호스트의 권위 있는 주소가 무엇인가?"라는 일반적 질문에 답하는 것이 아닙니다. 더 좁게 "내가 위임하는 권위에 접속을 시도할 수 있을 만큼의 주소 정보는 여기 있다"고 말하는 것입니다. 일단 도달하면, 자식은 자신의 존에서 답할 수 있습니다.

이 구분은 DNS를 실용적 의미에서 탈중앙화로 유지합니다. 부모는 위임을 부트스트랩할 수 있는지를 결정하는, 실제 운영상의 지렛대를 쥐고 있습니다. 자식은 자신의 존을 관리합니다. 리졸버는 레퍼럴을 실행하고 어떤 근거를 유지할지 결정합니다. 어떤 단일 레코드도 세 역할을 모두 대행할 필요가 없습니다.

이 예외가 약하게 남아야 했던 이유

추가(additional) 데이터는 별도 질의 없이 도착한다는 점에서 편리합니다. 그래서 과잉 신뢰하면 위험합니다. 서버는 질문의 대상이 아닌 레코드를 덧붙일 수 있고, 캐시는 실수로 힌트를 오래 남는 답으로 승격시킬 수 있습니다.

RFC 2181은 1997년에 이 순위 체계를 명확히 했습니다. 권위 있는 존 데이터는 비권위적 응답과 추가 정보보다 위에 놓입니다. 가장 신뢰도가 낮은 그룹의 미인증 레코드는 나중에 답으로 나타나지 않도록 캐시해서는 안 됩니다. 글루는 다음 질의를 안내할 수 있지만, 메모리에 남아 있었다는 이유만으로 권위를 얻어서는 안 됩니다.

같은 RFC는 운영상의 사실도 인정합니다. 하나의 이름에 대한 글루가 여러 존에 존재할 수 있고 서로 어긋날 수 있습니다. 올바르게 구성된 권위 있는 사본과 달리, 부모 쪽 힌트들은 충돌할 수 있습니다. 그래서 리졸버에는 단순한 주소 레코드 묶음이 아니라 출처(provenance)와 순위가 필요합니다.

글루가 필요한 곳과 그저 잡음인 곳

이후의 용어는 이 기하학을 더 명확히 했습니다.RFC 8499는 위임된 존 내부의 서버 이름을 "인도메인(in-domain)"이라고 부릅니다. 인도메인 서버는 글루가 필요하며, 없으면 확인이 실패합니다.

형제(sibling) 서버는 같은 부모 아래 다른 위치에 있습니다. 그 주소는 보통 그 형제 자신의 위임을 따라 확인할 수 있으므로, 형제 글루는 최적화에 해당합니다. 그러나 형제들이 서로를 순환적으로 의존할 수 있습니다.foo.test가bar.test아래의 서버를 쓰고bar.test가foo.test아래의 서버를 쓴다면, 부모가 이 고리를 끊는 주소를 제공해야 합니다.

바일리윅(bailiwick) 밖 서버 이름은 부모 존 바깥에 있습니다. 이에 대한 글루를 제공하는 것은 무용합니다. 리졸버는 그 이름을 DNS 트리의 적절한 가지를 통해 확인할 수 있고 그래야 합니다. 범위 밖의 임의 추가 주소를 수용하면 부트스트랩 필요를 해결하지 못한 채 모호성과 공격 표면만 커집니다.

따라서 "바일리윅"은 법적 관할이 아니라 프로토콜적 범위를 지칭합니다. 부모가 유용한 부트스트랩 레코드를 제공할 입장에 있는지를 리졸버에게 알려줄 뿐, 그 이름이나 조직 또는 주소에 대한 소유권을 확립하지 않습니다.

하나의 위임에 걸린 두 개의 시계

글루는 조율 작업도 낳았습니다. 부모와 자식은 서로 관련되면서도 다른 데이터를 보유하고, 캐시는 이 사본들이 서로 다른 시계로 노후화되게 합니다.RFC 1035는 필요한 글루가 빠진 존 파일은 거절하라고 조언했습니다. 리졸버 논의는 더 미묘한 실패를 기술합니다. 수명이 짧은 글루 주소가 만료된 뒤에도 캐시된 NS 레코드가 남아, 도달 가능한 주소가 없는 후보 서버 목록이 남을 수 있습니다.

따라서 주소 변경은 하나의 원자적 편집이 아닙니다. 자식이 부모가 글루를 바꾸기 전에 새 주소를 게시할 수도 있고, 자식의 이전 데이터가 캐시에 남아 있는 동안 부모가 먼저 바꿀 수도 있습니다. 따뜻한 캐시를 가진 리졸버는 계속 동작할 수 있지만, 차가운 리졸버는 끊어진 부트스트랩 경로를 드러냅니다. 가용성은 변경의 순서, 겹침, 만료에 달려 있습니다.

이것은 전지적이지 않은 권위입니다. 부모는 낡은 글루로 자식을 고립시킬 수 있지만 모든 리졸버 캐시를 볼 수는 없습니다. 자식은 올바른 권위 레코드를 제공할 수 있지만, 새 리졸버들이 그에 도달하지 못할 수도 있습니다. 운영상의 진실은 두 존과 수많은 독립된 시계에 분산되어 있습니다.

완전한 답이 들어가지 않을 때

원래 규칙은 이용 가능한 서버 주소를 추가 섹션에 넣으라고 했습니다. 현대의 DNS 응답은 DNSSEC 자료도 담을 수 있고, UDP 응답에는 크기 한계가 있습니다. 일부 구현은 무엇이 빠졌는지 알리지 않은 채 이용 가능한 글루의 일부만 담은 레퍼럴을 보냈습니다.

RFC 9471은 2023년 9월에 RFC 1034를 갱신했습니다. 서버는 인도메인 네임서버에 대해 이용 가능한 모든 글루를 포함하거나, 크기 때문에 불가능하면 TC 플래그를 설정해야 합니다. 이 플래그는 리졸버에게 근거 집합이 불완전하며 전체 응답을 옮길 수 있는 전송 계층으로 재시도해야 함을 알립니다.

이 명확화는 범위가 한정된 운영 증거에서 나왔습니다. RFC 9471은 2020년 6월에 필요한 글루가 들어가지 않았는데도 TC가 설정되지 않아 확인에 문제가 생긴 응답을 기록합니다. 저자들은 또한 2021년 말 ICANN CZDS 데이터의 약 2억 900만 개 위임 중 순환적인 형제 전용 위임 222건을 발견했습니다. 이것은 인터넷 전체의 실패율이 아닙니다. 드문 의존 구조라도 결정적 처리가 여전히 필요하다는 점을 보여줍니다.

이 수리 방식은 그 메커니즘의 특성을 그대로 보여줍니다. 새로운 DNS 권위를 임명하지 않습니다. 부분적 근거를 보이게 만듭니다. 서버는 불완전성을 공개하고, 리졸버는 재시도를 선택하며, 운영자는 일관된 위임 데이터에 대한 책임을 유지합니다.

소유권 증서가 아닌 좁은 다리

글루는 하나의 유한한 예외를 허용함으로써 실제 자기 참조 문제를 해결했습니다. 부모는 그렇지 않으면 자식이 도달 불가능해질 수 있으므로 자식 서버의 주소를 보유할 수 있습니다. 리졸버는 권위에 첫 패킷을 보내야 하므로 그 주소를 사용할 수 있습니다. 그러나 어느 단계도 빌린 레코드를 소유권, 서버 건강 상태 또는 제도적 정당성의 증거로 바꾸지 않습니다.

역사적 성취는 단순히 더 빠른 DNS가 아니었습니다. 데이터 처리에 새겨진 권력 분할이었습니다. 위임은 다음 권위를 지명하고, 글루는 그 권위에 도달하게 하며, 자식은 권위 있는 응답을 제공하고, 리졸버는 이 차이를 보존합니다. 인터넷은 부트스트랩 힌트를 주권으로 만들지 않고 루프를 벗어났습니다.

출처와 한계

1987년의 존 컷, 레퍼럴 및 글루 메커니즘은RFC 1034와RFC 1035에서 옵니다. 신뢰 순위와 상충하는 글루는RFC 2181로 한정됩니다. 현재 용어는RFC 8499에서, 완전성·절단·두 건의 배포 관찰은RFC 9471에서 옵니다. 이후의 언어를 1987년에 소급 적용하지 않으며, 관찰 결과를 전수 조사로 취급하지 않습니다.