How to not pass these upstream?

[Eduardo Schoedler]

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
<saksham.manchanda at secure64.com> 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
> > <unbound-users at nlnetlabs.nl> 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 <unbound-users at nlnetlabs.nl> 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