How to not pass these upstream?

[Petr Špaček]

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 <bcook at poughkeepsieschools.org> 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.