브라우저에 google.com을 입력하면 어떤 일이 일어날까?

도메인과 연결된 IP를 바꾼다거나, xxx.co.kr 도메인으로 접속했을 때 xxx.com 도메인으로 변경이 필요했던 적이 있다.

AWS로 구성된 인프라 환경이었기에 Route53에 있는 레코드 값을 변경해주면 됬지만, 각각의 레코드가 어떤 의미인지 모르고 있었기에 이번에 한번 정리해보고자 한다.

추가적으로 DNS에 대해 공부하며 브라우저에 google.com을 입력하면 어떤 일이 일어나는지에 대해서도 작성해보겠다.

 

아래와 같은 순서로 작성할 예정이다.

1. DNS?

2. 브라우저에 "google.com"을 입력하면 어떤 일이 일어날까?

           1) 캐시 검사

           2) DNS 조회

           3) TCP (및 TLS) 연결 설정

           4) HTTP 요청 및 응답

           5) 브라우저의 페이지 렌더링

3. DNS 레코드 종류와 역할

4. 서브도메인?

---

1. DNS?

나는 DNS를 IP의 별칭 정도로 이해했다.

11.22.33.44 라는 IP가 있다면 이에 대한 별칭으로 google.com이 등록돼 있는 것이고, 사람들은 IP보단 별칭인 DNS인 google.com을 사용하는 것 이다.

 

면접 문제로 브라우저에 "google.com"을 입력하면 어떤 일이 일어나나요?"라는 글을 한번쯤은 본 적 있을 것 이다.

DNS는 이 과정에서 꽤나 중요한 역할을 한다.

 

2. 브라우저에 "google.com"을 입력하면 일어나는 일

아래와 같은 순서로 동작한다.

1. 캐시 검사

2.  DNS 조회

3. TCP (및 TLS) 연결 설정

4. HTTP 요청 및 응답

5. 브라우저의 페이지 렌더링

---

1) 캐시 검사 및 DNS 조회

도메인 조회 시 캐시가 존재하는지, 존재한다면 TTL이 만료되었는지 확인하고 필요한 경우 DNS 서버에 요청한다.

 

모든 사이트는 DNS 레코드에 TTL을 설정할 수 있고,  브라우저, OS 등은 이전에 수행한 DNS 조회 결과인 IP 주소를 일정 기간 동안 저장한다.

 

DNS에 변경사항이 있을 때 아래와 같은 내용을 봤던 경험이 있을 것 이다.

"DNS 변경 사항은 몇 시간 이내에 전파되지만 모든 내용이 인터넷 전체에 전파되기까지는 최대 48시간이 소요될 수 있습니다"

이 이유중 하나가 캐시를 사용하기 때문이다. 따라서 DNS에 변경사항이 생겼을 때 전파 시간은 TTL에 어느정도 의존적이다.

 

브라우저, OS, Router, ISP에서 DNS 값들을 캐시하고 있으며  DNS 레코드의 TTL길이에 따라 장단점이 있다.

 

짧은 TTL

• 장점
  • 빠른 변경 반영 : 레코드 값이 변경되었을 때 새 정보를 빠르게 받아올 수 있음
  • 유연성: 동적 환경(예: 트래픽 분산, 장애 조치, 클라우드 환경)에서 빠른 전환이 필요한 경우 유리
• 단점
  • 높은 부하: 캐시가 자주 갱신되면, DNS 쿼리 요청의 빈도 증가로 권한 있는 DNS 서버나 재귀적 DNS 서버에 부하가 증가
  • 응답 성능 저하: 캐시가 자주 만료되면, DNS 조회를 위한 추가 네트워크 요청이 발생으로 응답 시간이 길어짐

 

긴 TTL

• 장점
  • 부하 감소: 캐시에 오래 남아 있기 때문에, 동일한 레코드에 대해 반복적인 DNS 조회가 줄어들어 전반적인 네트워크 트래픽 감소
  • 빠른 응답: 이미 캐시된 정보가 오랫동안 유지되므로 사용자 입장에서는 빠른 응답을 받을 수 있음
• 단점
  • 변경 반영 지연: 레코드 정보가 변경되었음에도 불구하고, 캐시된 정보가 만료되기 전까지는 변경 사항이 반영되지 않음
  • 유연성 부족:자주 변경되는 동적 서비스에서는 긴 TTL이 오히려 문제가 될 수 있음

 

이러한 장단점이 있기에 DNS 레코드의 TTL은 아래와 같은 선택 기준을 가진다.

• 정적 또는 거의 변경되지 않는 리소스
  회사 로고 이미지, 정적 웹페이지 등은 긴 TTL을 설정하면 서버 부하를 줄이고 안정적인 응답을 유지 가능
• 동적 환경 및 빠른 장애 복구가 요구되는 리소스
  트래픽 분산, 로드 밸런싱, 또는 클라우드 기반 서비스의 경우 짧은 TTL로 설정하면, 변경 사항이 빠르게 반영되어 유연한 대응이 가능

개인적인 궁금증으로 DNS 레코드 TTL의 최대값을 찾아봤는데 약 136년 이라고 한다.

---

2) DNS 조회

만약 위 과정에서 캐시가 없다면 DNS를 통해 IP를 조회해야 한다.

먼저 DNS의 구성 요소는 아래와 같다.

 

1. DNS 클라이언트(Stub Resolver)

- 사용자 PC나 모바일 기기 등의 운영체제에 내장되어 있는 DNS 클라이언트

 

2. 재귀적 DNS 리졸버(Recursive Resolver)

- 클라이언트의 요청을 받아 DNS 계층 구조를 따라 최종 답변을 찾는 서버

 

3. 루트 네임 서버(Root Name Servers)

- DNS 최상위 계층에 위치한 서버. 전 세계에 분산되어 있으며, 전반적인 DNS 질의의 진입점 역할

 

 

4. 최상위 도메인(TLD) 네임 서버

- 루트 서버가 반환한 정보를 바탕으로, 해당 TLD(예: .com, .org, .net 등)에 대해 관리하는 서버

 

 

5. 권한 있는(Authoritative) 네임 서버

- 특정 도메인(zone)에 대한 정식 DNS 레코드를 보유하고 있는 서버

 

 

6. DNS 레코드

- DNS 레코드는 각 도메인에 대해 정의된 데이터 항목으로, 도메인과 관련된 실제 정보를 가짐

---

위의 DNS 질의는 재귀 질의와 반복 질의가 있으며 질의 방법은 아래와 같다.

클라이언트는 최종 답변을 원하므로 재귀 질의를 통해 로컬 DNS 리졸버에 요청하고, 리졸버는 내부적으로 반복 질의를 통해 최정 결과를 찾아 클라이언트에게 반환한다.

 

그렇다면 재귀 질의와 반복 질의에 대해 알아보자

 

• 재귀 질의(Recursive Query)
  • 개념
    • 클라이언트(ex. 웹 브라우저)는 자신의 로컬 DNS 리졸버(보통 ISP나 사내 DNS 서버)에 재귀적 질의를 보냄
    • 재귀 질의란 클라이언트가 “문제의 전체 해결을 대신해달라”는 요청으로, 로컬 리졸버가 최종 결과(ex. 도메인 IP 주소)를 찾아서 클라이언트에 반환하는 방식
    • 클라이언트는 중간 과정을 신경 쓰지 않고 최종 결과를 받기를 기대
  • 사용 상황
    • 클라이언트 → 재귀 리졸버
      • 일반적으로 클라이언트는 재귀 질의를 DNS 리졸버에 보냄
      • 이 리졸버는 내부적으로 반복 질의를 사용해 루트 서버, TLD 서버, 그리고 권한 있는 네임 서버에 차례대로 질의를 보내 최종적인 답을 찾아냄
    • 최종 답변 제공
      • 클라이언트는 DNS 리졸버로부터 최종 결과(IP 주소 or 오류 메시지)를 받음
      • 이를 통해 도메인 이름 해석
  • 장점
    • 클라이언트 입장에서 단순함
    • 복잡한 이름 해석 과정을 모두 DNS 리졸버가 처리해 주므로 설정이나 구현 부담이 줄어듬
    • 복수의 DNS 계층을 통해 캐싱된 데이터를 활용할 수 있어 전체 응답 시간 단축
• 반복 질의(Iterative Query)
  • 개념
    • 질의를 받은 서버가 최종 답변을 가지고 있지 않을 경우, “나 대신 이 서버에 물어봐”라는 식으로 다음 대상 서버의 정보(Referral) 제공 방식
    • 질의를 받은 서버는 클라이언트에게 바로 최종 결과를 주지 않고, 답변을 위해 필요한 다음 정보를 안내
  • 사용 상황
    • 재귀 리졸버 내부에서 사용
      • 재귀적 DNS 리졸버는 클라이언트의 재귀 질의를 처리할 때, 루트 네임 서버, TLD 네임 서버, 권한 있는 네임 서버와 반복 질의 수행
      • 예를 들어, 루트 네임 서버는 해당 도메인의 TLD 네임 서버에 대한 정보를 반환하고, TLD 네임 서버는 권한 있는 네임 서버의 정보를 제공하는 식입니다.
    • 서버 간 통신
      • DNS의 상위 계층(루트 서버나 TLD 서버 등)은 자신들이 최종 답변을 가지고 있지 않기 때문에, 반복 질의를 통해 다음 단계의 서버 정보를 안내
    • 특징
      • 서버들은 요청받은 도메인의 전체 정보를 캐싱하고 있지 않으므로, “내가 알고 있는 최선의 정보를 알려줄게” 정도로 응답
      • 재귀적 리졸버가 이러한 반복 질의를 순차적으로 수행하면서 최종적인 응답을 모음
• 결론
  • 클라이언트와의 통신에서는 재귀 질의
    • 클라이언트(사용자)는 최종 결과만 필요로 하므로, 재귀 질의를 통해 DNS 리졸버에 요청. 이는 클라이언트에서 복잡한 단계별 질의를 하지 않고도 간단하게 “나 대신 찾아줘”라고 요청
  • DNS 리졸버와 다른 DNS 서버 간의 통신에서는 반복 질의
    • 재귀 리졸버가 실제로 루트, TLD, 그리고 권한 있는 네임 서버에 대해 질의를 할 때는 반복 질의 방식 사용. 이 경우 각 서버는 최종 답을 가지고 있지 않으므로, “이 서버로 물어보라”는 식의 Referral 정보 제공
  • 결합된 동작
    • 전체 DNS 질의 과정은 클라이언트와 재귀 리졸버 간의 재귀 질의와, 재귀 리졸버와 다른 DNS 서버 간의 반복 질의가 결합되어 작동. 이렇게 함으로써 클라이언트는 단순한 인터페이스로 최종 답을 받고, 내부적으로는 효율적인 분산 처리 및 캐싱 정책 적용

 

여기까지가 DNS 서버에 원하는 정보를 요청하는 방법이고, 이 과정으로 IP주소를 얻게 되었다.

그럼 이제 IP주소를 활용해 연결하는 방법에 대해 알아보자.

---

 

3) TCP (+TLS) 연결 설정

브라우저는 DNS를 통해 얻은 IP 주소로 TCP 연결을 시도한다. HTTP - 80, HTTPS - 443 포트를 사용한다.

이후 HTTPS인 경우 TLS 핸드쉐이크를 추가적으로 진행한다.

 

1. TCP 연결 설정

TCP(Transmission Control Protocol)는 신뢰성 있는 연결 기반 통신을 위해 사용되며, 3-way handshake 과정을 통해 연결된다.

 

3-Way 핸드쉐이크 단계

1. SYN (Synchronize) 패킷 전송
   • 클라이언트는 서버에 연결 요청을 의미하는 SYN 패킷을 보낸다.
   • 이 패킷에는 클라이언트의 초기 시퀀스 번호 포함
   • 서버와의 데이터 전송 순서를 맞추기 위한 첫 번째 단계
2. SYN-ACK (Synchronize-Acknowledge) 패킷 수신
   • 서버는 클라이언트의 SYN 패킷을 받으면, 자신의 초기 시퀀스 번호와 함께 클라이언트의 시퀀스 번호에 대한 응답(Acknowledgment)을 포함하는 SYN-ACK 패킷으로 응답
   • 이 단계에서 서버는 "내 시퀀스 번호는 이것이고, 네가 보낸 SYN을 받았으니 준비 완료"라는 의미로 응답
3. ACK (Acknowledge) 패킷 전송
   • 클라이언트는 서버로부터 받은 SYN-ACK 패킷을 확인하고, ACK 패킷 전송
   • 양쪽 모두 연결을 확립했음을 확인하며 데이터 통신 시작 준비 완료

TCP 연결의 특징

• 신뢰성 보장: 시퀀스 번호와 ACK를 사용하여 데이터 패킷의 손실 및 순서 오류를 감지 및 재전송
• 흐름 제어: 클라이언트와 서버 간의 데이터 전송 속도를 조절하여 네트워크 혼잡 완화
• 혼잡 제어: 네트워크의 상태에 따라 전송 속도를 동적으로 조절하는 메커니즘을 포함하여 전체 네트워크 효율 향상

 

2. TLS 연결 설정

TLS(Transport Layer Security)는 TCP 연결 위에서 작동하는 보안 프로토콜로, 데이터 암호화와 인증을 통해 클라이언트와 서버 간의 통신을 보호. TLS 연결 설정(handshake)은 TCP 연결이 확립된 이후에 진행.

 

TLS 핸드쉐이크 단계

1. Client Hello
   • 클라이언트는 자신이 지원하는 암호화 알고리즘, TLS 버전, 난수 값을 포함하는 Client Hello 메시지를 서버에 보냄
   • 이 메시지를 통해 클라이언트는 보안 연결의 기본 조건을 제시
2. Server Hello
   • 서버는 Client Hello 메시지를 검토한 후, 사용 가능한 암호화 스위트와 TLS 버전을 선택하여 Server Hello 메시지로 응답
   • 서버는 또한 자신의 난수 값을 포함하여, 클라이언트와 이후에 생성할 암호화 키의 기초 정보를 제공
3. 인증 및 키 교환
   • 서버 인증
     • 서버는 자신의 인증서를 클라이언트에게 전송하여 신뢰할 수 있는 인증 기관(CA)이 발행한 것임을 증명
     • 클라이언트는 이를 검증하여 중간자 공격(man-in-the-middle attack) 방지
   • 키 교환
     • 클라이언트와 서버는 사전 정의된 알고리즘을 통해 세션 키 생성
     • RSA, Diffie-Hellman 등 다양한 방식으로 이루어질 수 있으며, 이를 통해 양쪽에서 사용될 대칭 암호화 키가 생성
4. Change Cipher Spec & Finished
   • 클라이언트와 서버는 “이제부터 교환될 모든 메시지는 새로 협상된 암호화 키를 사용하여 암호화된다”는 메시지를 주고받으며 핸드쉐이크 과정 종료
   • 양측은 Finished 메시지를 교환함으로써, 핸드쉐이크 동안 주고받은 모든 정보가 올바르고 동일하게 처리되었음을 확인

TLS 연결 특징

• 데이터 암호화: 전송되는 모든 데이터는 협상된 대칭 암호화 키를 통해 암호화되어 중간에 도청되더라도 내용을 알아볼 수 없음
• 데이터 무결성: 해시 기반 메시지 인증 코드(HMAC) 등을 이용하여 데이터가 전송 중 변경되지 않았음을 확인할 수 있음
• 서버(및 선택적으로 클라이언트) 인증: 인증서를 통해 상대방의 신원을 확인하여 보안 강화

TCP와 TLS 연결의 상호작용

• 순차적 연결
  • TLS 핸드쉐이크는 반드시 TCP 연결이 완전히 확립된 이후에 시작
  • TCP는 안정적인 연결을 보장하고, TLS는 이 위에 보안 계층 추가
• 통합 역할
  • TCP는 데이터 전송의 신뢰성과 순서를 보장하고, TLS는 데이터의 기밀성, 무결성 및 인증 제공
  • 이 둘이 결합되어 사용자와 서버 간의 안전한 통신을 수행

 

DNS에게 질의를 보내 IP주소를 얻었고, 이를 활용해 TCP(+TLS) 연결까지 완료되었다.

이제는 HTTP로 요청을 보내고 받는 방법에 대해 알아보자.

---

4) HTTP 요청 및 응답

HTTP/HTTPS 요청 전송

• 연결이 성립되면 브라우저는 HTTP GET 요청을 보내어 서버에 "google.com"의 기본 페이지(보통 "/")를 요청
  • 요청에는 User-Agent, Accept, Cookie 등 다양한 헤더 정보 포함

서버 처리

• Google의 웹 서버는 요청을 수신하고, 이를 처리하여 적절한 웹 페이지(HTML, CSS, JavaScript, 이미지 등) 또는 리다이렉션 정보 반환

응답 전송

• 서버는 HTTP 응답을 통해 요청한 리소스와 함께 상태 코드(예: 200 OK, 301 Moved Permanently 등) 전송

---

5) 브라우저의 페이지 렌더링

• HTML 파싱: 브라우저는 받은 HTML 문서를 파싱하여 DOM(Document Object Model)을 생성
• 리소스 요청:  HTML 내에 포함된 링크(스타일시트, 스크립트, 이미지 등)를 추가로 요청하여, 필요한 리소스를 다운로드
• 렌더 트리 구성 및 화면 출력: 최종적으로 파싱된 내용과 추가로 다운로드한 리소스를 조합해 렌더 트리를 만들고, 이를 바탕으로 웹 페이지가 화면에 렌더링

여기까지 브라우저에 "google.com"을 입력하면 일어나는 일 이었다. 이제 좀 간단한 내용에 대해 작성해보겠다.

---

3. DNS 레코드 종류와 역할

여러 레코드가 있는데 개인적으로 사용해본건 도메인 연결 시 자동으로 생기는 NS, SOA 레코드와 EC2 인스턴스 연결 시 생기는 A레코드, 그리고 별칭으로 사용하는 CNAME 레코드 정도가 있다.

 

레코드별 설명은 아래와 같다.

 

1. A 레코드 (Address Record)

• 역할: 도메인이나 서브도메인을 IPv4 주소에 매핑
• 사용 예: example.com을 192.0.2.1과 같이 특정 서버의 IPv4 주소에 연결할 때 사용

2. AAAA 레코드 (IPv6 Address Record)

• 역할: 도메인이나 서브도메인을 IPv6 주소에 매핑
• 사용 예: IPv6 네트워크 환경에서 example.com을 2001:db8::1과 같이 연결하는 경우 사용

3. CNAME 레코드 (Canonical Name Record)

• 역할: 도메인이나 서브도메인을 다른 정식 도메인(캐노니컬 네임, canonical name)으로 별칭(alias) 형태로 지정
• 사용 예: www.example.com을 example.com에 매핑하여, 동일한 콘텐츠에 대해 여러 이름을 사용할 때 유용
• 주의: 루트 도메인에는 사용할 수 없으며, A나 AAAA 레코드와 동시에 존재할 수 없음

4. MX 레코드 (Mail Exchange Record)

• 역할: 이메일 서비스의 우선 순위를 지정하고, 도메인으로 수신된 이메일을 어떤 메일 서버로 전달할지 정의
• 사용 예: example.com의 이메일 처리를 위해 mail.example.com과 같은 메일 서버 지정, 숫자로 우선 순위를 설정
• 주의: 여러 MX 레코드를 우선 순위에 따라 설정하여, 한 서버에 장애가 발생할 경우 백업 서버로 전환

5. NS 레코드 (Name Server Record)

• 역할: 해당 도메인에 대한 권한 있는(DNS authority) 네임 서버 정보를 지정
• 사용 예: 도메인의 DNS 관리를 담당하는 네임 서버(예: ns1.example.com, ns2.example.com)를 설정
• 특징: 도메인이 어디에서 관리되는지를 결정하며, 서브도메인 역시 독자적인 NS 레코드를 가질 수 있음

6. SOA 레코드 (Start of Authority Record)

• 역할: DNS 영역(zone)의 시작과 관리 정보를 정의
• 포함 정보
  • 권한을 가진(primary) 네임 서버
  • 관리자 이메일 주소
  • 시리얼 번호(데이터 업데이트 감시)
  • 리프레시, 재시도, 만료, TTL(Time To Live) 값 등
• 중요성: DNS 서버들이 데이터 일관성을 유지하고, 언제 갱신해야 하는지 파악하는 데 필수적

7. PTR 레코드 (Pointer Record)

• 역할: IP 주소를 도메인 이름으로 역변환(reverse lookup)할 때 사용
• 사용 예: 주로 이메일 서버의 신뢰성 검증 및 네트워크 문제 해결 용도, IP 주소가 192.0.2.1일 때 해당하는 도메인 이름을 반환

8. TXT 레코드 (Text Record)

• 역할: 도메인에 대한 임의의 텍스트 정보를 저장합니다.
• 사용 예
  • SPF(Sender Policy Framework) 설정을 통해 스팸 메일 예방
  • DKIM(DomainKeys Identified Mail) 및 DMARC(Domain-based Message Authentication, Reporting and Conformance) 설정
  • 도메인 소유 검증용(예, Google Search Console 검증)
• 특징: 자유로운 문자열 입력이 가능하여 다양한 용도로 활용

9. SRV 레코드 (Service Record)

• 역할: 특정 서비스(예: VoIP, SIP, LDAP 등)를 제공하는 서버의 위치(호스트 및 포트)를 지정
• 사용 예: sip.example.com 같은 서비스에 대해, 어떤 서버와 포트로 연결해야 하는지 정보를 제공
• 추가 기능: 우선 순위와 가중치(weight) 값을 설정해 부하 분산도 조절 가능

10. DS 레코드 (Delegation Signer Record)

• 역할: DNSSEC(DNS Security Extensions)에서 도메인의 서명을 검증하는 데 사용되는 레코드
• 사용 예: 상위 도메인에 도메인 위임 시, 도메인의 DNSSEC 신뢰 체인을 구성하는 역할

11. CAA 레코드 (Certification Authority Authorization Record)

• 역할: 도메인에 대해 SSL/TLS 인증서를 발급할 수 있는 인증 기관(CA)를 제한
• 사용 예: 도메인 소유자가 승인한 특정 CA만 인증서를 발급하도록 하여, 잘못된 인증서 발급으로 인한 보안 문제를 예방

4. 서브도메인?

서브도메인은 기본 도메인의 왼쪽에 추가되는 이름으로, 계층적 DNS 네임스페이스 내에서 하위 영역을 구성한다.

예를 들어 "example.com" 도메인을 구입했다면, "www.example.com", "api.example.com"등의 원하는 이름을 붙여 별도의 서비스를 운영할 수 있다.

---

원래는 DNS에 대해서만 작성하려 했지만 어쩌다 보니 브라우저에 google.com을 입력하면 일어나는 일에 대해서도 작성하게 되었다.

작성하고 나서 다른 글들을 찾아보니 DNS로부터 IP를 가져온 뒤의 흐름이 많이 부실해보인다.

이후 내용은 다음에 좀 더 자세히 작성할 예정이다.