[AWS Networking] DNS와 보안 (Route53 & Security)

실무에서 /etc/hosts 파일을 수정했을 때, 브라우저가 DNS 서버를 거치지 않고도 특정 IP로 접속해버리는 것처럼 보이는데, 이 원리에 대해서 알지 못하다는 생각이 들었다. 이 기회에 브라우저에 URL을 입력하면 일어나는 전 과정에 대해서 알아보도록 한다. 

 

1. URL 입력부터 서버 도달까지

사용자가 브라우저에 https://app.example.com/path 를 입력하면 대략 이런 일이 일어난다. 

1. 이름 해석(Name resolution): app.example.com → IP(또는 대상) 찾기
2. 연결(Connection): IP로 TCP 연결(443)
   →  로드 밸런서(ALB) 와 TCP 연결을 맺게됨. 로드 밸런서가 대신 받아서 "어서 와(SYN/ACK)"라고 응답.
3. TLS 핸드셰이크(HTTPS): 어떤 도메인에 접속하는지(SNI) 전달, 인증서 선택
   → HTTPS 인증서는 보통 로드 밸런서에 설치.
   →  브라우저가 암호화해서 보낸 데이터를 로드 밸런서가 여기서 해독(Decryption)
4. HTTP 요청 전송: Host: app.example.com 헤더로 “어느 서비스인지” 구분
5. AWS 내부 라우팅: (CloudFront/ALB 등) → 대상 서비스로 전달
6. 보안 필터링: 서브넷 경계(NACL) → 인스턴스 경계(Security Group)
   →  NACL (Network ACL): "이 서브넷(마을)에 들어와도 돼?" (큰 대문)
   →  Security Group: "이 인스턴스(집) 문을 열어도 돼?" (현관문)

 

 

2. /etc/hosts를 수정했을 때 “DNS를 거치지 않는 것처럼 보이는” 이유

DNS의 역할은 “도메인 이름을 IP로 바꾸는 것”뿐이고, /etc/hosts는 그 변환을 로컬에서 먼저 해버리기 때문이다.

 

1-1. 이름 해석 우선순위: hosts가 먼저다

대부분의 OS는 도메인 → IP를 찾을 때 보통 이런 순서로 확인한다.

1. /etc/hosts (macOS/Linux) 또는 C:\Windows\System32\drivers\etc\hosts
2. OS/브라우저 DNS 캐시
3. 설정된 DNS 리졸버(공유기/회사/ISP/1.1.1.1/8.8.8.8 등)에게 질의

그래서 /etc/hosts에 다음을 넣으면:

203.0.113.10  app.example.com

브라우저는 “이미 답을 알고 있으니” DNS 서버에 물어볼 필요가 없다. 즉 DNS Lookup 단계가 생략되는 것이다.

 

1-2. 그런데 HTTPS에서는 왜 경고가 뜰 수 있을까?

• DNS는 “이름 → IP”만 해결한다.
• 하지만 HTTPS는 “이 서버가 진짜 app.example.com이 맞는지”를 인증서로 검증한다.

그래서 hosts로 IP를 강제했는데 접속은 되더라도,

• 인증서가 해당 도메인에 맞지 않거나
• 로드밸런서/서버가 그 도메인용 인증서를 못 고르면

브라우저가 인증서 경고를 띄울 수 있다.

 

 

 

3. DNS 작동 원리: A / CNAME / Alias

DNS로 IP를 얻은 다음, 같은 IP에서 여러 도메인을 어떻게 구분하지?

 

3-1. DNS는 “계층형 전화번호부”

브라우저(정확히는 OS)는 보통 “리졸버(Recursive Resolver)”에 물어보고, 리졸버가 필요하면 Root → TLD(.com) → Authoritative DNS 순으로 찾아가며 결과를 캐싱한다.

→   AWS에서 Route 53은 보통 Authoritative DNS(권한 DNS) 로 쓰인다.

 

3-2. A Record: 도메인 → IPv4 주소

• app.example.com → 203.0.113.10

→ DNS 결과가 “바로 IP”로 끝난다. (🤝 바로 전화번호 알려줌)

 

3-3. CNAME Record: 도메인 → 다른 도메인

• app.example.com → my-alb-123.ap-northeast-2.elb.amazonaws.com

“다른 도메인 이름”을 알려준다. (🗣 다른 사람에게 물어봐!) 
→  리졸버는 이 값을 받고 다시 한번 조회해서 최종 IP를 얻는다

 

3-4. Route 53 Alias 레코드 (Route 53 전용 느낌)

Route 53에서 자주 보는 Alias는 표준 DNS 레코드 타입이라기보다, Route 53이 AWS 리소스(CloudFront, ALB, S3 website 등) 에 자연스럽게 붙여주기 위한 기능이다. 겉보기에는 A처럼 동작하지만 의미는 “AWS 리소스를 가리키는 별칭”에 가깝다.

• example.com (루트 도메인) → Alias → CloudFront/ALB

 

 

4. DNS Lookup 이후 Host Header (그리고 HTTPS라면 SNI)

DNS는 app.example.com을 “어느 IP로 갈지”까지만 결정한다.
하지만 그 IP(혹은 ALB/CloudFront)가 여러 서비스를 동시에 받는다면 “어느 서비스로 보낼지”는 DNS만으로는 부족하다.

여기서 등장하는 게 Host Header다.

 

4-1. HTTP 요청의 핵심: Host:

[브라우저 요청]
GET /path HTTP/1.1
Host: app.example.com

 

로드밸런서(또는 웹서버)는 이 Host 값을 보고, 가상 호스트(Virtual Host) 라우팅을 할 수 있다.

 

• app.example.com이면 앱 서비스로
• api.example.com이면 API 서비스로

4-2. HTTPS라면 SNI도 같이 이해해야 한다

TLS 핸드셰이크 단계에서 브라우저는 SNI를 통해 “내가 원하는 도메인 이름”을 먼저 전달한다.

• SNI가 있어야 로드밸런서가 올바른 인증서를 선택할 수 있다.
• 그래서 hosts로 IP를 바꾸면 DNS는 해결돼도, TLS/인증서 문제가 생길 수 있다.

 

 

5. Route 53 라우팅: 가중치 기반 라우팅으로 A/B 테스트가 되는 원리

5-1. 가중치 라우팅이 하는 일

Route 53은 같은 도메인에 대해 여러 개의 “대상”을 등록하고, 가중치(Weight)에 따라 확률적으로 응답을 분산한다.

예를 들어:

• app.example.com → Target A (Weight 90)
• app.example.com → Target B (Weight 10)

그러면 어떤 요청은 A로, 어떤 요청은 B로 간다. 겉으로 보면 A/B 테스트처럼 보인다.

 

5-2. 그런데 DNS 기반 분산은 ‘정교한 유저 고정’이 아니다

DNS 분산은 보통 **“사용자 1명 = 1번 추첨”**이 아니다.

왜냐하면:

• DNS 응답은 리졸버/OS/브라우저 캐시에 저장되고
• TTL이 남아 있는 동안 같은 결과를 계속 쓸 수 있으며
• 회사/통신사 리졸버를 여러 사용자가 공유할 수 있기 때문이다.

즉 “유저 단위로 고정된 실험”이라기보다는, 점진적 배포(카나리), 장애 시 전환, 트래픽 분산에 더 어울리는 방식으로 이해하는 게 안전하다.

https://jibinary.tistory.com/421

 

5-3. TTL이 중요한 이유

• TTL이 길면: 변경/롤백이 느리다.
• TTL이 짧으면: 반영은 빠르지만 조회량이 늘 수 있다.

 

 

6. Security Group

virtual firewall

• Security Group (SG): 인스턴스/ENI에 붙는 Stateful(상태 기반) 방화벽

Security Group
 ├─ Inbound rules
 │    - 80 허용
 │    - 443 허용
 │    - 22 허용
 │
 └─ Outbound rules
      - 443 허용
      - 53 허용
      - 0.0.0.0/0 허용
-------------------------------------------

Client
  ↓
Security Group (Inbound 검사)
  ↓
EC2
  ↓
Application
  ↓
Security Group (Outbound 검사)
  ↓
Internet

EC2 listen port (80, 8080, 3306) - 부두 담당팀

 

• 포트를 연다 = “우리 항구의 몇 번 부두를 운영한다”
• SG에서 허용한다 = “그 부두까지 배가 들어오거나 나가도 되게 허가한다”

* SG 의 실패상황 (timeout 참고)

 

외부 요청이 SG 에서 막혔을 때