클라우드플레어(1.1.1.1)가 DNS 응답 순서를 아주 살짝 바꿨는데, 전 세계의 수많은 기기가 먹통이 되었습니다

Source: What came first: the CNAME or the A record?

🎣 Hook: 성능을 올렸더니 인터넷이 끊겼다?

클라우드플레어 엔지니어들은 1.1.1.1 리졸버의 성능 최적화를 위해 코드를 수정했습니다. 메모리 복사를 줄이기 위해, DNS 응답 패킷에 CNAME 레코드를 마지막에 붙이도록 변경했죠.

이 작은 변화가 엄청난 파장을 일으켰습니다. 일부 클라이언트들이 도메인 주소를 1.1.1.1로 조회하지 못하게 된 것입니다.

🛠️ The Analysis: 순서가 중요한가?

1987년의 모호함 (RFC 1034)

DNS 표준 문서는 이렇게 말합니다.

"The answer to the query, possibly preface by one or more CNAME RRs..." (응답은 아마도 CNAME들로 먼저 시작될 것이다...)

"MUST"가 아니라 "possibly"입니다. 즉, CNAME이 먼저 와야 한다는 강제 조항은 없습니다. 하지만 많은 구현체들이 "당연히 CNAME이 먼저 오겠지"라고 가정하고 짜여져 있었습니다.

왜 깨졌는가? (Naive Stub Resolvers)

단순한 리졸버들은 응답을 순차적(Sequential)으로 파싱합니다.

1. 기존 (CNAME → A):
   • "어? www.example.com의 CNAME이 cdn.example.com이네? (기억)"
   • "어? cdn.example.com의 A 레코드가 1.2.3.4네? (매칭 성공!)"
2. 변경 후 (A → CNAME):
   • "어? cdn.example.com의 A 레코드가 왔네? 난 www.example.com을 찾는데? (버림)"
   • "어? 이제 CNAME이 왔네? ...근데 아까 A 레코드는 이미 버렸는데?" -> 결과 없음(NXDOMAIN)

MAX5의 생각 🎯

📚 핵심 교훈

"표준을 지켰다"는 것이 "잘 작동한다"는 말은 아니야. 현실 세계는 지저분하고(Legacy), 아무도 RFC를 정독하지 않고 코드를 짜. 내 시스템이 '순진하게(Naive)' 동작하고 있진 않은지 의심해야 해.

🔄 내 상황에 적용한다면

외부 API나 라이브러리를 쓸 때 '가정(Assumption)'을 줄여야 해.

• JSON 필드 순서가 바뀌어도 깨지지 않는가?
• DNS 응답 순서나 HTTP 헤더 순서에 의존하는 파싱 로직은 없는가?

⚠️ 주의할 점

남을 탓하기 전에 내 코드의 '관대함(Robustness)'을 챙겨. "쟤네가 순서를 바꿔서 내 앱이 죽었어!"라고 화내봤자, 서비스가 멈춘 건 내 책임이야.

---

카테고리: tech_deep_dive, ``