서울대학교 컴퓨터공학과 권태경 교수님의 "Topics in Computer Networks" 강의를 필기한 내용입니다.
다소 잘못된 내용과 구어적 표현 이 포함되어 있을 수 있습니다.
DNSSEC
#symlink 내용 옮겨짐
- DNS Security Extension, DNSSEC (DNS)
- 0over%20Encryption%20(DNS).md) 기능이 없다
- 서명은
- Integrity: 데이터가 변경되지 않음
- Authentication: 신원인증
- Non-repudiation: 가령 A 의 개인키로 서명이 되어 있는 데이터가 수신되는 경우 A 는 해당 데이터를 보내지 않았다고 구라칠 수가 없음
- DNS 작동 과정
- client 는 example.com 에 IP 를 물어보면
- Local resolver 는 root zone 에 대한 authoritative nameserver 에 이것을 전달해주면 root zone ans 는 TLD 의 ans 를 전달해 주고
- local resolver 가 TLD ans 에 물어보면 examle.com ans 를 알려주고
- 마지막으로 local resolver 가 이 ans 에 물어봐서 client 에게 알려주는 방식으로 작동
- local resolver 는 이 결과는 cache 해서 사용하게 된다
- 근데 이 과정에서 신원을 인증하는 과정이 없기 떄문에 중간에 공격이 가능하다? 그래서 DNSSEC 이 필요하다
- DNSKEY: DNS 레코드를 서명할 개인키에 대한 공개키 → 얘도 record type 중 하나이다
- RRSIG: Resource Record SIGnature: 각 DNS 레코드에 대한 서명
- DS: Key Signing Key 에 대한 Hash (놓침 43”)
- 이거를 생성해서 higher-level zone 에 업로드 한다는 것 같다
- 즉, example.com 의 경우에는 .com TLD 의 DS repository 에 업로드 하는 셈
- 주의) 아래에서도 설명하지만 이 키는 record rrsig 을 생성할 때 사용하는 키가 아니다
- RRSET: 하나의 도메인에 대해 같은 타입의 다른 IP 레코드들이 당연히 존재할 수 있고, 각 레코드를 서명한게 RRSIG, 이것들을 모두 합친게 RRSET
- 이런식으로 작동한다는 듯
- Zone 의 Nameserver 는 키쌍을 생성해서 DNSKEY 에 업로드
- Zone 의 record 들에 대해 공개키로 RRSIG 를 생성
- ??? 왜 공개키로 서명하는지는 알수가 없음
sign(RRSIG_RDATA, []RRSIG)로 특정 도메인에 대한 signature 를 생성해 낸다
- Zone Signing Key: A 레코드 → A RRSIG 서명 (DNSKEY record 이외의 모든 record 를 서명)
- 이 키가 DNSKEY record 의 내용에 들어가게 되는 것인가
- 이것은 변경되더라도 상위 zone 에 알릴 필요가 없음
- Key Signing Key: DNSKEY → DNSKEY RRSIG 서명
- 이것은 DS record 로 상위 zone 으로 올라가기 때문에 변경되었을 경우 상위 zone 에 알려야 함
- Chain of trust:
- example.com 는 ZNK(ex)- 로 서명되고 아 적을시간이 없노
- 뭐 이런식으로 각 record 가 root 부터 시작되는 인증 chain 을 가지기 때문에 악성 변조가 불가능 하다
- KSK 가 변경되면 record 들을 전부 이 키로 서명하고 DS 레코드를 생성해서 상위 zone 에 알림??
- DNSSEC validation 할때 이 러한 chain of trust 를 올라가면서 검증하게 된다고 한다
- Limitation
- sig validation overhead
- local dns resolver 와 client 사이에는 여전히 보호되지 않기 때문에 공격할 수가 있다
- 이걸 막기 위해 DoH (HTTPS), DoT (TLS) 등의 방법을 사용하기도 한다
- 그래서 Local resolver 와 authoritative nameserver 사이에서는 DNSSEC 을 이용하고 local resolver 와 client 사이에는 DoH, Dot 를 이용한다고 한다ㅏ
- ns record 의 경우에는 tld 에 저장하지 않는다?? 1’10”
여기서부터는 강의 9 후반부 내용
- A 레코드에 대한 서명은 RRSIG 레코드로 들어가고 이 서명을 만들기 위해 사용된 개인키의 공개키는 DNSKEY 레코드로 들어간다
- 상위 zone 에 대한 link 관계는 현재 zone 의 DNSKEY 를 hash 한 값을 담고 있는 DS 레코드가 상위 zone 에 포함되며 이루어진다
- 근데 이렇게 하면 DNSKEY 를 변경하면 상위 zone 의 DS 가 변경되므로 변경이 용이하지 않다
- 따라서 나온 것이 KSK 이다
- 위에서 zone record 를 서명하던 DNSKEY 를 ZSK (Zone Signing Key) 라고 하고
- 추가적으로 Key Signing Key 가 추가되어서 이놈으로 서명한 키를 ZSK (Zone Signing Key) 라고 하고 이것을 이용해 zone record sign 을 하게 된다
- KSK 와 ZSK 모두 DNSKEY 레코드로 저장된다
- 다만 상위 zone 에는 KSK 의 hash 가 DS 레코드로 들어간다
- KSK 가 변경되면 ZSK 도 새로 서명되고 이것으로 생성된 RRSIG 들 (RRSET) 도 전부 새로 서명된다?
- DNS Header 에는 authentic data (AD) 가 있는데 resolver 가 DNSSEC 을 검증했다는 것을 의미
- CD 는 DNSSEC 으로 검증되지 않았다는 의미
- client 와 local resolver 사이는 encrypted 되지 않았지롱
- DNSSEC 은 resolver ↔ authoritative 간의 보안
- DoT, DoH 는 resolver ↔ client 간의 보안
- DNSSEC 의 문제
- local 이 tld 에 연락하면 DS 와 RRSIG 을 준다
- 그리고 추가적으로 auth 의 NS 와 A 를 준다
- 이때 이 NS 와 A 는 tld 에 저장되어 있긴 하지만 auth 의 소속이기 때문에 RRSIG 이 생성되지 않는다고 한다
- 결국에는 이 NS 와 GLUE 는 보호되지 않기 때문에 여기서 보안 취약점이 발생할 수 있다.