DNS CNAME 순서 변경으로 인한 장애: RFC의 모호성이 문제의 근본 원인
1.1.1.1 DNS 서버의 메모리 최적화 과정에서 CNAME 레코드 순서 변경으로 인해 DNS resolution 실패 발생
일부 DNS 클라이언트, 특히 glibc의 getaddrinfo 함수와 Cisco 스위치에서 CNAME 레코드 순서에 의존하는 구현으로 인해 장애 발생
RFC 1034의 모호한 표현으로 인해 CNAME 레코드 순서에 대한 표준 미비(Standard Ambiguity)가 존재하며, 클라이언트 구현 방식에 따라 문제 발생
Cloudflare는 문제 해결을 위해 변경 사항을 롤백(Rollback)하고, IETF(Internet Engineering Task Force)에 CNAME 처리 방식에 대한 RFC 제안(RFC Proposal)을 제출
DNS CNAME 체인(Chain) 동작 방식
DNS(Domain Name System)에서 CNAME(Canonical Name) 레코드는 도메인 별칭을 정의하며, www.example.com이 cdn.example.com으로, 다시 server.cdn-provider.com으로 연결되는 체인을 형성할 수 있다.
TTL(Time-To-Live): 각 레코드의 캐싱(Caching) 시간을 결정하며, 체인 내 각 레코드는 서로 다른 TTL 값을 가질 수 있음
부분 만료(Partial Expiration): 체인 일부 레코드 만료 시, 만료된 부분만 재귀적으로 질의하여 전체 체인을 완성
문제점: CNAME 체인 내 레코드 순서 변경 시, 일부 DNS 클라이언트에서 해석 오류(Interpretation Error) 발생 가능
glibc getaddrinfo 함수의 문제점
glibc의 getaddrinfo 함수는 DNS resolution을 위해 CNAME 레코드 순서에 의존하는 방식으로 구현되어, 1.1.1.1의 CNAME 순서 변경으로 인해 장애가 발생했다.
순차적 파싱(Sequential Parsing): CNAME 레코드를 만나면 예상 이름을 갱신하는 방식으로 동작
순서 의존성(Order Dependency): CNAME 레코드가 A 레코드보다 먼저 나타나야 정상적으로 처리
영향: CNAME 레코드가 뒤에 위치할 경우, 예상 이름 불일치로 인해 해석 실패(Parsing Failure) 발생
이러한 구현 방식은 RFC 1034의 모호한 표현에 기인하며, 다양한 DNS 클라이언트에서 호환성 문제(Compatibility Issue)를 야기할 수 있다.
RFC 1034의 모호성과 DNS 표준
RFC 1034는 DNS 프로토콜의 기본 동작을 정의하지만, CNAME 레코드 순서에 대한 명확한 요구사항을 제시하지 않아, 구현상의 혼란을 야기했다.
'Possibly preface' 표현: CNAME 레코드가 다른 레코드보다 앞에 올 수 있다는 의미로 해석될 수 있으나, MUST, SHOULD와 같은 강제적 표현 부재
RRset와 RR의 구분: RFC 1034는 RRset 내 레코드 순서는 중요하지 않다고 명시하지만, message section 내 RRset 간의 순서에 대한 언급은 부재
DNSSEC(DNS Security Extensions)와의 대조: RFC 4035는 RRSIG 레코드의 우선순위를 명확히 정의하여, 표준의 명확성(Standard Clarity) 중요성을 강조
결과적으로 RFC 1034의 모호성은 다양한 DNS 클라이언트의 상호 운용성(Interoperability) 문제를 발생시키는 원인이 되었다.
DNS 클라이언트 구현 방식의 다양성
DNS 클라이언트의 구현 방식에 따라 CNAME 레코드 순서 변경에 대한 영향이 다르게 나타났으며, 이는 DNS resolution의 안정성에 영향을 미친다.
systemd-resolved: 순서를 고려하지 않고 전체 answer set을 검색하는 방식으로 구현되어, CNAME 순서 변경에 영향 없음
Cisco 스위치: 특정 모델에서 CNAME 순서 변경으로 인해 재부팅 루프(Reboot Loop) 발생
getaddrinfo: CNAME 순서에 의존적인 구현으로 인해 resolution 실패(Resolution Failure) 발생
이러한 차이는 DNS 클라이언트의 구현 방식(Implementation Approach)과 RFC 해석의 차이에서 기인하며, DNS 시스템의 복잡성(Complexity)을 보여준다.
향후 개선 방향 및 제안
Cloudflare는 CNAME 레코드 순서 변경을 롤백하고, IETF에 CNAME 처리 방식에 대한 RFC 제안을 제출하여, DNS 표준의 명확성을 확보하려는 노력을 기울였다.
RFC 제안: CNAME 레코드 처리 방식에 대한 명확한 정의를 통해, DNS 클라이언트의 호환성(Compatibility) 및 안정성(Stability) 향상
테스트 강화: DNS 서버 및 클라이언트의 테스트 커버리지(Test Coverage)를 확대하여, 잠재적 문제점 사전 방지
표준 준수: RFC의 명확한 정의를 준수하여, 상호 운용성(Interoperability) 확보
결론적으로, DNS 표준의 명확화와 클라이언트 구현의 개선을 통해, DNS 시스템의 신뢰성(Reliability)을 높이는 것이 중요하다.
