히포

1. cloudflare public dns

1.1. cloudflare dns 종류

• 기본 DNS : 1.1.1.1
• 보조 DNS : 1.0.0.1

1.2. flush cache 참고 URL

• Cloudflare DNS cache purge 연결 URL : https://1.1.1.1/purge-cache/

2. google public dns

2.1. cloudflare dns 종류

• 기본 DNS : 8.8.8.8
• 보조 DNS : 8.8.4.4

2.2. flush cache 참고 URL

• Google DNS cache purge 연결 URL : https://developers.google.com/speed/public-dns/cache

참고 자료

• https://www.phpschool.com/gnuboard4/bbs/board.php?bo_table=tipntech&wr_id=82361

• 기본 Bind DNS는 localhost에서만 query가 가능
• 외부에서 query를 할 수 있도록 하려면 설정을 변경 필요 → 외부에서의 query하기 위해서는 recursion 대한 이해가 필요
• DNS는 자신에게 설정 되어 있는 도메인 외의 질의 요청이 오면, 해당 도메인이 설정 되어 있는 name server에게 요청을 보내여, 응답 받은 내용으로 응답
• name server에 등록이 되어 있지 않은 도메인에 대한 질의가 들어오더라도 찾아서 응답을 해 주는 것으로 caching name server 역할을 함
• recursion 정책 설정이 완료가 되면, Bind DNS는 기본적으로 정책에 따라 응답 가능

KLDP.org의 name server에 google.com의 A record를 질의 하는 경우

• KLDP.org의 NS에 google의 A record를 질의

  $ dig @ns.kldp.org google.com
  
  ; <<>> DiG 9.9.4-geoip-1.4-RedHat-9.9.4-38.an3.1 <<>> google.com @ns.kldp.org
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53082
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5
  
  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4096
  ;; QUESTION SECTION:
  ;google.com.                    IN      A
  
  ;; ANSWER SECTION:
  google.com.             300     IN      A       172.217.24.142
  
  ;; AUTHORITY SECTION:
  google.com.             80178   IN      NS      ns2.google.com.
  google.com.             80178   IN      NS      ns1.google.com.
  google.com.             80178   IN      NS      ns4.google.com.
  google.com.             80178   IN      NS      ns3.google.com.
  
  ;; ADDITIONAL SECTION:
  ns2.google.com.         80178   IN      A       216.239.34.10
  ns1.google.com.         80178   IN      A       216.239.32.10
  ns3.google.com.         80178   IN      A       216.239.36.10
  ns4.google.com.         80178   IN      A       216.239.38.10
  
  ;; Query time: 144 msec
  ;; SERVER: 14.0.82.80#53(14.0.82.80)
  ;; WHEN: 토  2월 11 03:30:45 KST 2017
  ;; MSG SIZE  rcvd: 191

recursion은 caching name server 역할을 제한 하는 기능

• recursion 옵션이 no로 설정이 되어 있다면 설정이 되어 있는 도메인 외의 요청에 대해서는 권한이 없다는 응답함

• 설정이 되어 있는 도메인에 대해서만 응답만함

  $ dig google.com @ns.kldp.org
  
  ; <<>> DiG 9.10.3-P4-Ubuntu <<>> google.com @ns.kldp.org
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 38503
  ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
  ;; WARNING: recursion requested but not available
  
  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 4096
  ;; QUESTION SECTION:
  ;google.com.                    IN      A
  
  ;; Query time: 7 msec
  ;; SERVER: 14.0.82.80#53(14.0.82.80)
  ;; WHEN: Sat Feb 11 03:29:33 KST 2017
  ;; MSG SIZE  rcvd: 39

• recursion 기능이 public하게 설정이 되어 있을 경우, DNS cache poisoning 공격을 발생시킬 수 있음 → 근래의 DNS 설정시에는 recursion 기능을 off 시키는 것을 권장

• 무조건 recursion을 off 시킬 수 없는 환경에 있는 경우를 대비하여, recursion 설정 정책에 학습 필요

recursion 설정 정책

1. 내 도메인 설정을 위한 DNS와 내부에서 사용할 caching name server가 따로 존재할 경우

• 외부에서의 query를 허가하고, recursion을 off 를 시킴
• /etc/named.conf의 options block에서 아래의 설정을 변경 또는 추가 필요

  options {
    ...
    recursion no;
    allow-query { any; };
    ...
  };

2. caching name server가 따로 존재하지 않을 경우

• 외부에서의 query를 허가하고, recursion을 할 수 있는 대역을 allow-recursion 옵션을 이용하여 설정

• allow-recursion에 사용할 RecursionAllow ACL group을 /etc/named.acl.conf에 생성

  acl LocalAllow {
    127.0.0.1;
    localhost;
  };
  
  acl RecursionAllow {
    192.168.0.0/16;
    111.112.113.128/25;
  };

• named.conf의 options block에서 다음의 설정을 변경 또는 추가

  options {
    ...
    recursion yes;
    allow-query { any; };
    allow-recursion { LocalAllow; RecursionAllow; };
    ...
  };

3. 내부 전용 caching name server로 사용할 경우

• 내부에서의 query만 허가하고, recursion을 public 하게 설정
• 먼저 /etc/named.acl.conf의 LocalAllow acl group에 query를 할 내부 대역을 추가

  acl LocalAllow {
    127.0.0.1;
    localhost;
    192.168.0.0/16;
  };

• named.conf의 options block에서 다음의 설정을 변경 또는 추가

  options {
    ...
    recursion yes;
    allow-query { LocalAllow; };
    ...
  };

4. public caching name server로 사용할 경우

• 외부에서의 query와 recursion을 모두 허가
• 이DNS 공격을 위하여 RPZ(Response Policy Zone)과 같이 공격을 방어하기 위한 기법들이 필요
• named.conf의 options block에서 다음의 설정을 변경 또는 추가

  options {
    ...
    recursion yes;
    allow-query { any; };
    ...
  };

참고 자료

• https://joungkyun.gitbook.io/annyung-3-user-guide/chapter5/chapter5-1-basic

• EDNS(Extension Mechanisms for DNS)는 인터넷 엔지니어링 커뮤니티에서 프로토콜의 기능을 향상시키기에는 너무 제한적이라고 판단한 크기 제한이 있는 Domain Name System(DNS) 프로토콜의 여러 매개변수 크기를 확장하기 위한 개발
• 1999년 인터넷 엔지니어링 태스크 포스에 의해 EDNS0이라고도 알려진 RFC 2671로 발표
• 2013년에 RFC 6891에 의해 약어가 EDNS(0)으로 약간 변경되어 업데이트
• RFC 참고 자료 : https://www.ietf.org/rfc/rfc2671.txt

1. EDNS Motivation

• Domain Name System(DNS)은 1980년대 초에 처음 개발 → DNS 초기 개발된 설정 제한이 새로운 기능을 추가하는 데 큰 장애물
• 기본 DNS 프로토콜에서는 사용할 수 있는 여러 플래그 필드(several flags fields), 리턴 코드(return codes) 및 레이블 유형(label types)의 크기 제한으로 인해 일부 바람직한 기능을 지원하지 못함
• UDP로 전송되는 DNS 메시지는 인터넷 프로토콜(IP) 및 전송 계층 헤더(transport layer headers)를 고려하지 않고 512바이트로 제한
• TCP(전송 제어 프로토콜)를 사용하는 가상 회로 전송(virtual circuit transport)에 의존하면 오버헤드가 크게 증가
• 1999년에 폴 빅시는 새로운 플래그(new flags)와 응답 코드(response codes)를 허용하고 이전 구현과 역호환되는 프레임워크에서 더 긴 응답을 지원하기 위해 DNS 확장을 제안

2. EDNS 매키니즘(Mechanism)

• DNS 헤더에 새로운 플래그를 추가할 수 없기 때문에 EDNS는 DNS 메시지의 "추가 데이터(additional data)" 섹션에 포함된 pseudo-Resource Records ("pseudo-RR"s)의 형태로 DNS 메시지에 정보를 추가
• 섹션은 요청과 응답 모두에 존재
• EDNS는 단일 의사 RR 유형(single pseudo-RR type)을 도입 OPT.
• pseudo-RRs인 OPT 유형 RR(OPT type RRs)은 어떤 영역 파일에도 나타나지 않으며, DNS 참여자(participants)가 조작한 메시지에만 존재

• 이전 DNS 응답자(responders)는 요청에 알 수 없는 OPT 유형의 RR(OPT type RRs)을 무시하고 최신 DNS 응답자(responders)는 요청에 OPT가 없는 한 응답에 OPT를 포함하지 않음
• 요청에 OPT가 있다면 최신 요청자(requester)가 응답에서 OPT로 무엇을 해야 하는지 알고 있다는 것을 의미

• OPT 의사 레코드(pseudo-record)는 최대 16개의 플래그(flags)를 위한 공간을 제공하며 응답 코드(response code)를 위한 공간을 확장함
• UDP 패킷의 전체 크기(The overall size of the UDP packet)와 버전 번호(현재 0)가 OPT 레코드에 포함
• 가변 길이 데이터 필드(variable length data field)를 사용하면 향후 버전의 프로토콜에 추가 정보를 등록할 수 있음
• DNS 프로토콜은 DNS 패킷의 처음 두 비트로 정의되는 두 가지 레이블 유형 제공(RFC 1035)→ 00(standard label)과 11(compressed label)
• EDNS는 확장 레이블로 레이블 유형 01을 도입
• 첫 번째 바이트의 하위 6비트는 최대 63개의 새로운 확장 레이블을 정의하는 데 사용될 수 있음

2.1. EDNS 사용하지 않는 경우(Without EDNS0 Client Subnet Option)

2.2. EDNS 사용하는 경우(With EDNS0 Client Subnet Option)

3. EDNS Example

• dig 명령으로 표시되는 OPT 의사 레코드의 예
  • EDNS: version: 0 → EDNS0을 완전히 준수함을 표시
  • flags: do → DNSSEC OK가 설정되었음을 표시
  • flags: do → DNSSEC를 완전히 준수함을 표시

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

4. EDNS Applications

• EDNS는 DNSSEC(DNS 보안 확장;DNS Security Extensions)를 구현하는 데 필수
• EDNS는 resolvers에서 name servers로 클라이언트의 지리적 위치에 대한 일반 정보를 EDNS Client Subnet(ECS) 옵션의 형태로 전송하는 데 사용
• EDNS를 사용하여 DNS message에 얼마나 많은 패딩이 있어야 하는지 설정하고, TCP 연결을 얼마나 오래 유지해야 하는지 표시하는 제안

5. EDNS Issues

• 방화벽은 최대 DNS 메시지 길이를 512바이트로 가정하고 더 긴 DNS 패킷을 차단하기 때문에 실제로 방화벽을 통과하는 EDNS를 사용할 때 어려움이 발생할 수 있음
• EDNS는 상대적으로 작은 요청 패킷에 비해 매우 큰 응답 패킷을 용이하게 하기 때문에 EDNS의 도입으로 반사 서비스 거부 공격(reflected denial-of-service attack)의 일종인 DNS 증폭 공격(DNS amplification attack)이 가능해졌음
• IETF DNS 확장 작업 그룹(dnsext)은 EDNS0의 개선 작업을 마쳤으며, 이는 RFC 6891로 게시

참고 자료

• https://en.wikipedia.org/wiki/Extension_mechanisms_for_DNS
• https://docs.netscaler.com/en-us/citrix-adc/current-release/global-server-load-balancing/how-to/configure-edns0-client-subnet.html

1. 도메인의 TTL

• TTL은 Time To Live의 약자로 도메인을 캐싱하고 있는 시간을 의미
• 누군가 A라는 도메인에 대해 질의를 했다면 응답을 준 DNS 서버에서 해당 도메인에 대해 TTL 시간 동안 캐싱을 함
• 같은 도메인을 여러 사람이 질의할 수 있기 때문에 한 번 질의한 내용을 캐싱하고 있는 게 불필요한 동작을 방지 가능

• www.kakao.com에 대한 도메인 질의 결과 → 리눅스에서는 간단하게 dig 명령으로 TTL 시간 확인 가능
  1. TTL 시간을 의미(1번 항목)
     • 질의한 도메인에 대해 DNS 서버가 해당 도메인을 캐싱하는 시간
     • 531초 동안 캐싱하고 있을 거라는 것을 알 수 있음
       
       
  2. www.kakao.com에 대한 도메인 질의 결과를 내려준 서버를 의미(2번 항목)
     • 모든 DNS 서버가 모든 도메인에 대해 알고 있을 수 없기 때문에 본인이 관리하는 도메인이 아니라면 상위 DNS 서버에 질의함
     • www.kakao.com 도메인을 관리하는 서버를 찾게 되고, www.kakao.com 도메인을 관리하는 서버가 ns2.iwilab.com임을 의미
       
       
  3. 현재 자신이 사용하고 있는 DNS 서버를 의미(3번 항목)
     • 도메인 질의 과정을 유추해 보면 www.kakao.com에 대한 도메인 질의를 10.20.30.60에 먼저 질의
     • 10.20.30.60은 자신이 관리하는 도메인이 아니기 때문에 상위 DNS 서버에 요청해서 해당 도메인을 관리하는 DNS 서버를 찾게 되고 결과적으로 ns2.iwilab.com 서버에 질의해서 결과를 받아오게 됨
       

       

2. TTL이 0이 되면?

• TTL이 0이 되면, DNS 서버는 도메인에 대한 질의 요청에 대해 사용자에게 응답해 주었지만, TTL이 0이 되기 때문에 캐싱하지 않고 바로 버림
• 다른 사용자가 똑같은 도메인을 요청했을 경우, 상위 DNS 서버를 찾아서 해당 도메인에 대한 질의 결과를 받아오는 작업을 진행
• TTL이 0인 도메인이 많은 경우, 상위 DNS로의 요청이 많아지고 전체적으로 도메인 질의 요청을 처리하는 데에 많은 시간이 소요되게 됨
• 하지만 TTL이 0이면, 매 요청마다 해당 도메인을 관리하고 있는 DNS 서버를 직접 찾아서 질의하기 때문에 최신의 정확한 정보를 가지게 됨
• TTL이 0이면, 도메인 요청에 걸리는 시간은 늘어나지만 도메인 변경 등에 대한 대응은 정확하고 빠르게 할 수 있다는 장점이 있음

참고 자료

• https://tech.kakao.com/2016/03/18/redis-ha-dns/

• DNS 쿼리 및 응답은 인터넷 작동 방식의 기본 → 웹사이트를 방문할 때, 브라우저에 URL을 입력
• DNS 쿼리를 보냄 → DNS는 사람이 읽을 수 있는 도메인 이름(예: hippo.com)을 인터넷 프로토콜(IP) 주소(예: 192.168.0.100)로 변환
• 웹사이트에 성공적으로 접속했는지 여부에 관계없이 받는 모든 응답에는 코드가 포함
• 거의 모든 DNS 쿼리와 함께 반환되는 가장 일반적인 네 가지 쿼리
  1. NOERROR
  2. NXDOMAIN
  3. SERVFAIL
  4. REFUSED

• DNS 쿼리에 문제가 있는 경우 응답 데이터를 통해 보안 위반 문제를 더 빨리 해결하거나 식별하는 데 도움이 될 수 있음
• DNS 반환 코드에 대해 간략하게 설명
  

  DNS 응답 코드	설명
  NOERROR	- DNS 쿼리가 성공적으로 완료
  NXDOMAIN	- 쿼리한 도메인 이름이 존재하지 않기 때문에 DNS 쿼리가 실패
  SERVFAIL	- 답변을 제공할 수 없기 때문에 DNS 쿼리가 실패
  REFUSED	- 서버가 정책으로 인해 응답을 거부했기 때문에 DNS 쿼리가 실패

• DNS 응답 코드 개요
  • 공식적으로 DNS의 응답 코드 전체 목록은 24개가 넘음
  • DNS 쿼리는 약 84%의 시간을 성공 → NOERROR 코드를 생성
  • DNS 쿼리의 약 16%가 실패 → 세 가지 공통 코드 중 하나가 발생(NXDOMAIN, SERVFAIL, REFUSED)

1. DNS 응답 코드 NOERROR

1.1. 가장 일반적인 응답

• 약 80~90%에서 NOERROR는 네트워크 로그에 표시되는 응답 코드
• NOERROR는 DNS 쿼리가 유효한 응답을 받았다는 의미
• NOERROR는 모든 것이 정상이며 쿼리에 문제가 없었음을 나타내는 방법
• 사용자가 hippo.com 도메인으로 요청을 하였으며, 리졸버와 DNS 서버가 hippo.com 도메인으로 정상 이동

1.2. NOERROR 응답 코드가 항상 완벽하다는 의미 X

• NOERROR 응답이 반환되었다고 하여, 네트워크의 사용자가 특별히 요청한 웹사이트로 이동했다는 의미는 아님
• 사용자가 hippo.com 도메인으로 요청
• hippo.com 도메인으로 요청을 보냈을 경우 test.com 도메인으로 리다이렉션되도록 설정
• 사용자가 hippo.com 도메인으로 이동하면, 성공적인 NOERROR 응답 코드를 받음
• 성공적으로 NOERROR 응답코드가 출력되면서, 사용자가 test.com 도메인으로 이동
• hippo.com 도메인 요청하였을 때, test.com 도메인 서버에 장애가 발생하거나 액세스 권한이 없다고 알려도 DNS 로그에서는 NOERROR 응답

2. DNS 응답 코드 NXDOMAIN

• 수신된 응답 코드의 나머지 10~15%는 대부분 NXDOMAIN
• 서버가 되돌려 보내는 NXDOMAIN 응답의 의미는 "이 도메인에 대해 쿼리했지만 해당 도메인이 존재하지 않거나 존재하는지 모르겠습니다."
• NXDOMAIN이 발생했다는 의미는 쿼리가 실패를 의미
• NXDOMAIN 응답 코드가 네트워크에 의미하는 바에 대한 전체 블로그 게시물이 있지만 여기에서 몇 가지 기본 사항을 다룸

2.1. NXDOMAIN에 대한 의미

1. 브라우저에서 도메인 이름을 잘못 입력하는 동안 사용자 오류가 발생
2. 보안 제어가 사용자가 접근하려는 사이트를 차단
3. 일부 오래된 코드가 더 이상 존재하지 않는 웹사이트에 연결
4. 잘못 구성된 응용 프로그램이 철자가 잘못된 도메인을 쿼리
5. 도메인이 손상되었거나 맬웨어가 존재한다는 표시

2.2. 악성코드 감염의 징후

• 일반적으로 맬웨어는 코드에 하나 이상의 도메인에 접근하는 경우가 있음
• 악성 코드에 감염된 장치가 현재 차단된 도메인을 확인할 수 없는 경우 NXDOMAIN 응답이 발생

3. DNS 응답 코드 SERVFAIL

• SERVFAIL 응답은 약 1%
• NXDOMAIN이 도메인이 존재하지 않는다는 것을 알려주는 DNS 서버라면, SERVFAIL은 "당신에게 그 쿼리에 대한 답을 줄 수 없다"라고 말하는 DNS 서버
• DNS 서버에 기술적인 문제로 인해 발생 가능 → 방화벽이나 침입 방지 시스템과 같은 네트워크의 보안 제어가 사용자가 해당 도메인으로 이동하는 것을 차단하고 있음을 의미
• NXDOMAIN과 마찬가지로 과도한 SERVFAIL 응답은 추가 조사가 필요
• SERVFAIL 응답을 받는 도메인도 악의적인 활동에 대해 조사 필요

4. DNS 응답 코드 REFUSED

• REFUSED는 DNS 이름 서버가 정책상의 이유로 작업 수행을 거부할 때 발생 → 특정 장치가 네임서버를 악용하는 경우 차단
• 특정 작업이 금지될 수 있음
  1. 영역 전송은 로드 밸런싱 또는 백업을 위해 여러 DNS 서버에 DNS 구성 정보를 복제하는 방법
  2. 일반적으로 권한이 있는 사람만 영역 이전을 완료 가능
  3. 일반 사용자가 DNS 구성 정보를 복제하려고 할 때, 권한이 없으면, REFUSED 응답 코드가 발생

1. DNS TXT 레코드란?

• DNS TXT 레코드를 사용하면 도메인 관리자가 도메인 네임 시스템(DNS)에 텍스트를 입력할 수 있음
• DNS TXT 레코드는 원래 사람이 읽을 수 있는 메모를 위한 장소 → 기계가 읽을 수 있는 일부 데이터를 TXT 레코드에 넣을 수 있음
• 하나의 도메인에 여러 TXT 레코드가 있을 수 있음

• TXT 레코드의 예
  

  

• 오늘날 DNS TXT 레코드의 가장 중요한 두 가지 용도 → TXT 레코드는 원래 아래 용도로 설계 X
  1. 이메일 스팸 방지
  2. 도메인 소유권 확인

2. DNS TXT 레코드에는 어떤 종류의 데이터가 포함될 수 있을까요?

• 참고 자료 : https://datatracker.ietf.org/doc/html/rfc1035#section-3.3.14
• RFC의 'TXT-DATA'에는 TXT 레코드의 값이 필드에 들어갈 수 있음

  TXT-DATA        One or more <character-string>s.

• 관리자가 자체 도메인과 연결하려는 텍스트 → TXT 레코드는 설명 텍스트를 저장하는 데 사용
• 대부분의 DNS 서버는 TXT 레코드의 크기와 저장할 수 있는 레코드 수에 제한 → 많은 양의 데이터에 TXT 레코드를 사용할 수 없음

3. DNS TXT 레코드에 데이터를 저장하는 공식적인 형식은?

• 1993년 인터넷 엔지니어링 태스크 포스(IETF)에서는 TXT 레코드의 '값' 필드에 속성과 해당 값을 저장하는 형식을 정의
• 따옴표(")에 포함된 속성과 값
• 속성과 값은 등호(=)로 구분

  "속성 = 값"

• DNS TXT 레코드를 정의하는 1993년 문서인 RFC 1464에는 아래 예제가 포함(https://datatracker.ietf.org/doc/html/rfc1464)
  

  

• DNS 관리자는 TXT 레코드를 사용하는 경우, TXT 레코드 내에서 자체 형식을 따름
• TXT 레코드는 특정 용도에 대해 특정 방식으로 형식이 지정될 수도 있음(예: DMARC 정책은 표준화된 방식으로 형식을 지정)

4. TXT 레코드는 이메일 스팸을 방지하는 데 어떻게 도움이 될까요?

• 스팸 발송자는 종종 이메일 메시지를 보내는 도메인을 위조하거나 위조하려고 시도함
• TXT 레코드는 이메일 서버가 신뢰할 수 있는 출처에서 온 메시지인지 확인하는 데 도움이 되는 여러 이메일 인증 방법의 핵심 구성 요소

• 일반적인 이메일 인증 방법
  1. 도메인 키 식별 메일(DKIM)
  2. 발신자 정책 프레임워크(SPF)
  3. 도메인 기반 메시지 인증 보고 및 적합성(DMARC)

• 도메인 운영자는 아래 TXT 레코드를 구성하여 스팸 발송자가 도메인을 스푸핑하는 것을 더 어렵게 만들고 스푸핑 하려는 시도를 추적할 수 있음
  1. SPF 레코드
     • SPF TXT 레코드에는 도메인에서 이메일 메시지를 보낼 권한이 있는 모든 서버가 나열
  2. DKIM 레코드
     • DKIM TXT 레코드는 공개-개인 키 쌍을 사용하여 각 이메일에 디지털 서명하는 방식으로 작동
     • DKIM을 사용하면 이메일이 실제로 보낸 도메인에서 온 것인지 확인 가능
     • 공개 키는 도메인과 연결된 TXT 레코드에서 호스팅
     • 공개 키 암호화 방식 참고 자료 : https://www.cloudflare.com/ko-kr/learning/ssl/how-does-public-key-encryption-work/
  3. DMARC 레코드
     • DMARC TXT 레코드는 도메인의 SPF 및 DKIM 정책을 참조
     • DMARC TXT 레코드는 제목 _dmarc.example.com 아래 'example.com'과 함께 실제 도메인 이름으로 대체해서 저장
     • 레코드의 '값'은 도메인의 DMARC 정책
     • DMARC TXT 레코드 참고 자료 : https://dmarcguide.globalcyberalliance.org/#/dmarc/

5. TXT 레코드는 도메인 소유권을 확인하는 데 어떻게 도움이 될까요?

• 도메인 소유권 확인은 처음에는 TXT 레코드의 기능이 아니었지만, 일부 웹마스터 도구 및 클라우드 공급자가 TXT 레코드를 활용
• 관리자는 특정 정보가 포함된 새 TXT 레코드를 업로드하거나 현재 TXT 레코드를 수정 → 도메인을 제어하고 있음
• 도구 또는 클라우드 공급자는 TXT 레코드를 확인하고 요청에 따라 변경되었는지 확인 가능
• 사용자가 이메일로 전송된 링크를 열고 클릭하여 이메일 주소를 확인해서 자신이 해당 주소를 소유하고 있음을 증명하는 것과 비슷

참고 자료

• https://www.cloudflare.com/ko-kr/learning/dns/dns-records/dns-txt-record/

1. DNS NS 레코드란

• NS는 '네임서버(Name Server)'를 의미
• 네임서버(Name Server) 레코드는 어떤 DNS가 해당 도메인의 권한 있는 Name Server(실제 DNS 레코드를 갖고 있는 서버)인지 지시함
• 기본적으로 NS 레코드는 해당 도메인의 IP 주소를 찾기 위해 가야 할 곳을 알려줌
• 도메인에는 해당 도메인의 기본 및 백업 네임서버(Name Server)를 나타낼 수 있는 NS 레코드가 다수 있음
• NS 레코드가 적절히 구성되어 있지 않다면 사용자는 웹 사이트나 애플리케이션을 로딩할 수 없게 됨

• NS 레코드의 예시
  

  

  
  ※ NS 레코드는CNAME 레코드를 지시할 수 없음

2. 네임서버(Name Server)란

• 네임서버(Name Server)는 DNS 서버의 유형 중 한 가지
• A 레코드, MX 레코드, CNAME 레코드 등 특정 도메인에 관한 모든 DNS 레코드를 저장하는 서버
• 모든 도메인이 안정성을 높이기 위해 다수의 네임서버(Name Server)에 의존
• 네임서버(Name Server) 하나가 중단되거나 사용할 수 없게 되어도 DNS 쿼리는 다른 네임서버(Name Server)를 이용할 수 있음
• 기본 네임서버(Name Server)가 하나 있으며, 네임서버(Name Server)의 DNS 레코드를 그대로 복사한 내용을 갖고 있는 보조 네임서버(Name Server)가 다수 존재하게됨
• 기본 네임서버(Name Server)를 수정하면 보조 네임서버(Name Server)도 마찬가지로 수정됨
• 다수의 네임서버(Name Server)를 이용할 경우에는 NS 레코드에 하나 이상의 서버 목록이 포함됨

3. 언제 NS 레코드를 수정하거나 변경 필요한가?

• 도메인 관리자는 도메인의 네임서버(Name Server)를 바꿔야 할 경우 NS 레코드를 수정 필요
• 예를 들어 클라우드 공급자 중에는 네임서버(Name Server)를 제공하며, 고객이 서버를 가리키도록 요구하는 경우가 있음
• 도메인 관리자는 하위 도메인에 다른 네임서버(Name Server)를 이용하고자 할 때도 NS 레코드를 수정이 필요함

• 예시
  1. example.com의 네임서버(Name Server)가 ns1.exampleserver.com임
  2. example.com의 네임 서버(Name Server)관리자가, blog.example.com 도메인을 질의할 때 ns1.exampleserver.com 대신 ns2.exampleserver.com을 통해 확인되도록 설정 필요
  3. NS 레코드를 수정함으로써 blog.example.com 도메인을 질의할 때, ns2.exampleserver.com을 통해 질의 가능

• NS 레코드를 수정하면, 변경 사항이 DNS에 복제되는 데는 몇 시간이 걸리기도 함

참고 자료

• https://www.cloudflare.com/ko-kr/learning/dns/dns-records/dns-ns-record/

1. DNSSEC 등장 배경

• DNS는 ‘도메인’을 ‘IP주소’로 변환하는 인터넷의 전화번호부 같은 역할을 함
• 인터넷 초기에 개발된 DNS는 설계당시 보안성을 충분히 고려하지 못해, DNS정보의 위-변조가 가능하다는 문제가 있음
• 악의적인 공격에 의해 도메인네임에 대한 IP주소가 악성 사이트 등으로 위/변조 된다면, DNS를 이용하는 인터넷 이용자들은 의도치 않은 IP주소로 연결되어 피해가 발생 가능

• 파밍(pharming)은 ISP의 캐시 DNS서버나 사용자 PC에 특정 도메인네임에 대해 위-변조된 IP주소가 설정되도록 하는 공격방식
• 파밍(pharming) 공격이 성공하면 사용자는 분명히 올바른 웹 사이트 주소를 입력하였음에도 불구하고(예: 인터넷뱅킹, 쇼핑몰 등), 공격자가 만들어놓은 가짜 사이트로 유도되는 상황이 발생
• 가짜 사이트는 원래 사이트와 동일한 모습으로 꾸며져 있기에 사용자는 아무런 의심도 하지 않고 자신의 로그인 정보와 계좌정보 등을 가짜 사이트에 입력해 피해가 발생
• ISP나 기관이 운영하는 캐시 DNS서버를 대상으로 "파밍(pharming)" 공격이 성공하는 경우, 캐시 DNS서버를 사용하고 있는 모든 인터넷 사용자에 대해 대규모의 피해가 발생 가능
• 캐시 DNS서버는 한번 파악한 DNS 정보는 자신의 캐시 메모리에 저장하여 일정시간이 경과하기 전까지 DNS 정보를 반복 사용하여 사용자 호스트의 DNS 질의에 응답
• 캐시 DNS서버의 캐시 메모리에 가짜 데이터를 저장하여 사용하도록 유도하는 방식의 파밍(pharming) 공격 → "DNS 캐시 포이즈닝(cache poisoning) 공격"

1.1. 인터넷 상의 피싱(phishing) 공격과 파밍(pharming) 공격 비교

1.2. 인터넷 상의 피싱(phishing) 공격과 파밍(pharming) 공격 비교

• 파밍 공격 절차
  1. 거래은행인 www.bank.kr 사이트 접속을 위해 사용자는 'http://www.bank.kr/' 주소를 입력
  2. 호스트는 www.bank.kr의 IP 주소를 파악하기 위해 DNS 질의 개시(1)
  3. DNS 서버들은 www.bank.kr의 IP 주소를 파악하기 위해 질의 진행(2~6)
  4. 파밍 공격자는 (7-1)의 정상 DNS응답이 캐시 DNS서버에 도달 전에 자신이 조작한 가짜 DNS 응답메시지를 (7-2)와 같이 대량으로 캐시 DNS서버에 송출
  5. 캐시 DNS서버는 DNS 응답메시지 수신대기 중 공격자가 송출한 (7-2)의 가짜 DNS 응답 메시지 수신(7-2), 정상 응답이 이루어진 것으로 간주, 캐시에 위-변조된 가짜 데이터 저장
  6. 캐시 DNS서버는 사용자 호스트에는 이 가짜 IP 주소 데이터로 응답처리(8-2)
  7. 사용자 호스트는 캐시 DNS서버가 응답한 가짜 IP 주소를 사용하여 웹 사이트 접속(9-2)
  8. 오염된 캐시 DNS서버를 사용하는 다른 사용자가 동일한 도메인네임을 질의하면 캐시 DNS서버는 이 캐시 메모리의 가짜 IP 주소로 바로 응답처리 → 인터넷 사용자의 피해자는 시간이 갈수록 늘어남

• 파밍 공격 절차 그림
  

  

2. DNSSEC 개념

• DNSSEC(DNS Security Extensions)은 DNS 데이터 대상의 "데이터 위조-변조 공격"을 방지하기 위한 인터넷 표준기술
• DNSSEC(DNS Security Extensions)은 2005년경 완성된 국제표준기술로 다양한 시험을 거쳐 2010년에는 전세계 최상위 DNS인 ‘루트DNS’에도 적용되면서, 전세계적으로 적용이 확대
• 우리나라는 2011년 “.kr” 국가도메인 영역에 대한 DNSSEC 적용을 시작
• 2012년 9월 .kr, .한국 등 총 31개 국가도메인 영역 전체에 DNSSEC 적용을 완료하여 DNSSEC 개념을 본격적으로 서비스 제공
• DNSSEC은 DNS를 대체하는 것이 아니라, 기존의 DNS에 공개키 암호화 방식의 보안기능을 추가 부여 → DNS의 보안성을 대폭 강화하는 역할
• DNS 데이터의 위조-변조 가능성을 원천적으로 차단하기 위해, DNSSEC은 공개키 암호화방식(Public Key Cryptography)의 전자서명 기술을 DNS 체계에 도입 적용
• 공개키 암호화방식의 전자서명 메커니즘은 금융권 등에서 널리 사용하는 공인인증서가 사용하고 있는 기술

2.1 DNSSEC은 전자데이터로 된 DNS정보에 서명코드를 추가하여 정보를 인증

2.2. 도메인과 IP주소에 대한 검증 절차가 수행되므로 해커에 의한 데이터 위·변조시 확인 가능

3. 보안침해 공격에 대한 DNSSEC이 제공하는 보안성 범위

4. DNS 구성체계 중 DNSSEC이 제공하는 보안 안정성 범위

• DNSSEC은 인터넷 상의 도메인에 대한 DNS 질의응답 절차 가운데 발생할 수 있는 "DNS 데이터 위-변조" 공격에 대응할 수 있는 보안기술
• 권한 DNS서버 간 존 데이터 전송 또는 동적업데이트와 같은 네임서버 관리영역의 동작에 대해서는 별도의 공유키 암호화 방식인 TSIG 기술을 사용하여 보호체계를 적용 가능
  

  

• DNS RR 내용 예
  

  구분	보호 영역 여부	비고
  권한 DNS서버 ⇔ 캐시 DNS서버	보호	- DNS 질의응답 절차 중 DNS 데이터 위-변조 공격 검출 수단 제공
  캐시 DNS서버 ⇔ 사용자 호스트	조건부 보호	- 사용자 호스트에 서명검증 가능한 리졸버(Validator) 사용 시 보호 - 그렇지 않은 경우, 보호할 수 없음
  권한 DNS서버 간 존 전송	대상 아님	- TSIG 적용 인증체계로 보호
  권한 DNS서버 동적 업데이트	대상 아님	- TSIG 적용 인증체계로 보호

참고자료

• KISA 참고 자료 : https://xn--3e0bx5euxnjje69i70af08bea817g.xn–3e0b707e/jsp/resources/dns/dnssecInfo/dnssecInfo.jsp
• google cloud 참고 자료 : https://cloud.google.com/dns/docs/dnssec?hl=ko