DNS-over-TLS 및 DNS-over-HTTPS를 지원하는 BIND DNS 서버 9.18.0 출시

9.18년간의 개발 끝에 ISC 컨소시엄은 BIND 9.18 DNS 서버의 새로운 주요 분기의 첫 번째 안정적인 릴리스를 출시했습니다. 브랜치 2에 대한 지원은 연장된 지원 주기의 일환으로 2025년 9.11분기까지 9.16년간 제공됩니다. 2023 브랜치에 대한 지원은 9.19.0월에 종료되고, XNUMX 브랜치에 대한 지원은 XNUMX년 중반에 종료됩니다. BIND의 다음 안정 버전의 기능을 개발하기 위해 실험적인 BIND XNUMX 브랜치가 형성되었습니다.

BIND 9.18.0의 릴리스는 DNS over HTTPS(DoH, DNS over HTTPS) 및 DNS over TLS(DoT, DNS over TLS) 및 XoT(XFR-over-TLS) 메커니즘에 대한 지원 구현으로 주목할 만합니다. DNS 콘텐츠의 안전한 전송을 위해 서버 간 영역(XoT를 통한 전송 및 수신 영역 모두 지원됨) 적절한 설정을 사용하면 명명된 단일 프로세스가 이제 기존 DNS 쿼리뿐만 아니라 DNS-over-HTTPS 및 DNS-over-TLS를 사용하여 전송된 쿼리도 처리할 수 있습니다. DNS-over-TLS에 대한 클라이언트 지원은 "+tls" 플래그가 지정된 경우 TLS를 통해 요청을 보내는 데 사용할 수 있는 dig 유틸리티에 내장되어 있습니다.

DoH에서 사용되는 HTTP/2 프로토콜의 구현은 선택적 어셈블리 종속성으로 포함된 nghttp2 라이브러리의 사용을 기반으로 합니다. DoH 및 DoT에 대한 인증서는 사용자가 제공하거나 시작 시 자동으로 생성될 수 있습니다.

DoH 및 DoT를 사용한 요청 처리는 Listen-on 지시어에 "http" 및 "tls" 옵션을 추가하여 활성화됩니다. 암호화되지 않은 DNS-over-HTTP를 지원하려면 설정에서 "tls none"을 지정해야 합니다. 키는 "tls" 섹션에 정의되어 있습니다. DoT의 경우 기본 네트워크 포트 853, DoH의 경우 443, DNS-over-HTTP의 경우 80은 tls-port, https-port 및 http-port 매개변수를 통해 재정의될 수 있습니다. 예를 들어:

tls local-tls { 키 파일 "/path/to/priv_key.pem"; 인증서 파일 "/path/to/cert_chain.pem"; }; http 로컬-http-서버 { 엔드포인트 { "/dns-query"; }; }; 옵션 { https-포트 443; 수신 대기 포트 443 tls local-tls http myserver {any;}; }

BIND의 DoH 구현 기능 중 하나는 TLS에 대한 암호화 작업을 다른 서버로 이동하는 기능입니다. 이는 TLS 인증서가 다른 시스템(예: 웹 서버가 있는 인프라)에 저장되고 유지 관리되는 조건에서 필요할 수 있습니다. 다른 직원에 의해. 암호화되지 않은 DNS-over-HTTP에 대한 지원은 디버깅을 단순화하고 내부 네트워크의 다른 서버로 전달하기 위한 계층으로 구현됩니다(암호화를 별도의 서버로 이동하기 위해). 원격 서버에서 nginx는 웹사이트에 대해 HTTPS 바인딩이 구성되는 방식과 유사하게 TLS 트래픽을 생성하는 데 사용될 수 있습니다.

또 다른 기능은 확인자에 대한 클라이언트 요청을 처리하는 데 사용할 수 있을 뿐만 아니라 서버 간 통신, 권한 있는 DNS 서버가 영역을 전송할 때, 다른 DNS에서 지원하는 쿼리를 처리할 때 사용할 수 있는 일반 전송으로 DoH를 통합하는 것입니다. 운송.

DoH/DoT로 빌드를 비활성화하거나 암호화를 다른 서버로 이동하여 보완할 수 있는 단점 중에서 코드 베이스의 일반적인 복잡성이 두드러집니다. 내장 HTTP 서버와 TLS 라이브러리가 추가되어 잠재적으로 다음을 포함할 수 있습니다. 취약점을 제거하고 공격을 위한 추가 벡터로 작용합니다. 또한 DoH를 사용하면 트래픽이 증가합니다.

DNS-over-HTTPS는 공급자의 DNS 서버를 통해 요청된 호스트 이름에 대한 정보 유출을 방지하고, MITM 공격 및 DNS 트래픽 스푸핑(예: 공용 Wi-Fi에 연결할 때)에 대응하는 데 유용할 수 있습니다. DNS 수준에서 차단(DNS-over-HTTPS는 DPI 수준에서 구현된 차단을 우회하는 VPN을 대체할 수 없음) 또는 DNS 서버에 직접 액세스할 수 없는 경우(예: 프록시를 통해 작업하는 경우) 작업을 구성하는 데 사용됩니다. 정상적인 상황에서 DNS 요청이 시스템 구성에 정의된 DNS 서버로 직접 전송되는 경우 DNS-over-HTTPS의 경우 호스트 IP 주소를 확인하기 위한 요청이 HTTPS 트래픽에 캡슐화되어 HTTP 서버로 전송됩니다. 확인자는 Web API를 통해 요청을 처리합니다.

"TLS를 통한 DNS"는 표준 DNS 프로토콜(일반적으로 네트워크 포트 853이 사용됨)을 사용한다는 점에서 "DNS over HTTPS"와 다르며, 인증된 TLS/SSL 인증서를 통한 호스트 유효성 검사와 함께 TLS 프로토콜을 사용하여 구성된 암호화된 통신 채널로 래핑됩니다. 인증 기관에 의해. 기존 DNSSEC 표준은 클라이언트와 서버를 인증하는 데에만 암호화를 사용하지만 트래픽을 가로채는 것을 방지하지 않으며 요청의 기밀성을 보장하지 않습니다.

기타 혁신:

• TCP 및 UDP를 통해 요청을 보내고 받을 때 사용되는 버퍼 크기를 설정하기 위해 tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer 및 udp-send-buffer 설정을 추가했습니다. 사용량이 많은 서버에서 수신 버퍼를 늘리면 트래픽이 최고조에 달하는 동안 패킷이 삭제되는 것을 방지하는 데 도움이 되며, 버퍼를 줄이면 오래된 요청으로 인한 메모리 막힘을 제거하는 데 도움이 됩니다.
• RPZ(응답 정책 영역) 전달 작업을 별도로 기록할 수 있는 새로운 로그 범주 "rpz-passthru"가 추가되었습니다.
• response-policy 섹션에 "nsdname-wait-recurse" 옵션이 추가되었습니다. "no"로 설정하면 해당 요청에 대해 캐시에 있는 권한 있는 이름 서버가 발견된 경우에만 RPZ NSDNAME 규칙이 적용됩니다. RPZ NSDNAME 규칙은 무시되지만 정보는 백그라운드에서 검색되어 후속 요청에 적용됩니다.
• HTTPS 및 SVCB 유형의 레코드에 대해 "ADDITIONAL" 섹션 처리가 구현되었습니다.
• SRV 및 PTR 레코드의 업데이트를 제한할 수 있는 사용자 정의 업데이트 정책 규칙 유형(krb5-subdomain-self-rhs 및 ms-subdomain-self-rhs)이 추가되었습니다. 업데이트 정책 블록은 또한 각 유형에 대해 개별적으로 레코드 수에 대한 제한을 설정하는 기능을 추가합니다.
• dig 유틸리티의 출력에 전송 프로토콜(UDP, TCP, TLS, HTTPS) 및 DNS64 접두사에 대한 정보를 추가했습니다. 디버깅 목적을 위해 dig에는 특정 요청 식별자를 지정하는 기능이 추가되었습니다(dig +qid= ).
• OpenSSL 3.0 라이브러리에 대한 지원이 추가되었습니다.
• 2020년 DNS 플래그 데이로 식별된 대규모 DNS 메시지를 처리할 때 IP 조각화 문제를 해결하기 위해 요청에 대한 응답이 없을 때 EDNS 버퍼 크기를 조정하는 코드가 확인자에서 제거되었습니다. 이제 모든 나가는 요청에 대해 EDNS 버퍼 크기가 상수(edns-udp-size)로 설정됩니다.
• 빌드 시스템은 autoconf, automake 및 libtool의 조합을 사용하도록 전환되었습니다.
• "맵" 형식(마스터파일 형식 맵)의 영역 파일에 대한 지원이 중단되었습니다. 이 형식의 사용자는 명명된-compilezone 유틸리티를 사용하여 영역을 원시 형식으로 변환하는 것이 좋습니다.
• 이전 DLZ(동적 로드 가능 영역) 드라이버에 대한 지원이 중단되고 DLZ 모듈로 대체되었습니다.
• Windows 플랫폼에 대한 빌드 및 실행 지원이 중단되었습니다. Windows에 설치할 수 있는 마지막 분기는 BIND 9.16입니다.

출처 : opennet.ru