히포

• 일반적인 anycast DNS구성은 BGP로 설정
• anycast DNS 구성을 이해하기 위해서는 네트워크 적인 부분을 이해가 필요
• anycast DNS 네트워크를 어떤 식으로 구성되며 어떤식으로 동작하는지 설명

1. 6곳 지사에서 모두 1곳의 동일 DNS로 사용

• 예를들에 서울, 인천, 대전, 광주, 대구, 부산 6곳에 지사를 두고 있으며 서울에 있는 1.1.1.5를 6곳 지사에서 모두 DNS로 사용한다고 예정
• 서울에 있는 1.1.1.5 DNS서버에 문제가 발생하거나 서울지사에서 정전작업 혹은 재해 등으로 인하여 DNS서버에 장애가 발생하거나, DNS 앞단 스위치에 장애가 발생하면 6곳 지사 모두 DNS서비스를 받지 못함
  

  

2. 6곳 지사에서 모두 1곳의 DNS로 사용할 때 발생하는 문제 해결 → DNS 이중화(새로운 IP 사용은 불가능)

• 6곳 지사에서 1곳의 동일 DNS로 요청하다보면 발생할 수 있는 문제점들을 해결하기 위하여 DNS 이중화 진행 → 부산에다가 새로운 DNS서버를 구축
• 이미 몇만명이 넘는 사용자들은 각자 PC에 1.1.1.5를 설정하였고 대부분의 서버에도 DNS가 1.1.1.5로 설정되었기 때문에 새로운 IP를 할당하고 공지한다는 것은 불가능
  

  

3. BGP라는 라우팅 프로토컬을 사용하면 1개의 IP를 서로 공유하는 것 가능

• 일반적으로 1개의 IP를 서로 공유한다는 것운 불가능 → 지역이 멀어져 있을 경우에 1개 IP를 공유하는 것은 더 불가능
• BGP라는 라우팅 프로토컬을 사용하면 1개의 IP를 서로 공유하는 것 가능
• anycast DNS를 구성하기 위해서는 반드시 BGP구성이 되어야 함
• 6개의 지사가 각각 BGP로 구성되어 있고 이 BGP정보(각자 가지고 있는 IP정보)를 주고받도록 설정되어야 함
  

  

4. 각각 BGP로 연결된 다른 자사에서도 1.1.1.5가 있는 BGP 네트워크를 알 수 있음

• 6개의 지사가 BGP로 구성되에 있고 서울과 부산에서 각각 1.1.1.5를 설정하면 BGP정보를 타고 서울과 부산은 각각 BGP로 연결된 다른 자사에게 - 1.1.1.5는 각자 자신에게 존재한다고 다른 지역에게 공유
• 인천, 광주, 대전, 대구는 1.1.1.5가 서울에도 존재하고 부산에도 존재함을 공유받게 되어 알게 됨
  

  

5. BGP를 통한 서로 다른 2곳에서 동일 IP DNS 서비스는 분산 서비스 가능(홉카운트가 가까운 DNS로 질의)

• 인천, 광주, 대전, 대구 지사는 서울, 부산으로부터 1.1.1.5에 대해 공유받음 → BGP라는 라우팅 프로토콜로 공유를 받아 1.1.1.5가 서울과 부산 두 곳에 존재한다는 여부를 알게 되었고 BGP 특성상 홉카운트가 가까운 쪽으로 찾아가게 됨
• 서로 다른 2곳에서 동일한 IP 1.1.1.5를 공유받았다 하더라도 거리가 가까운 쪽을 우선적으로 찾아감
• 인천과, 대전 사용자들은 BGP정책에 따라 서울이 가깝기 때문에 서울에 있는 1.1.1.5 DNS서버로 접속하게 되며, 광주, 대구 사용자들은 BGP정책에 따라 가까운 부산에 존재하는 DNS서버에서 DNS서비스를 받게 됨
• DNS 서비스는 서울과 부산 2곳에서 분산 서비스 가능
  

  

6. 1곳의 DNS 서비스에 장애가 발생하면, 다른 1곳 DNS에 서비스 질의(BGP 설정으론 DNS 장애 판단 불가)

• 부산의 DNS 서비스에 장애가 발생하면 기존에 부산에서 서비스받던 광주, 대전, 부산 사용자들은 다른 DNS서버인 서울에서 DNS 질의
  일반적으로 BGP만 설정하게 되면 BGP는 해당 DNS 서비스가 장애 유무를 판단할 수 없음
• 1.1.1.5/32을 static으로만 BGP에 redistribute(재분배) 시킴
  

  

7. BGP 내부에 다이나믹한 라우팅 프로토컬 중 OSPF를 사용(장애 유무 판단)

• 장애 유무를 판단하기 위해서는 다이나믹한 라우팅 프로토컬을 BGP 내부에서 DNS서버와 부산 백본스위치 간에 연동시켜야 함
• 일반적으로 RIP, EIGRP, OSPF 등 다양한 다이나믹 라우팅 프로토컬이 있으나 가장 많이 사용되는 OSPF를 예로 사용
  

  

8. 각각의 지역끼리 BGP로 정보를 주고받으며 각 지역의 내부는 OSPF로 연동

• 각각의 지역끼리 BGP로 정보를 주고 받으며 각 지역의 내부는 OSPF로 연동된 상태 → BGP를 사용하는 대부분의 네트워크 망 구성
• 지역 내부에서는 OSPF가 동작하여 1.1.1.5를 지역 내에서도 접근할 수 있도록 설정
• 각 지역 내부에 존재하는 IP도 타 지역에서 접속할 수 있도록 타 지역끼리는 BGP로 설정
  

  

9. DNS 장애 발생 시 서로 다른 지역은 BGP로 전파하며, 지역의 내부는 OSPF로 연동하여 전파

• 부산에 있는 DNS서버에 장애가 발생하여 링크 등이 끊기거나 상단 스위치에 문제가 발생하게 되면 OSPF는 부산지역에 OSPF로 연결되어 있는 장비들에게 해당 IP의 공유를 중단하게 되며 BGP를 통하여 그 사실을 타 지역에게도 공유하게 됨
• 부산 DNS 장애로 인해 서울 DNS에 접속하기 위해, 전 지역에 서울 DNS 1.1.1.5가 공유
  

  

• 부산의 DNS서버에 장애가 발생하면, 부산에서 서비스받고 있는 지역은 BGP 공유에 의하여 다음 우선 지역인 서울의 1.1.1.5에서 DNS서비스를 받게 됨
  

  

10. 지역의 내부는 DNS서버를 L4스위치에 연결하여 OSFP 연동 전파, 서로 다른 지역은 BGP로 전파

• 일반적으로 Bind를 사용하는 일반적인 서버에서는 OSPF를 구동시키기가 힘들다. → Redistribute Connect로 연결된 모든 것을 OSPF에 등록할 수 있지만 그런 경우 링크가 끊기는 경우만을 체크하게 되며 Bind 데몬이 Down되는 등의 장애를 감지할 수 없음
• 몇몇 인포블럭스 같은 상용 박스형 DNS 서버들은 자체적으로 OSPF가 구동되도록 생성할 수 있음
• 일반적인 Sun, Linux 기반에 Bind DNS서버들은 상단에 OSPF를 구현할 수 있는 L4등의 SLB장비가 구현되며, Real DNS서버들은 1.1.1.6, 1.1.1.7 등을 가지고 있으며 실적적으로 서비스받는 IP 등은 L4에서 대표 IP인 VIP로 설정
• 부산지사 백본과 L4 스위치를 OSPF로 설정하게 되면 부산 백본 스위치는 1.1.1.5가 L4 스위치게 존재함을 알게 되며 BPG에 network 1.1.1.5/32로 다른 지역에게도 공유하게
  

  

참고 자료

• https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=sdream4&logNo=10043264105

• 네트워크 기술 하나 중 Anycast는 DNS 서비스에서 주로 사용
• 각 글로벌 POP에 비용 절감 및 고가용성 용도로도 많이 사용

1. Anycast란

• 보통 알고 사용하고 있는 IP 주소는 Unicast IP이며 이것은 고유한 IP 주소
• Anycast IP는 서로 다른 곳, 서로 다른 호스트끼리 동일한 IP 주소를 가질 수 있는 개념 → 네트워크 내 다수의 서버가 동일한 IP 주소 또는 일련의 IP 주소를 이용(Anycast 네트워크에서는 통신은 일대다)
• 동일한 IP 주소를 사용하는 경우, 충돌 발생 가능 → 충돌된 IP들의 회피 방법은 BGP와 같은 라우팅 프로토콜에 의해서 해결
• 라우팅 프로토콜에 의해 충돌난 IP에 대해서 가장 최적의 경로의 IP를 가진 서버를 1개 선택해서 라우팅함
• 같은 IP를 각 라우터들이 어나운스하며 가장 가까운 곳으로 판단되는 쪽으로 사용
• 라우팅 코스트가 가장 적은 쪽의 경로를 선택, 라우팅 코스트가 같다면 로드밸런싱함
  

  

2. Anycast DNS

• Anycast는 주로 DNS 서비스에 많이 활용
• Anycast 기법을 사용하여 DNS 서버를 지역별 분산 구성하여 DNS 질의를 요청한 클라이언트와 가장 근접한 DNS 서버가 처리하도록 하여 응답속도와 안정성을 향상함
• 항상 네트워크 경로상 가장 가까운 DNS 서버가 응답 → 가장 가까운 DNS가 장애가 발생되면 라우터에서 어나운스가 되지 않아 자동으로 빠지며 그다음 가까이 위치에 있는 DNS가 대신 처리함
• 지리적으로 가장 가까운 서버가 응답하는 Anycast DNS는 대기 시간을 줄이고, DNS 확인 서비스의 가동 시간을 늘리면서, DNS 폭주 DDoS 공격을 방지 가능
• Google public DNS를 Anycast로 구성하여 가장 가까운 지역에서 DNS서비스를 받는 과정
  

  

2.1. Anycast DNS 도입배경

• Anycast가 도입된 이유는 2002년 10월 root DNS DDoS 공격으로 전 세계 13개 root DNS 중 8개가 다운, 2003년 1.25 인터넷 대란 때 5개의 root DNS가 웜으로 DDoS 공격당하여 전 세계 DNS가 마비되어서 개선안으로 Anycast 기술을 사용하게 됨
• Anycast IP를 이용하여 DNS를 적절히 분산구성하여 한쪽 지역이 무너지더라도 다른 지역에서 서비스를 받을 수 있도록 함

2.2. Google public DNS

• Google public DNS의 IP 8.8.8.8가 대표적으로 Anycast로 구성되어 있으며 전 세계 국가에 분산되어 있고 규모가 엄청남
• Google public DNS를 쓰면 자신이 속한 지역에서 라우팅 경로가 가장 최적인 지역의 DNS 서비스를 받고, Google 서비스에 대한 서비스도 최적에 있는 지역의 서버에 서비스를 진행
• 아시아에선 Google public DNS가 대만과 홍콩에 위치
• Google public DNS 참고 자료 : https://developers.google.com/speed/public-dns/faq#locations

3. Anycast DNS의 작동 방식

• Anycast를 이용하면 DNS 확인이 훨씬 빨라짐
• Anycast DNS에서는, DNS 질의가 하나의 특정 DNS가 아닌 다른 DNS의 네트워크로 향하며, 가장 가까우면서 가용한 DNS로 질의를 보냄
• DNS 질의 및 응답은 가장 빨리 질의에 응답할 수 있도록 최적화된 경로를 따름
• Anycast는 DNS 확인 서비스의 가용성을 높이는 데도 도움이 됨
• 하나의 DNS 가 오프라인 상태가 되더라도 네트워크의 다른 DNS가 질의에 응답할 수 있음
• CDN은 Anycast이므로, DNS 질의는 네트워크 내 어떤 데이터 센터에서도 확인 가능 → 네트워크 내의 모든 DNS가 모든 DNS 질의에 응답할 수 있음

4. Anycast가 없을 때의 DNS 확인 작동 방식

• Anycast를 사용하지 않는 DNS 확인 서비스는 Unicast 라우팅을 사용하는 경우가 많음
• Unicast 라우팅에서는 모든 DNS 서버에 하나의 IP 주소가 있으며 모든 DNS 질의는 특정 서버로 향함
• 해당 DNS가 작동하지 않거나 사용할 수 없는 경우, 클라이언트는 추가 DNS에 질의해야 하는데, DNS 확인 시간이 길어지게 됨

5. Anycast DNS가 DDoS 공격에 대한 복원력을 제공하는 방식

• DDoS 공격은 DNS 폭주 공격을 통해 DNS 마비시킴
• DDoS 공격은 대개 IoT 기기로 된 대규모 봇네트를 이용해 DNS 질의로 DNS를 압도하거나 DNS에 폭주함
• DNS 폭주 공격은 개방된 DNS를 통해 DDoS 공격을 증폭시키는 DNS 증폭 공격과는 다름

• Anycast 네트워크는 트래픽을 전체 네트워크에 분산시킬 수 있으므로, DDoS 방어도 제공
• Anycast 네트워크는 특정 IP 주소로의 요청에 대해 다수의 서버가 응답하므로, 한 대의 서버를 압도할 수 있는 수천 개의 요청이 다수의 서버에 나눠지는 것
• Anycast 네트워크는 대개의 DNS 폭주 공격에 취약하지 않음
  

  

• DNS 폭주 공격 참고 자료 1 : https://www.cloudflare.com/ko-kr/learning/ddos/dns-flood-ddos-attack/
• DNS 증폭 공격 참고 자료 2 : https://www.cloudflare.com/ko-kr/learning/ddos/dns-amplification-ddos-attack/

참고 자료

• https://tech.kakao.com/2014/05/29/anycast/
• https://www.cloudflare.com/ko-kr/learning/dns/what-is-anycast-dns/
• https://m.blog.naver.com/PostView.naver?isHttpsRedirect=true&blogId=sdream4&logNo=10043264105

1. DNS(Domain Name System) 보안 프로토콜

• 최초 DNS는 엄격한 보호 수단이 없었지만, 이후 카민스키(Kaminsky) 버그와 같은 보안상 취약점이 발견되면서 2010년 DNSSEC(Domain Name System Security Extensions)이 탄생
• DNSSEC은 디지털 서명 기반의 암호화로 보안을 강화 → 전 세계 DNS 클라이언트는 DNSSEC을 이용해 DNS 응답이 정상적인 DNS 서버에서 왔으며, 전송 과정에서 변조되지 않았음을 확인
• DNSSEC 등장 이후 DNS 오버 HTTPS(DNS over HTTPS, DoH)와 DNS 오버 TLS(DNS over TLS, DoT)가 등장
• DNSSEC가 DNS 응답의 진정성과 데이터 무결성을 보장하지만 개인정보는 보호하지 않기 때문에 DoH와 DoT 가 개발 → DoH와 DoT 프로토콜은 종단간 암호화를 제공하므로 데이터의 기밀성이 보장
• DNS 트래픽도 HTTPS 사이트 간의 웹 트래픽과 같은 종단간 암호화의 이점을 얻게 됨

1.1. DoH란

• DNS는 전송 제어 프로토콜(Transmission Control Protocol, TCP)에서 사용할 수도 있지만 기본적으로 DNS 프로토콜은 전송 계층 프로토콜인 사용자 데이터그램 프로토콜(User Datagram Protocol, UDP)에서 동작
• DoH는 더 빠른 UDP가 아닌 HTTPS를 통해 암호화된 DNS 메시지를 전송
• HTTPS는 전송 계층 보안(Transport Layer Security, TLS)에서 실행되는 HTTP 프로토콜이므로 DoH는 사실상 DNS 오버 HTTP 오버 TLS(DNS over HTTP over TLS)라고 할 수 있음
• DoH에서 DNS 질의와 DNS 응답은 모두 HTTPS를 통해 전송되며 포트 443을 사용 → 다른 HTTPS 웹 트래픽과 거의 구분 불가

• 웹 브라우저에서 구글 DoH 서비스를 사용해서 CSOOnline.com 도메인 해석(resolve)
  1. 브라우저에 HTTPS URL을 입력해 HTTPS를 통해 도메인 이름을 해석하는 방식은 SSL/TLS를 사용하는 일반 웹사이트를 방문할 때와 차이가 없음
  2. 구글이 반환하는 DNS 응답은 CSO의 서버 IP 주소(A 레코드)로, 모두 JSON 형식으로 깔끔하게 포장됨
  3. 사용자와 구글 DoH 사이에 기업 중간자(man-in-the-middle, MitM) 프록시가 없다면, 사용자가 조회하고자 하는 도메인(CSO 온라인)이 무엇인지, 또는 DNS 질의에 대한 응답(JSON 결과)이 무엇인지 누구도 알아낼 수 없음

• DoH를 사용하면 개인정보(데이터 기밀성) 보호와 수신된 정보의 무결성(DNS 응답이 전송 중 변조되지 않음)이 보장
• 종단간 암호화 채널을 통해 DNS를 전송하는 방식에는 문제의 소지도 있음 → 공격자가 DoH 서비스를 악용해 악성 트래픽을 숨긴 사례가 존재 가능
• 공격자는 구글의 DoH 또는 아무 DoH 제공업체를 통해 악성 도메인을 해석할 수 있음
• 반환된 암호화 응답에는 공격자가 제어하는 도메인의 TXT 레코드와 함께 암호화된 악성 페이로드가 포함되고, 악성코드가 페이로드를 파싱할 수 있음
• 기본적으로 위협 행위자가 지휘통제(C2) 활동을 용이하게 하기 위해 보안 DNS 프로토콜을 악용
• DoH 제공업체는 합법적인 비즈니스 사용 사례가 있으므로 기업 네트워크와 DoH 제공업체 간의 인바운드 또는 아웃바운드 트래픽을 단순히 차단하기는 어려움

1.2. DoT란

• DoT는 애플리케이션 계층에 상주하는 HTTPS가 아닌 전송 계층에서 TLS 프로토콜을 통해 DNS 질의를 암호화
• DoT는 DoH와 달리 애플리케이션 수준 HTTPS를 생략
• 기본적으로 DoT는 DNS UDP 요청과 응답을 TLS를 통해 암호화하며 메시지가 전송 과정에서 변경되지 않도록 보장
• DoT는 HTTPS(포트 443) 또는 일반 DNS(포트 53)와는 다른 포트 853을 사용
• DNS 클라이언트와 리졸버 간의 통신이 TLS를 통해 이뤄지므로 DoT 트래픽도 DoH와 마찬가지로 종단간 암호화의 이점을 얻게 됨

2. DoH와 DoT 중 어느 DNS 프로토콜이 더 좋을까

• 네트워크 관리자의 입장에서는 제어가 쉬운 DoT를 선호
  • DNS 질의 모니터링 측면에서 더 높은 유연성을 제공하는 DoT 쪽을 선호
  • 네트워크에서 악성 DNS 트래픽과 침해 지표(IOC)를 차단하려는 보안 전문가라면 DoT가 유용
  • DoH의 경우 사용자의 DNS 질의가 다른 HTTPS 트래픽과 섞이므로 최종 사용자의 개인정보 보호가 더 강화 → 네트워크 관리자는 해석되는 도메인과 반환되는 DNS 응답을 확인 X
  • 네트워크 관리자 입장에서는 정상적인 비즈니스 통신에 영향을 미치지 않으면서 DoH를 차단하기가 훨씬 더 어려움
  • DoT 차단을 위해 기업 방화벽을 구성해 포트 853을 통해 이동하는 트래픽을 일률적으로 필터링하는 정책을 추가가 쉽지만, 포트 443(DoH) 필터링은 불가능 → 만약 443 포트를 차단할 경우 정상적인 트래픽도 차단될 수 있음

• DNS 패킷이 가벼움
  • DoH는 애플리케이션 계층에 위치하는 HTTPS를 사용하지만, DoT는 전송 계층에 위치함으로 가벼움
  • DoT는 관여하는 계층의 수가 적으므로 패킷의 크기가 더 작음 → 패킷의 크기가 작음으로 지연 시간이 낮음

• 새롭게 고안된 프로토콜의 상당수는 HTTPS 또는 SOCKS(토르) 같은 암호화된 채널을 사용
• 최종 사용자에게 더 많은 선택권을 제공하지만 트래픽 필터링 측면에서는 보안 전문가에게 더 큰 어려움이 될 수 있음 → DNS 오버 트위터를 차단하면 트위터 전체가 차단될 수 있음
• 프록시와 같은 보조 대책을 사용할 경우 기밀성과 사용자 개인정보 보호 측면에서 DoH가 제공하는 많은 보호 기능이 무효화될 수 있음
• DoT든 DoH든 DNS 프로토콜 사용은 기업의 필요에 따라 결정
• 사용자 개인정보 보호와 적절한 네트워크 모니터링 간의 타협 기준을 어디에 두느냐도 중요

3. 추가 → 클라우드플레어(Cloudflare)

• 클라우드플레어(Cloudflare)는 새로운 DNS로 확장 시도
  1. DNS 오버 트위터(DNS over Twitter)
  2. DNS 오버 토르(DNS over Tor)
  3. DNS 오버 텔레그램(DNS over Telegram)
  4. DNS 오버 이메일(DNS over Email)

• 클라우드플레어(Cloudflare)는 고객 사이트 방문자가 토르 네트워크를 사용하도록 허용하는 어니언(Onion) 서비스를 제공
• 클라우드플레어의 리졸버(resolver) 1.1.1.1은 DoH와 DoT를 모두 지원하며 어니언 서비스를 통해 제공 → DNS 오버 토르(DNS over Tor)
• 1.1.1.1로 질의를 해석해 결과를 트윗으로 보내는 트위터 봇으로 운영

TYPE 65 개요

• Apple은 자사의 최신 OS인 iOS 14와 macOS 11에 암호화된 DNS 지원 기능을 추가하였음
• DNS 통신을 암호화하여 제3자가 DNS 질의·응답을 들여다 볼 수 없도록 하는 기술로 DoH(DNS-over-HTTPS), DoT(DNSover-TLS) 등 2가지 기술 존재
• iOS 14 및 macOS 11은 암호화된 DNS 기능을 위해 이전 버전과 달리 새로운 타입(TYPE65 HTTPS)의 DNS 질의를 추가로 발생시킴
• DNS 운영기관에서는 신규 DNS 타입 질의로 인한 영향이 없도록 인터넷 표준에 따라 적절히 처리하는지 자체 점검할 것을 권고함
• 애플의 최신 OS 배포 이후 새로운 유형의 DNS 질의 증가 → 애플 iOS 및 macOS 최신 버전 배포 이후, 표준화가 완료되지 않은 신규 타입인 TYPE65(HTTPS) 질의가 다량 유입됨
• TYPE65(HTTPS) 타입은 HTTPS 연관 서비스 정보를 담기 위한 신규 DNS 레코드로 표준화 작업 진행 중인 상태
• 애플은 암호화 DNS(DoH) 지원을 위한 목적으로 해당 타입의 DNS 질의를 사용
• 애플, 구글, 아카마이, 클라우드플레어 등 빅테크 기업들은 새로운 DNS 관련 표준들의 개발에 직접 참여 → 일부는 표준화가 완료되기 전에도 자사 서비스에 선 탑재
• 예상되지 않은 신규 유형의 질의는 DNS 질의량 증가 외 GSLB 등 DNS 기능을 활용한 서비스에 영향을 미칠 수 있음

iOS·macOS DNS 질의 변경사항

• iOS 14와 macOS 11은 암호화된 DNS(DoT/DoH) 지원을 위해 캐시 DNS를 선택하는 몇 가지 방법이 추가됨
  1. 사용자가 기기 전체에 적용되는 기본 DNS로 DoT/DoH를 지원하는 캐시 DNS를 직접 설정
  2. 도메인 소유자가 소유한 도메인에 질의할 때 특정한 캐시 DNS를 사용하도록 지정
  3. 앱 개발자가 개별 앱에서 특정한 캐시DNS를 사용하도록 지정

• 도메인 소유자는 DNS 레코드(TYPE65 HTTPS RR)을 통해 소유한 도메인에 질의할 때 암호화를 지원하는 특정한 캐시DNS를 사용하도록 지정 가능
• 예시) foo.example.com. 7200 IN HTTPS 1 . ( dohuri=https://doh.example.net/dns-query ) ⇒ foo.example.com 도메인 질의 시 캐시 DNS로 doh.example.net을 사용하도록 지정

• iOS 14와 macOS 11은 특정한 캐시 DNS를 사용 설정 여부를 확인하기 위해 사용자가 웹, 앱 등 사용하여 인터넷 이용 시 기존 DNS 질의(A, AAAA 타입 질의)에 추가로 TYPE65(HTTPS RR) 질의를 발생시킴
• TYPE65(HTTPS RR) 및 DNS 지정·확인 절차는 아직 표준이 아닌 인터넷 초안(Internet Draft)으로 향후 변경될 수 있음

발생가능한 문제점

• TYPE65(HTTPS RR) 질의를 정상적으로 처리하지 않는 경우, 불필요한 DNS 질의가 증가하거나 도메인 접속이 불안정해질 수 있음
• DNS 서버나 네트워크·보안장비 등에서 질의가 차단될 경우, 응답을 받지 못한 기기에서 같은 질의를 반복 시도하여 불필요한 DNS 트래픽이 지속 발생 가능
• 일부 DNS 서버나 네트워크·보안장비에서 자주 사용되는 DNS 레코드 타입(A, NS, MX 등)이 아닌 DNS 질의 패킷을 차단·폐기하거나 처리하지 않는 경우가 있음
• 해당 타입에 대해 잘못된 DNS 응답*을 하는 경우, 도메인 접속에 문제를 일으킬 가능성도 있음
• TYPE65 질의의 A, NS 등 다른 타입의 질의 결과로 응답하거나, NXDOMAIN으로 응답하면 잘못된 DNS 정보가 전파되어 도메인 접속에 문제가 발생할 수 있음

DNS 점검 방법 → TYPE65 및 알려지지 않은 타입으로 인한 문제 발생

• 운영 중인 DNS에 TYPE65 및 알려지지 않은 타입(Unknown Type)에 대한 테스트 질의*하여 정상 처리되는지 확인
• TYPE65 및 알려지지 않은 DNS 타입 질의가 의도치 않게 차단되거나 비정상 응답할 경우, 아래와 같이 조치 가능
  1. 사용 중인 DNS S/W에서 해당 타입 질의를 처리하지 못하는 경우, 최신 DNS S/W로 업그레이드
  2. 네트워크·보안장비 등에서 해당 타입 질의를 차단하거나 제대로 통과시키지 못하는 경우, 차단 정책을 조정하거나 제조사에 문의

• 문제가 발생할 경우의 권고사항
  1. 상기 문제점은 TYPE65에만 발생하는 것이 아닌 향후 다른 DNS 레코드 타입이 새롭게 만들어질 때도 동일하게 발생할 수 있음
  2. 현재 DNS 레코드 타입은 60가지 이상 존재하고 있으며, 인터넷 표준 제·개정에 따라 새로운 타입이 계속 추가될 수 있음
  3. 신규 타입 추가로 인한 문제없이 DNS 기능 확장이 가능하도록 인터넷 표준(RFC 1035, 3597)은 DNS 서버가 어떤 레코드 타입에 대해서도 투명하게 처리할 것을 명시하고 있음
  4. 따라서, DNS 운영기관에서는 DNS 서버가 인터넷 표준에 따라 동작하는지 점검 및 필요한 조치를 취할 것을 권고함

참고 자료

• https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&cad=rja&uact=8&ved=2ahUKEwig6e6ejq6BAxX6r1YBHTHhDekQFnoECBMQAQ&url=https%3A%2F%2Fkisa.or.kr%2Fpost%2FfileDownload%3FmenuSeq%3D20202%26postSeq%3D0227%26attachSeq%3D1&usg=AOvVaw1UPOdq6MnVhu-3RxUexLIS&opi=89978449

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/