DNS란?

백엔드 개발하면서 배포를 해보면 이런 흐름이 너무 익숙하다.

• “도메인 붙였어요”
• “이제 api.myservice.com으로 접속하세요”

근데 브라우저/클라이언트가 실제로 통신할 때 필요한 건 결국 IP:PORT다.
DNS는 이 간극을 메워주는 시스템이다.

1) DNS는 뭐 하는 시스템인가?

DNS(Domain Name System) 는 한 문장으로

사람이 읽기 쉬운 도메인 이름을 컴퓨터가 통신 가능한 IP 주소로 바꿔주는 시스템

• 도메인: example.com
• IP: 93.184.216.34 같은 숫자 주소

도메인은 IP가 바뀌어도 유지될 수 있고 서버를 옮기거나 로드밸런서를 붙여도 도메인만 유지하면 사용자 입장에선 변화가 없다.

2) DNS 조회는 대충 이런 순서로 진행된다

브라우저에 www.google.com을 입력하면:

1. 로컬 캐시 확인

• 브라우저/OS가 이전에 찾은 DNS 결과를 가지고 있는지 확인

2. 리졸버(Recursive Resolver)에게 물어봄

• 보통 통신사/회사 네트워크/공용 DNS(예: 8.8.8.8) 같은 “DNS 서버”에 요청

3. 권한 있는 DNS 서버(Authoritative DNS)까지 찾아감

• 최종적으로 해당 도메인의 정답을 알고 있는 서버에서 IP를 받아옴

4. 클라이언트는 그 IP로 TCP 연결을 맺고(필요 시), HTTP 요청을 보냄

실무적으로는 “캐시 → DNS 서버에 질의 → IP 획득” 정도로 이해해도 충분히 큰 그림이 잡힌다. 

3) DNS 캐시와 TTL이 중요한 이유

DNS 결과는 매번 조회하면 느리니까 캐시를 한다.
이때 “얼마 동안 이 결과를 믿을지”를 정하는 값이 TTL(Time To Live) 이다.

• TTL이 길면: DNS 조회가 줄어 빨라지지만, IP 변경 반영이 느릴 수 있음
• TTL이 짧으면: 변경 반영은 빠르지만 DNS 조회가 늘어날 수 있음

배포/장애 대응 때 “DNS 변경했는데 왜 아직도 옛날로 접속되지?” 같은 상황이 종종 발생하는데, 이런 경우 TTL/캐시 영향일 때가 많다.

4) DNS가 알려주는 건 보통 “IP”까지다

DNS는 주로 도메인 → IP를 알려준다.
그 다음 실제 통신 대상은 보통 이렇게 완성된다:

• IP:PORT

예)

• example.com → DNS로 IP 찾고
• HTTP면 보통 80, HTTPS면 443으로 접속 (포트는 프로토콜 기본값이 있음)

개발 환경에선 직접 포트를 붙여서 쓰는 경우가 많다.

• localhost:8080
• api.myservice.com:8080 (운영에선 보통 LB/리버스 프록시로 포트 숨김)

5) 개발자 관점에서 DNS를 체감하는 순간

1. 도메인 연결

• “도메인 구매 → DNS 레코드 설정 → 서버/로드밸런서로 연결”

2. 배포/이전

• 서버 IP가 바뀌었는데 도메인은 유지
• DNS만 바꾸면 사용자 접속 경로를 바꿀 수 있음

3. 장애/트래픽 분산

• DNS 또는 로드밸런서로 여러 서버에 분산
• 다만 DNS는 캐시가 있어서 “즉시 전환”이 어려울 수 있음(TTL 영향)