도메인 이름 하나가 IP 주소로 바뀌는 여정
DNS는 사람이 사용하는 도메인 이름에 연결된 정보를 계층적인 이름 공간에서 찾는 분산 시스템이다. IP 주소 조회가 가장 익숙하지만 메일 서버, 이름 별칭, 각종 검증 정보처럼 여러 종류의 레코드를 제공한다. 이름 하나가 항상 주소 하나에만 대응하는 것도 아니다.
권한 서버가 정보를 제공하고 리졸버는 위임과 캐시를 이용해 답을 찾는다.
누가 어떤 구역을 책임질까
example.com의 정보를 찾는다고 하자. 사용자의 장치는 보통 재귀 리졸버에 질의한다. 리졸버에 사용할 수 있는 캐시가 없다면 루트 서버에서 .com을 책임지는 서버의 정보를 받고, 해당 TLD 서버에서 example.com의 권한 서버 정보를 알아낸 뒤, 권한 서버에 원하는 레코드를 묻는다. 이 설명의 도메인은 예시용으로 예약되어 있다.
재귀 질의는 질의받은 쪽이 최종 답을 알아내 주기를 요청한다. 반복 질의에서는 서버가 아는 답 또는 다음에 물어볼 곳을 돌려주고 요청자가 탐색을 이어간다. 실제 통신에서는 이미 캐시된 위임과 레코드 때문에 매번 처음부터 루트까지 찾아갈 필요가 없다.
A 레코드는 IPv4 주소, AAAA는 IPv6 주소를 나타낸다. CNAME은 다른 이름을 가리키는 별칭이며, MX는 메일 교환기를 위한 정보다. 레코드의 종류가 다르면 같은 이름에 대해 서로 다른 목적의 답이 존재할 수 있다. 주소 결과가 여럿인 경우 클라이언트의 선택과 네트워크 조건도 실제 연결에 영향을 준다.
TTL은 변경이 보이는 속도에도 관여한다
TTL은 캐시가 정보를 얼마 동안 사용할 수 있는지를 제한한다. 짧게 설정하면 변경을 더 빨리 다시 확인할 가능성이 커지지만 질의 부하도 늘어난다. 긴 TTL은 조회 비용을 줄이면서 변경 후 이전 정보가 남는 시간을 길게 할 수 있다. 권한 서버에서 값을 바꾼 순간 모든 사용자의 캐시가 동시에 갱신되지는 않는다.
DNS 응답이 왔다고 웹 서비스가 정상이라는 뜻은 아니다. 이름 해석, 서버 연결, TLS 검증, HTTP 처리는 서로 다른 단계다. DNSSEC은 DNS 데이터의 인증과 무결성을 위한 체계이며, DNS 트래픽의 기밀성을 자동 제공하지 않는다. 암호화된 DNS 전송과도 구분해야 한다.
문제를 추적할 때는 어느 리졸버를 사용했는지, 어떤 레코드 유형을 조회했는지, 답의 TTL과 권한 정보를 함께 확인하면 좋다. 서로 다른 장소에서 다른 주소가 보이는 원인은 캐시, 정책, 지리적 응답 등의 여러 가능성이 있다. DNS는 하나의 전화번호부 서버라기보다 권한을 나눠 가진 여러 구역과 그 정보를 재사용하는 캐시의 협력으로 이해하는 편이 정확하다.
존과 도메인도 같은 말처럼 사용하지 않는 편이 좋다. 도메인은 이름 공간의 하위 트리이고, 존은 특정 권한 서버가 관리하는 범위다. 하위 도메인을 별도의 관리자에게 위임하면 그 부분은 다른 존이 될 수 있다. 위임 경계에 있는 이름 서버 정보와 실제 호스트 주소 레코드는 역할이 다르다. 또한 존재하지 않는 이름이라는 답도 정책에 따라 일정 시간 캐시될 수 있어, 방금 레코드를 추가했는데 아직 해석되지 않는 상황이 발생한다. 조회를 비교할 때 긍정 응답만 보지 말고 오류의 종류와 부정 캐시도 확인해야 한다. DNS는 매번 최신 값을 직접 읽는 중앙 데이터베이스가 아니라 권한과 캐시가 함께 동작하는 시스템이다.