How to not pass these upstream?

Unbound
1

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.

2

Hi,

RFC 8198, which was implemented in Unbound 1.7.0.

https://nlnetlabs.nl/news/2018/Mar/15/unbound-1.7.0-released/

Joe

3

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"

4

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.

(attachments)

diff (3.13 KB)

5

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.

6

Thank you for the answers, and I've read up on 8198; I am not sure if
I gave confusing information about the log entries..

These are unbound logs: (unbound in runit and logs are svlogd.. fwiw)

[1571746280] unbound[1249594:1] info: 10.20.77.223 qfxcewre. A IN
[1571746280] unbound[1249594:1] info: resolving qfxcewre. A IN
[1571746280] unbound[1249594:1] info: response for qfxcewre. A IN
[1571746280] unbound[1249594:1] info: reply from <.> 10.20.8.29#53
[1571746280] unbound[1249594:1] info: query response was NXDOMAIN ANSWER
[1571746280] unbound[1249594:1] info: 10.20.77.223 bilehriwzwmzp. A IN
[1571746280] unbound[1249594:1] info: resolving bilehriwzwmzp. A IN
[1571746280] unbound[1249594:0] info: 10.20.77.223 cfznhnqnsnpacw. A IN
[1571746280] unbound[1249594:0] info: resolving cfznhnqnsnpacw. A IN
[1571746280] unbound[1249594:1] info: response for bilehriwzwmzp. A IN
[1571746280] unbound[1249594:1] info: reply from <.> 10.20.8.29#53
[1571746280] unbound[1249594:1] info: query response was NXDOMAIN ANSWER
[1571746280] unbound[1249594:0] info: response for cfznhnqnsnpacw. A IN
[1571746280] unbound[1249594:0] info: reply from <.> 10.20.8.29#53
[1571746280] unbound[1249594:0] info: query response was NXDOMAIN ANSWER

This is on a recursive host (unbound) passed from dhcp to a client,
(and I would imagine) 10.20.77.223 (windows, mac, or chromebook) is
opening chrome, and chrome is doing "that thing it does when it opens,
for whatever reason they think this is ok".

I have many hosts and this generates a ton of noise, which is fine
locally, but it all gets passed upstream to an actual recursor..

(client 10.20.77.223 asks host 10.20.0.43 which passes to 10.20.8.29,
8.29 goes to one of two hosts with Internet connectivity, which passes
to an upstream, only to return nxdomain after 5+ hosts are involved..
and the whole process repeats because things are proxied..)

it looks like to me that, 8198 is working with a dnssec signed domain,
and from my read of the rfc, wildcard entries that will answer to more
than one request are what this setting works for.. (I could be totally
wrong)

If my understanding is right, (rhetorically) what domain do these
queries belong to.. unbound currently says they belong to 'nxdomain',
so I don't know where the dnssec signed domain would be.. unless it's
the actual '.' (root) domain..

Not sure if that helps or makes things more confusing..

Thank you again..

7

Hello,

in short all these queries go to root servers and RFC 8198 will prevent them from being passed upstream once sufficient number of proofs-of-nonexistence are in cache. Just enable DNSSEC validation (and use new-enough version of DNS resolver).

With empty cache the resolver will pass upstream first ~ 2000 queries, fill its cache with proof of nonexistence and answer the rest from cache (until TTL expires). I hope it helps.

Petr Špaček @ CZ.NIC