이 글은 Linux에서 DNS를 처음 접하는 사람을 대상으로, “호스트 이름이 어떻게 IP로 변환되는지(이름 해석, name resolution)”를 실습 가능한 수준으로 정리합니다. OSI 이론 대신 실제 파일과 명령 중심으로 갑니다.
마지막에는 다음 섹션(쿠버네티스의 CoreDNS)으로 자연스럽게 넘어가기 위해 CoreDNS로 DNS 서버를 직접 구성하는 방법까지 붙였습니다.

1) 왜 DNS가 필요한가: IP 대신 이름으로 통신하고 싶다

같은 네트워크에 두 컴퓨터 A/B가 있고 IP가 다음과 같다고 합시다.

  • A: 192.168.1.10
  • B: 192.168.1.11 (DB 서비스가 있음)

IP로는 통신이 되지만, 매번 192.168.1.11을 외우기 번거롭습니다. 그래서 B에 “db”라는 이름을 붙여서 쓰고 싶습니다.

ping 192.168.1.11   # 성공
ping db             # 실패 (아직 이름을 모름)

2) 가장 단순한 방법: /etc/hosts (로컬 파일로 이름 해석)

Linux는 로컬에서 이름→IP 매핑을 제공하는 파일이 있습니다.

  • /etc/hosts

A에서 다음처럼 등록하면 “db = 192.168.1.11”을 로컬에서 알게 됩니다.

sudo vi /etc/hosts

# 예시
192.168.1.11   db

이후:

ping db   # 이제 192.168.1.11로 해석되어 성공

2.1 중요한 함정: /etc/hosts는 “진실을 검증하지 않는다”

/etc/hosts에 적힌 내용은 해당 호스트(A) 입장에서는 소스 오브 트루스입니다.

  • 실제로 B의 hostname이 db인지 확인하지 않습니다.
  • B에서 hostname을 쳐서 host2가 나오더라도, A는 상관하지 않습니다.

극단적으로:

192.168.1.11   google.com

을 넣으면 A에서 ping google.com이 B로 가는 것처럼 보일 수 있습니다.
즉, /etc/hosts는 “로컬에서 강제하는 매핑”입니다.

2.2 /etc/hosts만 쓰면 왜 운영에서 힘든가

서버가 몇 대 없을 땐 괜찮지만, 규모가 커지면 문제:

  • 서버가 많아지면 hosts 파일이 비대해짐
  • IP가 바뀌면 모든 서버의 /etc/hosts를 수정해야 함
  • 중앙 관리가 안 됨

이때 등장하는 게 DNS 서버입니다.

3) DNS 서버로 중앙화: /etc/resolv.conf

이제 이름 해석 정보를 한 곳에서 관리하는 DNS 서버를 둡니다. 예를 들어 DNS 서버 IP가:

  • DNS: 192.168.1.100

각 호스트(A, B, …)는 “모르는 이름은 DNS 서버에게 물어보겠다”를 설정해야 합니다. 그 설정 파일이:

  • /etc/resolv.conf

예:

sudo vi /etc/resolv.conf

nameserver 192.168.1.100

이제 A는:

  • 로컬에서 못 찾는 이름이 나오면
  • 192.168.1.100에게 질의해서 IP를 받아옵니다.

참고: 환경에 따라 /etc/resolv.conf가 NetworkManager/systemd-resolved에 의해 자동 생성/덮어쓰기 될 수 있습니다.
실습에서는 직접 편집해도 되지만, 운영에서는 해당 시스템의 네트워크 관리 방식에 맞춰 설정하세요.

4) /etc/hosts vs DNS: 둘 다 있을 때 “무엇이 우선인가?”

A의 /etc/hosts에도 있고, DNS 서버에도 같은 이름이 등록되어 있다면?

  • 어떤 게 먼저 적용될까요?

이 “우선순위”를 정하는 파일이:

  • /etc/nsswitch.conf

여기에서 hosts: 라인을 봅니다.

예:

hosts: files dns

뜻:

  1. 먼저 files = /etc/hosts에서 찾고
  2. 없으면 dns = DNS 서버(/etc/resolv.conf의 nameserver)로 질의

즉, 기본 설정에서는 /etc/hosts가 DNS보다 우선입니다.

5) 외부 도메인(예: facebook.com)은 어떻게 되나?

A의 /etc/hosts에도 없고, 사내 DNS(192.168.1.100)에도 facebook.com이 없으면 실패합니다.

해결 방법은 두 가지 중 하나입니다.

5.1 각 호스트에 공용 DNS 추가(운영 관리가 번거로움)

nameserver 192.168.1.100
nameserver 8.8.8.8

5.2 사내 DNS가 “포워딩(forwarding)” 하게 만든다(추천)

  • 사내 DNS는 내부 레코드는 직접 응답
  • 모르는 도메인은 8.8.8.8 같은 상위(public) DNS로 전달

이렇게 하면 클라이언트(호스트)는 계속 사내 DNS만 바라보고도 인터넷 도메인을 해석할 수 있습니다.

6) 도메인 네임 구조: 점(.)으로 계층을 만든다

예: www.google.com

  • . : 루트(root)
  • com : TLD(Top Level Domain)
  • google : 도메인
  • www : 서브도메인

서브도메인은 서비스를 묶기 위해 씁니다.

  • maps.google.com
  • drive.google.com
  • mail.google.com

7) 사내 도메인에서 “짧은 이름” 쓰고 싶다: search domain

사내에서 웹 서버의 FQDN이 web.mycompany.com이라면, 외부에서는 이 전체 이름으로 접근해야 합니다.

하지만 내부에서는 web만 치고 싶습니다. 이를 위한 설정이 /etc/resolv.conf의 search입니다.

예:

nameserver 192.168.1.100
search mycompany.com

그러면 ping web을 했을 때, 시스템은 내부적으로 web.mycompany.com을 시도합니다.

여러 search 도메인도 가능합니다.

search mycompany.com prod.mycompany.com

8) DNS 레코드 타입(A, AAAA, CNAME)

DNS 서버는 다양한 타입의 레코드를 저장합니다.

  • A 레코드: 이름 → IPv4
  • AAAA 레코드: 이름 → IPv6
  • CNAME 레코드: 이름 → 다른 이름(별칭)

9) DNS 확인 도구: ping 말고 nslookup/dig가 더 정확할 때가 많다

9.1 nslookup

nslookup web.mycompany.com

중요: nslookup은 /etc/hosts를 보지 않고, DNS 서버 질의 중심으로 확인합니다.
즉, /etc/hosts에만 있는 이름은 nslookup으로 안 보일 수 있습니다.

9.2 dig

dig web.mycompany.com
dig A web.mycompany.com
dig AAAA web.mycompany.com

dig는 더 상세한 응답(TTL, authority 등)을 보여줘서 트러블슈팅에 유용합니다.

10) (Prerequisite) CoreDNS로 “진짜 DNS 서버” 구성해보기

이전까지는 “DNS 서버가 왜 필요한지”, “클라이언트 호스트가 DNS 서버를 어떻게 바라보는지”를 봤습니다.
이제는 호스트 한 대를 DNS 서버로 구성해봅니다.

DNS 서버 솔루션은 많지만, 여기서는 CoreDNS를 사용합니다. (쿠버네티스에서도 CoreDNS가 클러스터 DNS로 널리 사용됨)

10.1 CoreDNS 설치: 바이너리 다운로드

CoreDNS는 GitHub 릴리즈에서 바이너리로 받거나 Docker 이미지로 사용할 수 있습니다. 여기서는 “전통적인 방식(바이너리)”로 진행합니다.

curl -LO https://github.com/coredns/coredns/releases/download/v1.12.4/coredns_1.12.4_linux_amd64.tgz
tar -zxf coredns_1.12.4_linux_amd64.tgz
# 현재 디렉터리에 coredns 실행 파일이 생김

10.2 DNS 서버에 레코드(이름↔IP) 넣기: /etc/hosts를 데이터 소스로 쓰기

여러 방법이 있지만, 가장 간단한 방법은:

  1. DNS 서버 자신의 /etc/hosts에 엔트리를 넣고
  2. CoreDNS가 그 파일을 읽게 하는 것입니다.

DNS 서버의 /etc/hosts 예시:

192.168.1.11   db
192.168.1.12   web
192.168.1.13   nfs

10.3 Corefile 작성: CoreDNS 설정 파일

CoreDNS는 Corefile이라는 설정 파일을 읽습니다. 아래 설정은:

  • /etc/hosts에서 이름 해석(내부 레코드) 처리
  • 매칭이 안 되는 질의는 /etc/resolv.conf를 따라 상위 DNS로 포워딩
  • 캐시/로그/에러 출력
.:53 {
    # Use /etc/hosts to resolve hostname
    hosts /etc/hosts {
        reload 1m
        fallthrough
    }

    # Forward unmatched queries to the host's resolver
    forward . /etc/resolv.conf {
       max_concurrent 1000
    }

    cache 30
    log
    errors
}

핵심 포인트:

  • .:53 : 모든 도메인(.)에 대해 53번 포트로 리슨
  • hosts /etc/hosts : DNS 엔트리 소스로 /etc/hosts 사용
  • reload 1m : /etc/hosts 변경을 1분 주기로 리로드
  • fallthrough : hosts에서 못 찾으면 다음 플러그인(forward)으로 넘김
  • forward . /etc/resolv.conf : 외부 도메인은 상위 DNS로 전달(포워딩)
  • cache 30 : 응답 캐시(초)

10.4 CoreDNS 실행 (기본 포트 53)

DNS 기본 포트는 53입니다. 실행하면 기본적으로 53을 리슨합니다.

sudo ./coredns -conf ./Corefile

53 포트는 privileged 포트라 보통 root 권한이 필요합니다.

10.5 클라이언트 호스트가 이 DNS 서버를 바라보게 설정

이제 네트워크의 다른 호스트(A 등)에서 /etc/resolv.conf를 DNS 서버로 지정합니다.

nameserver 192.168.1.100

그리고 테스트:

# DNS 질의가 서버로 가는지 확인
nslookup db
dig db

# 실제 통신 확인
ping db

11) 실무 트러블슈팅 체크리스트(최소셋)

DNS 문제가 의심되면 순서대로 확인합니다.

  1. /etc/hosts에 고정 매핑이 있나?
cat /etc/hosts
  1. 질의 우선순위가 어떻게 되나?
grep '^hosts:' /etc/nsswitch.conf
  1. DNS 서버가 무엇으로 설정되어 있나?
cat /etc/resolv.conf
  1. DNS 서버 질의가 실제로 되나?
nslookup <name>
dig <name>

요약

  • 작은 환경: /etc/hosts로 이름 해석 가능(로컬 강제 매핑)
  • 규모가 커지면: DNS 서버로 중앙화하고, 각 호스트는 /etc/resolv.conf로 DNS를 바라봄
  • 우선순위는 /etc/nsswitch.conf의 hosts: 라인이 결정(기본은 files → dns)
  • 내부에서 짧은 이름을 쓰려면 resolv.conf의 search를 활용
  • CoreDNS는 /etc/hosts를 데이터 소스로 삼아 DNS 서버를 빠르게 구성할 수 있고, 모르는 질의는 forward로 상위 DNS에 넘길 수 있다
  • nslookup/dig는 DNS 서버 기반 확인에 유용하며, /etc/hosts만으로 해결된 이름은 nslookup/dig에서 다르게 보일 수 있다

'CKA' 카테고리의 다른 글

Network - Docker Network  (0) 2026.01.05
Network - 네트워크 기초(veth, bridge, routing, NAT, port-forward)  (1) 2026.01.05
Network - 네트워크 기초(스위치, 라우터, 게이트웨이)  (0) 2026.01.05
Storage - 정리  (0) 2026.01.05
Storage - Storage Class  (0) 2026.01.03

티스토리툴바