네트워크 면접 질문

면접관님, TCP와 UDP는 모두 인터넷 프로토콜 스택에서 사용되는 전송 계층 프로토콜입니다. 가장 큰 차이점은 TCP는 연결 지향적이고 신뢰성을 보장하는 반면, UDP는 비연결 지향적이고 신뢰성을 보장하지 않는다는 점입니다.

TCP는 데이터를 전송하기 전에 연결을 설정하고, 데이터 전송 과정에서 순서 보장, 오류 검출, 흐름 제어, 혼잡 제어 기능을 제공합니다. 따라서 파일 전송, 웹 브라우징, 이메일 등 데이터의 정확성이 중요한 상황에서 주로 사용됩니다.

반면 UDP는 연결 설정 없이 데이터를 바로 전송하며, 이러한 기능들을 제공하지 않습니다. 대신 TCP보다 속도가 빠르기 때문에 실시간성이 중요한 음성/영상 스트리밍, 온라인 게임, DNS 쿼리 등에 적합합니다. 예를 들어, 화상 회의에서 약간의 데이터 손실은 감수하더라도 끊김 없는 실시간 통신이 더 중요하기 때문에 UDP를 사용하는 경우가 많습니다.

프로세스와 스레드는 모두 병렬성을 구현하는 방식이지만, 핵심적인 차이점이 있습니다. 프로세스는 운영체제로부터 독립적인 메모리 공간을 할당받아 실행되는 프로그램의 인스턴스입니다. 반면 스레드는 프로세스 내에서 실행되는 실행 흐름의 단위로, 프로세스의 자원(메모리, 파일 등)을 공유합니다.

가장 큰 차이점은 메모리 공간입니다. 프로세스는 독립적인 공간을 가지므로 프로세스 간 통신에는 IPC(Inter-Process Communication)가 필요하지만, 스레드는 공유 메모리를 사용하므로 프로세스 간 통신보다 훨씬 빠릅니다.

컨텍스트 스위칭 비용도 다릅니다. 프로세스 간 컨텍스트 스위칭은 메모리 공간을 변경해야 하므로 비용이 큰 반면, 스레드 간 컨텍스트 스위칭은 프로세스 내에서 이루어지므로 비용이 적습니다. 프로세스는 안정성이 높지만 자원 소모가 크고, 스레드는 자원 소모는 적지만 프로세스에 문제가 생기면 함께 종료될 수 있다는 단점이 있습니다.

DNS 동작 과정은 웹사이트 주소(예: google.com)를 실제 서버 IP 주소(예: 142.250.200.14)로 변환하는 과정입니다.

1. 사용자가 웹 브라우저에 주소를 입력하면, 먼저 로컬 DNS 서버에 해당 주소에 대한 IP 주소를 묻는 DNS 쿼리를 보냅니다.

2. 로컬 DNS 서버에 정보가 없다면, 루트 DNS 서버에 질의합니다. 루트 서버는 .com, .net 등 TLD(최상위 도메인) 서버 주소를 알려줍니다.

3. 로컬 DNS 서버는 TLD 서버에 google.com에 대한 정보를 요청하고, TLD 서버는 google.com을 관리하는 권한 있는 DNS 서버 주소를 알려줍니다.

4. 마지막으로 로컬 DNS 서버는 권한 있는 DNS 서버에 질의하여 google.com의 IP 주소를 받아옵니다.

이 과정에서 로컬 DNS 서버는 응답받은 IP 주소를 캐싱하여 다음번 요청 시 빠르게 응답할 수 있도록 합니다. 이러한 질의 방식에는 재귀적 질의와 반복적 질의가 있습니다. 일반적으로 사용자의 로컬 DNS 서버는 재귀적 질의를 사용하고, 상위 DNS 서버들은 반복적 질의를 사용합니다.

CDN은 콘텐츠 전송 네트워크(Content Delivery Network)의 약자로, 웹 콘텐츠를 사용자에게 더 빠르고 효율적으로 전달하기 위해 지리적으로 분산된 서버 네트워크입니다.

CDN의 주요 이점은 다음과 같습니다.

• 성능 향상: 사용자와 가장 가까운 서버에서 콘텐츠를 제공하여 로딩 시간을 단축시키고 사용자 경험을 개선합니다.
• 가용성 향상: 원본 서버에 장애가 발생하더라도 CDN 서버가 콘텐츠를 제공하여 서비스 중단을 최소화합니다.
• 원본 서버 부하 감소: CDN 서버가 콘텐츠를 캐싱하여 원본 서버의 트래픽 부담을 줄여줍니다.
• 비용 절감: 원본 서버의 트래픽 감소로 인해 네트워크 비용을 절감할 수 있습니다.

요약하자면, CDN은 웹 사이트의 성능, 가용성, 확장성을 향상시키는 데 중요한 역할을 합니다.

OSI 7계층 모델과 TCP/IP 4계층 모델은 네트워크 통신 과정을 계층적으로 설명하는 모델입니다.

OSI 7계층 모델은 7개의 계층으로 나뉘어 각 계층별 역할을 정의합니다. 물리 계층은 전기적 신호, 데이터 링크 계층은 MAC 주소, 네트워크 계층은 IP 주소, 전송 계층은 TCP/UDP 프로토콜, 세션 계층은 연결 관리, 표현 계층은 데이터 변환, 응용 계층은 HTTP, FTP 등 응용 서비스와 관련됩니다.

TCP/IP 4계층 모델은 OSI 모델을 단순화한 것으로, 응용 계층, 전송 계층, 인터넷 계층, 링크 계층으로 구성됩니다. 응용 계층은 OSI 모델의 응용, 표현, 세션 계층을 포함하고, 링크 계층은 OSI 모델의 물리, 데이터 링크 계층을 포함합니다.

데이터는 각 계층을 거치면서 캡슐화되고, 목적지에서는 역캡슐화됩니다. 각 계층은 특정 프로토콜을 사용하여 통신하며, TCP/IP 모델은 인터넷의 기반이 되는 중요한 모델입니다.

면접관님, 쿠키와 세션은 모두 웹 환경에서 상태를 유지하기 위해 사용되는 기술입니다.

가장 큰 차이점은 저장 위치입니다. 쿠키는 사용자의 브라우저에 저장되는 작은 텍스트 파일이고, 세션은 서버에 저장됩니다.

쿠키는 클라이언트에 저장되므로 비교적 보안에 취약하고, 크기 제한이 있습니다. 반면, 서버에 부담을 줄여줄 수 있다는 장점이 있습니다. 쿠키 만료 시간을 설정하여 데이터를 유지하는 기간을 조절할 수 있습니다.

세션은 서버에 저장되므로 쿠키보다 보안성이 높지만, 서버에 부담을 줄 수 있습니다. 세션 ID를 쿠키에 저장하여 클라이언트를 식별합니다.

요약하자면, 쿠키는 클라이언트 측에 저장되어 서버 부담을 줄이지만 보안에 취약하고, 세션은 서버 측에 저장되어 보안은 높지만 서버 부담이 증가할 수 있습니다. 어떤 기술을 선택할지는 보안 요구사항, 서버 자원, 데이터 크기 등을 고려하여 결정해야 합니다.

HTTP 상태 코드는 서버가 클라이언트의 요청에 대한 응답 결과를 나타내는 3자리 숫자 코드입니다. 크게 5가지 종류로 나눌 수 있습니다.

1xx (Informational): 요청이 수신되어 처리 중임을 알립니다. 거의 사용되지 않습니다.

2xx (Success): 요청이 성공적으로 처리되었음을 의미합니다. 대표적으로 200 OK (성공적인 요청), 201 Created (새로운 리소스 생성 성공) 등이 있습니다.

3xx (Redirection): 요청을 완료하기 위해 추가적인 조치가 필요함을 나타냅니다. 301 Moved Permanently (영구적으로 리소스 이동), 302 Found (임시적으로 리소스 이동) 등이 있습니다.

4xx (Client Error): 클라이언트 측의 오류로 인해 요청을 처리할 수 없음을 의미합니다. 400 Bad Request (잘못된 요청), 401 Unauthorized (인증 실패), 403 Forbidden (권한 없음), 404 Not Found (리소스를 찾을 수 없음) 등이 있습니다.

5xx (Server Error): 서버 측의 오류로 인해 요청을 처리할 수 없음을 나타냅니다. 500 Internal Server Error (서버 내부 오류), 503 Service Unavailable (서비스 불가) 등이 있습니다.

네, TCP의 3-way handshake와 4-way handshake에 대해 설명드리겠습니다.

먼저 3-way handshake는 TCP 연결을 설정하는 과정입니다. 클라이언트가 서버에 연결 요청을 위해 SYN 패킷을 보냅니다. 서버는 SYN_RECEIVED 상태로 변경되고, SYN/ACK 패킷을 클라이언트에게 응답합니다. 마지막으로 클라이언트는 ACK 패킷을 서버에게 보내고, 연결이 설정됩니다. 이로써 클라이언트와 서버는 ESTABLISHED 상태가 되어 데이터를 주고받을 수 있습니다.

다음으로 4-way handshake는 TCP 연결을 종료하는 과정입니다. 한쪽(클라이언트 또는 서버)에서 연결 종료를 위해 FIN 패킷을 보냅니다. 상대방은 ACK 패킷으로 응답하고, CLOSE_WAIT 상태로 변경됩니다. 이후 상대방도 FIN 패킷을 보내 연결 종료를 알립니다. 마지막으로 처음 FIN 패킷을 보낸 쪽에서 ACK 패킷을 보내면 연결이 완전히 종료됩니다. 이 과정은 양방향 연결을 안전하게 종료하기 위해 필요합니다.

HTTP/1.1과 HTTP/2의 가장 큰 차이점은 성능입니다. HTTP/1.1은 요청과 응답이 순차적으로 이루어져 HOL Blocking 문제가 발생할 수 있지만, HTTP/2는 멀티플렉싱을 통해 하나의 TCP 연결에서 여러 개의 요청과 응답을 동시에 처리할 수 있습니다.

또한 HTTP/2는 헤더 압축 기술인 HPACK을 사용하여 헤더의 크기를 줄여 전송 효율을 높입니다. HTTP/1.1에서는 헤더가 압축되지 않아 불필요한 데이터 전송이 발생할 수 있습니다.

추가적으로 HTTP/2는 서버 푸시 기능을 제공하여 서버가 클라이언트의 요청 없이도 필요한 리소스를 미리 전송할 수 있습니다. 이는 페이지 로딩 속도를 향상시키는 데 도움이 됩니다. 마지막으로 HTTP/2는 텍스트 기반의 HTTP/1.1과 달리 이진 프로토콜을 사용해 파싱 속도가 빠르고 오류 발생 가능성이 낮습니다.

HTTPS는 HTTP 통신을 암호화하여 보안을 강화한 프로토콜입니다. SSL/TLS 핸드셰이크는 HTTPS 연결을 설정하는 과정이며, 다음과 같이 동작합니다.

1. 클라이언트가 서버에 접속 요청을 보냅니다.
2. 서버는 인증서(공개키 포함)를 클라이언트에게 전송합니다.
3. 클라이언트는 인증서를 검증하여 서버를 신뢰할 수 있는지 확인합니다.
4. 클라이언트는 대칭키 암호화에 사용할 세션 키를 생성하고, 서버의 공개키로 암호화하여 서버에 전송합니다.
5. 서버는 자신의 개인키로 암호화된 세션 키를 복호화합니다.
6. 이후 클라이언트와 서버는 생성된 세션 키를 사용하여 데이터를 대칭키 암호화 방식으로 안전하게 주고받습니다.

이 과정에서 비대칭키 암호화는 세션 키를 안전하게 교환하는 데 사용되고, 이후의 통신은 대칭키 암호화로 이루어져 효율성을 높입니다.

REST API 설계 원칙은 네트워크 기반 분산 시스템을 구축하기 위한 아키텍처 스타일입니다. RESTful하다는 것은 이러한 원칙을 잘 준수하여 설계된 API를 의미합니다.

핵심 원칙으로는 먼저 Uniform Interface가 있습니다. 이는 자원을 식별하는 URI, 자원 표현 방식, 그리고 자원 상태 변경을 위한 표준화된 인터페이스(GET, POST, PUT, DELETE 등)를 통해 시스템 복잡도를 줄이는 것을 목표로 합니다.

두 번째로 Stateless는 서버가 클라이언트의 상태를 저장하지 않는다는 것입니다. 각 요청은 필요한 모든 정보를 포함해야 하며, 서버는 이를 독립적으로 처리합니다.

세 번째는 Cacheable입니다. 응답은 캐싱 가능해야 하며, 이를 통해 성능을 향상시킬 수 있습니다.

네 번째는 Self-Descriptive Messages입니다. 메시지 자체에 충분한 정보가 담겨 있어, 메시지를 받는 쪽에서 추가적인 정보 없이도 메시지를 해석할 수 있어야 합니다.

마지막으로 **HATEOAS (Hypermedia as the Engine of Application State)**는 서버가 클라이언트에게 다음 상태 전이에 필요한 링크를 제공하여, 클라이언트가 API에 대한 사전 지식 없이도 동적으로 상호작용할 수 있도록 합니다. 예를 들어, 응답에 다음 액션을 수행할 수 있는 URI를 포함시키는 것입니다.

컨텍스트 스위칭은 CPU가 현재 실행 중인 프로세스(또는 스레드)의 상태를 저장하고, 다른 프로세스의 상태를 복원하여 CPU를 그 프로세스에게 넘겨주는 과정을 말합니다. 쉽게 말해, CPU가 하던 일을 잠시 멈추고 다른 일을 시작하기 위해 준비하는 과정이죠.

이 과정에서 발생하는 비용은 크게 두 가지입니다. 첫째, 현재 프로세스의 CPU 레지스터 값, 프로그램 카운터, 스택 포인터 등의 정보를 PCB(Process Control Block)라는 곳에 저장하고, 다음 프로세스의 PCB로부터 이 정보들을 다시 읽어오는 오버헤드가 발생합니다. 둘째, 컨텍스트 스위칭 이후에는 캐시 메모리나 TLB(Translation Lookaside Buffer)에 저장된 정보가 유효하지 않게 되어 캐시 미스율이 증가하고, 이는 성능 저하로 이어질 수 있습니다. 따라서 컨텍스트 스위칭은 빈번하게 발생할 경우 시스템 성능에 부담을 줄 수 있습니다.

가상 메모리는 실제 물리 메모리 크기보다 더 큰 주소 공간을 제공하는 기술입니다. 각 프로세스는 독립적인 가상 주소 공간을 가지며, 이 공간은 실제 물리 메모리에 매핑됩니다.

페이지 폴트는 프로세스가 접근하려는 페이지가 현재 물리 메모리에 없을 때 발생합니다. 이 경우 운영체제는 페이지 폴트 핸들러를 호출하여 처리합니다.

페이지 폴트 핸들러는 다음과 같은 과정을 거칩니다. 먼저, 요청된 페이지가 디스크(swap 공간)에 있는지 확인합니다. 있다면, 디스크에서 해당 페이지를 물리 메모리로 가져옵니다. 만약 물리 메모리가 부족하다면, Least Recently Used (LRU)와 같은 페이지 교체 알고리즘을 사용하여 물리 메모리에서 사용 빈도가 낮은 페이지를 디스크로 내보냅니다. 마지막으로, 페이지 테이블을 갱신하여 가상 주소와 물리 주소 간의 매핑을 업데이트하고, 중단되었던 프로세스를 재개합니다.

교착 상태는 여러 프로세스가 서로 원하는 자원을 점유하고 있어, 어느 프로세스도 작업을 진행하지 못하는 상황을 말합니다. 발생 조건은 크게 네 가지가 있습니다.

첫째, 상호 배제입니다. 자원은 한 번에 하나의 프로세스만 사용할 수 있어야 합니다. 둘째, 점유 대기입니다. 프로세스가 이미 자원을 가지고 있으면서, 다른 자원을 기다리는 상태여야 합니다. 셋째, 비선점입니다. 프로세스가 점유한 자원은 강제로 빼앗을 수 없어야 합니다. 마지막으로, 순환 대기입니다. 프로세스들이 서로 꼬리 물기 식으로 자원을 요구하는 상황이 발생해야 합니다.

교착 상태 해결 방법으로는 예방, 회피, 탐지 및 복구가 있습니다. 예방은 위 네 가지 조건 중 하나라도 발생하지 않도록 시스템을 설계하는 것이고, 회피는 안전한 상태를 유지하면서 자원을 할당하는 것입니다. 탐지 및 복구는 교착 상태를 탐지한 후, 프로세스를 종료하거나 자원을 강제로 회수하여 해결하는 방법입니다. 교착 상태 회피를 위해 은행원 알고리즘 같은 방법을 사용할 수 있습니다.

HTTP/3와 QUIC 프로토콜에 대해 설명드리겠습니다. HTTP/3는 기존 TCP 기반의 HTTP/2의 단점을 개선하기 위해 설계된 차세대 HTTP 프로토콜입니다. 핵심은 전송 계층 프로토콜로 QUIC을 사용한다는 점입니다.

QUIC은 UDP 기반으로 동작하여 TCP의 연결 설정 시간 지연을 줄이고, 혼잡 제어 및 오류 복구 기능을 개선했습니다. 특히, HTTP/2에서 발생했던 HOL(Head-of-Line) 블로킹 문제를 해결하기 위해 Multiplexing을 통해 독립적인 스트림을 제공합니다.

또한, QUIC은 TLS 1.3을 내장하여 보안 연결을 기본적으로 제공하며, 연결 마이그레이션 기능을 통해 IP 주소가 변경되어도 연결을 유지할 수 있다는 장점이 있습니다. 이러한 특징 덕분에 HTTP/3는 더 빠르고 안정적인 웹 경험을 제공할 수 있습니다.

네, 좋은 질문입니다. 데이터센터 설계에서 라우터와 L3 스위치를 구분하는 핵심은 패킷 포워딩 방식과 성능입니다.

L3 스위치는 주로 ASIC 기반 하드웨어 스위칭을 통해 매우 빠른 속도로 패킷을 처리합니다. 데이터센터 내부의 짧은 거리 통신이나 서버 간 통신처럼 대량의 트래픽을 낮은 지연 시간으로 처리해야 하는 경우에 최적화되어 있습니다. 즉, L3 스위치는 데이터센터 패브릭 내에서 고속의 라우팅 역할을 수행합니다.

반면, 일반적인 라우터는 소프트웨어 라우팅에 더 의존하는 경향이 있습니다. 이는 더 복잡한 라우팅 프로토콜 처리, WAN 연결, 보안 기능 등 다양한 광역망(WAN) 기능을 수행하는 데 유리합니다. 데이터센터 외부와의 연결이나, 복잡한 정책 기반 라우팅이 필요한 경우에 사용될 수 있습니다.

결론적으로, 데이터센터 내부에서는 ASIC 기반의 L3 스위치가 고성능 패킷 포워딩을 담당하고, 라우터는 데이터센터 경계나 WAN 연결 등 더 복잡하고 유연한 라우팅 기능이 필요할 때 사용된다고 보시면 됩니다.

동일 서브넷 통신 시, 두 호스트는 ARP를 통해 서로의 IP 주소에 해당하는 MAC 주소를 직접 알아냅니다. ARP 요청은 브로드캐스트되어 동일 서브넷 내 모든 호스트에게 전달되며, 목적지 IP에 해당하는 호스트만 자신의 MAC 주소를 응답합니다. 따라서 패킷의 목적지 MAC 주소는 통신하려는 상대방 호스트의 실제 MAC 주소가 됩니다.

반면, 다른 서브넷 호스트와 통신할 때는 게이트웨이를 거쳐야 합니다. 이때 ARP 요청 대상은 통신하려는 상대방 호스트의 IP 주소가 아니라, 게이트웨이 라우터의 IP 주소가 됩니다. 호스트는 ARP를 통해 게이트웨이 라우터의 MAC 주소를 알아내고, 패킷의 목적지 MAC 주소는 이 게이트웨이 라우터의 MAC 주소로 설정됩니다. 실제 목적지 호스트의 MAC 주소는 라우터가 다음 홉으로 전달할 때 다시 ARP를 통해 알아내게 됩니다. 즉, L2와 L3 주소의 책임이 분리되는 거죠. ARP 캐시는 이러한 MAC 주소 정보를 임시 저장하여 불필요한 ARP 요청을 줄여줍니다.

스위치 환경에서 브로드캐스트 스톰이나 루프는 여러 스위치가 이중화된 경로로 연결될 때 발생합니다. 데이터 프레임이 루프를 돌면서 무한히 복제되고 전송되어 네트워크 전체가 마비될 수 있습니다.

STP는 이러한 문제를 방지하기 위해 BPDU라는 제어 프레임을 사용하여 스위치 간에 토폴로지 정보를 교환합니다. 이를 통해 네트워크에서 유일한 루프 없는 트리 구조를 형성하고, 루프를 유발하는 경로는 차단 포트로 만들어 프레임의 무한 순환을 막습니다.

하지만 STP는 토폴로지 변경 시 수렴에 시간이 걸려 일시적인 서비스 중단을 야기할 수 있습니다. RSTP는 이러한 수렴 시간을 획기적으로 단축하여 서비스 영향을 최소화했습니다. RSTP는 BPDU 교환 방식과 포트 상태 전환 로직을 개선하여 더욱 빠르고 효율적인 네트워크 안정성을 제공합니다.

DNS 질의에는 재귀 질의와 반복 질의 두 가지 방식이 있습니다.

재귀 질의는 클라이언트(보통 리졸버)가 네임서버에게 최종 응답을 받을 때까지 모든 과정을 대신 처리해달라고 요청하는 방식입니다. 리졸버는 클라이언트의 요청을 받아 Root, TLD, Authoritative 네임서버를 순차적으로 질의하며 최종 IP 주소를 얻어 클라이언트에게 전달합니다.

반복 질의는 네임서버가 클라이언트에게 "모르겠으니 다른 곳에 물어보라"는 응답을 반복적으로 보내는 방식입니다. Root 네임서버는 TLD 네임서버의 주소를, TLD 네임서버는 Authoritative 네임서버의 주소를 알려주는 식이죠. 최종적으로 Authoritative 네임서버가 IP 주소를 알려주면, 이 정보가 다시 리졸버를 거쳐 클라이언트에게 전달됩니다.

요약하자면, 재귀 질의는 리졸버가 모든 책임을 지고, 반복 질의는 각 네임서버가 다음 단계를 안내하는 방식이라고 할 수 있습니다.

네, DNS 레코드 타입별 용도와 CNAME 레코드 제약 및 우회 방식에 대해 설명드리겠습니다.

A 레코드는 도메인 이름을 IPv4 주소로, AAAA 레코드는 IPv6 주소로 매핑합니다. CNAME 레코드는 다른 도메인 이름에 대한 별칭을 설정할 때 사용됩니다. NS 레코드는 해당 도메인의 네임서버를 지정하고, MX 레코드는 메일 서버 정보를, TXT 레코드는 임의의 텍스트 정보를 저장합니다. SOA 레코드는 존(zone)의 기본 정보를 담고 있습니다.

CNAME 레코드는 다른 레코드 타입과 같은 이름(예: www.example.com)에 공존할 수 없다는 RFC 규정이 있습니다. 특히 도메인 루트(zone apex, 예: example.com)에는 SOA, NS 레코드가 필수적이므로, CNAME을 직접 설정할 수 없습니다.

이를 우회하기 위해 ALIAS 또는 ANAME과 같은 비표준 레코드 타입이 사용됩니다. 이 방식은 DNS 제공업체에서 지원하며, CNAME처럼 동작하지만 실제로는 A 또는 AAAA 레코드로 변환되어 루트 도메인에서도 사용할 수 있게 해줍니다.

DNS 캐싱에서 TTL은 전환 속도와 질의 부하/안정성 간의 트레이드오프를 만듭니다.

TTL을 짧게 설정하면 DNS 레코드 변경 시 빠르게 반영되어 장애 대응에 유리합니다. 예를 들어, 서버 IP가 변경되었을 때 짧은 TTL 덕분에 클라이언트들은 빠르게 새 IP로 접근할 수 있습니다. 하지만 짧은 TTL은 DNS 서버에 대한 질의 부하를 증가시켜 성능 저하나 안정성 문제를 야기할 수 있습니다.

반대로 TTL을 길게 설정하면 DNS 서버의 질의 부하가 줄어들어 안정적이고 빠른 응답을 기대할 수 있습니다. 하지만 레코드 변경 시 반영 속도가 느려져 장애 발생 시 복구 시간이 길어지는 단점이 있습니다. 트래픽 분산 측면에서도, 짧은 TTL은 여러 서버로 트래픽을 분산시키는 데 더 유연하게 대처할 수 있습니다.

Negative Caching은 존재하지 않는 도메인이나 레코드에 대한 질의 결과를 캐싱하는 것입니다. TTL이 설정되어 있어, 해당 시간 동안은 동일한 질의에 대해 DNS 서버는 즉시 NXDOMAIN 응답을 반환합니다. 이는 불필요한 DNS 질의를 줄여 서버 부하를 감소시키고 응답 속도를 향상시키는 장점이 있습니다. 하지만 잘못된 Negative Caching 정보가 캐싱되면, 실제 존재하는 도메인에 접근하지 못하는 문제가 발생할 수 있습니다.