1) DNS 질의 단계-by-단계 흐름도
예: 브라우저가
www.example.com의 IP를 찾는 과정
[브라우저/앱]
│ ① 브라우저 캐시 확인
▼
[OS 스텁 리졸버]
│ ② /etc/hosts(또는 hosts 파일) → OS DNS 캐시 확인
▼
[재귀 리졸버(Resolver)]
(ISP/회사 DNS, Route 53 Resolver, DoH 등)
│ ③ 캐시 확인(있으면 바로 응답, TTL 소진까지 유효)
│ ④ 캐시 미스 시 권위 네임서버를 단계적으로 탐색
▼
(4-1) 루트 . 네임서버
│ ⑤ "TLD(.com) 담당 네임서버 주소" 돌려줌 (권위 위임)
▼
(4-2) TLD(.com) 네임서버
│ ⑥ "example.com 담당 네임서버(NS)" 돌려줌
▼
(4-3) 권한 있는(Authoritative) 네임서버
│ ⑦ 레코드 조회:
│ - A/AAAA면 → 최종 IP 반환
│ - CNAME면 → 대상 이름으로 다시 ④~⑦ 반복
│ - (Route 53 ALIAS면 내부적으로 대상 IP 계산 후 반환)
▼
[재귀 리졸버]
│ ⑧ 받은 결과를 TTL 동안 캐싱
▼
[OS/브라우저]
│ ⑨ 응답 수신(필요 시 TTL 동안 로컬 캐시)
▼
[애플리케이션 연결 시도 → IP로 TCP/TLS]흐름 이해 포인트
- Authoritative 가 정답의 원본. 루트/TLD는 “다음 NS가 누구인지”만 알려줌(위임).
- 캐시는 브라우저 → OS → 재귀 리졸버 순서로 존재. TTL(Time To Live) 동안 재질의 없이 응답.
- CNAME 체인은 추가 조회를 유발. apex(CNAME 불가) 는 Route 53의 ALIAS 같은 기능으로 해결.
- 음수 캐시: “없는 이름(NXDOMAIN)” 정보도 SOA의 Negative TTL 동안 캐시되어 재시도 폭주를 막음.
2) 레코드 타입별 “언제/어떻게 쓰나” 시나리오 표
| 타입 | 쓰임새(언제) | 값/제약(어떻게) | 예시 |
|---|---|---|---|
| A | IPv4로 연결해야 할 때(가장 흔함) | 값=IPv4. 같은 이름에 여러 A로 라운드로빈 가능 | www A 203.0.113.10 |
| AAAA | IPv6 제공 | 값=IPv6 | www AAAA 2001:db8::10 |
| CNAME | 별칭이 필요할 때(서비스 도메인으로 위임) | 그 이름엔 CNAME 하나만 존재 가능(다른 레코드와 공존 불가). Apex는 불가 | cdn CNAME d111.cloudfront.net |
| ALIAS (Route 53) | apex에서 CloudFront/ALB/S3 웹 등으로 가리킬 때 | A/AAAA처럼 동작(쿼리 비용만). 표준 DNS엔 없음(벤더 확장) | example.com ALIAS d111.cloudfront.net |
| NS | 하위 존 위임/도메인 권위 네임서버 지정 | 도메인/서브존의 담당 NS 목록 | example.com NS ns-123.awsdns.com |
| SOA | 존 메타데이터(권위 시작) | 시리얼/리프레시/리트라이/네거티브 TTL 등 | 자동 생성(수정 드묾) |
| MX | 메일 수신 서버 지정 | 값=호스트명(+우선순위). IP 직접 기재 불가 | example.com MX 10 mxa.mailhost.com |
| TXT | 도메인 소유 증명, SPF/DMARC, 앱 검증 | 자유 텍스트. SPF는 TXT에 기록 | @ TXT "v=spf1 include:_spf.mailhost ~all" |
| SRV | 서비스/포트 위치(VoIP, LDAP 등) | _service._proto.name 형식, 포트·우선순위 포함 | _sip._tcp.example.com SRV 10 60 5060 sip1.example.com |
| CAA | 인증서 발급 허용 CA 제한 | 잘못된 CA 발급 위험 줄임 | example.com CAA 0 issue "amazon.com" |
| PTR | IP→이름(역방향 조회) | 주로 메일 신뢰도·진단용 | 10.113.0.203.in-addr.arpa PTR www.example.com |
TTL 운용 팁
- 변경 직전엔 TTL을 짧게(예: 60s) 낮춰 두면 전파 시간 단축(변경 후 다시 늘리기).
- 트래픽 높은 이름은 너무 짧은 TTL이 리졸버 부하/비용을 올릴 수 있음 → 5~10분 실무 흔함.
3) 실전 레시피
A) 새 웹사이트를 ALB/CloudFront로 연결 (Route 53)
- Hosted Zone 생성(또는 기존 사용).
@(apex)에 ALIAS → CloudFront/ALB 레코드 생성.www는CNAME → apex또는 직접 ALIAS.- TTL은 초기에 60s, 안정화 후 300~600s.
B) 서브도메인을 별도 팀 DNS로 위임
- 팀이
dev.example.com용 Hosted Zone을 가진다. - 팀 존의 NS 레코드 값을 받아, 상위 존(example.com)에
dev NS ...추가. - 이후
dev이하 레코드는 팀이 자율 운영.
C) 이메일 수신 설정
- 이메일 호스팅 사업자가 준 MX 값을 그대로 기록(호스트명).
- SPF(TXT), DKIM(CNAME/TXT), DMARC(TXT) 추가.
- MX는 IP가 아닌 호스트를 가리켜야 함.
4) 자주 터지는 오류와 예방책
- apex에 CNAME 생성 오류 → Route 53 ALIAS 사용.
- CNAME와 다른 레코드 공존 → 이름당 CNAME 단독 원칙 기억.
- 변경이 안 먹는 것처럼 보임 → TTL/캐시/브라우저 DNS 캐시 플러시 확인.
- 메일 수신 불가 → MX가 호스트명인지, 방화벽/스팸필터 및 SPF/DMARC 설정 확인.
- 역방향(PTR) 미설정으로 메일 스팸 판정 → 발신 IP의 PTR 요청.
5) 요약
- 질의는 브라우저/OS 캐시 → 재귀 리졸버 → 루트 → TLD → 권위 NS 순.
- A/AAAA(IP), CNAME/ALIAS(이름→이름), MX/TXT/SRV/CAA는 정책/서비스 연동에 필수.
- TTL과 캐시를 계획적으로 조절하면 무중단 전환과 비용/부하를 모두 잡을 수 있다.
`•.¸¸.•´´¯`••._.• 🎀 𝒸𝓇𝒶𝓏𝓎 𝓅𝓈𝓎𝒸𝒽💞𝓅𝒶𝓉𝒽 🎀 •._.••`¯´´•.¸¸.•`