How to not pass these upstream?

[Saksham Manchanda]

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.
>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diff
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20191021/df2a8a0c/attachment.ksh>