DNS 쿼리는 항상 UDP를 통해 이동합니까?

나는이 주제를 연구하는 데 약간의 시간을 보냈으며 정확한 답변을 찾을 수없는 것처럼 보이므로 중복되지 않으며 상당히 안전하다고 생각합니다. 내 질문은 보안 요구 사항을 기반으로하지만 여전히 안전하다고 생각합니다. 여기로 문의하되 보안 커뮤니티로 옮겨야하는지 알려주십시오.

기본적으로 DNS 쿼리는 TCP를 사용합니까? 그렇다면 어떤 시나리오가 발생할 수 있습니까? 다시 한 번 나는 쿼리에 대해서만 이야기하고 있습니다. 그들이 TCP를 통해 여행 할 수 있습니까? 도메인의 최대 길이가 253 바이트이고 UDP 패킷의 크기가 512 바이트 일 수있는 경우 쿼리가 항상 UDP처럼 나오지 않습니까? 해결 가능한 쿼리가 TCP 사용을 요구할만큼 충분히 클 수 있다고 생각하지 않았습니다. DNS 서버가 253 바이트보다 큰 도메인에 대한 요청을받은 경우 서버가이를 삭제하거나 시도하지 않습니까? 나는 여기에 약간의 잘못된 가정을했다고 확신한다.

상황에 따라 보안 그룹과 협력하여 DNS 쿼리를 보안 모니터링 도구에 내장하고 있으며 여러 가지 이유로 DNS 서버 및 도메인 컨트롤러에서 표준 패킷 ​​캡처를 통해이 트래픽을 캡처하기로 결정했습니다. 핵심 요구 사항은 모든 DNS 쿼리를 캡처하여 클라이언트가 어떤 도메인을 확인하려고 시도했는지 식별 할 수 있도록하는 것입니다. 이 요구 사항을 기반으로, 우리는 DNS 응답 또는 영역 전송과 같은 다른 트래픽 캡처와 관련이 없으며 가능한 한 로그 볼륨을 제한해야한다는 사실에 기인합니다. 따라서 DNS 서버로 향하고 UDP를 통해 전송되는 DNS 쿼리 만 캡처 할 계획입니다. 더 많은 맥락 (여기서는 다양한 질문 범위가 등장)에서 보안을 확장해야 할 필요성이 제기되었습니다. ' 가시성을 통해 DNS를 통해 실행되는 비밀 채널 (DNS 응답 및 TCP 트래픽을 캡처해야 함)과 같은 활동을 모니터링 할 수 있습니다. 그러나 그런 종류의 시나리오에서도 아웃 바운드 DNS 트래픽은 조회 ​​/ 쿼리의 형태가 될 것이며 악성 소스에서 온 경우에도 UDP를 통해 발생한다고 생각했습니다 (첫 번째 단락의 추론 때문에). 따라서 몇 가지 추가 질문이 있습니다.

• 내가 설명한 접근 방식으로 대화의 절반을 캡처하고 있습니까? 아니면 클라이언트가 쿼리 형식이 아닌 DNS 트래픽을 전송합니까? (DNS 서버의 응답에 대한 일종의 응답과 같으며 TCP를 통해 끝날 수 있습니다)

• TCP를 사용하도록 DNS 쿼리를 수정할 수 있습니까? DNS 서버가 TCP를 통해 오는 DNS 쿼리를 수락하고 응답합니까?

관련성이 있는지 확실하지 않지만 DNS 요청을 승인 된 DNS 서버로 제한하고 포트 53을 통해 아웃 바운드 된 다른 모든 트래픽을 차단합니다. 확실히 신인이므로 내 질문에 부합하지 않으면 죄송합니다. 어떻게 수정해야합니까?

일반 DNS 쿼리는 UDP 포트 53을 사용하지만 더 긴 쿼리 (> 512 옥텟)는 '잘린'응답을 수신하므로 전체 쿼리를 쉽게 보내고받을 수있는 TCP 53 대화가 생성됩니다. 또한 DNS 서버는 포트 53에 바인딩되지만 쿼리 자체는 포트 53으로 전송 된 임의의 높은 번호의 포트 (49152 이상)에서 발생합니다. 포트 53에서 동일한 포트로 응답이 반환됩니다.

DNS가 사용하는 네트워크 포트 | Microsoft 문서

따라서 네트워크의 DNS 쿼리에 대해 보안 스누핑을 수행하려는 경우 위의 사항을 고려해야합니다.

조회되지 않은 트래픽의 경우 DNS는 영역 전송 (쿼리 유형 AXFR)을 사용하여 다른 DNS 서버를 새 레코드로 업데이트합니다. 중간 공격에있는 사람은 이러한 전송으로 시작하여 DDOS에서 기본 이름 서버를 작성하여 업데이트 된 레코드를 요청하는 보조에 응답하기에는 너무 바쁩니다. 그런 다음 해커는 동일한 기본 서버를 스푸핑하여 '중독 된'레코드를 보조 서버에 공급하여 인기있는 DNS 도메인을 손상된 호스트로 리디렉션합니다.

따라서 보안 감사는 쿼리 유형 AXFR에주의를 기울여야하며 DNS 시스템은 특정 IP 주소의 AXFR 교환 만 허용해야합니다.

SANS Institute InfoSec 독서실 | sans.org

이것은 George의 답변에 대한 주석으로 시작되었지만 시간이 오래 걸렸습니다. 더 큰 그림은 일부 역사를 이해해야하기 때문에 다소 복잡합니다.

• RFC 1035는 원래 UDP 조각화를 피하기 위해 512 바이트 제한을 요구했습니다. DNS 트랜잭션의 오버 헤드를 최소화하기 위해 조각난 UDP 데이터 그램과 TCP를 최후의 옵션으로 선택했습니다. 영역 전송은 본질적으로> 512 바이트를 차지하므로 영역 전송은 항상 TCP를 사용합니다. (UDP로 시작하기에는 대역폭 낭비가 될 것입니다)

• 절단시 TCP 재 시도는 1989 년 이후 RFC 1123 에 지정된대로 널리 지원됩니다 .

• EDNS (0)은 RFC 6891 (2013)에 의해 정의되었으며 그 이전에는 1999 년으로 거슬러 올라간 제안 된 표준으로 존재했습니다 . 클라이언트와 서버가 512보다 큰 UDP 크기를 협상 할 수있는 메커니즘을 정의합니다. EDNS (0)의 새로운 기능으로 인해 많은 하드웨어 어플라이언스는 호환 패킷을 버리는 DNS 패킷의 구조에 대해 가정합니다. 가장 빈번한 이유는 512 바이트가 넘는 DNS 메시지가 유효하지 않다고 가정하기 때문입니다.

이를 관찰 된 동작으로 분류하면 :

1. 회신이 너무 커서 처음에는 알 수없는 경우가 아니면 DNS 쿼리는 일반적 으로 UDP로 시작합니다. (존 전송)
2. 회신은 할 수 잘린 응답이 보이는 경우 클라이언트에서 TCP 재시을 트리거합니다. 이것은 상당히 잘 지원됩니다.
3. 512 바이트 초과의 UDP 응답이 있다 클라이언트가 더 큰 페이로드를 광고 (0)를 사용한 경우 EDNS 보이는, 수 와 수신 서버가 지원 그것. 이는 두 하드웨어 사이에있는 하드웨어가 방해를받지 않고 패킷이 손실되거나 엉망 이되는 경우 에만 발생 합니다 .
4. 클라이언트 는 응답이 보이지 않으면 광고 페이로드가 더 작은 EDNS (0) 쿼리를 다시 시도하도록 선택할 수 있지만 구현에 따라 세부 사항이 다를 수 있습니다.
   • 마지막으로 응답하는 응답이 요청 된 크기에 맞지 않을 수 있으므로 위의 동작 # 2가 발생할 수 있습니다. (예전 TCP 재시도)
   • 클라이언트 측은 최종적으로 성공한 크기를 기억하도록 선택할 수 있습니다. 이를 통해 불필요한 쿼리를 다시 조사하지 않아도됩니다. 그렇지 않으면 특히 최종 결과에 TCP 폴 백이 필요한 경우 상당히 낭비가됩니다.

RFC 7766은 TCP를 통한 연결 재사용을 허용 하며 TCP를 통한 쿼리 파이프 라이닝이 발생할 수 있음을 명심해야합니다 . 일부 도구 는 TCP 세션에서 처음 보이는 것 이상으로 DNS 쿼리를 감지 하지 못합니다 . dnscap은 그러한 예입니다.

가 이다 RFC 7766는, TCP를 통해 DNS 운송 - 구현 요구 사항 .

1. 소개

대부분의 DNS [ RFC1034 ] 트랜잭션은 UDP [ RFC768 ]를 통해 발생 합니다. TCP [ RFC793 ]는 항상 전체 영역 전송 (AXFR 사용)에 사용되며 크기가 DNS 프로토콜의 원래 512 바이트 제한을 초과하는 메시지에 종종 사용됩니다. DNS 보안 (DNSSEC) 및 IPv6의 배포가 증가함에 따라 응답 크기가 증가하여 TCP 사용이 증가했습니다. 또한 TCP 스푸핑을 방지하고 리플렉션 / 앰프 공격에서 DNS를 악용 할 수있는 보호 기능으로 인해 TCP 사용이 증가해야했습니다. 응답 속도 제한 [ RRL1 ] [ RRL2 ]에 널리 사용됩니다 . 또한 [ DNS-over-TLS 와 같은 DNS 개인 정보 보호 솔루션에 대한 최근 연구]는 DNS-over-TCP 요구 사항을 다시 방문하려는 또 다른 동기입니다.

[RFC1123] 상태 6.1.3.2 절 :

  DNS resolvers and recursive servers MUST support UDP, and SHOULD
  support TCP, for sending (non-zone-transfer) queries.

그러나 일부 구현자는 TCP 지원이 DNS 프로토콜의 선택적 기능이라는 것을 의미하기 위해 위에서 인용 한 텍스트를 사용했습니다.

대부분의 DNS 서버 운영자는 이미 TCP를 지원하며 대부분의 소프트웨어 구현에 대한 기본 구성은 TCP를 지원하는 것입니다. 이 문서의 주요 대상은 TCP에 대한 제한된 지원이 상호 운용성을 제한하고 새로운 DNS 기능의 배포를 방해하는 구현 자입니다.

따라서이 문서는 TCP 지원이 전체 DNS 프로토콜 구현의 필수 부분이되도록 핵심 DNS 프로토콜 사양을 업데이트합니다.

TCP 사용 증가 ( 부록 A 참조 )와 고려해야 할 구현 세부 사항 에는 몇 가지 장점과 단점 이 있습니다. 이 문서는 이러한 문제를 해결하고 TCP를 DNS의 올바른 전송 대안으로 제시합니다. DNS 및 기타 인터넷 프로토콜에서 TCP의 연구, 개발 및 구현을 통해 얻은 추가 고려 사항 및 교훈과 함께 [ RFC5966 ] 의 내용을 확장합니다 .

이 문서는 DNS 서버 운영자가 충족해야 할 특정 요구 사항을 제시하지는 않지만 서버와 네트워크에서 TCP를 최적으로 지원할 수 있도록 운영자에게 몇 가지 제안을 제공합니다. TCP (또는 네트워크 계층에서 TCP를 통한 DNS 차단)를 지원하지 않으면 해결 실패 및 / 또는 응용 프로그램 수준 시간 초과가 발생할 수 있습니다.

TCP / 53을 어떤 방향으로도 필터링해서는 안됩니다. 예를 들어 nsupdate요청이 너무 크면 (빠르게 발생할 수있는) 쿼리가 TCP를 사용할 수 있습니다. 따라서 포트 53 (IPv4 및 V6!)의 UDP 및 TCP가 모든 방향으로 흐르도록해야합니다.

또한 TLS를 통한 DNS에 대한 작업이 점점 더 많아지고 있으므로 TCP는 양방향으로 필요합니다. RFC7858을 참조하십시오.