dns DNS 조회 (A, MX, TXT, NS) star

작동 방식

도메인을 입력하고 레코드 유형을 선택하면, 조회는 전통적인 이진 UDP 포트 53 프로토콜이 아니라 DNS-over-HTTPS(DoH)를 통해 Google의 공개 리졸버 8.8.8.8로 전송됩니다 — 이는 JSON 기반 HTTPS API입니다. 이것은 의도적인 선택입니다. DoH는 표준 HTTPS 위에서 동작하므로 원시 소켓 접근 없이도 브라우저 내부에서 작동하며, 그에 못지않게 중요한 점은 운영체제, 라우터, ISP가 평소 사용하는 DNS 리졸버를 모두 건너뛴다는 것입니다. 사용자의 기기, 사무실 네트워크, ISP는 각각 자체 DNS 캐시를 유지하며, 각각 레코드의 TTL(Time To Live)에 따라 독자적인 일정으로 갱신되므로, 어느 순간에는 셋 모두 조금씩 다르고 조금씩 오래된 응답을 보여줄 수 있습니다. Google의 리졸버에 직접 질의하면 이 세 캐시를 모두 우회하여, 크고 자주 갱신되는 공개 리졸버가 현재 무엇을 알고 있는지를 보여줍니다 — "지금 인터넷이 보고 있는 것"에 가장 가까운 대리 지표이지만, 그래도 하나의 리졸버 관점일 뿐 전 세계적으로 보장된 값은 아닙니다.

각 레코드 유형은 서로 다른 운영상의 질문에 답합니다. A와 AAAA 레코드는 호스트명을 IPv4 또는 IPv6 주소로 매핑합니다 — 브라우저가 연결을 열기도 전에 먼저 해결하는 것이 바로 이것입니다. MX 레코드는 해당 도메인의 이메일을 수신하는 메일 서버를 나열하며, 각각 숫자 우선순위(낮은 숫자일수록 먼저 시도됨)를 가집니다 — 이메일 제공업체를 이전할 때 특히 중요한데, 오래된 MX 레코드가 남아 있으면 메일이 계속 이전 제공업체로 전달되기 때문입니다. TXT 레코드는 구조화되지 않은 임의의 텍스트이며 SPF, DKIM, 도메인 인증 문자열이 여기에 저장됩니다. 도메인은 여러 개의 TXT 레코드를 가질 수 있으며, 잘못되었거나 누락된 SPF TXT 레코드는 정상적인 이메일이 스팸함으로 분류되는 가장 흔한 원인 중 하나입니다. CNAME 레코드는 한 호스트명을 다른 이름의 별칭으로 지정합니다(예: www가 최상위 도메인을 가리키거나, 서브도메인이 CDN 엔드포인트를 가리키는 경우) — CNAME이 있는 호스트명은 같은 이름으로 다른 레코드 유형을 함께 가질 수 없으며, 이는 "왜 이 서브도메인에는 MX 레코드도 함께 둘 수 없는가"라는 혼란의 흔한 원인입니다. NS 레코드는 해당 도메인에 대한 질의에 답할 권한을 가진 네임서버를 나열합니다 — 이 값이 잘못되었거나 등록기관과 동기화되지 않으면, 그 도메인의 다른 어떤 레코드도 어디에서든 올바르게 해석되지 않습니다.

대표적인 활용 예: 웹사이트를 새 호스팅으로 옮긴 후 A 레코드를 새 서버의 IP로 지정합니다. 전파는 즉시 일어나지 않습니다 — 이전 레코드의 TTL에 의해 제한되므로, TTL이 3600(1시간)으로 설정된 레코드는 전 세계 캐시에서 사라지기까지 최대 1시간이 걸릴 수 있고, 일부 리졸버는 TTL을 무시하고 필요 이상으로 오래 캐시하기도 합니다. Google의 DoH 리졸버에 직접 질의하면, 자신의 ISP 캐시가 만료되기를 기다리지 않고도 "적어도 이 주요 리졸버 하나에는 새 값이 반영되었는가"를 바로 확인할 수 있습니다.

알아두어야 할 사항

• DNS-over-HTTPS는 로컬 캐시를 우회하므로, 이곳의 결과가 nslookup이나 운영체제가 보여주는 값보다 더 최신일 수 있습니다 — 이는 예상된 동작이며 버그가 아닙니다.
• A, MX, TXT, CNAME, NS는 전파, 메일, 인증 점검의 거의 모든 경우를 다룹니다. SRV나 CAA 같은 더 드문 유형은 현재 포함되어 있지 않습니다.
• DNS 변경은 즉시가 아니라 캐시를 거쳐 반영됩니다 — 즉각적인 전 세계적 효과가 아니라 이전 TTL에 의해 제한되는 지연을 예상하세요.