From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [RFC PATCH] Unbound: Deny DNS queries of type ANY Date: Tue, 28 Sep 2021 11:53:04 +0100 Message-ID: In-Reply-To: <2ed9b3f6-28eb-3922-5501-f431df64e5ba@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1759867926772566647==" List-Id: --===============1759867926772566647== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, I would like to NACK this change. > On 25 Sep 2021, at 08:53, Peter M=C3=BCller wr= ote: >=20 > While not inherently malicious, ANY queries are nowadays commonly used > in DNS-based DDoS attacks, since nameservers must respond with a _very_ > large answer to a very small query. ANY requests are definitely very common, but they are not the only record typ= e being used for this. > In 2015, Cloudflare stopped responding to them altogether (see: > https://blog.cloudflare.com/deprecating-dns-any-meta-query-type/), and > several discussions took place in various DNS operator working groups, > ultimately resulting in RFC 8482 (https://datatracker.ietf.org/doc/html/rfc= 8482). Yes sure. Why would Cloudflare try to fix things when there is a much cheaper= alternative? Just turning everything off. > Aside from - very uncommon - debugging or enumerating purposes, there is > little legitimate reason why a client behind IPFire needs to conduct an > ANY query. In fact, no up-to-date implementation of some legitimate software > has been observed doing so in the recent past. Indeed clients (if every) send an ANY query. However, debugging DNS is a comm= on operation and sending an ANY query helps to figure out any problems very q= uickly. I would therefore like to NACK this proposal because we are basically destroy= ing DNS here. We are making it harder for users to use and debug their DNS sy= stem. I am personally affected by this change. I also do not see any benefit here. IPFire=E2=80=99s DNS system isn=E2=80=99t= designed to be publicly accessible on the internet. If people decide to do s= o, then it requires more configuration and they are welcome to add this confi= guration line to filter ANY requests, too - do they wish so. > To prevent IPFire from unintentionally participating in a DDoS attack, > this patch changes the handling of ANY queries, forbidding them > altogether. This change isn=E2=80=99t helping anyone. Maybe Cloudflare wants to look like= the =E2=80=9Cgood guy=E2=80=9D, but filtering ANY requests doesn=E2=80=99t c= hange anything. What about DNSSEC-signed responses? They would be larger and = make an amplification attack possible. What about TXT records? Are we going t= o filter them next if they are longer than the query packet? That probably wo= uld destroy DMARC, DKIM, SPF, IPSECKEY, SSHFP and many many other application= s. It is a common thing on the internet to send a small query and receive a bigg= er response. It is part of its nature. However blocking that is only destroyi= ng our protocols which become limited in their application. I could live with a rate-limiting which is what the Lightning Wire Labs DNS s= ervice is applying. That way, debugging is still possible, and abusing the se= rvice isn=E2=80=99t. There is also rate-limiting on all other record types, j= ust not as strict as on ANY queries. -Michael > Signed-off-by: Peter M=C3=BCller > --- > config/unbound/unbound.conf | 1 + > 1 file changed, 1 insertion(+) >=20 > diff --git a/config/unbound/unbound.conf b/config/unbound/unbound.conf > index 9d5e840dd..3848b0f71 100644 > --- a/config/unbound/unbound.conf > +++ b/config/unbound/unbound.conf > @@ -40,6 +40,7 @@ server: > harden-large-queries: yes > harden-referral-path: yes > aggressive-nsec: yes > + deny-any: yes >=20 > # TLS > tls-cert-bundle: /etc/ssl/certs/ca-bundle.crt > --=20 > 2.26.2 --===============1759867926772566647==--