DNS 조회 — A·MX·TXT 레코드 확인

DNS 레코드 타입 이해하기

DNS는 사람이 읽는 도메인 이름을 컴퓨터가 쓰는 IP 주소로 바꿔 주는 인터넷의 전화번호부입니다. 도메인 하나에는 여러 종류의 레코드가 함께 등록되며, 각 레코드가 담당하는 역할이 다릅니다.

웹사이트가 열리지 않으면 A/AAAA를, 메일이 도착하지 않으면 MX와 TXT를, 도메인 위임이 꼬였으면 NS를 먼저 확인하는 식으로 문제 지점을 좁힐 수 있습니다.

정방향 조회와 역방향 조회

같은 DNS라도 방향에 따라 조회 방식이 다릅니다.

• 정방향 조회: example.com 같은 이름을 입력해 그 도메인의 IP·메일·인증 레코드를 찾습니다. 이 도구의 기본 동작입니다.
• 역방향 조회(PTR): IP 주소를 거꾸로 뒤집은 특수 이름(in-addr.arpa 존)으로 질의해, 그 IP에 연결된 도메인 이름을 찾습니다.

역방향 레코드는 정방향과 별개로 등록해야 하며, 대개 IP 대역을 관리하는 통신사·호스팅사가 관리합니다. 메일 서버는 발신 IP의 PTR이 정방향 A 레코드와 일치하는지(FCrDNS)를 신뢰도 평가에 활용하므로, 자체 메일 서버 운영자라면 PTR 정합성을 반드시 확인해야 합니다.

TTL과 전파, 캐시

DNS 응답에는 항상 **TTL(Time To Live)**이 붙습니다. TTL은 “이 값을 몇 초 동안 캐시해도 좋은가”를 뜻하며, 전 세계 리졸버가 이 시간만큼 결과를 저장합니다. 그래서 레코드를 바꿔도 기존 TTL이 만료되기 전까지는 옛 값과 새 값이 지역마다 뒤섞여 보이는 전파(propagation) 기간이 생깁니다.

• TTL이 길면(예: 86400초=24시간): 조회 부하는 줄지만 변경 반영이 느립니다.
• TTL이 짧으면(예: 300초=5분): 변경이 빠르게 퍼지지만 조회가 잦아집니다.

서버 이전이나 메일 설정 변경을 앞뒀다면, 작업 하루 전쯤 해당 레코드의 TTL을 미리 낮춰 두는 것이 실무 요령입니다. 이 도구로 조회할 때 데이터가 바뀌지 않는다면, 표시된 TTL을 보고 캐시 잔여 시간을 가늠할 수 있습니다.

메일 설정 점검에 활용하기

메일 도달률 문제의 상당수는 DNS 설정에서 비롯됩니다. 이 도구로 다음 순서로 점검하면 원인을 빠르게 좁힐 수 있습니다.

1. MX 확인: 수신 서버가 올바르게, 우선순위대로 지정됐는지.
2. SPF(TXT) 확인: 발신 허용 서버 목록에 실제 발송 서버가 포함됐는지.
3. DKIM(TXT) 확인: 서명 셀렉터 이름의 공개키가 게시됐는지.
4. DMARC(TXT) 확인: _dmarc 하위 이름에 정책(none/quarantine/reject)이 설정됐는지.

점검 순서대로 진행하면 대부분의 메일 도달률 문제는 근본 원인까지 빠르게 좁혀집니다. 참고로 CNAME 체인이 길게 이어지면 응답 일부가 잘릴 수 있으니, 별칭이 최종적으로 어떤 A 레코드로 귀결되는지 함께 확인하는 것이 좋습니다. 네 항목 중 하나라도 누락되면 대형 메일 서비스(Gmail·Naver 등)가 스팸함으로 분류하거나 아예 거부할 수 있으므로, 신규 발송 도메인을 운영한다면 이 순서를 발송 전 체크리스트로 삼는 것이 안전합니다.

레코드별로 무엇을 확인하나

각 레코드 유형은 서로 다른 문제를 진단하는 데 쓰입니다. 증상별로 어디를 봐야 하는지 정리하면 다음과 같습니다.

• 사이트가 안 열림 → A / AAAA: 도메인이 올바른 서버 IP를 가리키는지 확인합니다. A는 있는데 AAAA가 없으면 IPv6 환경에서만 접속이 안 될 수 있습니다.
• 메일이 안 옴 → MX: 수신 서버가 지정됐는지, 우선순위가 의도대로인지 봅니다. MX가 비어 있으면 수신 자체가 불가합니다.
• 메일이 스팸함으로 감 → TXT(SPF/DKIM/DMARC): 발신 인증이 제대로 게시됐는지 확인합니다. 셋 중 하나라도 누락되면 도달률이 떨어집니다.
• 도메인 전체가 먹통 → NS: 관할 네임서버가 올바른지 확인합니다. NS가 잘못되면 다른 모든 레코드도 조회되지 않습니다.
• 하위 도메인 연결 문제 → CNAME: 별칭이 올바른 대상을 가리키는지, 순환 참조가 없는지 봅니다.

이처럼 “증상 → 레코드”의 지도를 갖고 있으면, 막연히 전부 뒤지지 않고 문제 지점을 곧장 찾을 수 있습니다.

CNAME과 별칭의 주의점

CNAME은 한 이름을 다른 이름으로 연결하는 별칭이지만 제약이 있습니다. 대표적으로 도메인 최상위(root, 예: example.com 자체)에는 CNAME을 둘 수 없다는 규칙이 있어, 루트에는 A/AAAA를, 하위(예: www)에만 CNAME을 쓰는 것이 일반적입니다. 또한 CNAME이 지정된 이름에는 원칙적으로 다른 레코드를 함께 둘 수 없습니다.

별칭 체인이 여러 단계로 이어지면 최종 목적지에 도달하기까지 조회가 누적돼 응답이 느려지거나 일부가 잘릴 수 있습니다. 따라서 CNAME을 조회할 때는 그 별칭이 결국 어떤 A/AAAA로 귀결되는지 끝까지 따라가 확인하는 습관이 중요합니다. 이 도구로 단계별 레코드를 확인하면 체인 어디에서 연결이 끊기는지 짚어낼 수 있습니다.

변경 작업 전후 점검 요령

DNS 레코드를 바꾸는 작업은 전파 지연 때문에 사전·사후 점검이 특히 중요합니다. 실무에서 권장되는 순서는 다음과 같습니다. 먼저 작업 하루 전, 바꿀 레코드의 TTL을 짧게(예: 300초) 낮춰 새 값이 빠르게 퍼지도록 준비합니다. 다음으로 변경 직후 이 도구로 해당 레코드를 조회해 새 값이 응답되는지, 옛 값이 여전히 캐시로 남아 있는지 TTL과 함께 확인합니다. 마지막으로 전파가 안정되면 TTL을 원래 값으로 되돌려 조회 부하를 줄입니다. 이 과정을 지키면 서버 이전이나 메일 설정 변경 중 발생하는 접속 끊김을 최소화할 수 있습니다.

자주 묻는 질문