DNS 조회 과정

가까운 캐시부터 훑고 없으면 위로 올라갑니다.

4번부터 6번은 로컬 DNS 서버가 대신 돌아다니고, 결과를 캐시해 다음 요청부터는 3번에서 끝납니다.

흔한 실수: 매 요청이 루트까지 간다고 답하는 것. 실제로는 캐시 적중률이 높아 대부분 1번에서 3번 안에서 끝납니다. 루트 서버가 전 세계 13개 주소로 운영되는데도 버티는 이유입니다.

누가 돌아다니는지가 다릅니다.

실제 조합은 이렇습니다.

이렇게 나눈 이유는 부하와 캐시 때문입니다. 루트 서버가 모든 클라이언트의 재귀 요청을 받으면 감당할 수 없습니다. 로컬 서버가 대신 돌고 결과를 캐시하면 같은 도메인 요청이 거기서 끝납니다.

흔한 실수: 둘을 순서 개념으로 이해하는 것. 재귀와 반복은 책임을 누가 지는가의 차이입니다.

여러 층에서 이뤄지고, TTL 이 각 층의 보관 기간을 정합니다.

TTL 은 권한 서버가 응답에 실어 보내는 값으로 이 답을 얼마 동안 재사용해도 되는지를 알려줍니다.

TTL 이 길면   조회 부하와 지연이 준다. 대신 변경 반영이 느리다
TTL 이 짧으면 변경이 빨리 퍼진다. 대신 조회가 잦아진다

그래서 서버 이전 며칠 전에 TTL 을 낮춰두고, 이전이 끝나고 안정되면 다시 올리는 절차를 씁니다. 낮춘 값이 퍼지는 데도 기존 TTL 만큼 걸리기 때문에 미리 해야 합니다.

흔한 실수: 변경 직후 TTL 을 낮추는 것. 이미 옛 값을 받아간 서버들은 원래 TTL 이 끝날 때까지 그대로입니다.

CNAME 은 이름을 다시 조회해야 하므로 왕복이 한 번 더 듭니다. 그리고 루트 도메인에는 CNAME 을 둘 수 없습니다. 같은 이름에 다른 레코드(MX, NS)가 함께 있어야 하는데 CNAME 은 그것을 금지하기 때문입니다.

그래서 루트 도메인을 CDN 이나 로드밸런서에 붙일 때는 제공자별 대체 방식(A 레코드 자동 갱신, ALIAS 유형)을 씁니다.

흔한 실수: 루트 도메인에 CNAME 을 걸려다 실패한 뒤 원인을 못 찾는 것. 표준 제약이라 서비스마다 우회 수단을 확인해야 합니다.

DNS 는 주소를 알려줄 뿐 서버 상태를 모릅니다.

그래서 실무에서는 DNS 로 지역이나 데이터센터를 고르고, 그 안에서 로드밸런서가 실제 분배와 헬스 체크를 맡는 2단 구조를 씁니다.

TTL 을 짧게 잡으면 전환은 빨라지지만 조회가 늘고, 일부 해석기는 짧은 TTL 을 무시하기도 해서 한계가 남습니다.

흔한 실수: DNS 라운드 로빈을 장애 대응 수단으로 쓰는 것. 서버가 죽어도 주소가 계속 나가 일부 사용자가 실패합니다.