You can also add a include to your unbound.conf to deny response for invalid domains: https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml
local-zone: "0.in-addr.arpa." deny local-zone: "10.in-addr.arpa." deny local-zone: "127.in-addr.arpa." deny local-zone: "254.169.in-addr.arpa." deny ... and so on. Em seg, 21 de out de 2019 às 16:59, Saksham Manchanda <[email protected]> escreveu: > > We have been seeing this kind of traffic in a lot of places. The > auth-server method works. > > Also attached it a implementation of drop-tld > > drop-tld: <yes/no> > > Default no. Drop exactly 2 label queries from client(. being one label). > > > This is generally useful because we don't see many uses for a client > query asking for TLD information. > > > On 10/21/19 1:26 PM, Eduardo Schoedler via Unbound-users wrote: > > You can cache root zone: > > > > # Authority zones > > # The data for these zones is kept locally, from a file or downloaded. > > # The data can be served to downstream clients, or used instead of the > > # upstream (which saves a lookup to the upstream). The first example > > # has a copy of the root for local usage. The second serves example.org > > # authoritatively. zonefile: reads from file (and writes to it if you also > > # download it), master: fetches with AXFR and IXFR, or url to zonefile. > > # With allow-notify: you can give additional (apart from masters) sources of > > # notifies. > > auth-zone: > > name: "." > > for-downstream: no > > for-upstream: yes > > fallback-enabled: yes > > master: e.root-servers.net > > master: f.root-servers.net > > master: b.root-servers.net > > master: c.root-servers.net > > master: g.root-servers.net > > master: k.root-servers.net > > zonefile: "/etc/unbound/root.zone" > > > > > > > > > > Em seg, 21 de out de 2019 às 13:01, Joe Abley via Unbound-users > > <[email protected]> escreveu: > >> Hi, > >> > >> RFC 8198, which was implemented in Unbound 1.7.0. > >> > >> https://nlnetlabs.nl/news/2018/Mar/15/unbound-1.7.0-released/ > >> > >> > >> Joe > >> > >>> On 21 Oct 2019, at 11:57, B. Cook via Unbound-users > >>> <[email protected]> wrote: > >>> > >>> is there a way to address these locally? > >>> > >>> Without passing them to an upstream recursor? > >>> > >>> 10.20.8.29 is unbound and these are logs from dns-over-http client (aur > >>> ports) > >>> > >>> 10.20.8.29:15020 - - [21/Oct/2019:11:49:13 -0400] "hbkuojyles. IN A" > >>> 10.20.8.29:13033 - - [21/Oct/2019:11:49:13 -0400] "fgtfkkdxgwfa. IN A" > >>> 10.20.8.29:56696 - - [21/Oct/2019:11:49:13 -0400] "hbkuojyles. IN A" > >>> 10.20.8.29:62727 - - [21/Oct/2019:11:49:13 -0400] "xkmnguqpjx. IN A" > >>> 10.20.8.29:16633 - - [21/Oct/2019:11:49:13 -0400] "xkmnguqpjx. IN A" > >>> 10.20.8.29:24331 - - [21/Oct/2019:11:49:13 -0400] "xkmnguqpjx. IN A" > >>> 10.20.8.29:35893 - - [21/Oct/2019:11:49:13 -0400] "gmjisoen. IN A" > >>> 10.20.8.29:31220 - - [21/Oct/2019:11:49:13 -0400] "rxdqenbginmvnm. IN A" > >>> 10.20.8.29:10867 - - [21/Oct/2019:11:49:14 -0400] "esfvwynlyoxgox. IN A" > >>> > >>> Is there someway to limit these? > >>> > >>> the randomly come in bursts from clients doing various checking.. > >>> > >>> 10.20.8.29:59511 - - [21/Oct/2019:11:54:40 -0400] "uppkncjqrg. IN A" > >>> 10.20.8.29:29935 - - [21/Oct/2019:11:54:40 -0400] "sfedxwtllfx. IN A" > >>> 10.20.8.29:37957 - - [21/Oct/2019:11:54:40 -0400] "ewskqfu. IN A" > >>> 10.20.8.29:6215 - - [21/Oct/2019:11:54:40 -0400] "cfrwvnynxfquzr. IN A" > >>> 10.20.8.29:53225 - - [21/Oct/2019:11:54:40 -0400] "ovtxiaeztpaoxj. IN A" > >>> 10.20.8.29:9016 - - [21/Oct/2019:11:54:40 -0400] "kmavvjppntn. IN A" > >>> 10.20.8.29:11245 - - [21/Oct/2019:11:54:40 -0400] "fkshwbgafpp. IN A" > >>> 10.20.8.29:60053 - - [21/Oct/2019:11:54:40 -0400] "iqkjgvysb. IN A" > >>> > >>> Thanks in advance. > >>> > >>> -- > >>> > >>> This message may contain confidential information and is intended only for > >>> the individual(s) named. If you are not an intended recipient you are not > >>> authorized to disseminate, distribute or copy this e-mail. Please notify > >>> the sender immediately if you have received this e-mail by mistake and > >>> delete this e-mail from your system. > > -- Eduardo Schoedler
