From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bernhard Bitsch To: development@lists.ipfire.org Subject: Re: [RFC PATCH] Unbound: Deny DNS queries of type ANY Date: Tue, 28 Sep 2021 14:17:56 +0200 Message-ID: In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7871848220717251155==" List-Id: --===============7871848220717251155== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello, after reading Michael's annotations, I must agree to his arguments. So I reject my ACK. Regards, Bernhard Am 28.09.2021 um 12:53 schrieb Michael Tremer: > Hello, >=20 > I would like to NACK this change. >=20 >> On 25 Sep 2021, at 08:53, Peter M=C3=BCller w= rote: >> >> 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. >=20 > ANY requests are definitely very common, but they are not the only record t= ype being used for this. >=20 >> 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/rf= c8482). >=20 > Yes sure. Why would Cloudflare try to fix things when there is a much cheap= er alternative? Just turning everything off. >=20 >> 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 softwa= re >> has been observed doing so in the recent past. >=20 > Indeed clients (if every) send an ANY query. However, debugging DNS is a co= mmon operation and sending an ANY query helps to figure out any problems very= quickly. >=20 > I would therefore like to NACK this proposal because we are basically destr= oying DNS here. We are making it harder for users to use and debug their DNS = system. I am personally affected by this change. >=20 > 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 so, then it requires more configuration and they are welcome to add this c= onfiguration line to filter ANY requests, too - do they wish so. >=20 >> To prevent IPFire from unintentionally participating in a DDoS attack, >> this patch changes the handling of ANY queries, forbidding them >> altogether. >=20 > This change isn=E2=80=99t helping anyone. Maybe Cloudflare wants to look li= ke the =E2=80=9Cgood guy=E2=80=9D, but filtering ANY requests doesn=E2=80=99t= change anything. What about DNSSEC-signed responses? They would be larger an= d make an amplification attack possible. What about TXT records? Are we going= to filter them next if they are longer than the query packet? That probably = would destroy DMARC, DKIM, SPF, IPSECKEY, SSHFP and many many other applicati= ons. >=20 > It is a common thing on the internet to send a small query and receive a bi= gger response. It is part of its nature. However blocking that is only destro= ying our protocols which become limited in their application. >=20 > I could live with a rate-limiting which is what the Lightning Wire Labs DNS= service is applying. That way, debugging is still possible, and abusing the = service isn=E2=80=99t. There is also rate-limiting on all other record types,= just not as strict as on ANY queries. >=20 > -Michael >=20 >> Signed-off-by: Peter M=C3=BCller >> --- >> config/unbound/unbound.conf | 1 + >> 1 file changed, 1 insertion(+) >> >> 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 >> >> # TLS >> tls-cert-bundle: /etc/ssl/certs/ca-bundle.crt >> --=20 >> 2.26.2 >=20 --===============7871848220717251155==--