From a796fdae6f34fcdb5f7a9f8bb721ac75cb587546 Mon Sep 17 00:00:00 2001 From: Bruce Davie <3101026+drbruced12@users.noreply.github.com> Date: Fri, 25 Jul 2025 17:33:07 +1000 Subject: [PATCH 1/3] DNS amplification --- infra.rst | 41 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 41 insertions(+) diff --git a/infra.rst b/infra.rst index ced30e8..db5b73a 100644 --- a/infra.rst +++ b/infra.rst @@ -713,6 +713,47 @@ effects in and beyond China. `__. Computer Communications Review, July 2012. +.. sidebar:: 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 to 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.1 DNS Security Extensions (DNSSEC) From a794afca269827bb3701bc367f296a0511ba43de Mon Sep 17 00:00:00 2001 From: Bruce Davie <3101026+drbruced12@users.noreply.github.com> Date: Fri, 25 Jul 2025 17:52:39 +1000 Subject: [PATCH 2/3] White space --- infra.rst | 3 --- 1 file changed, 3 deletions(-) diff --git a/infra.rst b/infra.rst index db5b73a..b832a8d 100644 --- a/infra.rst +++ b/infra.rst @@ -753,9 +753,6 @@ effects in and beyond China. of content distribution networks and black-holing of DoS traffic. We discuss these further in Chapter 9.* - - - 8.2.1 DNS Security Extensions (DNSSEC) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From d4cccf5ffb7047957cfb8fa4cd1caeedcab9f6cc Mon Sep 17 00:00:00 2001 From: Bruce Davie <3101026+drbruced12@users.noreply.github.com> Date: Mon, 28 Jul 2025 17:38:21 +1000 Subject: [PATCH 3/3] More on amplification --- infra.rst | 125 ++++++++++++++++++++++++++++-------------------------- 1 file changed, 65 insertions(+), 60 deletions(-) diff --git a/infra.rst b/infra.rst index b832a8d..ad51c0a 100644 --- a/infra.rst +++ b/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,47 +696,48 @@ effects in and beyond China. `__. Computer Communications Review, July 2012. -.. sidebar:: 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 to 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.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, @@ -848,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: @@ -859,7 +862,9 @@ recently. APNIC Blog, May 2024. -8.2.2 Encrypted DNS (DoH, DoT, ODNS) + + +8.2.3 Encrypted DNS (DoH, DoT, ODNS) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~