DNS(Domain Name System) 완벽 정리

1. DNS란 무엇인가? - 인터넷의 전화번호부

우리가 전화를 걸 때 친구 이름으로 검색하듯, 인터넷에서도 "www.google.com" 같은 이름으로 웹사이트에 접속합니다. 하지만 컴퓨터와 서버는 이름이 아니라 숫자(IP 주소)로 서로를 찾습니다.

비유: DNS는 인터넷 세계의 전화번호부입니다. "김철수"라는 이름을 검색하면 "010-1234-5678"이라는 번호가 나오듯, "www.google.com"을 입력하면 "142.250.196.68"이라는 IP 주소를 찾아줍니다.

• 도메인 이름: 사람이 읽기 쉬운 주소 (www.google.com)
• IP 주소: 컴퓨터가 이해하는 숫자 주소 (142.250.196.68)
• DNS: 도메인 이름을 IP 주소로 변환해주는 시스템

2. DNS 조회 과정 - 단계별 여행

브라우저에 "www.google.com"을 입력하면, DNS는 다음과 같은 여정을 거칩니다.

2-0. 가장 먼저: hosts 파일 확인

DNS 서버에 물어보기 전에, 운영체제는 로컬에 저장된 hosts 파일을 먼저 확인합니다. hosts 파일에 해당 도메인이 등록되어 있으면, DNS 조회 자체를 하지 않고 바로 IP를 반환합니다.

hosts 파일의 형식은 간단합니다:

127.0.0.1   localhost
192.168.1.100   myapp.local
0.0.0.0   ads.example.com  ← 광고 차단 용도

활용 사례:

• 개발 환경: myapp.local 같은 커스텀 도메인을 로컬 서버에 연결
• 사이트 차단: 특정 도메인을 0.0.0.0이나 127.0.0.1로 매핑하여 접속 차단
• 서버 이전 테스트: 새 서버 IP로 미리 연결하여 이전 전 테스트
• DNS 장애 대응: 주요 서비스의 IP를 직접 등록하여 DNS 장애 시에도 접속

주의: hosts 파일은 DNS보다 우선순위가 높으므로, 잘못 설정하면 정상적인 웹사이트에 접속하지 못할 수 있습니다. 문제가 생기면 hosts 파일부터 확인하세요!

2-1. 재귀적 조회 (Recursive Query)

hosts 파일에 없으면, 재귀적 리졸버(보통 ISP가 운영)에게 질문합니다. 리졸버는 마치 도서관 사서처럼, 여러분 대신 여러 서가(서버)를 돌아다니며 답을 찾아옵니다.

1. hosts 파일 확인: 로컬에 등록되어 있나? → 없으면 다음 단계로
2. 브라우저 → 재귀적 리졸버: "www.google.com의 IP 주소가 뭐야?"
3. 리졸버 → 루트 DNS 서버: ".com을 관리하는 서버가 어디야?" (전 세계 13개)
4. 루트 DNS → 리졸버: ".com은 이 TLD 서버가 관리해."
5. 리졸버 → TLD 서버 (.com): "google.com을 관리하는 서버가 어디야?"
6. TLD 서버 → 리졸버: "google.com은 이 권한 있는 DNS 서버가 관리해."
7. 리졸버 → 권한 있는 DNS 서버: "www.google.com의 IP는?"
8. 권한 있는 DNS → 리졸버: "142.250.196.68이야!"
9. 리졸버 → 브라우저: IP 주소 전달 + 캐시에 저장

2-2. 반복적 조회 (Iterative Query)

리졸버가 각 서버에게 물어볼 때, 서버는 직접 답을 주지 않고 "여기에 물어봐"라고 다음 주소를 알려줍니다. 리졸버가 직접 발품을 파는 방식입니다.

3. DNS 서버의 종류

4. DNS 레코드 종류

DNS 서버에는 다양한 유형의 정보가 저장되어 있습니다. 이를 DNS 레코드라고 합니다.

5. DNS 레코드는 어떻게 등록되나? - 조회의 전제 조건

위 시뮬레이션에서는 DNS가 도메인의 IP를 찾아오는 과정을 보여줍니다. 하지만 그 전에, 누군가가 해당 정보를 미리 등록해두어야 합니다. 전화번호부에 전화번호가 실려 있으려면, 먼저 번호를 등록해야 하는 것과 같습니다.

5-1. 도메인 등록 과정 (전체 흐름)

1. 도메인 구매: 도메인 등록 대행업체(Registrar)에서 원하는 도메인을 구매합니다.
   • 예: 가비아, Cloudflare, GoDaddy, Namecheap 등
2. 네임서버 지정: 구매한 도메인이 어떤 DNS 서버를 사용할지 설정합니다.
   • 등록 대행업체의 기본 네임서버를 쓰거나, Cloudflare DNS 같은 외부 서비스를 지정합니다.
   • 이 정보가 TLD 서버(.com, .kr 등)에 NS 레코드로 등록됩니다.
3. DNS 레코드 설정: 네임서버 관리 화면에서 실제 레코드를 추가합니다.
   • A 레코드: example.com → 93.184.216.34
   • CNAME: www.example.com → example.com
   • MX 레코드: 이메일 서버 지정
4. 전파(Propagation): 변경된 레코드가 전 세계 DNS 서버로 퍼집니다. 기존 캐시의 TTL이 만료되어야 새 정보가 반영되므로, 보통 수 분~48시간이 소요됩니다.

5-2. 등록 체계의 구조

DNS 등록은 계층적 위임 구조를 따릅니다.

비유: 아파트를 분양받으면(도메인 구매), 관리사무소에 입주 신고를 하고(네임서버 지정 → TLD에 NS 등록), 우편함에 이름표를 붙이는 것(A 레코드 설정)과 같습니다. 그래야 택배 기사(재귀적 리졸버)가 주소를 찾아올 수 있습니다.

5-3. 재귀적 리졸버는 어떻게 루트 서버를 아나?

재귀적 리졸버가 DNS 조회를 시작하려면, 맨 처음 물어볼 루트 DNS 서버의 주소를 알아야 합니다. 이 정보는 루트 힌트 파일(root hints)에 미리 내장되어 있습니다.

• 전 세계 13개 루트 서버(A~M)의 IP 주소가 담긴 파일입니다.
• 모든 DNS 리졸버 소프트웨어(BIND, Unbound 등)에 기본 내장되어 출시됩니다.
• IANA가 관리하며, 루트 서버 주소가 변경되면 소프트웨어 업데이트로 반영합니다.
• 이 13개 주소는 수십 년간 거의 변경되지 않아 안정적으로 동작합니다.

요약: DNS 조회가 작동하려면 ① 루트 힌트가 리졸버에 내장되어 있고 ② TLD 서버에 도메인의 NS 레코드가 등록되어 있고 ③ 권한 있는 네임서버에 A/CNAME 등 실제 레코드가 설정되어 있어야 합니다. 이 세 가지가 갖추어져야 시뮬레이션에서 본 조회 흐름이 성립합니다.

6. DNS 캐싱 - 속도의 비밀

매번 이렇게 복잡한 과정을 거치면 너무 느리겠죠? 그래서 캐싱(Caching)이 존재합니다.

캐싱 단계 (확인 순서)

1. hosts 파일: OS가 가장 먼저 확인하는 로컬 DNS 매핑 파일
2. 브라우저 캐시: 이전에 방문한 사이트의 IP를 브라우저가 기억합니다.
3. OS 캐시: 운영체제(Windows/macOS)가 DNS 결과를 저장합니다.
4. 리졸버 캐시: ISP의 DNS 서버가 최근 조회 결과를 보관합니다.

TTL (Time To Live)

각 DNS 레코드에는 TTL이라는 유효 시간이 설정되어 있습니다.

• TTL이 300(초)이면, 5분 동안 캐시된 결과를 사용합니다.
• TTL이 만료되면 다시 DNS 조회를 수행합니다.
• 짧은 TTL: 변경이 빠르게 반영 (서버 이전 시 유용)
• 긴 TTL: 조회 속도가 빠름 (캐시 적중률 높음)

비유: TTL은 음식의 유통기한과 같습니다. 유통기한이 지나면 새로 구매(조회)해야 합니다. 유통기한이 길면 자주 안 가도 되지만, 재료가 바뀌어도 모를 수 있습니다.

7. DNS 보안

DNS의 보안 취약점

기본 DNS는 암호화 없이 통신합니다. 이로 인해 다음과 같은 공격이 가능합니다:

• DNS 스푸핑/캐시 포이즈닝: 가짜 IP 주소를 DNS 캐시에 주입하여 사용자를 가짜 사이트로 유도
• DNS 하이재킹: DNS 요청을 가로채 다른 서버로 리다이렉트
• DNS 증폭 공격 (DDoS): DNS 서버를 이용한 대규모 트래픽 공격

DNSSEC (DNS Security Extensions)

DNS 응답에 디지털 서명을 추가하여 위변조를 방지합니다.

• 응답이 정당한 DNS 서버에서 왔는지 검증
• 중간에서 데이터가 변조되지 않았는지 확인
• 하지만 데이터 암호화는 하지 않음 (무결성만 보장)

DNS over HTTPS (DoH) / DNS over TLS (DoT)

DNS 쿼리 자체를 암호화하는 현대적인 방법입니다.

• DoH: HTTPS 프로토콜을 통해 DNS 쿼리 전송 (포트 443)
• DoT: TLS 프로토콜을 통해 DNS 쿼리 전송 (포트 853)
• 장점: ISP나 해커가 어떤 사이트를 방문하는지 볼 수 없음
• Chrome, Firefox 등 주요 브라우저가 DoH를 지원

8. 실생활 비유로 총정리

DNS 조회 과정을 우체국 비유로 다시 정리해봅시다.

1. 여러분(브라우저): "ChovisSchool에 편지 보내고 싶어요!"
2. 내 수첩(hosts 파일): "혹시 내가 적어둔 주소가 있나 확인..." → 없음!
3. 동네 우체국(재귀적 리졸버): "잠깐만요, 찾아볼게요."
4. 중앙 우체국(루트 DNS): "한국(.kr) 우체국에 물어보세요."
5. 한국 우체국(TLD 서버): "서울 강남구 우체국에 물어보세요."
6. 강남구 우체국(권한 있는 DNS): "ChovisSchool 주소는 여기입니다!"
7. 동네 우체국 → 여러분: "주소 찾았어요! 그리고 다음에 또 물어보시면 바로 알려드릴게요." (캐싱)

만약 수첩(hosts 파일)에 주소가 적혀 있었다면?
우체국에 갈 필요 없이 바로 편지를 보낼 수 있습니다! 이것이 hosts 파일의 역할입니다.

9. 자주 묻는 질문 (FAQ)

Q. DNS 서버가 다운되면 인터넷을 못 쓰나요?

DNS 서버가 응답하지 않으면 도메인 이름으로 접속이 불가합니다. 하지만 IP 주소를 직접 입력하면 접속 가능합니다. 실제로 2021년 Cloudflare DNS 장애 때 많은 사이트가 접속 불가능해진 사례가 있습니다.

Q. 8.8.8.8이 뭔가요?

Google Public DNS의 IP 주소입니다. ISP의 DNS 대신 사용할 수 있는 무료 공개 DNS 서버입니다.

• Google DNS: 8.8.8.8, 8.8.4.4
• Cloudflare DNS: 1.1.1.1, 1.0.0.1
• 일반적으로 ISP DNS보다 빠르고 안정적이며, DoH/DoT를 지원합니다.

Q. DNS 변경은 왜 시간이 걸리나요?

도메인의 DNS 레코드를 변경하면, 전 세계의 DNS 캐시가 만료(TTL)될 때까지 기다려야 합니다. 이를 "DNS 전파(Propagation)"라고 하며, 보통 몇 분~48시간이 소요됩니다.

Q. hosts 파일은 뭔가요?

운영체제에 있는 로컬 DNS 매핑 파일입니다. DNS 서버보다 먼저 확인되므로, 특정 도메인을 원하는 IP로 강제 연결할 수 있습니다. 자세한 내용은 위의 "2-0. hosts 파일 확인" 섹션을 참고하세요.

• Windows: C:\Windows\System32\drivers\etc\hosts
• macOS/Linux: /etc/hosts
• 확인 순서: hosts 파일 → 브라우저 캐시 → OS 캐시 → DNS 서버 조회