DNSSEC가 유용합니까?

DNSSEC가 유용합니까?

DNSSEC는 DNS 결과가 무엇이든 그것이 진짜인지 확인하기 위한 목적으로 영역 데이터를 검증하고 인증합니다.

  1. DNS 확인자가 권한 있는 네임서버가 변조되지 않은 올바른 데이터를 전송했음을 검증하는 경우에도 DNS 확인자가 변조된 DNS 응답을 DNS 클라이언트에 보내는 것을 방지하려면 어떻게 해야 합니까?

  2. DNS 확인자가 DNSSEC를 지원하지 않는 경우에도 해당 영역에 대해 DNSSEC가 활성화된 권한 있는 네임서버에 DNS 쿼리를 보낼 수 있습니까?

감사합니다

답변1

DNSSEC가 유용합니까?

방어하려는 항목에 대해 설명을 시작할 때까지 해당 문장에 "DNSSEC" 대신 입력한 단어에 대해 답변할 수 없습니다.

자신을 방어하려는 위험/취약성/위협 목록이 있으면 어떤 솔루션이 존재하는지 확인하고 각 솔루션이 얼마나 유용한지 결정할 수 있습니다.

DNSSEC일부 DNS 문제에는 유용하지만 모든 문제에는 유용하지 않습니다. 이는 새로운 문제(서명 및 키의 지속적인 유지 관리)뿐만 아니라 새로운 기능( NXDOMAINDNSSEC에서 적절하게 검증된 경우 아래의 모든 항목에 대한 공격적인 캐싱)도 발생합니다.

DNS 확인자가 권한 있는 네임서버가 변조되지 않은 올바른 데이터를 전송했음을 검증하더라도 DNS 확인자가 변조된 DNS 응답을 DNS 클라이언트에 보내는 것을 어떻게 방지할 수 있습니까?

이는 오늘날과 별반 다르지 않습니다. 공용 DNS 확인자( 예: 8.8.8.8, 1.1.1.1, 9.9.9.9등)를 사용하는 경우 당연히 가비지 데이터를 보낼 위험이 있습니다. 그것은 절충안입니다. DoH/DoT는 콘텐츠 자체가 아닌 사용자와 이 확인자 간의 콘텐츠 전송만 보호하므로 여기서는 아무 것도 해결하지 않습니다. 쿼리를 수행하는 도메인 이름이 DNSSEC로 보호되는 한 DNSSEC로 "보호"되는 콘텐츠는 무엇입니까?(질문에서 잊어버린 부분 중 하나이며 실제로 DNSSEC를 어렵게 만드는 부분: 도메인 이름 소유자가 이를 활성화해야 함)그리고DNS 확인자는 새 서명을 사용하고 유효성 검사를 수행해야 합니다. 이 2개 변수 방정식의 한 부분이 없으면 DNSSEC는 작동하지 않기 때문에 유용하지 않습니다.)

따라서 질문은 어떤 재귀 네임서버를 사용할지, 어디에서 실행해야 하는지에 관한 것입니다. 물론 제어를 최대화하려면 리졸버가 귀하의 컴퓨터에서 실행되기를 원합니다. 외부 리소스와 DNS 확인자를 계속 사용할 수 있지만 최종 DNSSEC 확인은 다른 이름 서버가 아닌 사용자의 이름 서버에서 이루어져야 합니다. 물론 이것은 모든 DNSSEC 작업을 "무료"로 수행하는 다른 리소스에 의존하는 것보다 더 많은 작업입니다.

DNS 해석기가 DNSSEC를 지원하지 않는 경우에도 해당 영역에 대해 DNSSEC가 설정된 권한 있는 네임서버에 DNS 쿼리를 보낼 수 있습니까?

예. DNSSEC 데이터를 갖고 싶어하는 확인자는 요청에서 "DO" 플래그를 전환해야 합니다.

문서 에서 dig:

        +[no]dnssec
         This option requests that DNSSEC records be sent by setting the DNSSEC OK (DO) bit in the OPT record in the additional section of the query.

그렇게 볼 수 있습니다:

$ dig +dnssec example.com

; <<>> DiG 9.16.18 <<>> +dnssec example.com
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40492
;; flags: rd ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
                           ^^

또는 RFC 4035의 §3.2.1에서:

3.2.1. DO 비트

보안 인식 재귀 이름 서버의 확인자 측은 이름 서버 측에서 수신한 시작 요청의 DO 비트 상태에 관계없이 요청을 보낼 때 DO 비트를 설정해야 합니다. 시작 쿼리의 DO 비트가 설정되지 않은 경우 이름 서버 측은 응답에서 모든 인증 DNSSEC RR을 제거해야 하지만 시작 쿼리가 명시적으로 요청한 DNSSEC RR 유형을 제거해서는 안 됩니다.

DNS 클라이언트(재귀 확인자)가 이 작업을 수행하고 쿼리 중인 권한 있는 네임서버에 DNSSEC가 활성화되어 있으면(따라서 // RRSIG영역 의 레코드 유형) 확인자는 해당 레코드를 가져온 다음 DNSSEC 유효성 검사를 수행할 수 있습니다.NSECNSEC3

CD해석기가 아닌 DNS 스텁/클라이언트가 재귀 해석기에 쿼리할 때 다음과 같이 정의된 플래그를 사용할 수 있습니다 .

        +[no]cdflag
        This option sets [or does not set] the CD (checking disabled) bit in the query. This requests the server to not perform DNSSEC validation of responses.

(이중 부정 가능성에 주의하세요)

클라이언트가 를 사용하지 않는 경우 CDDNSSEC 유효성 검사는 비활성화되지 않으므로 활성화되고 제거 서버는 최종 답변을 제공하거나(DNSSEC가 레코드에 대해 활성화되고 유효성 검사가 성공한 경우) NXDOMAINDNSSEC가 응답하는지 응답합니다. 검증에 실패했습니다. 플래그는 AD모든 레코드가 안전한 것으로 검증되었음을 나타내기 위해 설정됩니다(쿼리가 재귀 네임서버에서 오는 경우 IANA 루트의 전체 DNSSEC 체인이 필요하므로 해당 플래그는 신뢰할 수 있는 네임서버에서 존재할 수 없습니다). 주어진 기록을 검증하기 위해)

답변2

  1. 이상적으로는 클라이언트에서 로컬로 유효성을 검사하거나(현재 흔하지는 않지만 전례가 없는 경우임) 클라이언트와 신뢰할 수 있는 유효성 검사 확인자 사이의 격차를 해소할 수 있는 보안 네트워크 경로를 사용하는 것이 좋습니다.
    이 보안 네트워크 경로는 DNS-over-TLS, DNS-over-HTTPS, DNSCrypt 또는 어느 정도 로컬 네트워크(신뢰 수준은 낮지만 공격 시나리오의 하위 집합에는 여전히 유용함)와 같은 것을 의미할 수 있습니다.

관련 정보