Cloudflare 1.1.1.1 DoH JSON API 추가 레코드 형식 변경, 응답 파서 호환성 점검 필요
Cloudflare는 1.1.1.1 DoH JSON API(application/dns-json)에서 추가 레코드 유형의 data 필드 표현 방식을 바꾸고 있다고 밝혔습니다. 이번 변경은 응답 구조를 소비하는 애플리케이션 입장에서는 호환성 이슈가 될 수 있으며, 특히 문자열 포맷에 의존하는 DNS 모니터링, 진단 스크립트, 네트워크 운영 자동화에서 영향 여부를 먼저 확인할 필요가 있습니다.
무엇이 바뀌었나
기존에는 일부 레코드 유형의 data 필드가 RFC 3597의 일반 hex 인코딩 형태로 반환됐지만, 이제는 사람이 읽기 쉬운 표준 표현 형식으로 제공됩니다. 변경 대상으로 예시된 레코드 유형은 CAA, NAPTR, RP, IPSECKEY, SVCB입니다.
Cloudflare는 이번 변경이 순차 적용 중이라고 설명했습니다. 따라서 같은 API를 호출하더라도 일정 기간 동안은 기존 형식과 새 형식이 함께 나타날 수 있어, 응답 포맷을 단일 문자열 패턴으로 가정한 구현은 오동작할 가능성이 있습니다.
운영 환경에서 확인할 부분
이 이슈는 DNS 서버 자체 장애보다도, DoH JSON 응답을 후처리하는 운영 도구의 파싱 실패 가능성과 더 직접적으로 연결됩니다. 예를 들어 네트워크 점검 스크립트, 도메인 설정 검증 배치, 고객 포털의 DNS 조회 기능, 장애 분석용 내부 유틸리티가 특정 data 문자열 형식을 전제로 작성돼 있다면 결과 표시 오류나 비교 로직 실패가 발생할 수 있습니다.
특히 한국·일본 리전에서 운영되는 IDC, 서버호스팅, 코로케이션 환경에서는 외부 DNS 상태 확인을 자동화한 경우가 많습니다. 다만 이번 공지는 Cloudflare 1.1.1.1 DoH JSON API의 표현 형식 변경에 관한 내용이므로, 실제 영향 범위는 해당 API를 직접 사용하는 워크플로에 한정해 판단하는 것이 적절합니다.
롤아웃 기간 중 대응 체크리스트
우선 1.1.1.1의 application/dns-json 응답을 사용하는 서비스와 스크립트를 식별해야 합니다. 이후 CAA, NAPTR, RP, IPSECKEY, SVCB 레코드 조회 시 data 필드가 기존 hex 형태와 새 표준 표시 형태 중 어느 쪽으로 와도 정상 처리되는지 테스트하는 것이 필요합니다.
응답 문자열을 그대로 비교하거나 정규식으로 고정 매칭하는 로직이 있다면 혼재 기간에 실패할 수 있으므로 보완이 필요합니다. Cloudflare는 안정적인 형식이 필요할 경우 DoH wireformat 사용을 권고했으므로, 장기적으로 스키마 고정성이 필요한 내부 시스템은 wireformat 전환 가능성도 검토할 만합니다.
또한 표준 이미지나 내부 패키지 저장소에 포함된 진단 도구, 고객용 셀프서비스 조회 페이지, API 연동 문서가 이전 형식을 전제로 설명하고 있는지도 함께 점검해야 합니다. 운영팀과 개발팀이 각각 다른 파서를 유지 중이라면 결과 불일치가 없는지도 확인하는 편이 안전합니다.
변경 성격과 유의점
Cloudflare는 이번 변경을 브레이킹 체인지로 명시했습니다. 동시에 DoH JSON 형식에는 공식 RFC가 없고 스키마 안정성이 보장되지 않는다고 밝혔기 때문에, JSON 응답의 사람이 읽기 쉬운 표현을 장기 인터페이스처럼 취급하는 설계는 재검토가 필요합니다.
즉 이번 이슈의 핵심은 DNS 레코드 의미가 바뀌는 것이 아니라, 이를 JSON 문자열로 표시하는 방식이 달라진다는 점입니다. 운영 관점에서는 DNS 분석 기능 자체보다 파싱, 표시, 비교, 알림 연계 로직의 내구성을 점검하는 것이 우선입니다.
핵심 포인트
- Cloudflare 1.1.1.1 DoH JSON API의 일부 레코드 data 필드 형식이 변경된다.
- 롤아웃 중에는 기존 형식과 새 형식이 혼재할 수 있다.
- CAA, NAPTR, RP, IPSECKEY, SVCB 레코드가 변경 예시로 제시됐다.
- Cloudflare는 이를 브레이킹 체인지로 안내했다.
- 안정적 형식이 필요하면 DoH wireformat 사용이 권고됐다.