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 On 22. 10. 19 14:26, B. Cook via Unbound-users wrote: > 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.. > > > On Mon, Oct 21, 2019 at 11:57 AM B. Cook <[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.
