요약

  • Ray Bellis의 RFC 5625는 단순 DNS 프록시의 무지를 설계 제약 조건으로 바꿉니다. 알 수 없는 플래그, 레이블, 질의 유형, 클래스, 리소스 레코드는 통과해야 하고, 완전한 응답, EDNS 옵션, 잘림(truncation) 신호, TCP 전송은 보존되어야 하며, 형식이 맞지 않는 입력과 능동적인 정책은 DNS의 미래 경계인 것처럼 가장하지 않고 눈에 보이게 실패해야 합니다.
  • 이 문서는 2009년에 BCP 152가 되었습니다. 현재의 게이트웨이가 이를 준수한다는 것을 증명하지 않으며, 투명한 포워딩은 DNSSEC 검증도, 완전한 보안 정책도 아닙니다. 이 문서의 지속적인 기여는 권한의 분할입니다. 엔드포인트와 사양이 의미를 소유하고, 프록시는 제한된 포워딩, 클라이언트 상관(correlation), 인터페이스 노출, 명시적인 로컬 선택을 소유합니다.

예약된 채로 남지 않았던 비트

특정 DNS 헤더 비트가 반드시 0이어야 했던 시절에 만들어진 브로드밴드 라우터를 떠올려 보십시오. 그 파서는 오래된 규칙을 진지하게 받아들입니다. 몇 년 뒤 표준 문서가 그 비트에 용도를 부여합니다. 업데이트된 클라이언트가 그 비트를 설정해 보냅니다. 재귀 리졸버는 이를 이해합니다. 그 사이에 놓인 프록시는 여전히 이를 오류로 간주해 패킷을 조용히 폐기합니다.

양쪽 엔드포인트 어디에도 잘못된 것이 없습니다. 설치된 중개자가 자신의 펌웨어 나이를 프로토콜 진화에 대한 거부권으로 바꿔 버린 것입니다.

이것이RFC 5625,DNS Proxy Implementation Guidelines의 실무적 문제입니다. 2009년 8월에 Best Current Practice 152로 발행된 이 문서는 당시 Nominet UK에 재직하던 Ray Bellis가 집필했습니다. 이 문서는 작은 게이트웨이에게 모든 DNS 기능을 구현하라고 요구하지 않습니다. 게이트웨이에게 자신의 구현 한계를 프로토콜의 한계와 혼동하지 말라고 요구할 뿐입니다.

이 구분은 프록시가 가정이나 소규모 사무실의 모든 기기에 대한 기본 경로에 놓이기 전까지는 소박해 보입니다. DHCP는 흔히 게이트웨이를 DNS 서버로 광고합니다. 게이트웨이는 LAN에서 질의를 받아 재귀 리졸버에 관련 요청을 보내고 응답을 돌려줍니다. 이제 게이트웨이는 완전한 리졸버에 기대되는 파서, 업데이트 주기, 운영 가시성을 반드시 갖추고 있지 않으면서도 제어 지점을 차지하게 됩니다.

Bellis의 해답은 의도적으로 얇은 역할입니다. 단순 프록시는 요청을 알려진 업스트림 재귀 리졸버에 그대로 전달하고 완전한 응답을 발신 클라이언트에 그대로 돌려주어야 합니다. 프록시에게도 해야 할 일은 있지만, 경로에 존재한다는 이유만으로 의미론적 권한을 얻어서는 안 됩니다.

역사적 증거이지 오늘의 실태 조사가 아니다

2009년에 이 우려는 가설이 아니었습니다.SAC035 요약본과전체 보고서는 2008년 7월과 8월에 주택용 라우터 및 소규모 사무실 방화벽 24대를 대상으로 한 통제 실험을 기록하고 있습니다.

24대 모두 DNSSEC 질의를 업스트림 리졸버로 직접 라우팅할 수 있었습니다. 22대는 DNS 프록시 모드도 제공했습니다. 그 프록시 구현 중 6개가 DNSSEC 관련 플래그나 검증된 응답을 처리하는 데 어려움을 겪었습니다. 18대는 UDP 응답을 512바이트 또는 MTU 관련 크기로 제한했으며, 4096바이트까지의 프록시 응답을 돌려준 것은 4대뿐이었고 DNS over TCP를 프록시한 것은 1대뿐이었습니다. 6대는 기본 구성에서 완전히 호환되었고, 9대는 프록시 비호환을 우회하도록 구성할 수 있었습니다.

이 수치들이 이 문서의 시급성을 설명합니다. 하지만 오늘의 설치 기반을 묘사하지는 않습니다. 표본은 작았고, 실험은 2008년에 수행되었으며, 이후 펌웨어, 제품, 네트워크 관행이 바뀌었습니다. RFC 5625가 유용한 이유는 정확히 그 역사적 실험을 현대의 시장 주장으로 바꿀 필요 없이 그 논리가 성립하기 때문입니다. 프로토콜 확장은 앞으로도 그 확장보다 먼저 만들어진 중개자와 부딪히게 됩니다.

IETF 승인 문서는 DNS Extensions Working Group의 강한 합의와 벤더 및 구매자의 관심을 기록하고 있습니다. 이는 표준화 과정과 문제의 관련성에 대한 증거입니다. 구매자가 그 가이드를 강제했거나 배포된 기기가 이를 채택했다는 증거는 아닙니다.

알 수 없다고 형식이 틀린 것은 아니다

RFC 5625는 프록시가 이해하지 못하는 값과 유효할 수 없는 패킷 사이에 가장 중요한 선을 긋습니다.

프록시가 알지 못하는 DNS 헤더 플래그는 무시하고 패킷을 전달해야 합니다. 레이블 인코딩, QTYPE, QCLASS, 리소스 레코드 TYPE 및 CLASS 값에도 동일하게 적용됩니다. 오늘의 레지스트리를 기준으로 설계된 파서가 내일의 할당을 폐기하도록 허용되어서는 안 됩니다. 데이터를 요청한 엔드포인트와 이에 답하는 리졸버가 그 값의 의미를 판단하기에 더 적합한 위치에 있습니다.

RFC 3597은 보다 일반적인 확장성 규칙을 제공합니다. 알 수 없는 리소스 레코드 유형을 만난 서버나 리졸버는 그 RDATA를 구조화되지 않은 이진 정보로 취급하고, 저장하고, 변경 없이 전송해야 합니다. 이는 레코드를 이해하는 척하라는 지시가 아닙니다. 올바른 의미론을 가진 구성 요소가 레코드를 받을 때까지 보존하는 방법입니다.

형식이 맞지 않는 입력은 다릅니다. 불가능한 섹션 수나 잘못된 압축 포인터는 오래된 구현이 파싱하지 못한다고 해서 미래의 확장이 아닙니다. RFC 5625는 그러한 메시지를 거부할 수 있도록 허용합니다. 그 운영상의 선호도 여전히 시사적입니다. 안전하다면 패킷을 조용히 폐기하기보다 SERVFAIL을 반환하십시오. 그러면 클라이언트는 재전송을 멈출 수 있고, 운영자는 어느 계층이 요청을 거부했는지에 대한 증거를 얻습니다.

명시적인 정책 예외도 있습니다. 능동적인 보안 또는 네트워크 정책을 구현하는 프록시는 트래픽을 의도적으로 차단하거나 변경할 수 있습니다. 그러나 의도적인 규칙은 정책으로서 귀속 가능해야 합니다. 불완전한 파서에서 우연히 발생한 결과를 프로토콜 준수라고 묘사해서는 안 됩니다.

보존 책임에는 크기와 전송도 포함된다

DNS의 의미는 이름과 레코드 유형뿐 아니라 응답이 자신의 완전성을 선언하는 방식에도 담겨 있습니다. UDP 응답을 TC 플래그를 설정하지 않은 채 512바이트로 잘라내는 프록시는 그럴듯해 보이는 불완전한 응답을 만듭니다. TC를 제거하는 프록시는 TCP로 재시도하라는 서버의 지시를 지워 버립니다.

따라서 RFC 5625는 프록시가 UDP 응답이 512바이트를 초과한다는 이유만으로 잘라내서는 안 된다고 규정합니다. 피할 수 없는 로컬 한계가 있다면 TC를 설정해야 하며, 업스트림에서 받은 TC 표시를 절대 제거해서는 안 됩니다. 이 차이는 기술적일 만큼 인식론적입니다. 클라이언트는 선언된 잘림에 대응할 수 있습니다. 그러나 부재가 성공으로 위장된 정보는 복구할 수 없습니다.

TCP도 같은 보존 책임의 일부입니다. 프록시는 DNS over TCP를 수신하고 전달할 준비가 되어 있어야 합니다. 클라이언트가 TCP로 접속했다면 업스트림 질의도 TCP를 유지해야 하며, 이미 잘릴 가능성이 높은 투기적 시도를 위해 UDP로 강등해서는 안 됩니다. Bellis가 이후 네 명의 동료와 함께 집필한RFC 7766은 TCP 지원을 DNS 구현의 요구 사항으로 만들었습니다. 이 후속 Standards Track 문서는 전송 경계를 강화하지만, 모든 게이트웨이가 준수한다는 것을 보여주지는 않습니다.

EDNS는 확장 문제를 구체화합니다. RFC 5625는 OPT 레코드가 프록시로 하여금 질의를 거부하게 해서는 안 된다고 말합니다. 이후RFC 6891은 준수하는 중간 장치가 이전의 512바이트 UDP 상한을 강제해서는 안 되며, 단순 포워더는 양방향 모두에서 OPT 내용을 수정하거나 삭제해서는 안 된다고 규정합니다. 2009년 프록시 문서가 권장한 4096바이트 용량은 그 시대의 구현 규모에 속하며, 시간을 초월한 최대치가 아닙니다.

투명성에도 운영 표면이 있다

얇은 프록시는 선이 아닙니다. 업스트림 재귀 리졸버를 선택하거나 학습합니다. 돌아오는 응답을 올바른 LAN 클라이언트에 매핑합니다. 그 상태를 얼마나 유지할지, 어떤 인터페이스가 질의를 받을지, DHCP가 어떤 리졸버 주소를 광고할지를 결정합니다. 클라이언트 상관을 위해 발신 Query ID를 바꿀 수도 있습니다.

이러한 선택은 실제 권한이며 자체적인 통제가 필요합니다. RFC 5625는 무작위화된 질의 식별자와 소스 포트를 포함해RFC 5452의 위조 저항 조치를 가리킵니다. 무작위화는 한 부류의 스푸핑 노출을 줄이지만, 응답을 인증하지 않으며 DNSSEC를 대체하지 않습니다.

패킷 무결성은 '도움이 되는' 재작성의 여지를 좁힙니다. TSIG 서명된 교환에서, 질의 식별자에 대한 특별히 허용된 처리를 제외하고 인증된 DNS 내용을 수정하면 검증에 실패합니다. 프록시는 메시지를 보존하거나 전체 인증 동작을 올바르게 구현해야 합니다. 부분적 해석은 도움이 아니라 관찰 가능한 손상입니다.

인터페이스 범위도 중요합니다. LAN 클라이언트를 위한 게이트웨이 프록시는 기본적으로 WAN 측에서 수신해서는 안 됩니다. 노출된 프록시는RFC 5358에서 기술된 반사 공격 위험에 일조할 수 있습니다. 정당한 클라이언트를 향한 투명성이 인터넷 전체에 대한 무차별적 가용성을 요구하는 것은 아닙니다.

마지막으로 우회는 경계의 일부입니다. 명시적인 정책이 달리 정하지 않는 한, 사용자는 프록시를 강제로 거치지 않고 지정한 업스트림 리졸버로 질의를 보낼 수 있어야 합니다. 편의 서비스는, 낯선 기능을 보존한다는 증명 없이 모든 탈출 시도를 네트워크가 붙잡는 순간 의미론적 목으로 변합니다.

늙게 될 중개자를 위한 Bellis의 규칙

IETF Datatracker 프로필은 Ray Bellis의 RFC 10개를 나열하며 RFC 5625를 포함합니다.ISC 팀 페이지는 오늘 그를 DNS 운영 디렉터(Director of DNS Operations)로 밝히고 있습니다. 이 경력적 배경이 관련 있는 이유는 이 문서가 DNS 기능 목록보다 운영 책임의 배분에 가깝게 읽히기 때문입니다.

그 기준은 프록시가 충분히 아는가가 아닙니다. 기준은 모를 때 무슨 일이 일어나는가입니다. 낯선 플래그가 통과하는가? 알 수 없는 리소스 레코드가 온전히 살아남는가? 클라이언트가 TC를 보고, SERVFAIL을 받고, TCP를 유지하며, 엔드포인트가 이해하는 OPT 데이터를 지키는가? 운영자가 명시적 정책 결정과 펌웨어의 무지를 구분할 수 있는가?

이후 Mark Andrews와 Bellis가 공동 집필한RFC 8906은 이러한 사례 상당수를 명시적인 DNS 리졸버 테스트 벡터로 만듭니다. 예상하지 못한 필드, 레코드 유형, EDNS 버전, 옵션과 플래그, 잘림, TCP가 그 대상입니다. 이 후속 문서는 침묵을 새 문제로 만들지 않습니다. 오래된 문제를 측정 가능하게 만들 뿐입니다.

RFC 5625는 투명성이 검증, 프라이버시 또는 가용성을 제공한다고 결코 주장하지 않습니다. 운영자가 업스트림을 설정하고, 인터페이스를 보호하고, 선언된 정책을 집행할 권리도 부정하지 않습니다. 그것이 하는 일은 더 좁고 더 지속적입니다. 중개자가 자신의 무지를 관할권으로 조용히 취급하지 못하게 만드는 것입니다.

프록시는 포워딩 상태를 소유할 수 있습니다. 자신의 노출과 로컬 정책도 소유할 수 있습니다. 그러나 자신이 우연히 운반하는 모든 비트의 미래 의미를 소유할 수는 없습니다.

출처