ALIAS와 ANAME 레코드: 루트 도메인의 CNAME 문제

example.com을 CDN에 연결해야 합니다. CDN 측에서 cdn.example.net 같은 호스트명을 제공합니다. CNAME 레코드를 사용하려고 하면—존 최상위에서는 CNAME을 사용할 수 없다는 사실을 발견하게 됩니다.

해결책은 이제 업계 표준이 된 영리한 우회 방법입니다: ALIAS와 ANAME 레코드입니다. DNS 제공업체가 대상 호스트명을 직접 조회한 후 클라이언트에게 거짓말을 합니다—마치 원래 그랬던 것처럼 A 레코드를 반환하는 것입니다.

CNAME이 존 최상위에 존재할 수 없는 이유

DNS 명세(RFC 1034)는 존 최상위에서 CNAME 레코드를 금지합니다. CNAME은 해당 이름에 존재하는 유일한 레코드여야 하기 때문입니다. 그런데 존 최상위에는 제대로 동작하기 위해 SOA와 NS 레코드가 반드시 필요합니다. 두 가지를 동시에 가질 수는 없습니다. 이 충돌은 표준 DNS 안에서는 해결할 수 없습니다.

서비스들이 IP 주소 대신 호스트명을 제공할 때 이 문제가 중요해집니다. CDN, 클라우드 로드 밸런서, 플랫폼 서비스들은 lb-1234.us-east-1.elb.amazonaws.com 같은 형태를 제공합니다. 이들의 인프라가 동적 IP를 사용하기 때문입니다—확장, 장애 조치, 지리적 분산을 위해 IP가 변경됩니다.

수동 해결책—대상을 조회하고, IP를 A 레코드에 복사하고, 변경될 때마다 업데이트하는 방법—은 관리형 인프라의 목적을 무력화합니다.

속임수가 작동하는 원리

ALIAS와 ANAME 레코드는 서버 측 조회를 통해 이 문제를 해결합니다:

1. 클라이언트가 example.com의 A 레코드를 조회합니다
2. DNS 서버가 cdn.example.net을 가리키는 ALIAS를 확인합니다
3. 서버가 직접 cdn.example.net을 조회합니다
4. 서버가 조회된 IP 주소들을 A 레코드로 반환합니다
5. 클라이언트는 간접 참조를 전혀 알지 못한 채 표준 A 레코드를 받습니다

클라이언트는 CNAME을 전혀 보지 못합니다. DNS 명세는 위반되지 않습니다. 리졸버 작업은 서버 측에서 일어나며, 클라이언트에게는 보이지 않습니다.

제공업체별 구현

제공업체마다 다른 이름으로 이를 구현합니다.

Cloudflare는 이를 "CNAME 평탄화(flattening)"라고 부르며, 최상위 도메인의 CNAME에 자동으로 적용합니다. 표준 CNAME을 생성하면 Cloudflare가 나머지를 처리합니다. 간편하지만, 이 보이지 않는 처리 방식이 디버깅을 어렵게 만들 수 있습니다.

AWS Route53은 AWS와의 깊은 통합이 특징인 "ALIAS 레코드"를 사용합니다. CloudFront 배포, Elastic Load Balancer, S3 엔드포인트를 가리킬 수 있습니다. AWS 리소스에 대한 조회는 쿼리 한도에 포함되지 않아—내부 라우팅에는 사실상 무료입니다.

DNSimple 등은 "ANAME 레코드"를 사용합니다—기능은 동일하며, 여러 제공업체에 걸쳐 퍼진 명명 관행을 따릅니다.

이 중 어느 것도 표준화되어 있지 않습니다. ANAME에 대한 IETF 초안(draft-ietf-dnsop-aname)은 RFC가 되지 못한 채 만료되었습니다. 이것들은 여전히 각 업체의 독자적인 우회 방법이며, 그래서 이름과 동작이 제공업체마다 다른 것입니다.

장단점

서버 측 조회는 표준 A 레코드에는 없는 복잡성을 도입합니다.

추가 지연. DNS 서버가 응답하기 전에 추가 조회를 수행합니다. 캐싱이 도움이 되지만, TTL 만료 후 첫 번째 쿼리는 그 부담을 감수해야 합니다.

제공업체 의존성. 도메인의 접근 가능성이 이제 DNS 제공업체가 대상을 조회할 수 있는 능력에 달려 있습니다. 제공업체의 리졸버가 대상의 권한 있는 서버에 접근할 수 없으면, 도메인이 작동을 멈춥니다.

지리적 라우팅 문제. 리졸버 위치에 따라 다른 IP를 반환하는 서비스들은 사용자의 위치가 아닌 DNS 제공업체의 인프라 위치를 보게 됩니다. 도쿄의 사용자가 제공업체의 리졸버가 버지니아에 있기 때문에 버지니아 데이터 센터로 라우팅될 수 있습니다.

TTL 불일치. 클라이언트는 대상의 TTL이 아닌 ALIAS 레코드의 TTL을 봅니다. 너무 낮으면 DNS 서버에 과부하를 주고, 너무 높으면 IP 변경이 느리게 전파됩니다.

숨겨진 간접 참조. dig 같은 도구는 A 레코드만 보여줘서 ALIAS를 숨깁니다. 표시되는 레코드가 실제 설정과 일치하지 않아 디버깅이 혼란스러워집니다.

언제 사용해야 하나

CDN, 로드 밸런서, 고정 IP가 없는 플랫폼 등 호스트명 기반 서비스에 존 최상위를 연결해야 할 때 ALIAS/ANAME 레코드를 사용하세요.

고정 IP를 사용할 수 있다면 사용하지 마세요. 표준 A 레코드가 더 단순하고, 빠르며, 숨겨진 의존성이 없습니다.

대신 www 패턴을 고려해 보세요. www.example.com을 기본 도메인으로 사용하면 표준 CNAME을 사용할 수 있으며, 최상위 도메인은 www로 리다이렉트됩니다. 이렇게 하면 문제 자체를 피할 수 있습니다.

중요한 도메인의 경우, 제공업체의 구현에 상태 확인 기능이 포함되어 있는지 확인하세요. 없다면, 대상 조회가 실패할 경우 도메인에 접근할 수 없게 됩니다.

ALIAS와 ANAME 레코드에 관한 자주 묻는 질문

ALIAS와 ANAME 레코드가 공식 DNS 명세의 일부인가요?

아니요. 이것들은 DNS 제공업체들이 존 최상위 제한을 우회하기 위해 구현한 독자적인 해결책입니다. IETF가 ANAME(draft-ietf-dnsop-aname)을 표준화하려 했지만, 초안이 만료되었습니다. 통합된 표준이 없기 때문에 제공업체마다 다른 이름과 동작을 사용합니다.

DNS 제공업체를 변경하면 이 레코드들이 이전되나요?

자동으로 이전되지 않습니다. 이것들은 제공업체별 레코드 유형이므로, 새 제공업체가 제공하는 구현 방식으로 다시 생성해야 합니다. 개념은 이전되지만, 설정은 이전되지 않습니다.

CDN이 고정 IP 주소를 제공하지 않는 이유는 무엇인가요?

CDN의 인프라는 확장, 장애 조치, 지리적 분산을 위해 동적 IP에 의존합니다. 고정 IP는 단일 장애 지점을 만들고 탄력적 확장을 방해합니다. 호스트명 추상화는 트래픽을 투명하게 이동시킬 수 있게 해줍니다—그것이 CDN을 사용하는 핵심 이유입니다.

서브도메인에도 ALIAS 레코드를 사용할 수 있나요?

대부분의 제공업체는 모든 수준에서 ALIAS/ANAME 레코드를 허용합니다. 하지만 서브도메인에는 표준 CNAME이 잘 작동하므로, 더 단순한 방법이 통하는 곳에서 굳이 더 복잡한 해결책을 사용할 이유가 없습니다.

출처