Domain IP Lookup

거의 모든 존에서 만나게 되는 레코드

A호스트 이름을 IPv4 주소로 연결
AAAA호스트 이름을 IPv6 주소로 연결
CNAME호스트 이름을 다른 호스트 이름으로 연결
MX도메인을 메일 서버로 연결, 우선순위 기준
TXT도메인에 임의의 텍스트 연결: SPF, DKIM, 소유권 확인
NS도메인에 응답하는 네임서버 지정
실무 가이드

DNS 체커: DNS 레코드를 올바르게 확인하는 방법

읽는 시간 5분

DNS 체커는 리졸버가 현재 도메인에 대해 가져올 수 있는 레코드를 간편하게 확인하는 방법입니다. 웹사이트 호스트를 바꾸거나, 이메일을 설정하거나, DNS 제공업체를 옮기거나, 확인되지 않는 이름을 조사할 때 사용합니다. 결과는 한 시점의 스냅샷일 뿐이며, 모든 재귀 리졸버가 갱신되었다거나 기반 서비스를 사용할 수 있다는 보장은 아닙니다. 조회를 유용하게 만들려면 정확한 호스트 이름을 선택하고, 증상에 맞는 레코드 유형을 고르고, 빈 응답을 DNS 오류와 다르게 해석해야 합니다. 이 세 단계만 지켜도 많은 오탐을 막고 어느 설정 계층을 살펴봐야 하는지 알 수 있습니다.

질문에 답해 주는 레코드를 고르세요

웹사이트의 IPv4 주소는 A를, IPv6는 AAAA를 확인합니다. 서브도메인은 주소를 직접 가지는 대신 CNAME으로 호스팅 제공업체의 호스트 이름을 가리킬 수 있습니다. 이메일 전달은 먼저 MX 레코드에 달려 있고, TXT 레코드에는 SPF, DKIM, DMARC, 소유권 인증 데이터가 게시되는 경우가 많습니다. NS 레코드는 존에 등록된 네임서버를 보여 주고, SOA는 해당 존의 관리 정보와 타이밍 필드를 제공합니다. 따라서 문제가 메일 전달, 위임된 서브도메인, 인증 단계에 있다면 A 레코드만 확인해서는 충분하지 않습니다. 영향을 받는 서비스에서 출발해 증상을 해당 레코드 유형에 대응시키세요.

증상먼저 확인할 레코드
웹사이트가 잘못된 호스트를 가리킴A, AAAA, CNAME
메일 라우팅이 고장 난 것처럼 보임MX, SPF/DKIM/DMARC TXT
도메인 변경이 무시되는 것처럼 보임NS, SOA, 변경한 레코드, TTL
외부 서비스가 소유권을 인증하지 못함서비스가 요청한 정확한 TXT 또는 CNAME

다음으로 조회한 이름이 정확한지 확인하세요. example.com, www.example.com, api.example.com은 서로 다른 DNS 이름이며 완전히 다른 응답을 반환할 수 있습니다. 정규화된 DNS 표기의 끝에 붙는 점은 루트를 나타내며 사용자 인터페이스에서는 대개 생략해도 됩니다. 경로가 포함된 전체 URL을 붙여 넣고 체커가 어느 호스트 이름이 중요한지 알아서 판단할 것이라고 가정하지 말고, 호스트 이름을 먼저 추출하세요. 새 레코드를 검증한다면 반환된 값을 제공업체의 안내와 글자 하나하나 비교하세요. TXT 정책에는 구두점, 구분자, 긴 문자열이 포함되는 경우가 많아 사소해 보이는 오타 하나로 레코드가 무효가 될 수 있습니다.

서로 다른 응답이 나오는 이유 이해하기

DNS는 분산되어 있고 캐시됩니다. 권한 네임서버는 존의 게시된 데이터를 보유하고, 재귀 리졸버는 사용자에게 응답하며 TTL이 만료될 때까지 이전 응답을 캐시할 수 있습니다. 그래서 두 체커가 서로 다른 리졸버, 위치 또는 레코드 버전을 조회하면 일시적으로 다른 값을 보여 줄 수 있습니다. 여러 위치를 조회하는 체커는 차이를 보여 주는 데 도움이 되지만, 모든 네트워크가 수렴했다는 증거는 아닙니다. 결과가 의도한 설정과 다르면 어떤 리졸버가 응답했는지 확인하고 권한 네임서버와 비교하세요. 그다음 또 변경하기 전에 TTL과 이전 값이 캐시된 시점을 고려하세요.

  • 요청한 레코드 없이 NOERROR가 나오면 이름은 존재하지만 해당 유형의 데이터가 없다는 뜻일 수 있습니다.
  • NXDOMAIN은 조회한 이름이 존재하지 않는 것으로 보고되었다는 뜻입니다.
  • SERVFAIL은 리졸버가 질의를 성공적으로 완료하지 못했다는 신호입니다.
  • 시간 초과는 체커의 대기 시간 안에 응답이 도착하지 않았다는 뜻입니다.
  • A 또는 AAAA 응답이 여러 개인 것은 이중화나 트래픽 분산을 위해 의도된 경우가 있습니다.

DNS 확인을 안전한 문제 해결 단계로 만들기

DNS를 변경할 때는 변경 전후 기록을 남기세요. 이름, 유형, 값, TTL, 리졸버, 시각을 기록하고, 업데이트 후 같은 조회를 반복하세요. 권한 서버는 새 값을 반환하는데 일부 재귀 리졸버만 이전 값을 반환한다면 캐시가 만료되기를 기다리는 것이 적절할 수 있습니다. 레코드를 반복해서 바꾸면 상황을 진단하기가 더 어려워집니다. 권한 서버끼리 값이 다르다면 존 복제나 제공업체 설정을 조사하세요. 모든 DNS 응답이 올바른데도 웹사이트가 계속 실패한다면, 무작정 DNS를 계속 바꾸지 말고 연결, TLS, 라우팅 또는 애플리케이션 상태로 넘어가세요.

마지막으로 응답을 범위에 맞게 해석하세요. 공개 DNS 체크는 공개 인터넷에 노출되도록 의도된 도메인과 레코드에 적합하며, 조직 내부 전용 네임스페이스를 점검하는 방법이 아닙니다. DNS가 반환한 IP는 애플리케이션을 호스팅하는 머신이 아니라 CDN 엣지, 로드 밸런서 또는 리버스 프록시일 수 있습니다. 공개 주소 응답만 필요하다면 도메인-IP 조회가 목적에 맞는 다음 단계입니다. A, AAAA, MX, TXT, NS의 용어와 예시는 DNS 레코드 유형 설명을 참고하세요.

체커 보고서는 건강한 의심을 가지고 읽으세요

DNS 체커는 반환된 값이 서비스에 필요한 값이 아니더라도 어떤 응답이든 받으면 초록색 표시를 보여 줄 수 있습니다. 요약 배지에만 의존하지 말고 원본의 소유자 이름, 유형, 데이터를 읽으세요. 한 위치의 응답 역시 하나의 표본일 뿐 전 세계가 일치한다는 보장이 아닙니다. 도구가 여러 위치를 나열하더라도 각 위치는 그 지역의 모든 사용자가 아니라 특정 리졸버와 캐시 상태를 나타낼 수 있다는 점을 기억하세요. 보고서는 다음 진단 단계를 고르는 데 사용하세요. 권한 서버와 비교하거나, TTL을 확인하거나, 서비스를 테스트하는 것입니다. 제공업체가 지원하는 엔드포인트인지 확인하지 않은 채 IP를 운영 환경 설정에 복사하지 마세요. 좋은 문제 해결은 체커가 결과를 “유효”라고 부르는지가 아니라, 기대하는 값과 그 기대의 근거를 바탕으로 합니다.

도메인의 공개 DNS 주소를 확인해야 하나요? Domain IP Lookup 도구를 사용해 보세요.

이 주제의 무료 도구