DNS_PROBE_FINISHED_NXDOMAIN, 회사에서 왜 나만 접속이 안 되는 거야?

최근에 사내에서 사용할 프로젝트인 JEI데이터허브(JUNDA)를 개발했습니다. 지금은 QA 과정에서 발생한 이슈를 직접 처리하고 있으며, 파일럿 테스트를 위한 준비를 하고 있습니다.

간단하게 소개하자면, 사업지원팀처럼 개발자가 아닌 분들이 SQL 없이 자연어로 사내 서비스 데이터를 직접 조회할 수 있게 해 주는 서비스입니다. 그동안은 데이터를 확인할 때마다 개발팀에 조회를 요청해야 했는데, 이러한 병목을 없애기 위한 프로젝트입니다.

그런데 기획팀에서 QA를 진행하던 중, 한 분만 Chrome에서 DNS_PROBE_FINISHED_NXDOMAIN 에러로 서비스에 접속하지 못하는 일이 발생했습니다. 다른 분들은 모두 정상적으로 접속되는 상황이었습니다.

지금부터 왜 이런 일이 발생했는지 네트워크 개념 정리와 함께 간단하게 글로 정리해 보려고 합니다.

문제 상황

이슈가 발생한 환경은 아래와 같습니다.

• OS: macOS
• 브라우저: Google Chrome
• 네트워크: 회사 전용 네트워크 (사내 DNS 사용)

서비스 주소로 접속하면 Chrome에 DNS_PROBE_FINISHED_NXDOMAIN 에러 화면이 나타났습니다.

이상한 점은 같은 사무실에서 같은 사내망에 연결된 다른 분들은 모두 정상적으로 접속된다는 것이었습니다. 그리고 이슈를 겪은 분이 사내망에 연결된 핸드폰으로 접속하면 서비스가 정상적으로 열렸습니다.

만약 서버나 네트워크 전체의 문제였다면 핸드폰으로도 접속이 되지 않았을 테니, 이슈를 겪은 분의 PC 세팅 문제겠구나라고 생각했습니다.

이슈 원인 추적 과정

시도 1: DNS 캐시 초기화

DNS의 개념에 대해 자세하게 다루지는 않겠습니다.

DNS(Domain Name System)은 example.com 같은 도메인 주소를 컴퓨터가 접속할 수 있는 IP 주소로 바꿔 주는 시스템입니다. 그리고 한 번 조회한 결과는 매번 다시 묻지 않도록 운영체제와 브라우저가 일정 시간 저장해 두는데, 이를 DNS Cache라고 합니다.

처음에는 해당 PC에 잘못된 DNS 조회 결과가 남아 있어서 에러가 발생한다고 생각해, DNS 캐시부터 초기화했습니다.

macOS에서는 아래 명령어로 OS의 DNS 캐시를 초기화할 수 있습니다.

# 참고) ;는 앞 명령이 끝나면 다음 명령을 이어서 실행한다는 의미입니다.
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

• dscacheutil -flushcache: macOS의 디렉터리 서비스 캐시를 비웁니다.
• killall -HUP mDNSResponder: macOS에서 DNS 조회를 담당하는 mDNSResponder 프로세스에 HUP(Hang-UP) 신호를 보내서 저장해 둔 DNS 캐시를 비우게 합니다. 참고로 killall이지만 프로세스가 종료되지는 않습니다.

Chrome 브라우저에서도 자체적으로 DNS 캐시를 가지고 있어서, chrome://net-internals/#dns에 들어가 Clear host cache 버튼을 눌러 초기화했습니다.

하지만 두 캐시를 모두 비워도 여전히 이슈가 발생했습니다.

시도 2: DNS 설정 확인

캐시를 비워도 해결이 안 돼서, 이슈가 발생하신 분의 PC를 받아 어떤 DNS 서버에 조회를 요청하고 있는지를 확인해 봤습니다.

DNS 서버는 어떻게 정해질까?

PC가 사용할 DNS 서버를 정하는 방법은 크게 두 가지입니다.

• 자동(DHCP): 네트워크에 접속하면 공유기나 회사 네트워크 장비가 IP 주소와 함께 사용할 DNS 서버를 자동으로 알려 줍니다. 이 방식을 DHCP(Dynamic Host Configuration Protocol)라고 합니다.
• 수동: 사용자가 DNS 서버 주소를 직접 입력합니다. 직접 입력한 DNS가 하나라도 있으면, DHCP로 받은 DNS 대신 직접 입력한 DNS만 사용합니다.

참고로 macOS에서는 시스템 설정 -> Wi-Fi -> 세부사항 -> DNS에서 사용 중인 DNS 서버 목록을 볼 수 있습니다. 목록에서 회색 글씨는 DHCP로 받은 DNS이고 검은 글씨는 사용자가 직접 입력한 DNS입니다.

터미널에서는 아래 명령어로도 확인할 수 있습니다.

# 직접 입력한 DNS 확인 (없으면 "There aren't any DNS Servers set on Wi-Fi." 출력됨)
networksetup -getdnsservers Wi-Fi

# 실제로 사용 중인 DNS 확인
scutil --dns

정상적으로 접속되는 필자의 PC DNS

$ networksetup -getdnsservers Wi-Fi
There aren't any DNS Servers set on Wi-Fi.

$ scutil --dns
resolver #1
  nameserver[0] : 192.168.x.x     # 사내 DNS
  nameserver[1] : 168.126.63.1    # KT 공용 DNS

직접 입력한 DNS는 없고, 회사 네트워크가 DHCP로 알려 준 DNS를 그대로 사용하고 있었습니다. 그리고 그 순서는 사내 DNS가 첫 번째, KT 공용 DNS가 두 번째였습니다.

이슈를 겪은 PC의 DNS

반면 이슈를 겪은 분의 PC에는 사내 DNS는 없고, DNS가 KT 공용 DNS(168.126.63.1)로 직접 입력되어 있었습니다.

회사 네트워크는 이 PC에도 DHCP로 사내 DNS를 알려 줬겠지만, 직접 입력한 DNS가 있으면 DHCP로 받은 DNS는 사용되지 않습니다. 그래서 DNS 목록에도 직접 입력한 KT DNS만 보였고, 사내 DNS에는 조회 요청 자체가 가지 않고 있었습니다. 이 부분이 문제의 시발점이었습니다.

시도 3: 사내 DNS 추가

원인을 확인했기 때문에 사내 DNS를 추가하면 해결될 거라고 생각했습니다. 그래서 기존의 KT DNS는 그대로 두고, 그 아래에 사내 DNS를 추가했습니다.

순서	DNS 서버
1	168.126.63.1 (KT 공용 DNS)
2	192.168.x.x (사내 DNS)

그렇지만 결과는 그대로였습니다. 여전히 DNS_PROBE_FINISHED_NXDOMAIN 에러가 발생했습니다.

사내 DNS가 목록에 분명히 들어 있는데 왜 안 되는지 의아했습니다. 그래서 혹시나 하는 마음에 두 DNS의 순서를 바꿔 보았습니다.

순서	DNS 서버
1	192.168.x.x (사내 DNS)
2	168.126.63.1 (KT 공용 DNS)

이 경우에 정상적으로 접속이 되었습니다. 같은 DNS 서버 두 개를 등록했는데, 순서만 바꿨을 뿐인데 결과가 달라진 것입니다. 그리고 이 순서는 앞에서 본 필자의 PC, 즉 회사 네트워크가 DHCP로 알려 주는 DNS 순서와 동일했습니다.

왜 순서가 중요했을까?

JEI데이터허브 서비스 도메인은 사내 DNS만 알고 있었다!

회사에서 쓰는 도메인이라고 모두 사내 DNS에만 종속되는 건 아닙니다. 저희 회사도 개발 서버에 같은 회사 도메인을 쓰지만, 어떤 서비스는 외부에서도 접속할 수 있고 어떤 서비스는 사내에서만 접속할 수 있습니다.

JEI데이터허브 서비스는 사내 데이터를 다루기 때문에 사내망에서만 사용할 수 있도록 구성했고, 도메인도 사내 DNS에만 등록되어 있었습니다. 실제로 dig 명령어로 두 DNS에 각각 물어보면 차이를 바로 확인할 수 있습니다.

# 사내 전용 서비스(JEI데이터허브) - KT 공용 DNS에 질의
$ dig @168.126.63.1 junda.example.com
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

# 사내 전용 서비스(JEI데이터허브) - 사내 DNS에 질의
$ dig @192.168.x.x junda.example.com +short
192.168.y.y

정리하면 아래와 같습니다.

도메인	KT 공용 DNS의 답	사내 DNS의 답
외부에 공개된 서비스 (public.example.com)	203.0.113.10	203.0.113.10
사내 전용 서비스 (junda.example.com)	없음 (NXDOMAIN)	192.168.y.y

외부에 공개된 서비스는 어느 DNS에 물어봐도 같은 응답이 오지만, JEI데이터허브는 사내 DNS에서만 응답을 받을 수 있습니다. 이렇게 같은 도메인에 대해 회사 안과 밖의 DNS가 서로 다른 답을 주도록 나눠 놓은 구성을 스플릿 DNS(Split DNS)라고 합니다.

KT 공용 DNS는 사내 DNS에 무엇이 등록되어 있는지 알 수 없기 때문에, JEI데이터허브 도메인을 물어보면 “그런 도메인은 없다”고 답합니다. 이 “없다”는 응답이 바로 NXDOMAIN(Non-Existent Domain)이고, Chrome의 에러 이름 DNS_PROBE_FINISHED_NXDOMAIN도 “DNS 조회 결과 NXDOMAIN을 받았다”는 뜻입니다.

참고로 KT가 아니라 Google DNS(8.8.8.8) 같은 다른 공용 DNS를 썼어도 결과는 같았을 것입니다.

NXDOMAIN은 “모른다”가 아니라 “없다”는 의미이다.

DNS 서버를 여러 개 등록하면, 보통 첫 번째 서버에 먼저 물어봅니다. 두 번째 서버는 첫 번째 서버가 응답하지 않을 때(타임아웃 등) 사용하는 예비 서버에 가깝습니다.

여기서 중요한 점은, NXDOMAIN은 “응답하지 않은 것”이 아니라 “그런 도메인은 없다”고 확실하게 응답한 것이라는 점입니다. 그래서 첫 번째 서버에게 NXDOMAIN을 받으면, PC는 그 답을 믿고 두 번째 서버에 다시 물어보지 않습니다. (DNS 응답에 붙는 결과 코드(예를 들어 SERVFAIL 등)에 따라 다시 물어볼 수도 있습니다)

결국 사내 DNS를 추가한 것만으로는 부족했고, 사내 DNS가 첫 번째에 있어야 했던 것입니다.

다만 DNS 서버를 언제, 어떤 순서로 사용하는지는 OS마다 조금씩 다릅니다. 특히 macOS는 순서를 엄격하게 지키지 않고 응답이 빠른 서버를 더 자주 쓰기도 합니다. 그래서 사내 DNS와 공용 DNS를 섞어 쓰면 가끔씩 실패할 수도 있습니다.

핸드폰은 왜 접속됐을까?

처음에 이상하게 느꼈던 점이 하나 더 있었습니다. 같은 분이 같은 사내 Wi-Fi에 연결된 핸드폰으로는 정상적으로 접속했다는 점입니다.

핸드폰에는 DNS를 따로 입력하지 않았기 때문에, 회사 네트워크가 DHCP로 알려 준 DNS를 그대로 사용했을 것입니다. 즉, 필자의 PC와 마찬가지로 사내 DNS가 첫 번째인 구성이었고, 그래서 사내 서비스 도메인을 문제없이 찾을 수 있었습니다.

만약, 회사 밖에서 접속해야 한다면?

JEI데이터허브는 사내에서만 사용하는 서비스라 그럴 일은 거의 없지만, 만약 회사 밖에서 접속해야 한다면 어떨까요?

JEI데이터허브의 도메인은 사내 DNS에만 등록되어 있고, 서버 역시 사내 네트워크에서만 접근할 수 있는 주소(사설 IP)를 사용합니다. 그래서 집이나 카페처럼 회사 밖의 네트워크에서는 DNS 설정을 어떻게 바꾸더라도 접속할 수 없습니다. 사내 DNS 자체가 회사 네트워크 안에 있어서, 밖에서는 사내 DNS에 물어볼 수조차 없기 때문입니다.

일반적으로 회사 밖에서 사내 서비스에 접속해야 할 때는 VPN(Virtual Private Network)을 사용합니다.

VPN은 인터넷 위에 회사 네트워크까지 이어지는 암호화된 전용 통로를 만들어 주는 기술입니다. VPN에 연결하면 내 PC는 물리적으로는 집에 있어도, 네트워크상으로는 회사 안에 있는 것처럼 동작합니다. 보통 VPN에 연결하면 사내 DNS도 함께 설정되기 때문에, 회사에서와 마찬가지로 사내 서비스 도메인을 찾을 수 있습니다.

마무리

이번 일을 정리하면 이렇습니다.

• 사내 서비스 도메인은 사내 DNS만 알고 있었고, 공용 DNS는 “없다(NXDOMAIN)”고 답했습니다.
• NXDOMAIN은 확실한 답이라서, 두 번째로 등록한 사내 DNS까지 질의가 넘어가지 않았습니다.
• 그래서 DNS 서버를 등록했는지뿐 아니라, 어떤 순서로 등록했는지도 중요했습니다.

네트워크… 공부 더 열심히 해야겠습니다… 순서가 중요한 것을 몰랐다니..!