마법 없는 DNS: A, AAAA, CNAME, MX, TXT
어떤 DNS 레코드 유형이 있는지, 어떻게 다른지, TTL을 읽는 방법, 그리고 변경 사항이 인터넷에 도달했는지 확인하는 방법을 알아봐요.
업데이트 2026년 8월 23일
DNS는 디렉터리와 같아요. 이름을 주면 주소나 다른 이름을 돌려주죠. 여기에 오류가 생기면 서버는 멀쩡한데 “사이트가 안 열려요”처럼 보여요. 각 레코드 유형이 무엇을 담당하는지 알면 문제를 훨씬 쉽게 찾을 수 있어요.
주요 유형
| 유형 | 담는 내용 | 필요한 상황 |
|---|---|---|
| A | IPv4 주소 | 웹사이트와 모든 서비스의 기본 레코드 |
| AAAA | IPv6 주소 | Millida VDS 장비에서는 사용하지 않아요. IPv6를 제공하지 않거든요 |
| CNAME | 다른 이름 | www → 기본 도메인 같은 별칭 |
| MX | 메일 서버와 우선순위 | 도메인으로 메일 받기 |
| TXT | 임의의 텍스트 | SPF, DKIM, DMARC, 소유권 확인 |
| NS | 존 네임 서버 | 도메인 위임 |
가장 자주 발목을 잡는 규칙이 있어요. 도메인 루트에는 다른 레코드와 함께 CNAME을 둘 수 없어요. 루트(example.com)에는 A만 둘 수 있죠. CNAME 별칭은 서브도메인용이에요.
실제로는 이렇게 생겼어요
example.com. A 203.0.113.10
www.example.com. CNAME example.com.
mail.example.com. A 203.0.113.10
example.com. MX 10 mail.example.com.
example.com. TXT "v=spf1 mx -all"
주소는 제어판의 “개요”에서 /hosting/vds/m/<id>로 확인할 수 있어요. 연결의 실전 부분은 도메인을 장비에 연결하기 문서에서 다뤄요.
TTL과 캐시
TTL은 레코드가 캐시에 저장될 수 있는 시간(초)이에요. 값이 3600이면 수정한 뒤에도 한 시간 동안 제공자와 브라우저가 예전 응답을 내줄 수 있다는 뜻이에요.
계획된 이전 절차는 이래요. 하루 전에 TTL을 300으로 낮추고, 기다린 뒤, 레코드를 바꾸고, 잘 동작하는지 확인한 다음, 이전 TTL로 되돌려요.
확인
dig example.com A +short
dig www.example.com CNAME +short
dig example.com MX +short
dig example.com TXT +short
dig @8.8.8.8 example.com A +short
마지막 명령은 특정 공용 리졸버에 질의해서 로컬 캐시를 우회해요. 해석 경로까지 포함한 전체 그림은 이래요.
dig +trace example.com
흔한 오류
| 증상 | 원인 | 해결 |
|---|---|---|
| 어디서도 도메인이 안 열려요 | NS 레코드가 필요한 제공자를 가리키지 않아요 | 등록기관에서 dig example.com NS를 확인하세요 |
| 나는 되는데 남들은 안 돼요 | 캐시에 남은 예전 응답 | TTL이 만료될 때까지 기다리고 @8.8.8.8로 확인하세요 |
www가 안 열려요 | 서브도메인 레코드가 없어요 | 루트를 가리키는 CNAME을 추가하세요 |
| 메일이 안 와요 | MX가 없거나 CNAME을 가리켜요 | MX는 A 레코드가 있는 이름을 가리켜야 해요 |
| SPF를 수정한 뒤 메일이 사라졌어요 | 존에 SPF 레코드가 두 개 있어요 | v=spf1 줄을 정확히 하나만 남기세요 |
레코드는 한 번에 하나씩 바꾸고
dig명령으로 결과를 확인하세요. 존을 한꺼번에 수정한 뒤 “왜 다 죽었지”를 찾는 데는 세 배나 오래 걸려요.
메일을 받으려면 올바른 역방향 주소 레코드도 필요해요.