4.5.2. DNSSEC 이해

인터넷 연결을 위해 점점 더 많은 웹 사이트에서 HTTPS 를 사용하여 안전하게 연결할 수 있는 기능을 제공합니다. 그러나 HTTPS 웹 서버에 연결하기 전에 IP 주소를 직접 입력하지 않는 한 DNS 조회를 수행해야 합니다. 이러한 DNS 조회는 안전하지 않게 수행되며 인증 부족으로 인해 중간자 공격을 받습니다. 즉, DNS 클라이언트는 지정된 DNS 이름 서버에서 제공하는 응답이 정품이며 로 변경되지 않았음을 확신할 수 없습니다. 더 중요한 것은 재귀적 이름 서버가 다른 이름 서버에서 얻는 레코드가 정품인지 확인할 수 없다는 것입니다. DNS 프로토콜은 클라이언트의 메시지 가로채기(man-in-the-middle) 공격의 대상이 되지 않도록 하는 메커니즘을 제공하지 않았습니다. DNSSEC는 DNS 를 사용하여 도메인 이름을 확인할 때 인증 및 무결성 검사 부족을 해결하기 위해 도입되었습니다. 이는 기밀성의 문제를 다루지 않습니다.

DNSSEC 정보를 게시하려면 DNS 확인자가 계층적 신뢰 체인을 구축할 수 있도록 하는 방법과 같이 DNS 리소스 레코드에 디지털 서명과 공개 키를 배포해야 합니다. 모든 DNS 리소스 레코드에 대한 디지털 서명이 생성되어 영역에 디지털 서명 리소스 레코드(RRSIG)로 추가됩니다. 영역의 공개 키는 DNSKEY 리소스 레코드로 추가됩니다. 계층적 체인을 빌드하기 위해 DNSKEY의 해시는 상위 영역에 서명(DS) 리소스 레코드 Delegation 으로 게시됩니다. 존재하지 않는 것의 증거를 용이하게 하기 위해, NextSEC (NSEC) 및 NSEC3 리소스 레코드가 사용됩니다. DNSSEC 서명된 영역에서 각 리소스 레코드 세트 (RRset)에 해당 RRSIG 리소스 레코드가 있습니다. 하위 영역(NS 및 글루 레코드)에 대한 위임에 사용되는 레코드는 서명되지 않습니다. 이러한 레코드는 하위 영역에 표시되고 여기에 서명됩니다.

DNSSEC 정보를 처리하는 작업은 루트 영역 공개 키로 구성된 확인자에 의해 수행됩니다. 이 키를 사용하여 확인자에서 루트 영역에 사용된 서명을 확인할 수 있습니다. 예를 들어 루트 영역은 .com 의 DS 레코드에 서명했습니다. 루트 영역은 .com 이름 서버에 대한 NS 및 glue 레코드도 제공합니다. 확인자는 이 위임을 따르고 이러한 위임된 이름 서버를 사용하여 .com 의 DNSKEY 레코드에 대한 쿼리를 따릅니다. 가져온 DNSKEY 레코드의 해시는 루트 영역의 DS 레코드와 일치해야 합니다. 그렇다면 확인자는 .com 에 대해 가져온 DNSKEY를 신뢰합니다. .com 영역에서 RRSIG 레코드는 .com DNSKEY에 의해 생성됩니다. 이 프로세스는 .com 내의 위임(예: redhat .com )에 대해 비슷하게 반복됩니다. 이 방법을 사용하면 정상적인 작업 중에 전 세계에서 많은 DNS KEY를 수집하는 동안 하나의 루트 키로 DNS 확인자만 구성하면 됩니다. 암호화 검사에 실패하면 확인자는 SERVFAIL을 애플리케이션에 반환합니다.

DNSSEC는 DNSSEC를 지원하지 않는 애플리케이션과 완전히 보이지 않는 방식으로 설계되었습니다. 비DNSSEC 애플리케이션이 DNSSEC 가능 리졸버를 쿼리하는 경우 RRSIG와 같은 이러한 새로운 리소스 레코드 유형 없이 응답을 받습니다. 그러나 DNSSEC 가능 확인자는 여전히 모든 암호화 검사를 수행하고 악성 DNS 응답을 탐지하는 경우 애플리케이션에 SERVFAIL 오류를 반환합니다. DNSSEC는 DNS 서버(인증 및 재귀) 간 데이터의 무결성을 보호하며, 애플리케이션과 확인자 간에 보안을 제공하지 않습니다. 따라서 애플리케이션에 해당 확인자에게 안전한 전송이 제공되는 것이 중요합니다. 가장 쉬운 방법은 localhost 에서 DNSSEC 가능 확인자를 실행하고 /etc/resolv.conf 에서 127.0.0.1 을 사용하는 것입니다. 또는 원격 DNS 서버에 대한 VPN 연결을 사용할 수 있습니다.

Wi-Fi 핫스팟 또는 VPN “은 DNS에 의존하는 경우”: 유용한 포털은 Wi-Fi 서비스에 대한 인증(또는 결제)에 필요한 페이지로 사용자를 리디렉션하기 위해 DNS 를 납치하는 경향이 있습니다. VPN에 연결하는 사용자는 회사 네트워크 외부에 존재하지 않는 리소스를 찾기 위해 “내부 전용” DNS 서버를 사용해야 하는 경우가 많습니다. 이를 위해서는 소프트웨어의 추가 처리가 필요합니다. 예를 들어 dnssec-trigger 를 사용하여 Hotspot이 DNS 쿼리를 가로채고 unbound 가 프록시 이름 서버로 작동하여 DNSSEC 쿼리를 처리할 수 있는지 감지할 수 있습니다.

DNSSEC 가능 재귀 확인을 배포하려면 BIND 또는 unbound 를 사용할 수 있습니다. 기본적으로 DNSSEC를 활성화하고 DNSSEC 루트 키를 사용하여 구성됩니다. 서버에서 DNSSEC를 활성화하려면 로컬 사용자가 dnssec-trigger 를 사용할 때 Hotspots에 필요한 DNSSEC 재정의를 동적으로 재구성할 수 있고 Libreswan 을 사용할 때 VPN과 같은 모바일 장치에서 unbound 를 사용하는 것이 좋습니다. 바인딩되지 않은 데몬에서는 서버와 모바일 장치 모두에 유용할 수 있는 etc/ EgressIP/*.d/ 디렉터리에 나열된 DNSSEC 예외의 배포를 추가로 지원합니다.