Multiple questions inside the same packet are quite common in DNS-SD based multicast queries. The idea there is to save DNS packets so that you only ask for a

Multiple questions inside the same packet are quite common in DNS-SD based multicast queries. The idea there is to save DNS packets so that you only ask for a pointer (PTR) to a service identifier and get as a response all information that you need (address via A/AAAA, hostname and port via SRV, API version and necessary parameters via TXT etc). My point was exactly about the QDCOUNT field because its intent clearly was to be able to save unnecessary packets, but in practice, nobody uses it and wastes a lot of bandwidth. Note that technically, servers have to support TCP via port 53, too...but they never actually do :) As a sidenote: 0x0c is only appearing because it's the start of the label identifier of the first question. This can be a byte pointer to anything, and, if labels of records are crafted maliciously, even lead to an infinite loop or buffer overflow on clients/resolvers with naive implementations (see NAMEWRECK vulnerability [1]). Regarding the ANY problem and why it's disabled: I think this is the wrong point in the architecture to fix DDoS or amplification attacks and the abuse of a public resolver. ISPs or ASNs could simply block UDP traffic which has a different source/target network. That alone would reduce most of the DDoS traffic and probably fix most of the abuse. I mean, at some point you have to wonder: What happens when hackers start to use TXT queries to DDoS a target because their buffer size is larger, too? Just disable TXT? I hope you understand my point. A DNS server could also always block via a throttling mechanism or increase the TTL to limit the bandwidth to a specific target, additionally to the comparison of source/target addresses. If someone with a different origin keeps requesting DNS queries, you can likely assume that it's an amplification attack...there are literally dozens of ways to fix this in a better way than disabling ANY completely. [1] https://www.forescout.com/blog/forescout-and-jsof-disclose-new-dns-vulnerabilities-impacting-millions-of-enterprise-and-consumer-devices/ https://www.forescout.com/blog/forescout-and-jsof-disclose-n...