DNS_PROBE_FINISHED_NXDOMAIN 대응기

개요

highjoon-dev.com 도메인을 가비아에서 구매하고, 프론트엔드를 Vercel, 백엔드를 AWS Lightsail에 구성한 상황에서 발생한 DNS 이슈 해결 과정이다.

프론트엔드: highjoon-dev.com, www.highjoon-dev.com (Vercel 배포)
백엔드 API: api.highjoon-dev.com (AWS Lightsail 배포)

문제 상황

highjoon-dev.com 또는 www.highjoon-dev.com 접속 시, 간헐적으로 DNS_PROBE_FINISHED_NXDOMAIN 오류가 발생했다.

DNS_PROBE_FINISHED_NXDOMAIN

의미: “DNS 요청 결과, 해당 도메인 이름이 존재하지 않는다고 응답받았다.”

NXDOMAIN은 Non-eXistent Domain의 약자로, 브라우저가 DNS 서버에 도메인 이름에 대한 질의를 보냈지만 “해당 도메인은 없다”는 응답을 받은 상태를 의미이다.

주로 발생하는 원인

네임서버 혼합 사용

서로 다른 DNS 제공자의 네임서버가 함께 등록되어 있을 경우, 어떤 DNS 응답은 정상, 어떤 것은 실패하면서 간헐적 오류가 발생할 수 있다.

DNS 레코드 누락

도메인을 등록했지만 A 레코드나 CNAME 레코드가 등록되지 않은 경우

네임서버와 레코드 설정 불일치

도메인의 네임서버는 A라는 DNS 제공자(DNS 호스팅)를 가리키고 있지만, 실제로 그 DNS 서버에는 해당 레코드가 등록되어 있지 않은 경우

관련 개념

트러블슈팅 과정에서 정리한 핵심 개념

네임서버

도메인의 DNS 레코드를 어디서, 누가, 어떻게 관리할지를 결정하는 서버

하나의 도메인은 반드시 하나의 네임서버 세트 (동일한 DNS 제공자)만 사용해야한다.

예: 가비아, Vercel, Cloudflare, AWS Route 53 등

서로 다른 네임서버를 혼합하면 일부 질의에서만 응답하는 등 불안정한 상황이 발생할 수 있다.

DNS 레코드

도메인 이름을 IP 주소, 다른 도메인, 인증 정보 등으로 매핑하는 설정

도메인 이름이 어떤 IP 주소나 리소스를 가리킬지 정의하는 설정 항목

A 레코드 (Address)

도메인을 IP 주소로 직접 연결하는 방식

가장 기본적이고 빠른 DNS 연결 방법

CNAME 레코드 (Canonical Name)

도메인을 다른 도메인의 별칭(alias) 으로 연결

유연한 연결 방식이지만, 루트 도메인(@)에는 사용할 수 없음

“이 도메인은 저 도메인의 또 다른 이름” 이라는 의미

TXT 레코드

도메인 소유 인증 (Google, AWS, GitHub 등), 이메일 보안(SPF, DKIM), 설명 정보 등 다양한 용도로 사용

DNS 요청 흐름: 브라우저 주소 입력 시

사용자가 브라우저에 호스트.highjoon-dev.com (예: www.highjoon-dev.com)을 입력
브라우저는 로컬 DNS 캐시 → 운영체제 → 설정된 DNS 서버 순으로 DNS 질의를 시도
DNS 서버는 highjoon-dev.com 도메인의 네임서버(NS 레코드) 를 따라 권한 있는 DNS 서버를 조회
해당 네임서버가 호스트에 대한 A 또는 CNAME 레코드를 응답 (예: 76.76.21.21 또는 cname.vercel-dns.com)
브라우저는 받은 IP 주소로 서버에 HTTP/HTTPS 요청을 전송하여 웹페이지를 로딩

dig 명령어를 통한 레코드 확인 예시

➜  ~ dig highjoon-dev.com

;; ANSWER SECTION:
highjoon-dev.com. 600 IN A 76.76.21.21

문제점

기존 가비아 네임서버 설정

문제점은 서로 다른 네임서버 제공자를 혼용해서 사용하고 있었다는 점이다.

1차, 3차: Vercel의 네임서버
2차~6차: AWS 네임서버

하나의 도메인은 하나의 네임서버 세트만 사용해야 한다.

DNS 질의는 브라우저(또는 클라이언트)가 등록된 네임서버 중 하나를 무작위로 선택해 질의한다.

즉, 어떤 요청은 Vercel 네임서버로, 어떤 요청은 AWS 네임서버로 보내졌고:

✅ Vercel NS → www 레코드 응답 → 정상 연결
❌ AWS NS → www 레코드 없음 → NXDOMAIN 발생

따라서, AWS로 보내졌을 때는 www.highjoon-dev.com 에 대한 도메인 정보가 없기 때문에 DNS_PROBE_FINISHED_NXDOMAIN 에러가 발생했다.

사용자 요청 → 네임서버 랜덤 선택 →
   → Vercel NS → www 레코드 있음 → OK
   → AWS NS → www 레코드 없음 → NXDOMAIN

또한 도메인의 네임서버가 가비아가 아니기 때문에, 가비아에서 설정한 DNS 레코드는 실제로 참조되지 않았다. 클라이언트는 Vercel 또는 AWS의 네임서버에 질의했기 때문에, 가비아에게는 질의 자체가 전달되지 않았다.

해결책

1. 가비아 네임서버로 통일

Vercel과 AWS로 나뉘던 네임서버를 가비아 네임서버로 통일했다.

이제 highjoon-dev.com 도메인으로 들어오는 모든 요청은 가비아 네임서버를 통하게 된다.

따라서 가비아 DNS 설정이 정확히 반영되게 된다.

2. 가비아 DNS 레코드 설정

호스트	타입	값	용도
`www`	CNAME	`cname.vercel-dns.com.`	프론트엔드 연결
`api`	A	`3.35.178.188`	백엔드 (Lightsail)
`@`	A	`76.76.21.21` (Vercel)	루트 → www 리디렉션

프론트와 백엔드를 분기 처리해 연결했으며, 루트 도메인은 Vercel 고정 IP로 연결하여 Vercel에서 www로 리디렉션 처리하게 했다.

3. Vercel 도메인 설정

Vercel 프로젝트에 highjoon-dev.com 도메인을 추가하고, Redirect to www.highjoon-dev.com 옵션 활성화했다.

이제 루트 도메인으로 접근해도 Vercel이 자동으로 www로 리디렉션 처리하게 된다.

DNS 변경이 바로 적용되지 않는다? - TTL 캐시, DNS 전파

DNS 레코드를 변경했음에도 웹에서 바로 적용되지 않고 여전히 NXDOMAIN 오류를 겪는 경우가 있었다.

이는 DNS의 캐싱과 TTL (Time To Live) 때문이었다.

캐싱과 TTL (Time To Live)

TTL이 남아 있는 동안은 기존 레코드가 유지되므로, 변경 사항이 바로 반영되지 않을 수 있다.

DNS 레코드는 클라이언트(브라우저 등)에 일정 시간 동안 캐싱된다. 이 캐싱이 유지되는 시간이 TTL이다.

TTL 값이 유지되는 동안, 클라이언트는 DNS 서버에 다시 질의하지 않고, 캐시된 값만 사용한다.

즉, 이전 설정이 잘못된 상태로 캐시되어 있다면 DNS를 올바르게 수정했더라도 여전히 문제가 보일 수 있다.

DNS 전파

도메인의 DNS 설정(예: 네임서버, A/CNAME 레코드 등)을 변경한 뒤, 이 변경 사항이 **모든 클라이언트, 브라우저, 운영체제, DNS 서버 (ISP 등)**에 반영되기까지 걸리는 시간 또는 과정

DNS 설정을 변경하면 DNS 전파는 즉시 시작된다.

하지만 클라이언트는 TTL이 만료되기 전까지는 이전에 캐시된 DNS 값을 계속 사용하므로, TTL이 만료되어야 비로소 새로운 DNS 질의를 수행하고 최신 정보를 받아온다.

https://dnschecker.org/ 에서 DNS 전파 진행 상황을 알 수 있다.

마치며

DNS_PROBE_FINISHED_NXDOMAIN 에러는 DNS 레코드나 네임서버 설정 충돌로 발생할 수 있다.

하나의 도메인은 하나의 네임서버 세트만 사용해야 한다. ex) highjoon-dev.com 으로 프론트엔드, 백엔드 모두 호스팅하려는 경우 하나의 DNS 제공자에서 하나의 네임서버만 사용 필요.

가비아에서 도메인을 구매했다면, 가비아 DNS 설정이 유효하려면 네임서버도 가비아여야 한다.