서버에서 curl api.internal이 안 됩니다. ping api.internal도 "Name or service not known"입니다. 외부 IP로는 되는데 내부 도메인만 안 됩니다. 이런 상황에서 /etc/resolv.conf를 보면 내부 DNS 서버 주소가 없거나 잘못된 서버를 바라보고 있습니다. DNS 클라이언트 설정 파일의 구조를 모르면 어디를 어떻게 고쳐야 하는지 알 수 없습니다.

확대

resolv.conf란

/etc/resolv.conf는 리눅스/유닉스 시스템에서 DNS 해석(Resolver) 동작을 설정하는 파일입니다. 프로그램이 google.com 같은 도메인 이름을 IP로 변환할 때 이 파일을 참조합니다.

resolv.conf가 사용되는 시점:
curl google.com
    → curl이 OS에 "google.com의 IP 알려줘" 요청
    → OS 리졸버가 /etc/resolv.conf 읽음
    → nameserver로 지정된 DNS 서버에 질의
    → IP 응답 받아서 curl에 전달
    → curl이 해당 IP로 HTTP 요청

resolv.conf 파일 구조

실제 파일 내용을 보면 지시어 구조를 바로 파악할 수 있습니다.

# 실습 디렉토리 준비
mkdir -p /tmp/networking/part2/exam_7 && cd /tmp/networking/part2/exam_7

cat /etc/resolv.conf

전형적인 내용:

# DNS 서버 IP (최대 3개, 위에서 아래 순서로 시도)
nameserver 8.8.8.8
nameserver 8.8.4.4
nameserver 1.1.1.1

# 검색 도메인 (짧은 호스트명 자동 보완)
search example.com internal.company.com

# 현재 도메인 (일반적으로 search와 유사한 역할)
domain example.com

# 추가 옵션
options ndots:5 timeout:2 attempts:3

각 지시어 상세 설명

nameserver

DNS 질의를 보낼 서버 IP를 지정합니다. 최대 3개까지 설정하며 위에서 아래 순서로 시도합니다.

nameserver 8.8.8.8

역할: DNS 질의를 보낼 서버 IP 지정
규칙:
- 최대 3개까지 설정 가능
- 첫 번째 서버가 응답 없을 때 두 번째 시도
- IPv4 또는 IPv6 주소 사용 가능

search

짧은 호스트명 입력 시 자동으로 도메인을 붙여 완전한 FQDN으로 만드는 검색 도메인을 지정합니다.

search example.com internal.company.com

역할: 짧은 호스트명 → FQDN 자동 변환
예시:
  ping web01
  → web01.example.com 시도
  → web01.internal.company.com 시도

실무 활용:
  쿠버네티스: search default.svc.cluster.local svc.cluster.local cluster.local
  → ping my-service 입력 시 my-service.default.svc.cluster.local로 질의

domain

시스템의 기본 도메인을 설정합니다. search와 함께 선언되면 마지막에 선언된 것이 적용됩니다.

domain example.com

역할: 시스템의 기본 도메인 설정
search와의 차이: search는 여러 도메인 지정 가능, domain은 하나만
참고: search와 domain이 둘 다 있으면 마지막에 선언된 것이 적용

options ndots

도메인 이름의 점(.) 개수가 ndots 값보다 작으면 search 도메인을 먼저 시도합니다. 쿠버네티스 환경에서는 기본값 5를 자주 만납니다.

options ndots:5

역할: 도메인 이름에 점(.)이 몇 개 미만이면 search 도메인 먼저 시도
기본값: 1
쿠버네티스 기본값: 5

예시 (ndots:2 설정 시):
  nslookup google.com  → 점이 1개, ndots:2보다 작음
  → google.com.example.com 먼저 시도 (search 도메인 붙임)
  → 실패하면 google.com 시도

/etc/nsswitch.conf와의 관계

resolv.conf는 DNS 질의 자체를 설정하지만, OS가 이름 해석에 어떤 방법을 어떤 순서로 사용할지는 /etc/nsswitch.conf가 결정합니다.

grep hosts /etc/nsswitch.conf
# hosts: files dns myhostname

이 한 줄이 이름 해석 순서를 정합니다.

• files — /etc/hosts를 먼저 확인
• dns — 그다음 /etc/resolv.conf의 nameserver로 DNS 질의
• myhostname — 마지막으로 자기 호스트명 해석

/etc/hosts에 항목이 있으면 DNS보다 먼저 사용됩니다.

nameserver 한 줄만 맞으면 될 것 같지만, 실제 한 번의 이름 조회는 nsswitch 순서 판정 → /etc/hosts 확인 → resolv.conf의 nameserver·search·options 적용이라는 여러 단계를 거칩니다. 이 순서를 알면 "IP는 되는데 도메인만 안 되는" 경우가 어느 단계에서 끊긴 것인지, "가끔 정확히 5초 지연"이 어디서 새는지를 짚을 수 있습니다.

[앱]  getaddrinfo("web01") — 이름 하나 조회
   │
   ① nsswitch.conf의 hosts 행이 순서 결정
   │    hosts: files dns → /etc/hosts 먼저, 없으면 DNS
   │
   ② /etc/hosts 조회 (files)
   │    매칭 있으면 즉시 반환 (DNS로 안 감)
   │
   ③ resolv.conf 로드 — nameserver·search·options 읽기
   │
   ④ ndots 판정 (options ndots:N)
   │    이름의 점(.) 개수 < N → search 도메인부터 붙여 시도
   │
   ⑤ search 도메인 하나씩 붙여 nameserver에 질의
   │    web01.example.com → ... → 마지막에 절대 이름
   │    첫 nameserver 무응답이면 timeout 후 다음 nameserver로
   │
   ⑥ 응답(A/AAAA) 수신 → IP 반환
   ▼
[앱]  받은 IP로 실제 연결

각 단계에서 무슨 일이 일어나고, 막히면 어떤 증상인가:

즉 resolv.conf는 단순히 'DNS 서버 IP를 적는 곳'이 아니라 한 번의 조회가 몇 번의 질의로 불어나고 어디서 지연되는지를 결정하는 지점 입니다. 그래서 IP는 되는데 도메인만 안 되면 ③(nameserver)을, 사내 도메인만 실패하면 ⑤의 search·nameserver 우선순위를, 외부 도메인이 유독 느리면 ④(ndots 확장)를, 가끔 정확히 5초 걸리면 ⑤의 timeout 폴백을 의심합니다. cat /etc/resolv.conf로 이 네 필드(nameserver·search·options·ndots)를 먼저 읽는 것이 DNS 진단의 출발점입니다.

/etc/resolv.conf를 직접 수정해서 DNS 서버를 바꿨습니다. 그런데 다음 날 아침에 보면 원래대로 돌아가 있습니다. 다시 수정하면 또 바뀝니다. NetworkManager나 systemd-resolved가 자동으로 덮어쓰기 때문인데, 이 구조를 모르면 같은 작업을 계속 반복하게 됩니다.

확대

문제의 핵심

현대 리눅스(Ubuntu 18.04+, RHEL 7+)에서는 /etc/resolv.conf를 직접 수정해도 재부팅이나 네트워크 재연결 시 원래대로 돌아갑니다. 이는 NetworkManager 또는 systemd-resolved가 자동으로 관리하기 때문입니다.

resolv.conf 관리 주체 확인:

# resolv.conf가 심볼릭 링크인지 확인
ls -la /etc/resolv.conf

# Ubuntu 20.04+ (systemd-resolved 사용):
# /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
# → 심볼릭 링크! 직접 수정해도 재부팅 시 덮어써짐

# 일반 파일인 경우:
# -rw-r--r-- 1 root root 89 ...
# → NetworkManager가 관리하거나, 수동 설정

resolv.conf 관리 구조

어떤 프로세스가 resolv.conf를 관리하는지에 따라 영구 설정 방법이 달라집니다.

확대

관리 주체 확인 방법

아래 순서로 확인하면 어떤 프로세스가 resolv.conf를 관리하는지 파악할 수 있습니다.

# systemd-resolved 실행 중인지 확인
systemctl is-active systemd-resolved
# active → systemd-resolved 사용

# NetworkManager 실행 중인지 확인
systemctl is-active NetworkManager
# active → NetworkManager 사용

# resolv.conf 내용으로 판단
head -3 /etc/resolv.conf
# "# Generated by NetworkManager" → NetworkManager 관리
# "# This is /run/systemd/resolve/stub-resolv.conf" → systemd-resolved 관리
# 주석 없음 → 수동 관리 가능성

nameserver 한 줄만 맞으면 될 것 같지만, 정작 부하와 지연은 리졸버가 '한 번의 조회'를 뒤에서 여러 질의로 바꾸는 데서 나옵니다. resolv.conf의 search·options가 그 뒷면입니다.

• search 도메인 확장과 ndots: options ndots:N은 '이름의 점(.) 개수가 N 미만이면 search 도메인을 먼저 붙여 시도하라'는 뜻입니다. 쿠버네티스 기본값 ndots:5에서는 api.example.com(점 2개)조차 search 접미사(svc.cluster.local 등 45개)를 하나씩 다 붙여 NXDOMAIN을 받은 뒤에야 절대 이름을 질의합니다. 외부 도메인 한 번 부르는데 DNS 왕복이 56배로 늘어 지연·부하가 커집니다. 이름 끝에 점을 붙여 FQDN(api.example.com.)으로 쓰거나 ndots를 낮추면 이 확장을 건너뜁니다.
• 병렬 A/AAAA 질의: glibc 리졸버는 IPv4(A)와 IPv6(AAAA)를 같은 소켓·같은 소스 포트로 거의 동시에 보냅니다. 여기에 NAT/conntrack이 끼면 두 질의의 conntrack 항목이 5-튜플 경쟁을 일으켜 한쪽 응답이 드롭될 수 있고, 리졸버는 잃은 응답을 options timeout(기본 5초)만큼 기다렸다 재시도합니다 — '가끔 정확히 5초 지연되는 DNS'의 정체입니다.
• 그래서 '가끔 느린 DNS'는 nameserver가 틀린 게 아니다: (a) search 확장으로 질의 수가 폭증했거나 (b) 병렬 질의 중 하나가 유실돼 timeout을 기다리는 경우입니다. options single-request(-reopen), timeout/attempts 축소, ndots 조정, FQDN 사용이 이때 쓰는 도구입니다.

즉 resolv.conf는 'DNS 서버 IP를 적는 곳'을 넘어, 조회가 몇 배로 늘어나고 어디서 5초가 새는지를 결정하는 튜닝 지점입니다.