리턴 메시지 : DNS resolving error

□ 리턴 메시지

▷ 451 DNS resolving error ▷ 512 Bad destination system address ▷ 550 5.4.4 Sorry, I couldn't find any host by that name ▷ DNS type 'mx' lookup of [domain] responded with code NXDOMAIN Domain name not find: [도메인]  ▷ 550 Host unknown

뜻 : 수신측의 도메인(DNS) 정보를 찾을 수가 없습니다.

▶ 공통점을 확인해 보면 전부 수신 측의 「도메인(DNS)」 이름을 찾을 수 없거나 잘못된 주소라고 인식하여 실패한 리턴메시지라는 점입니다. 또는 도메인 정보는 살아 있더라도 메일을 수신받을 수 있는 「MX」라는 레코드가 없을 경우에도 발생할 수 있습니다.

DNS(Domain Name System, DNS) 란?

서버에는 통신하기 위해 IP(111.111.111.111)와 같은 네트워크 숫자가 할당되어 있지만, 숫자를 기억하기 어렵기 때문에 사람이 이해하기 쉬운 도메인 이름을 숫자로 된 IP로 변환해주는 것을 말합니다. 예시로 URL주소에 daum.net, tistory.com 을 입력하면 사이트를 찾아갈 수 있는것도 이 「DNS」의 역활입니다.

DNS 레코드 참고 : https://foxydog.tistory.com/28

---

□ 원문 메시지[예시]

---

□ 발생 패턴

메시지의 의미는 같지만 발생할 수 있는 패턴이 생각보다 많습니다. 순차적으로 알아보도록 하겠습니다.

 

① 발송자가 메일주소 도메인을 잘못 입력하였을 경우

해당 경우는 받은 메일을 회신할 경우는 이미 저장되어 있는 메일주소를 불러와서 발송하기 때문에 문제가 없지만 구두상으로 메일주소를 듣고 직접 입력하는 과정 중에 오타가 발생하는 경우가 대부분이었습니다.

 

② 수신자의 도메인이 없거나 기간이 만료가 된 경우

평소 잘 주고받던 메일주소이나 갑자기 위 리턴메시지가 온다면 수신자의 도메인 기간이 만료가 된 건지 확인할 필요가 있습니다. 이는 반대의 상황에서도 발생할 수 있습니다.

 

◇ 도메인 확인 사이트「KISA 제공」 : https://후이즈검색.한국

- test.co.kr | test.kr (.한국) | test.com | test.net등 외 도메인도 검색이 가능합니다.

- .co.kr |  .kr 등의 한국 도메인은 한글로 나오지만 .com | .net 등의 국제 도메인은 영문으로 출력됩니다.

※ 국제도메인의 경우는 「Domain Status」 상태 메시지가 「ClientHold」라고 도메인 기간이 만료되어 일시중지(잠긴) 상태라고 생각하면 됩니다.

 

후이즈(WHOIS) 사이트를 통해 어디에서 도메인을 구입했는지 만료일이 언제인지 네임서버가 어디에 연결되어 있는지 확인이 가능합니다. 만약 도메인 만료가 되더라도 바로 삭제처리는 하지 않고 평균적으로 약 30일 정도의 유예기간을 줍니다. (도메인 종류 또는 기관마다 다릅니다.) 그 안에 비용을 지불하면 다시 도메인이 활성화가 되고 연결되어 있는 네임서버도 같이 연결이 됩니다.

※ 이런 사례도 있습니다. 회사에서 사용하는 중요한 고유 도메인이나 연장을 하지 않고 기간이 만료되어 삭제처리가 되어 다른 개인 또는 기업이 해당 업체의 도메인을 구입 사용하여 분쟁이 발생하는 경우도 있었습니다. 만약 꼭 기존에 사용하던 도메인을 찾아야 한다면 KISA 한국인터넷흥원에서 ICT분쟁조정지원센터를 통해 문의를 해보셔야 합니다.

 

③ 수신 측 도메인이 네임서버 변경으로 인한 MX 레코드 누락

생각보다 흔하게 발생하는 유형입니다. 어떤 업체가 홈페이지를 재 구축하기 위해 웹에이전시 업체에 맡깁니다. 구축이 완료되면 홈페이지 관리 편의성을 위해 본인들이 운영하는 네임서버로 권하는 경우가 많은데요. 이 과정에서 기존에 사용하던 네임서버의 레코드 정보를 알고 난 후에 미리 세팅한 상태에서 변경 진행을 해야 하나 본인들이 사용하는 A 레코드만 등록하고 메일을 수신받을 수 있는 MX 레코드를 누락하는 경우가 있습니다. 수신이 안되고 나서야 뒤늦게 MX값을 파악하여 등록하는 경우가 대다수입니다. 거기다 네임서버라는 것은 전파 시간이 있기 때문에 등록하더라도 완전히 정상화가 되려면 최소 6시간 ~ 24시간 정도 소요가 될 수 있습니다.

 

④ 발송서버의 네임서버 문제(메일서버 관리자 참고)

드물긴 하지만 이게 제일 난감한 문제인데요, 수신 측의 도메인이 전혀 문제가 없음에도 이상하게 내가 이용하는 메일서버에서만 발송실패하는 경우가 있습니다. 일반 사용자는 해당문제인지 알 수 없기 때문에 메일관리자가 확인하는 방법밖에 없습니다.

 

메일을 발송할 때 그냥 발송되는 게 아니라 수신 측의 도메인 네임서버 정보를 찾아서 발송하게 됩니다. 윈도우의 네트워크 설정을 확인해 보면 모든 PC/서버에는 DNS 서버를 자동(DHCP)으로 할당받거나 수동으로 세팅을 하게 되는데요. 리눅스, 유닉스 메일서버에도 대체로 「/etc/resolv.conf」 파일에 「nameserver 168.126.63.1」 형태로 네임서버가 설정되어 있습니다. 그런데 이 네임서버라는 게 하나만 있는 게 아니라 각 「인터넷 서비스 제공(ISP, Internet Service Provider)」 업체마다 대표적(글로벌)으로 제공하는 네임서버가 있습니다. 예시로 「KT, LG U+, SKT」를 말합니다.

 

※ 각 통신사별 대표 네임서버(DNS) 서버 IP 목록(그외에도 많음)

통신사	사용처	기본 설정 DNS	보조 DNS
KT	국내	168.126.63.1	168.126.63.2
SKT	국내	219.250.36.130	210.220.163.82
LG U+	국내	164.124.101.2	203.248.252.2
구글(Google)	해외	8.8.8.8	8.8.4.4
클라우드 플레어(Cloudflare)	해외	1.1.1.1	1.0.0.1

그래서 이런 상황이 발생할 수 있습니다. 수신 측이 도메인 정보 업데이트를 하면 각 통신사 네임서버로 전파를 하게 되는데 간혹 전파 시리얼 정보를 받지(업데이트) 못해 기존 정보를 계속 가지고 있는 경우가 있습니다.

예시에 나와 있는 것처럼 SKT/구글 DNS를 사용하는 발송메일서버는 정상적으로 수신 측의 도메인을 질의하여 메일(메시지) 전송에 성공을 하였지만 KT DNS를 사용하는 발송메일서버는 수신 측의 도메인이 아직 업데이트가 되지 않아 발송 실패를 하는 경우를 말합니다. 이는 웹사이트 홈페이지를 연결할 때도 마찬가지입니다.

누구 PC에서는 빠르게 접속이 되나 또 다른 PC에서는 접속이 느리거나 안 되는 경우를 경험한 적이 있을 겁니다. 이 모든 게 DNS/DNS캐시 정보에서 찾지 못해서 발생하는 문제입니다.

 

◇ 가장 빠른 해결 방법은 발송메일서버의 네임서버를 바꾸는 방법입니다. 리눅스, 유닉스 서버에 메일서버를 구축했다면 일반적으로 「# /etc/resolv.conf」 파일에 「nameserver」 정보를 따라가므로 수신 측 도메인 질의가 잘되는 네임서버로 변경해 주시면 됩니다. 간혹 이용하는 솔루션에서 SMTP 환경설정에 네임서버를 먼저 참조하는 경우도 있으므로 환경에 따라 대처하면 됩니다.

 

◇ 참고로 네임서버는 「UDP 53 Port」로 통신을 합니다. 아래와 같이 「nslookup」이라는 명령어를 통해 질의가 정상적으로 되는지 테스트할 수 있습니다. 질의가 안된다면 국가적으로 53 Port를 방화벽에 의해 막는다던가 네트워크 라우터 설정 문제라던가, 또는 네임서버 전파 문제등 여러 가지가 있지만 복잡해지므로 간단하게 설명하였습니다.

# nslookup -type=mx [도메인주소] [ISP 네임서버]

예시# nslookup -type=mx eztest.com 8.8.8.8

---

마치며

리턴메일이 왜 오는지 공부를 해보면, 자연스럽게 메일 송수신 흐름을 알게 됩니다. 일반 사용자들은 메일 보내기 하고 끝이지만 메일서버 내부에서부터 ISP인터넷 네트워크를 통해 수신메일서버까지 DNS조회와 SMTP 처리 통신 단 한 번도 문제가 없을 때 비로소 수신자에게 메일이 도착합니다. 제가 올리는 리턴메시지는 자주 접하게 되는 흔한 리턴메일이지만 그 외에도 정말 수없이 많은 패턴들이 존재합니다. 이런 패턴들을 하나둘씩 누적하여 원인을 파악하다 보면 자기도 모르게 메일서버 관리를 할 수 있는 수준을 볼 수 있을 겁니다.