5 ms·

I wish the DNS RFC had included a MUST support for ANY requests on the server side, and wildcard domain support (e.g. ANY for label *.domain.tld). That would h

I wish the DNS RFC had included a MUST support for ANY requests on the server side, and wildcard domain support (e.g. ANY for label *.domain.tld). That would have made life so much easier. The state now is that clients cannot even rely on multiple request questions to be answered correctly...and is the reason why every Browser sends out separate DNS questions for A and AAAA and TXT etc. All the overhead for parsing message compression is also kinda useless when you have only one record with the same labels answered all the time.

addingnumbers 5y ago
Sounds similar to AXFR queries, which it is best practice to disable. It's not advisable in general to provide information about hosts that the querier didn't request specifically and individually. "A remote unauthenticated user may observe internal network structure, learning information useful for other directed attacks." https://us-cert.cisa.gov/ncas/alerts/TA15-103A https://us-cert.cisa.gov/ncas/alerts/TA15-103A
LinuxBender 5y ago
Those requests are most often used in combination with spoofed packets to DDoS others. Many of us block those requests.
fanf2 5y ago
QTYPE=ANY has very tricky interaction with caches. The standard semantics are that ANY means whatever the server has, not all the types at the qname. So, if you have a mixture of v4-only and dual stack clients, you can’t predict whether the cache will have just A or both A and AAAA, so ANY will be worse than just making both queries concurrently. And because ANY interacts badly with UDP fragmentation and certain backend database design, and because it has been abused for DDoS attacks, it is increasingly common for it to return a subset of the records that the server has. So I am afraid there is no realistic way to make ANY mean ALL. Multiple questions don’t work because DNS packets only have one RCODE so there is no way to signal a mixture of success and failure. I don’t know why the DNS message format has a QDCOUNT field for multiple questions. Yeah DNS compression is problematic in many ways, but in many cases it allows the answer name(s) to be represented by 0x000C. In another context, the root-servers.net domain looks unnecessarily verbose but having all the servers in the same domain makes good use of compression.
- cookiengineer 5y ago
  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...
  - ate53 5y ago
    > Multiple questions inside the same packet are quite common in DNS-SD based multicast queries. mDNS is DNS in name only. Yes the wire format is mostly the same but the semantics are not. > Note that technically, servers have to support TCP via port 53, too...but they never actually do :) No? I haven't come across a widely used server implementation that doesn't support TCP in a very long time. What server software are you referring to? > ...there are literally dozens of ways to fix this in a better way than disabling ANY completely. As fanf2 said, ANY isn't ALL, and so it doesn't do what most people would want it to do anyway.

addingnumbers 5y ago

Sounds similar to AXFR queries, which it is best practice to disable. It's not advisable in general to provide information about hosts that the querier didn't request specifically and individually. "A remote unauthenticated user may observe internal network structure, learning information useful for other directed attacks." https://us-cert.cisa.gov/ncas/alerts/TA15-103A https://us-cert.cisa.gov/ncas/alerts/TA15-103A

LinuxBender 5y ago

Those requests are most often used in combination with spoofed packets to DDoS others. Many of us block those requests.

fanf2 5y ago

QTYPE=ANY has very tricky interaction with caches. The standard semantics are that ANY means whatever the server has, not all the types at the qname. So, if you have a mixture of v4-only and dual stack clients, you can’t predict whether the cache will have just A or both A and AAAA, so ANY will be worse than just making both queries concurrently. And because ANY interacts badly with UDP fragmentation and certain backend database design, and because it has been abused for DDoS attacks, it is increasingly common for it to return a subset of the records that the server has. So I am afraid there is no realistic way to make ANY mean ALL. Multiple questions don’t work because DNS packets only have one RCODE so there is no way to signal a mixture of success and failure. I don’t know why the DNS message format has a QDCOUNT field for multiple questions. Yeah DNS compression is problematic in many ways, but in many cases it allows the answer name(s) to be represented by 0x000C. In another context, the root-servers.net domain looks unnecessarily verbose but having all the servers in the same domain makes good use of compression.

cookiengineer 5y ago
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...
- ate53 5y ago
  > Multiple questions inside the same packet are quite common in DNS-SD based multicast queries. mDNS is DNS in name only. Yes the wire format is mostly the same but the semantics are not. > Note that technically, servers have to support TCP via port 53, too...but they never actually do :) No? I haven't come across a widely used server implementation that doesn't support TCP in a very long time. What server software are you referring to? > ...there are literally dozens of ways to fix this in a better way than disabling ANY completely. As fanf2 said, ANY isn't ALL, and so it doesn't do what most people would want it to do anyway.