DNS 레코드 종류(A, CNAME, TXT)와 DoH(DNS over HTTPS) 동작 원리

DNS(Domain Name System)는 인간이 기억하기 쉬운 도메인 이름(devutils.run)을 컴퓨터가 통신할 수 있는 IP 주소로 변환하는 전 세계 분산 계층 데이터베이스입니다. 브라우저가 주소를 입력받으면 다음 4단계를 거쳐 IP를 찾습니다:

1. 리커시브 리졸버(Recursive Resolver): ISP 또는 Cloudflare(1.1.1.1), Google(8.8.8.8)이 운영하며, 클라이언트를 대신해 전 세계 계층을 순회합니다.
2. 루트 네임서버(Root Nameserver): 전 세계에 13개의 논리적 권한 서버가 존재하며, 도메인 확장자(.run, .com)에 따라 TLD 서버 주소를 안내합니다.
3. TLD 네임서버: 도메인을 관리하는 공인 등록소로, 해당 도메인의 책임 네임서버 정보를 제공합니다.
4. 권한 네임서버(Authoritative Nameserver): 도메인 소유자가 설정한 실제 DNS 레코드(A, CNAME 등)가 저장된 최종 서버입니다.

• A 레코드: 도메인을 IPv4 주소(예: 192.0.2.1)로 매핑합니다.
• AAAA 레코드: 도메인을 128비트 차세대 IPv6 주소(예: 2001:db8::1)로 매핑합니다.
• CNAME (Canonical Name): 하나의 도메인을 다른 표준 도메인 이름의 별칭으로 연결합니다. 표준 RFC 규정상 루트 도메인(Apex 도메인)에는 CNAME 설정이 불가하여 CNAME 플래트닝 기술이 등장했습니다.
• MX (Mail Exchange): 도메인의 이메일을 수신할 메일 서버와 우선순위 가중치를 지정합니다.
• TXT (Text): 임의의 텍스트 데이터를 저장할 수 있어 도메인 소유권 확인 및 이메일 위조 방지 정책에 광범위하게 쓰입니다.
• CAA (Certificate Authority Authorization): 내 도메인에 SSL/TLS 인증서를 발급할 수 있는 공인 인증기관(Let's Encrypt 등)을 제한하여 부정 발급을 방지합니다.

기본 이메일 프로토콜(SMTP)은 발신자 주소(From:)를 자유롭게 위조할 수 있는 취약점이 있습니다. 이를 원천 차단하기 위해 3대 DNS 보안 레코드가 필수로 운영됩니다:

1. SPF (Sender Policy Framework): 내 도메인을 대신하여 이메일을 보낼 수 있는 공인 IP 및 외부 서비스 목록을 정의하는 TXT 레코드입니다.
2. DKIM (DomainKeys Identified Mail): 메일 서버가 발송하는 이메일에 개인키로 디지털 서명을 남기고, 수신 서버는 도메인의 TXT 레코드에 게시된 공개키로 위변조 여부를 검증합니다.
3. DMARC: SPF나 DKIM 검증에 실패한 위조 메일을 수신 서버가 어떻게 처리할지(none, quarantine, reject)를 선언하고 리포트를 수집합니다.

// SPF 레코드 예시 (TXT @)
v=spf1 include:_spf.google.com ~all

// DMARC 레코드 예시 (TXT _dmarc)
v=DMARC1; p=reject; rua=mailto:dmarc-reports@devutils.run; pct=100; adkim=s; aspf=s

전통적 DNS 질의는 UDP 53번 포트를 통해 암호화되지 않은 평문으로 전달되었습니다. 이는 공용 와이파이 관리자나 통신사가 사용자가 방문하는 도메인을 엿보거나 DNS 스푸핑 공격을 감행할 수 있는 여지를 남겼습니다.

• DoT (DNS over TLS): 853번 전용 포트로 DNS 질의를 TLS 터널 안에 암호화합니다.
• DoH (DNS over HTTPS): 443번 표준 웹 포트를 통해 HTTPS 암호화 웹 요청 속에 DNS 질의를 캡슐화합니다. 일반 HTTPS 웹 트래픽과 포트가 동일하여, 통신사나 중간 네트워크에 의한 DNS 도청과 변조를 어렵게 만듭니다.

DNS 성능과 고가용성은 TTL(Time to Live)의 전략적 설정에 의해 좌우됩니다:

• 낮은 TTL (60~300초): 데이터센터 이전, 무중단 블루-그린 배포, 동적 장애 조치(Failover) 시 권장됩니다. 변경 사항이 수 분 내에 전 세계에 전파되지만, 권한 네임서버의 질의 부하가 증가합니다.
• 높은 TTL (86400초 / 24시간): 변경이 거의 없는 MX, SPF, 안정적인 정적 인프라에 적합합니다. 리커시브 리졸버의 캐시 적중률을 극대화하여 클라이언트의 DNS 조회 지연을 최소화합니다.
• 네거티브 캐싱 (SOA MINIMUM): 도메인이 존재하지 않는다는 NXDOMAIN 응답을 리졸버가 캐싱하는 시간입니다. DNS 레코드를 생성하기 전에 신규 도메인으로 서비스를 먼저 호출하면, 실패 응답이 캐시되어 전파가 지연되는 문제가 발생할 수 있습니다.
• Dig를 통한 검증: 로컬 DNS 캐시를 무시하고 dig @1.1.1.1 devutils.run +trace 명령을 실행하거나 DevUtils의 DNS Lookup 도구를 활용하면 루트 서버부터 권한 서버까지의 전 위임 과정을 직접 추적할 수 있습니다.

# 루트 서버부터 권한 서버까지의 전체 DNS 위임 경로 추적
dig +trace devutils.run A

# 로컬 캐시를 우회하여 Cloudflare 1.1.1.1에 직접 질의
dig @1.1.1.1 devutils.run A +short