dig와 nslookup으로 질의하기
앞 절에서 설명한 계층적 DNS 조회를 직접 눈으로 확인해 봅니다. dig와 nslookup은 DNS 조회를 직접 수행해 결과를 보여주는 도구입니다. macOS와 Linux에서는 기본 설치되어 있습니다.
dig로 A 레코드 조회하기
# 파일: 터미널dig example.com실행하면 여러 섹션으로 나뉜 출력이 나옵니다. 핵심 부분은 ANSWER SECTION입니다.
;; ANSWER SECTION:
example.com. 3578 IN A 93.184.216.34
각 항목의 의미입니다. example.com.은 조회한 도메인 이름입니다. 3578은 TTL로, 이 캐시가 앞으로 3578초 동안 유효하다는 뜻입니다. IN은 인터넷 클래스를 의미합니다. A는 레코드 타입입니다. 93.184.216.34는 실제 IP 주소입니다.
+trace 옵션을 추가하면 루트 서버부터 권한 서버까지 계층 전체를 직접 쫓아가는 과정을 볼 수 있습니다.
# 파일: 터미널dig +trace example.com루트 서버를 시작으로 .com TLD 서버, 그리고 example.com 권한 서버가 차례로 나타납니다. 앞 절에서 설명한 재귀 조회가 실제로 어떻게 일어나는지 눈으로 확인하는 경험입니다.
nslookup으로 조회하기
# 파일: 터미널nslookup example.comnslookup은 dig보다 출력이 간결합니다.
Server: 192.168.0.1
Address: 192.168.0.1#53
Non-authoritative answer:
Name: example.com
Address: 93.184.216.34
Server는 내 컴퓨터가 사용하는 리졸버 주소입니다. Non-authoritative answer라는 표현은 권한 서버가 아닌 캐싱 리졸버에서 가져온 답이라는 뜻입니다.
DNS 캐싱과 TTL 문제
여기서 실무에서 자주 겪는 문제를 이야기해야 합니다. 서버 IP를 바꿨는데 사용자들이 한동안 옛 IP로 접속되는 현상입니다.
원인은 TTL 캐시입니다. 위 예시에서 TTL이 3578초였습니다. 리졸버는 이 값이 만료될 때까지 이전에 받은 IP를 계속 반환합니다. 심지어 사용자 컴퓨터의 운영체제도 DNS 결과를 자체적으로 캐시합니다. 그러면 새 IP로 전파되기까지 TTL 시간만큼 기다려야 합니다.
대비책은 IP를 바꾸기 전에 TTL 값을 미리 낮춰 두는 것입니다. 보통 변경 24~48시간 전에 TTL을 수십 초로 줄여 놓습니다. 그러면 변경 후 새 IP가 빠르게 전파됩니다. 변경이 완료되면 TTL을 다시 높게 설정합니다.
운영체제의 DNS 캐시를 직접 비우는 명령도 있습니다.
# macOSsudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder# Linux (systemd-resolved)sudo systemctl restart systemd-resolved캐시를 비워도 이미 다른 리졸버들이 값을 캐시하고 있으면 전파에 시간이 걸립니다. DNS 변경은 항상 충분한 준비와 기다림이 필요합니다.
다음 장에서는 DNS로 IP를 알아낸 직후 실제로 데이터를 주고받는 프로토콜, HTTP와 HTTPS를 살펴봅니다.