Summary

  • 11월 5일 개인 초안은 CNAME을 포함한 DNS 응답에서 질의한 별칭, 그다음 별칭, 최종 답 순서로 RRSet을 놓자고 제안한다. 더 넓던 앞선 제안을 실제 고장이 드러난 경우로 좁혔다.
  • 초안의 1월 사건 기록에는 glibc 이름 조회 실패와 NTP 서버 이름을 찾다 재부팅된 일부 스위치가 나온다. Cisco 공식 지원 문서는 해당 장비군과 DNSC 프로세스의 치명적 오류를 밝힌다.

새 필드가 문제를 만든 것은 아니다. 재귀 리졸버는 하나의 Answer 구역에 첫 CNAME, 다음 CNAME, 마지막 A 레코드를 담을 수 있다. RFC 1034는 CNAME이 답 앞에 올 수 있다고 설명하고 레코드를 답에 복사하라고 했지만, “복사”가 순서대로 뒤에 붙이라는 명시적 규칙인지는 정하지 않았다. 한쪽은 묶음으로 보고 다른 쪽은 순서로 읽었다. 2026년 1월 8일 리졸버 업데이트가 CNAME 응답의 RRSet 순서를 바꿨다. 초안 부록에 따르면 회귀 시험은 순서를 중요하게 보지 않아 변화를 놓쳤다. glibc 조회가 실패하고 일부 스위치는 설정된 NTP 이름을 질의하다 재부팅됐다.

Cisco 공지는 Catalyst 1200/1300과 CBS 250/350의 특정 펌웨어를 지목한다. DNSC의 치명적 오류를 기록하고 특정 DNS 응답 형식을 원인 후보로 보며, 다른 DNS 사용, 이름 조회 중지, 정적 호스트 매핑을 임시 조치로 제시한다. 전체 피해 장비 수는 제시하지 않는다. IETF 작성자들은 사건을 CNAME 순서와 연결하지만 공식 기록만으로 전체 손실 규모를 계산할 수 없다.

11월 02판은 질의 이름의 CNAME, 이어지는 CNAME, 마지막 목표 레코드 순으로 추가하자는 좁은 수정을 내놓는다. 동일 RRSet 내부의 순서는 여전히 중요하지 않다. 클라이언트는 어떤 CNAME RRSet 순서도 받아들여야 하지만 서버는 그 관용에 의존해서는 안 된다. 8월 01판은 DNS 구역 전반의 순서를 다뤘다. 작업반 의견 뒤에 범위가 줄었다. IETF 기록은 아직 개인 초안이며 RFC 1034 변경은 승인 후에만 가능하다.

낡은 소프트웨어 비용을 누가 부담할지의 문제다. 서버는 보수적으로 보내고 클라이언트는 유연하게 읽는다. 시험 기록에는 리졸버 빌드, 두 응답의 원시 바이트, 다단 CNAME, glibc 결과, NTP 조회와 스위치 로그가 함께 있어야 한다. DNS 성공 응답만으로 스위치가 계속 켜져 있었는지 알 수 없다.