Hi folks,
This question is directed mainly at the NSD developers, but I'm posting it here for knowledge sharing.
NSD with default settings, returns a partial response to ANY queries, whether the queries are made over UDP or TCP. I did not expect this.
I went through all the release notes, and found this:
4.1.27
I just explained to knot developers yesterday why it's bad idea to
respond any queries on tcp on authoritative server.
Let's try to do it again now here.
As long as authoritative server answers to any queries with tcp it is
possible to do dns amplification attack like described here:
https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack/
So dns server responding to any query (especially applicable when
dnssec is used) can be used as a tool for dns amplification attack. It
doesn't matter if query is udp or tcp, resolvers can query with tcp at
any time. And still respond to victims with udp. So It's important part
of mitigation to do it at all levels.
Only way to prevent this is to implment rfc8482 for both udp and tcp on
authoritative server.
Hello Tuomo,
I just explained to knot developers yesterday why it's bad idea to
respond any queries on tcp on authoritative server.Let's try to do it again now here.
As long as authoritative server answers to any queries with tcp it is
possible to do dns amplification attack like described here:https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack/
This Cloudflare article is all about amplification over UDP, and it is something that we all understand. The article makes NO mention of amplification over TCP (because it's not possible), so I don't know what you are talking about.
So dns server responding to any query (especially applicable when
dnssec is used) can be used as a tool for dns amplification attack. It
doesn't matter if query is udp or tcp, resolvers can query with tcp at
You are wrong. DNS amplification attacks cannot be done over TCP.
And if perchance you're referring to open resolvers that are made to do ANY queries... well, minimising responses to ANY over UDP solves that quite neatly. They won't retry over TCP.
any time. And still respond to victims with udp. So It's important part
of mitigation to do it at all levels.Only way to prevent this is to implment rfc8482 for both udp and tcp on
authoritative server.
RFC 8482 section 4.4 specifically discusses response behaviour depending on transport. Over UDP, it is good to minimise responses. On the other hand, it's quite okay to provide a complete answer over TCP.
Regards,
Anand
You missed the point.
If authoritative answers over tcp with any data, resolver dns can
answer to victim with udp.
So at authoritative it is important not to answer to any.
Hi Tuomo,
You missed the point.
If authoritative answers over tcp with any data, resolver dns can
answer to victim with udp.
No, it seems you haven't understood how a resolver works. Suppose a signed zone's apex has SOA, A, AAAA, TXT, DNSKEY, MX and NS records, along with RRSIG records for all these.
Now suppose a resolver queries for these records individually, one at a time, and caches them all.
Finally, suppose a client queries this resolver with an ANY for this zone's apex. The resolver will return *all* those cached records to the client.
Whether a resolver gets all these records from the authoritative server with a single ANY query, or by querying for the records individually, its response to a downstream client's ANY query will be the same. I can tell you with certainty that at least BIND behaves this way, because I have experimented and observed.
Before you reply to this thread to tell me I'm wrong, please set up a resolver or two, and test this yourself to understand it 
Regards,
Anand
On 07/05/2020 22:11, Tuomo Soini wrote:
Hi Tuomo,
You missed the point.
If authoritative answers over tcp with any data, resolver dns can
answer to victim with udp.No, it seems you haven't understood how a resolver works. Suppose a signed zone's apex has SOA, A, AAAA, TXT, DNSKEY, MX and NS records, along with RRSIG records for all these.
Now suppose a resolver queries for these records individually, one at a time, and caches them all.
Finally, suppose a client queries this resolver with an ANY for this zone's apex. The resolver will return *all* those cached records to the client.
Whether a resolver gets all these records from the authoritative server with a single ANY query, or by querying for the records individually, its response to a downstream client's ANY query will be the same. I can tell you with certainty that at least BIND behaves this way, because I have experimented and observed.
The two of you keep only bringing up one case, amplification with spoofed source, or open resolver used for amplification. Both are problems.
An authoritative server preventing ANY over TCP might be helping a little bit, but not much. That degree is where both of you disagree. There is an implicit requirement that doing ANY over TCP could be useful, for debugging, and should perhaps not be blocked.
Before you reply to this thread to tell me I'm wrong, please set up a resolver or two, and test this yourself to understand it
This comment was unnecessary and impolite.
Paul
Whether a resolver gets all these records from the authoritative
server with a single ANY query, or by querying for the records
individually, its response to a downstream client's ANY query will be
the same. I can tell you with certainty that at least BIND behaves
this way, because I have experimented and observed.
Sure. Named might work that way today. But the problem is all the dns
resolvers out there which are open. Not only latest named versions.
I haven't checked lately, but when I investigated these attacks,
hundreds of open dns servers queried any from authoritative dns. I can
only hope those are now updated to versions which refuse to answer to
any with udp - but can you guarantee that?
Before you reply to this thread to tell me I'm wrong, please set up a
resolver or two, and test this yourself to understand it
I'm not saying what you say is wrong - but it is not complete story.
google dns might have fixed that issue now, I haven't checked that
lately either. Our authoritative dns serves were under attack for at
least two years and we were required to block ANY queries with firewall
because there was no way to disable any queries some years ago with
authoritative dns software.