DNS amplification

infra.rst

@@ -1,22 +1,5 @@
 Chapter 8.  Infrastructure Security
 ==============================================
-.. Brad notes
-   I really enjoyed the CCR paper with anonymous authors on collateral
-   damage of China’s censorship (IIRC, causing DNS lookup failures in
-   other countries).
-   That paper is not exactly current now, but it is a nice example of
-   how a state actor can deploy things that break infrastructure
-   outside its own state boundaries.
-   My gut feeling is that material on why stock DNS is vulnerable to
-   attack, what DNSSEC is, how it’s supposed to make things better,
-   and why it’s hard to deploy would definitely be useful.
-   And probably the same for BGP and the RPKI. Goldberg has a paper on
-   why it’s so hard to secure routing; I think it was in Queue.
-   I wonder if a synthesis of any sort is possible on this
-   topic. Certainly certificate chains and delegated signature authority
-   are at the core of both DNSSEC and the RPKI.
-   Perhaps there is a unifying theme of securing infrastructure with distributed domains of control.
-   In a way CAs fit this model, too.
 
 
 In the preceding chapters we have focused on the security of
@@ -713,9 +696,48 @@ effects in and beyond China.
    <https://dl.acm.org/doi/10.1145/2317307.2317311>`__. Computer
    Communications Review, July 2012.
 
-
-
-8.2.1 DNS Security Extensions (DNSSEC)
+8.2.1 DNS Amplification Attacks
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+There is a class of denial-of-service (DoS) attack that leverages the
+properties of DNS to attack other systems, rather than being an attack
+on DNS itself. Recall that DNS is UDP-based. A name server sends a
+response back to the IP address from which a query was sent, and since
+there is no TCP connection to establish, it is relatively easy to use
+a fake source address in a query. In this case, the name server can be
+tricked into sending traffic to some unsuspecting host. And it is not
+hard to see how this can be turned into a *distributed*
+denial-of-service attack: many hosts (e.g., a set of hosts in a
+botnet) can make coordinated requests to a set of name servers, with
+all the requests using the same spoofed source address. Not only does
+this lead to a lot of traffic heading to the target address, but the
+name servers can be make to perform a traffic *amplification*
+function, because the response to a DNS query can be much larger than
+the query that triggered it. In particular, the DNS query type "ANY"
+causes all records for a domain to be returned, which can be a lot of
+data returned for a simple query. The handling of such queries has
+recently been clarified in an RFC in a manner that should reduce the
+impact of ANY queries, but that is not a complete solution to DNS
+amplification attacks.
+
+Three main steps can be taken to reduce these attacks. The first
+is to avoid the deployment of "open" resolvers, i.e., resolvers
+which will accept queries from anywhere. For example, the resolver
+for an enterprise should be configured such that only clients
+within that enterprise can send queries to it; it should not accept
+queries from the broader Internet.
+
+The second step is source address validation. Source address
+filtering is a tool that can be applied at the boundaries of
+autonomous systems to reject traffic with spoofed source
+addresses. It may not be 100% effective but it will reduce the
+effectiveness of large scale attacks.
+
+Finally, there are ways to deal with DoS attacks such as the use
+of content distribution networks and black-holing of DoS
+traffic. We discuss these further in Chapter 9.
+
+8.2.2 DNS Security Extensions (DNSSEC)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Since DNS queries in the original design are unauthenticated,
@@ -810,7 +832,26 @@ This is not to say that protecting DNS is unimportant,
 however. Interference with DNS is still a vector for censorship and
 surveillance of Internet usage. For this reason there are other
 methods of protecting DNS that have started to gain traction more
-recently.
+recently, as discussed in the next section.
+
+A final note on DNSSEC is that, by making responses larger, it has the
+potential to worsen amplification attacks. The response to a request
+to a DNS server that implements DNSSEC contains both a signature and
+the key used to verify the signature. That's a significant increase in
+the number of bytes returned for a single query. The mitigation
+techniques outlined above—source address filtering and DoS
+prevention—can still be applied. Additionally, there is an advantage
+to using crytographic algorithms that use relatively short keys. For
+this reason the EDCSA algorithm may be preferred to RSA, since EDCSA
+keys are considerably shorter than RSA keys for comparable levels of
+security.
+
+This small detail illustrates how much of security consists of making
+tradeoffs. While adding DNSSEC is a positive in terms of securing the
+DNS itself, it has contributed to the risk of DoS attacks leveraging
+DNS amplification. Adding security almost always imposes some costs—it
+is important to be aware of them and to ensure that the payoff for an
+additional mechanism justifies its costs.
 
 
 .. _reading_dnstime:
@@ -821,7 +862,9 @@ recently.
    APNIC Blog, May 2024.
 
 
-8.2.2 Encrypted DNS (DoH, DoT, ODNS)
+
+
+8.2.3 Encrypted DNS (DoH, DoT, ODNS)
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~