캐시와 bailiwick — 어디까지 믿을 수 있는가
referral·glue·bailiwick 을 나누고, 어디까지를 cache 에 넣어도 되는지 정리한다.
이전 장의 복습: 제 1 장에서는 shared recursive resolver 의 cache 에 거짓 RRset 이 남으면, 이용자 전체에게 같은 오답이 배포되는 구도를 확인했습니다. 본 장에서는 그 「resolver 가 무엇을 cache 에 넣어도 되는가」를 판단하는 기준으로서 referral / glue / bailiwick 을 정리합니다.
위임에서는 「최종 answer」가 아니라 「다음 행선지」가 돌아온다
recursive resolver 는 처음부터 최종 답만 받는 것이 아닙니다. 부모 존은 child zone 의 NS 를 가리키는 referral 을 돌려주고, resolver 는 그 안내를 사용해 다음 authoritative server 로 진행합니다.
| 장소 | 자주 들어가는 것 | 사고 방식 |
|---|---|---|
| ANSWER | 최종 RRset | 정말로 원하는 이름·형의 답인가 |
| AUTHORITY | NS / SOA | referral 인가 부정 응답인가 |
| ADDITIONAL | glue / 보조 주소 | 다음으로 진행하기 위한 발판인가, 무관한 추가 데이터인가 |
연습 2-1 — glue 는 다리 역할의 발판
in-bailiwick 한 NS 이름에 대한 A / AAAA 가 Additional 에 있으면, resolver 는 child zone 에 도달하기 쉬워집니다.
Q1. 부모 존 example.com 이 shop.example.com 을 ns1.shop.example.com 으로 위임하고, referral 의 Additional 에 ns1.shop.example.com A 192.0.2.53 이 들어 있었습니다. 이 추가 정보의 설명으로 가장 가까운 것은 어느 것입니까.
자식 존으로 도달하기 위한 「발판」인지 아닌지를 생각합니다.
이것은 자식 존으로 따라가기 위한 in-bailiwick glue 입니다. 위임을 진행하는 보조 정보로서 도움이 되지만, 일반 최종 answer 와 같은 강도로 취급하지는 않습니다.
Q2. delegation 의 NS 군이 dig 의 출력에서 주로 나타나는 곳은 어디입니까.
referral 은 「최종 answer」보다 「다음 행선지」를 나타냅니다.
delegation 의 NS 군은 dig 에서는 주로 AUTHORITY 섹션에 나타납니다. ANSWER 는 최종 RRset, ADDITIONAL 은 glue 나 보조 주소, QUESTION 은 질의된 이름·형·클래스가 들어가는 섹션입니다(dig 의 출력은 HEADER / QUESTION / ANSWER / AUTHORITY / ADDITIONAL 의 5 섹션 구성입니다).
bailiwick 판정의 3 가지 시나리오
Additional 에 있는 레코드를 어떻게 취급할지는, 그 레코드가 referral 하고 있는 위임 범위의 내측(in-bailiwick)인가 외측(out-of-bailiwick)인가에 따라 달라집니다.
여기서의 판정은 개념 학습용입니다. 구현마다 세부는 달라도, 「위임의 발판」과 「무관한 추가 데이터」를 나누어 생각하는 관점이 중요합니다.
out-of-bailiwick additional 은 신중히 다룬다
referral 의 Additional 에 unrelated 한 데이터가 섞여 있으면 위험합니다. 그래서 resolver 구현은 어느 범위의 glue 를 어떻게 믿을지 엄격하게 다룹니다. 이 맥락에서 자주 등장하는 것이 bailiwick 입니다.
bailiwick 의 어원: 원래는 중세 영국법에서 「bailiff(집행관)의 관할 구역」을 가리키는 법률 용어이며, 「어떤 주체가 책임을 지는 범위」라는 함의가 있습니다. DNS 의 맥락에서는 이를 전용하여, 「위임원의 존이 책임을 지는 이름 공간의 범위 안에 있는가」를 판단하는 사고 방식으로 사용합니다. referral 의 Additional 에 나타난 레코드가 그 위임의 범위(bailiwick)의 안쪽에 있으면 in-bailiwick, 바깥쪽에 있으면 out-of-bailiwick 이라고 부릅니다.
연습 2-2 — out-of-bailiwick additional 은 신중히 다룬다
referral 의 Additional 에 unrelated 한 데이터가 섞여 있으면 위험합니다. bailiwick 은 어느 범위의 glue 를 어떻게 믿을지 제한하는 사고방식입니다.
Q3. example.com 으로부터 ns.partner.net 으로의 referral 에 ns.partner.net A 198.51.100.10 이 Additional 로 함께 왔습니다. 가장 보수적인 취급은 어느 것입니까.
그 추가 A 가 example.com 의 지배하에 있는지를 확인합니다.
out-of-bailiwick 의 추가 정보는 권위 데이터로서 전면적으로 믿지 않고, 필요하다면 그 이름 자체를 별도로 해석하는 것이 안전한 쪽입니다. bailiwick 의 사고 방식은 무관한 추가 데이터의 혼입을 억제하기 위해 있습니다.
Q4. bailiwick 이라는 사고 방식의 주목적으로 가장 가까운 것은 어느 것입니까.
「어느 범위의 소개장이라면 받아들이는 방식을 엄격하게 할 것인가」를 생각합니다.
bailiwick 은 referral 에 편승하여 섞여 들어간 무관한 추가 데이터의 수락을 억제하기 위한 사고 방식입니다. 이로써 resolver 는 glue 의 취급을 한정할 수 있습니다.
Q5. Additional 의 glue 에 대해 올바른 것은 어느 것입니까.
glue 는 편리하지만, 역할은 「다리 역할」입니다.
glue 는 delegation 을 따라가는 보조 정보입니다. 「취급을 한정한다」는 것은 구체적으로 (1) in-bailiwick glue 만을 위임의 발판으로 사용한다, (2) out-of-bailiwick 의 Additional 은 권위 데이터로 믿지 않고, 필요하다면 별도로 해석한다, (3) Additional 의 레코드를 이용자가 질의한 이름의 최종 answer 로 취급하지 않는다, 라는 3 가지로 나누어 생각하는 것을 의미합니다.
제 2 장의 정리
- delegation 의 NS 는 주로 AUTHORITY, 발판의 glue 는 ADDITIONAL 에 나타난다
- in-bailiwick glue 와 out-of-bailiwick additional 은 같은 강도로 믿지 않는다
- bailiwick 은 무관한 추가 데이터의 혼입을 억제하기 위한 관점