DNS 영역 전송

DNS zone transfer

DNS 영역 전송은 유도 DNS 쿼리 유형 AXFR로도 알려져 있으며 DNS 트랜잭션의 한 유형이다.관리자가 DNS 서버 집합에 걸쳐 DNS 데이터베이스를 복제할 수 있는 여러 메커니즘 중 하나이다.

구역 전송은 전송을 위해 TCP(Transmission Control Protocol)를 사용하며,[1][2] 클라이언트-서버 트랜잭션의 형태를 취한다.영역 전송을 요청하는 클라이언트는 주 서버로부터 데이터를 요청하는 보조 서버일 수 있다.[3]복제되는 데이터베이스의 부분은 영역이다.

작전

영역 전송은 서문 뒤에 실제 데이터 전송으로 구성된다.서문은 "구역"의 상단에 있는 DNS 네임스페이스의 노드인 "구역 a펙스"에 대한 권한 시작(SOA) 리소스 레코드의 조회를 구성한다.이 SOA 자원 기록의 필드, 특히 "일련 번호"는 실제 데이터 전송이 필요한지 여부를 결정한다.고객은 SOA 리소스 레코드의 일련 번호와 해당 리소스 레코드의 마지막 사본에 있는 일련 번호를 비교한다.이관되는 기록의 일련번호가 클 경우 구역 내 데이터는 (어떤 식으로든) "변경"된 것으로 간주되며, 2차적으로는 실제 구역 데이터 전송을 요청한다.일련번호가 동일한 경우, 구역의 데이터는 "변경"되지 않은 것으로 간주되며, 클라이언트는 이미 보유하고 있는 데이터베이스 사본을 계속 사용할 수 있다.

실제 데이터 전송 프로세스는 클라이언트가 서버에 대한 TCP 연결을 통해 특수 쿼리 유형 AXFR(값 252)으로 쿼리(opcode 0)를 보내는 것으로 시작된다.DNS는 UDP(User Datagram Protocol)를 통해 기술적으로 AXFR을 지원하지만, 손실되거나 스푸핑된 패킷의 위험으로 인해 수용할 수 없는 것으로 간주된다.[2][1]서버는 "구역"에 있는 모든 도메인 이름에 대한 모든 자원 레코드를 구성하는 일련의 응답 메시지로 응답한다.첫 번째 대응은 구역 정점에 대한 SOA 자원 기록으로 구성된다.다른 데이터는 정해진 순서가 없다.데이터의 끝은 구역 정점에 대한 SOA 자원 기록을 포함하는 응답을 반복하는 서버에 의해 신호를 받는다.

일부 구역 전송 클라이언트는 시스템의 정상적인 DNS 쿼리 확인 메커니즘을 사용하여 서문 서문에 대한 SOA 조회를 수행한다.이들 클라이언트는 실제 데이터 전송을 수행할 필요가 있다고 판단하기 전까지는 서버에 대한 TCP 연결을 열지 않는다.그러나 TCP는 구역 전송뿐만 아니라 정상적인 DNS 트랜잭션에 사용될 수 있으므로, 다른 구역 전송 클라이언트는 실제 데이터 전송을 수행할 때와 동일한 TCP 연결을 통해 SOA 조회 서문을 수행한다(가능).이들 클라이언트는 프리앰블을 실행하기도 전에 서버에 대한 TCP 연결을 연다.

앞에서 설명한 것은 전체 구역 이전을 설명한다.증분 구역 전송은 다음과 같은 점에서 전체 구역 전송과 다르다.

  • 고객은 AXFR QTYPE 대신 특수 QTYPE IXFR(값 251)을 사용한다.
  • 클라이언트는 IXFR 메시지에 현재 보유하고 있는 구역 정점에 대한 SOA 리소스 레코드를 전송하여 서버가 현재라고 생각하는 "구역"의 버전을 알 수 있도록 한다.
  • 서버는 구역에 대한 전체 데이터로 정상적인 AXFR 방식으로 응답할 수 있지만, 대신 "증분" 데이터 전송으로 응답할 수도 있다.후자는 클라이언트가 가지는 것으로 서버에 보고한 구역의 버전과 서버에 현재 있는 구역의 버전 사이의 구역 데이터의 변경 목록(구역 일련 번호 순서)으로 구성된다.변경사항은 삭제된 리소스 레코드 중 하나와 삽입된 리소스 레코드 중 하나, 두 개의 목록으로 구성된다.(자원 기록의 수정은 삭제 후 삽입으로 표시된다.)

구역 전송은 전적으로 클라이언트에서 시작한다.영역 데이터를 변경할 때마다 서버가 클라이언트에 알림 메시지를 보낼 수 있지만(알려진 정보를 수신한 경우) 영역 전송 스케줄은 전적으로 클라이언트의 관리 하에 있다.고객 스케줄 구역 전송은 처음에 데이터베이스가 비어 있을 때, 그리고 이후 정기적으로 구역 정점에 대한 SOA 리소스 레코드의 "새로 고침", "재시도" 및 "확장" 필드에 있는 값에 의해 제어되는 패턴으로 수행된다.

제한 사항

표준화된 전체 영역 전송은 RFC 1034와 RFC 5936에서 가능한 데이터베이스 복제 메커니즘 중 하나로 설명되지만, 영역 전송은 그러한 데이터베이스 복제 메커니즘 중 가장 제한적이다.구역 전송은 "와이어 포맷" 자원 기록, 즉 DNS 프로토콜을 사용하여 전송되는 자원 기록의 관점에서 운용된다.그러나 유선 형식 리소스 레코드의 스키마는 DNS 서버의 백 엔드가 사용하는 데이터베이스 스키마와 동일하지 않을 수 있다.

운영상의 문제

일련 번호 변경

구역 전송의 서문 부분은 구역의 데이터가 변경되었는지, 따라서 실제 데이터 전송이 필요한지 여부를 결정하기 위해 일련 번호와 일련 번호에만 의존한다.일부 DNS 서버 패키지의 경우 SOA 리소스 레코드의 일련 번호는 관리자가 손으로 관리한다.데이터베이스에 대한 모든 편집에는 변경되는 레코드와 구역 일련 번호의 두 가지 변경이 포함된다.그 과정은 정확성을 요구한다: 관리자는 일련번호를 바꾸는 것을 잊거나 잘못 변경할 수 있다(축소한다).RFC 1912(섹션 2.2 SOA 레코드)는 YYYYMMDDn 값을 숫자로 사용할 것을 권고한다(YYYY=year, MM= month, DD=day, nn=revision num)이것은 4294년까지 넘치지 않을 것이다.

일부 DNS 서버 패키지는 디스크에 있는 데이터베이스 파일의 마지막 수정 타임스탬프에서 일련 번호를 자동으로 구성하여 이 문제를 해결했다.예를 들어 djbdns의 경우는 이렇다.운영 체제는 관리자가 데이터베이스 파일을 편집할 때마다 마지막 수정 타임스탬프가 업데이트되도록 보장하고, 일련 번호를 효과적으로 자동으로 업데이트하며, 따라서 관리자가 매번 변경될 때마다 두 번의 편집(다른 두 곳에서)을 해야 하는 필요성을 덜어준다.

더욱이, 일련번호 검사(및 실제로 구역 전송 자체)가 설계되는 데이터베이스 복제 패러다임은 데이터베이스의 기본 버전을 보유하는 단일 중앙 DNS 서버와 단순히 복사본을 보유하는 다른 모든 DNS 서버를 포함하는 것으로, 단지 많은 최신 DNS 서버 패키지의 그것과 일치하지 않는다.[citation needed]SQL 서버 및 Active Directory와 같은 정교한 데이터베이스 백엔드가 포함된 최신 DNS 서버 패키지를 통해 관리자는 다중 마스터 복제를 사용하는 여러 위치에서 데이터베이스를 업데이트할 수 있으며, 데이터베이스 백엔드 자체 복제 메커니즘은 다른 모든 서버에 대한 복제를 처리한다.이 패러다임은 단순히 변화를 기록하기 위해 중앙에서 단조롭게 증가하는 단일 숫자의 그것과 일치하지 않기 때문에, 크게 구역 이동과 양립할 수 없다.[citation needed]정교한 데이터베이스 백엔드를 가진 현대의 DNS 서버 패키지는 종종 "심" 일련 번호를 생성하여 업데이트가 이루어지는 단일 중앙 장소의 존재를 시뮬레이션하지만, 이것은 기껏해야 불완전한 것이다.

이것과 여러가지 이유가 나중에 나와 전반에 다행히도, 다시 그런 정교한 데이타를 사용하는 DNS서버 끝은 거의 자신의 데이터베이스 복제 메커니즘으로써 첫번째 장소에서 뒷쪽 자신들을 제공한다 끝나 대개 대신 훨씬 우수한 분산 데이터베이스 복제 메커니즘을 고용 영역 전송을 사용한다.[표창 필요한]

일련번호 비교

일련번호 비교는 RFC 1982에 정의된 대로 일련번호 산술을 사용하기 위한 것이다.단, 이는 RFC 1034에 명확히 명시되지 않아 모든 클라이언트가 서문에서 동일한 방식으로 일련번호 검사를 수행하지는 않았다.일부 클라이언트는 서버가 제공하는 일련 번호가 클라이언트가 알고 있는 일련 번호 또는 0이 아닌 일련 번호와 다른지 확인만 한다.다른 클라이언트는 서버에서 제공한 일련 번호가 클라이언트가 이미 알고 있는 일련 번호의 지정된 범위 내에 있는지 검사한다.그러나 다른 클라이언트들은 여전히 후자 검사를 수행하고 서버가 제공하는 일련 번호가 0이 아닌지 추가로 확인한다.

여러 리소스 레코드

원래 실제 데이터 전송에서는 단일 도메인 이름과 유형에 대한 각 리소스 레코드 세트가 서버에서 클라이언트로 별도의 응답 메시지로 전송되었다.그러나 이는 비효율적이며, 일부 DNS 서버 소프트웨어는 다음과 같은 데이터 전송의 총 대역폭 요구 사항을 줄이기 위해 DNS 프로토콜의 응답 압축 메커니즘을 허용하는 데 적합한 최적화를 구현했다.

  • NS, SRV 또는 MX 리소스 레코드 세트와 동일한 응답에 "glue" 리소스 레코드 세트를 포함하도록 "추가 섹션 처리" 수행
  • 단일 도메인 이름과 관련된 모든 리소스 레코드 집합을 수집하여 적합한 경우 단일 응답으로 전송

일부 클라이언트는 원래 응답 형식만 예상하도록 작성되었으며, 이러한 최적화가 채택될 경우 데이터 전송을 수행하지 못할 수 있다.따라서, 여러 DNS 서버 패키지는 관리자가 그것을 필요로 하는 클라이언트에 대해 "단일 응답 형식"의 사용을 지정할 수 있는 구성 설정을 가지고 있다.

데이터 노출

DNS 영역에 포함된 데이터는 운영 보안 측면에서 민감할 수 있다.이것은 서버 호스트명과 같은 정보가 공공 지식이 될 수 있기 때문에, 이것은 조직에 대한 정보를 발견하고 심지어 더 큰 공격 표면을 제공하는 데 사용될 수 있기 때문이다.2017년 6월 러시아 최상위권 등록 담당자가 실수로 AXFR을 통한 DNS 구역 전송을 가능하게 해 560만 개의 레코드가 우연히 노출됐다.[4]

2008년 미국 노스다코타 법원은 공개적으로 접근할 수 없는 정보를 얻기 위해 허가받지 않은 외부인으로서 구역 이전을 행하는 것은 노스다코타 법 위반에 해당한다고 판결했다.[5]

참고 항목

참조

  1. ^ a b "Domain names - implementation and specification". IETF. November 1987.
  2. ^ a b Dickinson, John; Dickinson, Sara; Bellis, Ray; Mankin, Allison; Wessels, Duane (March 2016). "DNS Transport over TCP - Implementation Requirements". IETF.
  3. ^ Fujiwara, Kazunori; Sullivan, Andrew; Hoffman, Paul. "DNS Terminology". tools.ietf.org. Retrieved 2020-06-21.
  4. ^ "Wrong Bind Configuration Exposes the Complete List of Russian TLD's to the Internet". SecurityTrails Blog. 2018-03-14. Retrieved 2018-04-10.
  5. ^ "Anti-spammer fined for accessing DNS records of private network". The H. 18 January 2008.

외부 링크

보안 표준 정보

관련 의견 요청