DNS DOTS considerations
draft-zhang-dots-dns-considerations-00

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00

Internet Engineering Task Force                                 H. Zhang
Internet-Draft                                                    P. Zuo
Intended status: Informational                                    Y. Sun
Expires: January 27, 2021                                        M. Yuan
                                                                   CNNIC
                                                           July 26, 2020

                        DNS DOTS considerations
                 draft-zhang-dots-dns-considerations-00

Abstract

   DDoS Open Threat Signaling(DOTS) described in [RFC8612] is a
   standardized method to coordinate a real-time response among involved
   operators.  This document focus on the considerations regard to the
   use of DOTS to mitigate DNS-Related DDoS attacks.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on January 27, 2021.

Copyright Notice

   Copyright (c) 2020 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of

Zhang, et al.           Expires January 27, 2021                [Page 1]
Internet-Draft           DNS DOTS considerations               July 2020

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

1.  Introduction

   Domain Name System(DNS) is one of the most foundational and essential
   services on the Internet, the security and robustness of DNS are of
   great significance.  However, the stable operation of DNS has been
   threatened by Distributate Denial of Service(DDoS) for quiet a long
   time.  In addition, DNS is often used to implement amplification
   attacks, reflection attacks, etc.

   DDoS Open Threat Signaling(DOTS) described in [RFC8612] is a
   standardized method to coordinate a real-time response among involved
   operators.  This document focus on the considerations regard to the
   use of DOTS to mitigate DNS-Related DDoS attacks.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document uses the terminologies defined in [RFC8612] and [I-
   D.ietf-dots-use-cases].

3.  DNS DOTS considerations

3.1.  DOTS Server

   DOTS Server described in RFC 8612 is responsible for handling
   messages from DOTS client.  In order to provide more effective and
   comprehensive mitigation, the DOTS server should have the ability to
   filter DNS messages based on different transfer protocols.  At the
   time of this writing, the majority of DNS traffic is transmitted in
   plain text via UDP.  As some new DNS protocols like DoT[RFC 7858],
   DoH[RFC8484] are introduced, encrypted DNS traffic transmitted via
   TLS and HTTPS is growing.  As the normal deep packet inspection
   method is not easy to detect encrypted traffic, port filtering or
   deep learning methods can be considered to identify abnormal traffic
   in the case of DoT or DoH.

Zhang, et al.           Expires January 27, 2021                [Page 2]
Internet-Draft           DNS DOTS considerations               July 2020

3.2.  Filter

   Filters described in RFC 8612 should be extended to filter DNS
   traffic based on DNS message characteristics.  For example, DNS
   packets can be filtered by domain name queried.  Based on the
   telemetry of the attack, filter can drop or transmit DNS packages
   according to specific domain names or other DNS characteristics.  In
   addition, filter should support bidirectional filtering of DNS
   traffic.  For example, for the use of DNS to implement amplification
   attacks, the filter can drop the DNS response from the DNS server
   side.

3.3.  Data channel