Zone Apex (Root Domain, Naked Domain)
Zone Apex (Root Domain, Naked Domain)
서브도메인이 붙지 않은 도메인을 Zone Apex라 부른다.(Root Domain, Naked Domain이라고도 불린다)
예를 들어, 자신이 등록한 도메인 이름이 example.com 이라면,
앞에 서브도메인이 붙지 않는, "example.com" 자체는 Zone Apex라 칭한다.
Zone Apex에는 CNAME 레코드를 사용할 수 없다.
[RFC 2181 - 6.1]
The authoritative servers for a zone are enumerated in the NS records for the origin of the zone, which, along with a Start of Authority (SOA) record are the mandatory records in every zone.
https://tools.ietf.org/html/rfc2181#section-6.1
[RFC 2181 - 10.1]
An alias name (label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no other data.
That is, for any label in the DNS (any domain name) exactly one of the following is true:
+ one CNAME record exists, optionally accompanied by SIG, NXT, and KEY RRs,
+ one or more records exist, none being CNAME records,
+ the name exists, but has no associated RRs of any type,
+ the name does not exist at all.
https://tools.ietf.org/html/rfc2181#section-10.1
- 모든 Zone에서는 SOA 레코드와 NS 레코드가 필수로 존재해야 한다.
> Zone Apex는, SOA레코드와 NS 레코드가 반드시 존재함
(그래야 해당 Zone의 Authority가 있음을 알리므로)
- CNAME은 타 레코드와 겹칠 수 없다(DNSSEC의 일부 레코드를 제외하고)
> 하지만 Zone Apex는 이미 SOA, NS 레코드가 존재한다.
결론적으로, Zone Apex에는 CNAME 레코드를 사용할 수 없다.
https://serverfault.com/questions/613829/why-cant-a-cname-record-be-used-at-the-apex-aka-root-of-a-domain
예를 들어 자신의 도메인 이름이 example.com이라면,
example.com. IN A 1.2.3.4 (가능한 문법)
example.com. IN CNAME alias.example.com. (불가능한 문법)
이 되는 것이다.
만일 Zone Apex를 다른 별칭 레코드과 연계하고 싶은 경우,
해당 별칭 레코드값을 조회하여 A 레코드 값을 찾은 다음 그 값을 Zone Apex에 업데이트 시켜줘야한다.
(예시) AWS Route53에 DNS를 호스팅 하는 경우,
Zone Apex의 "A 레코드"를 같은 영역의 다른 CNAME에 "Alias" 하는 방법으로 이 문제를 해결할 수 있다. (Zone Apex에 대한 CNAME 레코드는 생성할 수 없다)
만일 "www.example.com"이 고정 IP라면 웹서버 세팅을 조금 바꿔주면 해결되지만, Floating IP 라면 이야기가 달라진다.
1. 그런 경우에는 "example.com" 을 고정 IP주소와 연결시키고, 해당 고정 IP주소에서 HTTP 요청을 "www.example.com"으로 넘겨주어야 한다.
그런데 이것이 상황에 따라 구축하기가 상당히 난해해지는 경우가 발생한다.
예를 들어 AWS 인프라 위에 웹 서비스를 올라가 있는데 Route53을 안쓰면, 이 문제를 어떻게 해결해야 할지 참 난해하다. Network Load Balancer에 IP를 고정시켜서 쓸 수는 있지만 관리해야할 부분이 많아지고 Load Balancer 뒤에 뭘 둬야할지 고민하게 된다. (거꾸로 말해서 Route53을 쓴다면 쉽게 해결되는 문제다)
GCP에서는 생각보다 이 이슈를 쉽게 해결할 수 있다. 부하 분산에 고정 IP를 연결해주고, 백엔드에 static 호스팅을 연결한 다음 static hosting으로 redirection 시키면 해결할 수는 있다. 단지 301이나 302리다이렉션이 아닌, HTML 소스 코드로 리다이렉션 시켜주는 방법일 뿐이다.
대부분 도메인 등록대행사에서 HTTP 포워딩 서비스를 제공할 것이다. 단지 해당 서버를 신뢰할 것이냐의 문제일 뿐이다.
2. 아니면 직접 스크립트를 작성해서, 일정한 간격으로(TTL 기반) 해당 Floating IP를 조회하다가 IP가 변경된 것을 확인하면 즉시 네임서버에서 Zone Apex 레코드 값을 업데이트 해주는 방법이 있을 것이다.
단 사용자들에게 DNS 조회 오류를 뱉고 싶지 않다면 굉장히 낮은 TTL 값(초단위)를 적용해야 할 것이다. 그리고 이 방식은 TTL이 0이 아닌 이상 Reliable 할 수 없다고 봐야할 것이다.
(예를 들어 TTL이 3초라면, 그 3초 사이에 Floating IP가 변경될 것이고 그 사이에 DNS 응답을 해준 Client들에게 모조리 DNS 에러가 날 것이다)
어떤 Architecture가 명확한 정답이라고 할 수 없다. 주어진 Workload, 제한되어 있는 예산 사이에서 최선의 답을 찾을 필요가 있다.
The authoritative servers for a zone are enumerated in the NS records for the origin of the zone, which, along with a Start of Authority (SOA) record are the mandatory records in every zone.
https://tools.ietf.org/html/rfc2181#section-6.1
[RFC 2181 - 10.1]
An alias name (label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no other data.
That is, for any label in the DNS (any domain name) exactly one of the following is true:
+ one CNAME record exists, optionally accompanied by SIG, NXT, and KEY RRs,
+ one or more records exist, none being CNAME records,
+ the name exists, but has no associated RRs of any type,
+ the name does not exist at all.
https://tools.ietf.org/html/rfc2181#section-10.1
- 모든 Zone에서는 SOA 레코드와 NS 레코드가 필수로 존재해야 한다.
> Zone Apex는, SOA레코드와 NS 레코드가 반드시 존재함
(그래야 해당 Zone의 Authority가 있음을 알리므로)
- CNAME은 타 레코드와 겹칠 수 없다(DNSSEC의 일부 레코드를 제외하고)
> 하지만 Zone Apex는 이미 SOA, NS 레코드가 존재한다.
결론적으로, Zone Apex에는 CNAME 레코드를 사용할 수 없다.
https://serverfault.com/questions/613829/why-cant-a-cname-record-be-used-at-the-apex-aka-root-of-a-domain
예를 들어 자신의 도메인 이름이 example.com이라면,
example.com. IN A 1.2.3.4 (가능한 문법)
example.com. IN CNAME alias.example.com. (불가능한 문법)
이 되는 것이다.
만일 Zone Apex를 다른 별칭 레코드과 연계하고 싶은 경우,
해당 별칭 레코드값을 조회하여 A 레코드 값을 찾은 다음 그 값을 Zone Apex에 업데이트 시켜줘야한다.
(예시) AWS Route53에 DNS를 호스팅 하는 경우,
Zone Apex의 "A 레코드"를 같은 영역의 다른 CNAME에 "Alias" 하는 방법으로 이 문제를 해결할 수 있다. (Zone Apex에 대한 CNAME 레코드는 생성할 수 없다)
<사담>
보통 이 문제가 "example.com"을 "www.example.com"으로 연결해주려 할 때 발생한다.만일 "www.example.com"이 고정 IP라면 웹서버 세팅을 조금 바꿔주면 해결되지만, Floating IP 라면 이야기가 달라진다.
1. 그런 경우에는 "example.com" 을 고정 IP주소와 연결시키고, 해당 고정 IP주소에서 HTTP 요청을 "www.example.com"으로 넘겨주어야 한다.
그런데 이것이 상황에 따라 구축하기가 상당히 난해해지는 경우가 발생한다.
예를 들어 AWS 인프라 위에 웹 서비스를 올라가 있는데 Route53을 안쓰면, 이 문제를 어떻게 해결해야 할지 참 난해하다. Network Load Balancer에 IP를 고정시켜서 쓸 수는 있지만 관리해야할 부분이 많아지고 Load Balancer 뒤에 뭘 둬야할지 고민하게 된다. (거꾸로 말해서 Route53을 쓴다면 쉽게 해결되는 문제다)
GCP에서는 생각보다 이 이슈를 쉽게 해결할 수 있다. 부하 분산에 고정 IP를 연결해주고, 백엔드에 static 호스팅을 연결한 다음 static hosting으로 redirection 시키면 해결할 수는 있다. 단지 301이나 302리다이렉션이 아닌, HTML 소스 코드로 리다이렉션 시켜주는 방법일 뿐이다.
대부분 도메인 등록대행사에서 HTTP 포워딩 서비스를 제공할 것이다. 단지 해당 서버를 신뢰할 것이냐의 문제일 뿐이다.
2. 아니면 직접 스크립트를 작성해서, 일정한 간격으로(TTL 기반) 해당 Floating IP를 조회하다가 IP가 변경된 것을 확인하면 즉시 네임서버에서 Zone Apex 레코드 값을 업데이트 해주는 방법이 있을 것이다.
단 사용자들에게 DNS 조회 오류를 뱉고 싶지 않다면 굉장히 낮은 TTL 값(초단위)를 적용해야 할 것이다. 그리고 이 방식은 TTL이 0이 아닌 이상 Reliable 할 수 없다고 봐야할 것이다.
(예를 들어 TTL이 3초라면, 그 3초 사이에 Floating IP가 변경될 것이고 그 사이에 DNS 응답을 해준 Client들에게 모조리 DNS 에러가 날 것이다)
어떤 Architecture가 명확한 정답이라고 할 수 없다. 주어진 Workload, 제한되어 있는 예산 사이에서 최선의 답을 찾을 필요가 있다.
댓글
댓글 쓰기