IETF가 2024년 1월 31일 RFC 9532 "HTTP Proxy-Status Parameter for Next-Hop Aliases"를 발표했습니다. 이 문서는 HTTP Proxy-Status 응답 필드에 쓰는 새 매개변수 next-hop-aliases를 정의합니다. 프록시 같은 중개자(intermediary)는 다음 홉(next hop)에 연결하려고 DNS 이름을 해석하는데, 이때 받은 별칭(alias)과 정식 이름(canonical name), 곧 CNAME 체인을 이 매개변수에 담아 클라이언트에 알려 줄 수 있습니다.
무엇이 발표되었나
- 문서: RFC 9532, 저자 T. Pauly, HTTP 분야, 표준 트랙(Standards Track)의 표준안(Proposed Standard)
- 배경: 기존 Proxy-Status 필드에는
next-hop매개변수가 있습니다. 여기에는 다음 홉의 호스트 이름, IP 주소, 별칭 중 하나만 넣을 수 있어서, DNS 해석 중에 거친 별칭 체인 전체는 전달할 수 없었습니다. - 값 형식: 구조화 필드(Structured Fields)의 String 형식이며, DNS 이름 하나 이상을 쉼표로 구분해 나열합니다. 이름 안에 쉼표가 들어 있으면 RFC 2.1절에 따라 인코딩해야 합니다.
- 담는 내용: 다음 홉의 호스트 이름을 해석하는 동안 CNAME 레코드로 받은 별칭과 정식 이름 전부입니다. 처음 요청한 호스트 이름을 넣어도 됩니다(MAY). 이름은 DNS에서 받은 순서대로 적는 것이 바람직하며, 마지막 이름이 실제로 주소로 해석된 이름이 됩니다.
next-hop없이next-hop-aliases만 넣을 수도 있습니다.
원문의 예시를 보면, host.example.com이 tracker.example.com을 거쳐 service1.example.com(AAAA 2001:db8::1)으로 해석되었을 때 프록시는 다음과 같이 응답할 수 있습니다.
Proxy-Status: proxy.example.net; next-hop="2001:db8::1";
next-hop-aliases="tracker.example.com,service1.example.com"영향 범위
원문은 이 정보가 특히 순방향 프록시(forward proxy)의 클라이언트에게 쓸모 있다고 설명합니다. 클라이언트가 CONNECT 메서드나 UDP 프록시(CONNECT-UDP)로 특정 호스트에 연결할 때에 해당합니다. CNAME 레코드는 추적이나 악성 행위를 하는 호스트를 무해해 보이는 이름 뒤에 숨기는 데("cloak") 쓰이기도 합니다. 웹 브라우저 같은 클라이언트는 DNS 이름 체인을 보고 쿠키 사용 정책을 정하거나 악성 호스트를 차단합니다. 프록시를 거치면 클라이언트가 직접 DNS를 조회하지 않으므로 이 체인을 볼 수 없었는데, 이 매개변수가 그 틈을 메웁니다.
역방향 프록시(reverse proxy)에서는 목록 첫 항목에 다음 홉 이름을 넣을 수 있습니다. next-hop에 IP 주소만 넣어 클라이언트가 다음 홉 이름을 알 수 없을 때 특히 유용하다고 원문은 설명합니다.
이 매개변수는 다음 홉 이름을 DNS로 해석한 경우에만 적용됩니다. DNS 프로토콜이나 권한 서버, 리졸버의 동작을 바꾸는 문서는 아닙니다.
운영자가 할 일
당장 반드시 해야 할 조치는 없습니다. 아래 내용은 운영 환경에 따라 검토하시기 바랍니다.
- HTTP 프록시를 운영한다면 사용하는 프록시 소프트웨어가
next-hop-aliases를 지원하는지, 켜고 끌 수 있는지 확인합니다. - 이 매개변수를 쓰면 프록시가 DNS에서 받은 CNAME 이름이 클라이언트에 그대로 전달됩니다. 내부 서비스 이름이 CNAME 체인에 들어 있다면 외부에 보여도 되는지 미리 판단해 두는 것이 좋습니다.
- DNS 영역을 관리할 때는 CNAME 체인이 클라이언트의 정책 판단(쿠키, 차단)에 쓰일 수 있다는 점을 염두에 두고, 불필요한 중간 별칭은 정리하는 것을 검토합니다.
원문을 한국어로 번역·요약한 글입니다. 정확한 내용은 원문을 확인해 주세요. AI의 도움을 받아 작성하고 담당자가 검토했습니다.