RHEL에서의 DNS Cache, 그리고 systemd-resolved 이야기 1

서버이야기

RHEL에서의 DNS Cache, 그리고 systemd-resolved 이야기 1

지기(ZIGI) 2025. 11. 8. 14:22

Today Keys : dns, cache, 도메인, 캐시, rhel, systemd-resolved, query, 질의, redhat

이번 포스팅에서는 RHEL(Redhat Enterprise Linux)에서의 DNS Cache에 대한 내용입니다.

Linux Distro에 따라 현재 DNS Cache 사용이 다를 수 있기 때문에, 사용 중인 Linux에 따라서 어떻게 동작하는지 알아두면 좋을 듯 하여, 간단히 정리해 보았습니다.

관련하여, 작년에 포스팅 한 아래의 글들도 읽어보시면 좋을 것 같습니다.

DNS 동작 이해를 위한 기술 - Netplan Part 1

DNS 동작 이해를 위한 기술 - Netplan Part 2

DNS 동작 이해를 위한 기술 - Netplan Part 3

Linux에서 DNS 질의(Query) 동작 이해 (Ubuntu 기준) - Part 1

Linux에서 DNS 질의(Query) 동작 이해 (Ubuntu 기준) - Part 2

Linux에서 DNS 질의(Query) 동작 이해 (Ubuntu 기준) - Part 3

RHEL에서의 기본 DNS Query 동작

RHEL 계열 OS는 기본적으로 DNS 캐시 기능이 비활성화(disabled) 되어 있습니다.

즉, 각 애플리케이션이 getent, curl, ping, yum 등의 명령을 통해 도메인 이름을 조회할 때마다, 매번 새로운 DNS Query가 발생하게 됩니다.

google로 2번의 ping을 수행 시에, 매번 DNS Query를 보냄.

이 동작은 /etc/nsswitch.conf 파일의 hosts: 항목과 /etc/resolv.conf의 네임서버 설정에 의해 제어되며,
일반적으로 아래와 같은 순서로 질의가 진행됩니다.

1. /etc/hosts →
2. DNS 서버 (/etc/resolv.conf의 nameserver) →
3. myhostname (로컬 호스트명)

만약 캐시 데몬(nscd, dnsmasq, unbound 등)이 동작하지 않는다면, 동일한 도메인에 대한 반복 요청이라도 매번 DNS 서버로 질의가 전송됩니다.

DNS Cache가 필요한 이유

“DNS는 가벼우니까 굳이 캐시가 필요할까?”
라는 생각이 들 수도 있습니다.

물론, 대부분의 환경에서는 DNS Lookup은 아주 짧은 시간에 끝나고,
눈에 띄는 부하를 주는 경우는 흔치 않습니다.

하지만 트래픽이 많은 환경
예를 들어 API Gateway, 웹서버, 컨테이너 오케스트레이션 환경(Kubernetes 등)에서는
초당 수천~수만 건의 DNS 요청이 발생하는 경우가 있습니다.

이런 상황에서는 다음과 같은 문제가 발생할 수 있습니다.

외부 DNS 서버에 과도한 부하 발생
애플리케이션의 DNS Lookup 지연 누적
네트워크 장애 시 전체 서비스 응답 지연

즉, 단순한 “속도 문제”가 아니라,
서비스 안정성과 회복력(Resilience) 측면에서도 DNS 캐시는 중요한 역할을 합니다.

그렇다고 해서 “모든 서버에서 반드시 DNS 캐시를 사용해야 한다”는 건 아닙니다.
운영 환경에서는 “성능 향상”만큼이나 TTL 관리, 장애 시 복구 속도, 캐시 동기화 문제도 함께 고려해야 합니다.
실제 운영 환경에서는 트래픽 패턴과 서비스 구조에 따라, 캐시의 필요성이 달라집니다.

트래픽이 적거나, 특정 내부 도메인 몇 개만 반복적으로 사용하는 환경이라면 DNS 캐시로 얻는 이점은 크지 않을 수도 있습니다.

반면, 외부 API 연동이 많거나, 클러스터 내부 통신이 빈번한 환경이라면 DNS 캐시 하나만 추가해도 눈에 띄는 개선이 체감되기도 합니다.

RHEL에서 DNS Cache를 사용할 수 있는 주요 방법

RHEL에서는 다음과 같은 방식으로 DNS 캐시를 구현할 수 있습니다.

구성 방식	주요 패키지	특징
nscd (Name Service Cache Daemon)	nscd	전통적인 캐싱 데몬. 단순하지만 관리가 불편하고 systemd 환경에서는 비추천 경향.
dsmasq	dnsmasq	소규모 DNS/DHCP 캐시 서버. 설정이 간단하고, 로컬 네임서버로 활용 가능.
unbound	unbound	보안 DNS, DNSSEC 지원, 대규모 캐시 환경에서 적합.
systemd-resolved	systemd-resolved	systemd 기반 통합 네임리졸버. 캐싱, DNSSEC, mDNS 등 지원. 단, RHEL에서는 Technology Preview 상태

이 중 systemd-resolved는 최근 리눅스 배포판에서 점점 표준화되는 방향입니다.

Ubuntu에서는 이미 기본 리졸버로 포함되어 있죠.

다만, RHEL에서는 아직 정식 지원(SLA 보장) 기능은 아니며, RHEL 8, 9, 10 모두 Technology Preview로 제공되고 있습니다.

즉, 정식 SLA 지원은 아직 불가합니다.

RHEL에서 systemd-resolved 구성 방법

RHEL 테스트 환경
- 본 포스팅에서의 테스트 환경은 AWS로 만든 RHEL 10.0 입니다
systemd-resovled 패키시 확인
- RHEL에서는 systemd-resolved 패키지는 기본 설치 상태는 아닙니다.
- 현재 RHEL 8,9,10에서 모두 Technology Preview로 제공
systemd-resolved 패키지 설치
systemd-resolved 서비스 활성 및 점검
- systmed-resolved 서비스를 부팅 시 자동 실행되도록 활성화 및 실행합니다.
- 서비스가 정상적으로 동작 중인지 확인합니다.
nsswitch.conf 수정
- 도메인 질의에 files(/etc/hosts) 다음에 resolved를 사용하도록 nsswitch.conf를 아래와 같이 수정합니다.
- !UNAVAIL=return 은 ~~
DNS Cache 사용 확인
- google.com 으로 ping을 보내면서, DNS query에 대한 패킷을 tcpdump로 확인해보면,
  첫 질의(query)시에만 DNS query 패킷이 발생하는 것을 확인 할 수 있습니다.
캐시 확인
- resolvectl statistics 명령을 이용해서, 현재 Cache 사용 현황을 볼 수 있습니다.
- 현재 Cache Size, Hit, Miss 수 확인이 가능합니다.
- Cache Hit 수(140)와 Miss 수(40)를 확인한 상태에서, 기존에 질의하여 Cache에 있을 google로 ping을 2번 보내고
  다시 Cache Hit 수와 Miss수를 보면, Hit수만 증가하고, Miss 수는 증가하지 않는 것을 확인 할 수 있습니다.