What's new
  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Diversion Question- Configuring the Cache TTL

jrichard326

Occasional Visitor
On Hagezi's github the following was posted (https://github.com/hagezi/dns-blocklists/issues/4651)

"The DNS flood can be reduced somewhat if you have the option of configuring the cache TTL (time to live) for blocked domains in the DNS. I use a blocked TTL of 3600 sec. so that a new request to the DNS is only made after 1 hour if a domain is blocked, unless the client ignores the TTL.
Flooding the DNS is a typical tracker behaviour when the tracker is blocked. Some trackers then go wild and make requests every second."

Is it possible to adjust TTL in Diversion?
 
Thank you. I will give it a try.
 
Might enabling ‘firewall > dos protection’, block a flood such as this?
 
On Hagezi's github the following was posted (https://github.com/hagezi/dns-blocklists/issues/4651)

"The DNS flood can be reduced somewhat if you have the option of configuring the cache TTL (time to live) for blocked domains in the DNS. I use a blocked TTL of 3600 sec. so that a new request to the DNS is only made after 1 hour if a domain is blocked, unless the client ignores the TTL.
Flooding the DNS is a typical tracker behaviour when the tracker is blocked. Some trackers then go wild and make requests every second."

Is it possible to adjust TTL in Diversion?

You could use /jffs/configs/dnsmasq.conf.add to set local-ttl=3600 and see how it goes.

I tried dave’s suggestion, but I was still seeing DNS flooding from that domain.
What finally fixed it for good was adding the following to
/jffs/configs/dnsmasq.conf.add:

Code:
address=/minerva.devices.a2z.com/0.0.0.0 #stop_dns_flood_ipv4#
address=/minerva.devices.a2z.com/::1 #stop_dns_flood_ipv6#
address=/global.telemetry.insights.video.a2z.com/0.0.0.0 #stop_dns_flood_ipv4#
address=/global.telemetry.insights.video.a2z.com/::1 #stop_dns_flood_ipv6#
local-ttl=3600 #dnsmasq_cache_ttl#
neg-ttl=3600 #NXDOMAIN_cache_ttl#

At first, I only added this:
Code:
address=/minerva.devices.a2z.com/0.0.0.0 #stop_dns_flood_ipv4#
address=/minerva.devices.a2z.com/::1 #stop_dns_flood_ipv6#
local-ttl=3600 #dnsmasq_cache_ttl#
neg-ttl=3600 #NXDOMAIN_cache_ttl#

Then I restarted dnsmasq:
Code:
service restart_dnsmasq

Right after that, a different domain started flooding DNS:
global.telemetry.insights.video.a2z.com

So I added that domain to the same file, as shown above. After that, the flooding stopped.

Explaining what I did as simple as i can:
==========================
address=/minerva.devices.a2z.com/0.0.0.0
If a device asks for this domain over IPv4, the router answers locally with a fake IP instead of forwarding the request to the internet. That stops repeat lookups from going upstream.

address=/minerva.devices.a2z.com/::1
Same idea, but for IPv6.
Same thing for IPv6. The router replies with its own loopback address, which prevents IPv6 lookups from hammering dnsmasq.

local-ttl=3600
Tells dnsmasq to cache these blocked answers for one hour. If a device keeps asking every few seconds, dnsmasq just reuses the cached response instead of processing it again.

neg-ttl=3600
This applies to “nothing exists here” answers (NXDOMAIN).
Dnsmasq will cache those “doesn’t exist” responses for 1 hour, instead of rechecking them constantly. In another word, this caches NXDOMAIN for IPv4 and IPv6 negative responses, but since these are AAAA queries without an explicit block, dnsmasq handles them as “NODATA” and they still appear in logs occasionally. Result "flood is dramatically reduced", but not completely gone for AAAA queries, that's why i have address=/minerva.devices.a2z.com/::1 as showing above.

In short, I'm not just blocking the domain but teaching the router to answer it once and shut up about it for an hour.
That’s why DNS flood dropped from nonstop spam to occasional entries.
 
Keepout Ranges...

0.0.0.0/8 - Used for broadcast messages to the current network
::1/128 - loopback

Don't redirect hosts to those addresses...
 
local-ttl=3600
Tells dnsmasq to cache these blocked answers for one hour. If a device keeps asking every few seconds, dnsmasq just reuses the cached response instead of processing it again.
This parameter doesn’t affect dnsmasq’s caching, it informs clients to cache this response for up to an hour. Since these blocked domains are usually configured directly in dnsmasq via its loaded config, there’s nothing for dnsmasq to cache. Clients can choose to respect the TTL or not.
 
Keepout Ranges...

0.0.0.0/8 - Used for broadcast messages to the current network
::1/128 - loopback

Don't redirect hosts to those addresses...
That make a lot of sense.
Now I am confused. My understanding is that 0.0.0.0/8 is reserved, but when dnsmasq returns 0.0.0.0 for a domain, it simply means “nowhere”. In that case, why i cannot use any of those addresses is there a down side if i did? I am just trying to understand and avoid anything I may do wrong..lol

Edit:
I re-read your post again and it made me realize I wasn’t using any ranges—just 0.0.0.0 and ::1. Given that, is it safe to keep what I had?
address=/minerva.devices.a2z.com/0.0.0.0
address=/minerva.devices.a2z.com/::1


This parameter doesn’t affect dnsmasq’s caching, it informs clients to cache this response for up to an hour. Since these blocked domains are usually configured directly in dnsmasq via its loaded config, there’s nothing for dnsmasq to cache. Clients can choose to respect the TTL or not.
You are absolutely correct, I just didn't phrase it well.
 
Last edited:
You can use an unassigned address ... such as 192.168.1.99 (assuming that your network is within the range 192.168.1.0/8)
(Change this as applicable.)

It will go nowhere ... make sure that requests for 192.168.1.0/8 do not go outside of the local network.
(It should not unless you somehow force it !!!)

Remember to NEVER assign it in the future.

i.e. address=/minerva.devices.a2z.com/192.168.1.99

It probably is 'bad form' or something but does work !!!

:)
 
Edit: I re-read your post again and it made me realize I wasn’t using any ranges—just 0.0.0.0 and ::1. Given that, is it safe to keep what I had?
address=/minerva.devices.a2z.com/0.0.0.0
address=/minerva.devices.a2z.com/::1
Yes it is (but there's a better way). The previous post misses the point. While technically using 0.0.0.0 as a DNS blackhole is not what it is intended for, it's been a common method of blocking domains for at least 20 years.

The better way would be to use this line instead:
Code:
local=/minerva.devices.a2z.com/
This returns an NXDOMAIN instead of 0.0.0.0. This may or may not satisfy your rogue client.
 
Yes it is (but there's a better way). The previous post misses the point. While technically using 0.0.0.0 as a DNS blackhole is not what it is intended for, it's been a common method of blocking domains for at least 20 years.

The better way would be to use this line instead:
Code:
local=/minerva.devices.a2z.com/
This returns an NXDOMAIN instead of 0.0.0.0. This may or may not satisfy your rogue client.
Thanks for the prompt/reminder.
I am actually already doing this (!!!???) and it slipped my mind (or my mind slipped) ... too many mince pies & glasses of sherry :)
 
Yes it is (but there's a better way). The previous post misses the point. While technically using 0.0.0.0 as a DNS blackhole is not what it is intended for, it's been a common method of blocking domains for at least 20 years.

The better way would be to use this line instead:
Code:
local=/minerva.devices.a2z.com/
This returns an NXDOMAIN instead of 0.0.0.0. This may or may not satisfy your rogue client.

I tried it but I still see that domain flooding dns more often, almost non-stop!!!!
Code:
dnsmasq[6896]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN

When using the dns black-hole 0.0.0.0 and ::1, I don't see it that often.
Code:
dnsmasq[17684]: query[A] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.service.minerva.devices.a2z.com from 192.168.x.x
dnsmasq[17684]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is 0.0.0.0
dnsmasq[17684]: query[AAAA] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
dnsmasq[17684]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is ::1
 
I tried it but I still see that domain flooding dns more often, almost non-stop!!!!
Code:
dnsmasq[6896]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN

When using the dns black-hole 0.0.0.0 and ::1, I don't see it that often.
Code:
dnsmasq[17684]: query[A] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.service.minerva.devices.a2z.com from 192.168.x.x
dnsmasq[17684]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is 0.0.0.0
dnsmasq[17684]: query[AAAA] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
dnsmasq[17684]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is ::1
It would be interesting to see the timestamps (across multiple queries) for both methods.
 
This could be because the negative replies (NXDOMAIN) are not being cached as long as the reply when using 0.0.0.0.

Your local-ttl setting is 3600.

The default time-to-live for negative replies is set by:

neg-ttl=<time>

i.e. neg-ttl=7200

This equates to holding the negative reply in the cache for 2 hours (7200 seconds).
This overides the TTL for NXDOMAIN set by the value in the SOA record of the DNS Server being queried.

Try setting neg-ttl=7200
I don't see how neg-ttl= will help. That parameter caches (in dnsmasq) the response from the upstream server. When using the local= option nothing is being sent upstream or forwarded to the client.

However, local-ttl= might have an effect as per the original reply to this thread.
 
Last edited:
=========================================
Corrected Text: Had problems posting original message !!!???
=========================================
0.0.0.0 will have a default ttl of 3600

NXDOMAIN will have a ttl as set by the value in the SOA record of the DNS Server.

This ttl may be shorter than 3600 therefore the DNS Server is queried more often than the value for 0.0.0.0 is retreived from the cache.

Solution is to increase the ttl for the NXDOMAIN values by using the neg-ttl overide.


The default time-to-live for negative replies is set by:


neg-ttl=<time>

i.e. neg-ttl=7200


This equates to holding the negative reply in the cache for 2 hours (7200 seconds).

This overides the TTL for NXDOMAIN set by the value in the SOA record of the DNS Server being queried.



Try setting neg-ttl=7200
 
Last edited:
It would be interesting to see the timestamps (across multiple queries) for both methods.

I captured about 2 seconds of queries and replies: SPOILER, it is bananas and non-stop.
The terminal screen was rolling up so fast and I had ctrl+c to stop the flow to capture the following.
Code:
Dec 25 21:30:22 dnsmasq[10950]: query[AAAA] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:22 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:22 dnsmasq[10950]: query[A] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:22 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:22 dnsmasq[10950]: query[AAAA] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:22 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:22 dnsmasq[10950]: query[A] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:22 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:23 dnsmasq[10950]: query[AAAA] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:23 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:23 dnsmasq[10950]: query[A] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:23 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:23 dnsmasq[10950]: query[AAAA] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:23 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:23 dnsmasq[10950]: query[A] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:23 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:23 dnsmasq[10950]: query[AAAA] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:23 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:23 dnsmasq[10950]: query[A] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:23 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:23 dnsmasq[10950]: query[AAAA] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:23 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:23 dnsmasq[10950]: query[A] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:23 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:23 dnsmasq[10950]: query[AAAA] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:23 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:23 dnsmasq[10950]: query[A] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:23 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:23 dnsmasq[10950]: query[AAAA] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:23 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:23 dnsmasq[10950]: query[A] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:23 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:23 dnsmasq[10950]: query[AAAA] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:23 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:23 dnsmasq[10950]: query[A] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:23 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:23 dnsmasq[10950]: query[AAAA] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:23 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:23 dnsmasq[10950]: query[A] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:23 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:24 dnsmasq[10950]: query[AAAA] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:24 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:24 dnsmasq[10950]: query[A] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:24 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:24 dnsmasq[10950]: query[AAAA] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:24 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:24 dnsmasq[10950]: query[A] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:24 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:24 dnsmasq[10950]: query[AAAA] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:24 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN
Dec 25 21:30:24 dnsmasq[10950]: query[A] 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com from 192.168.x.x
Dec 25 21:30:24 dnsmasq[10950]: config 20c21bbc399f9ef2c91f0365d42531bf5023b70d32dbaf7f53f0b49d5110f72.xx.prod.service.minerva.devices.a2z.com is NXDOMAIN


=========================================
Corrected Text: Had problems posting original message !!!???
=========================================
0.0.0.0 will have a default ttl of 3600

NXDOMAIN will have a ttl as set by the value in the SOA record of the DNS Server.

This ttl may be shorter than 3600 therefore the DNS Server is queried more often than the value for 0.0.0.0 is retreived from the cache.

Solution is to increase the ttl for the NXDOMAIN values by using the neg-ttl overide.


The default time-to-live for negative replies is set by:


neg-ttl=<time>

i.e. neg-ttl=7200


This equates to holding the negative reply in the cache for 2 hours (7200 seconds).

This overides the TTL for NXDOMAIN set by the value in the SOA record of the DNS Server being queried.



Try setting neg-ttl=7200

I tried that and it looked very optimistic as I didn't see any dns flood for a about ~ 4 min and then it went bananas after that, laterally non-stop. Don't these queries give up and stop at some point, geez.

Now, the only way for me to stop it is to use the dns black-hole of 0.0.0.0 and ::1 :(.
 
+
Now, the only way for me to stop it is to use the dns black-hole of 0.0.0.0 and ::1 :(.
+
I will still keep
Code:
neg-ttl=7200
as it seems a nice idea.

Here is what I have currently:
Code:
address=/minerva.devices.a2z.com/0.0.0.0
address=/minerva.devices.a2z.com/::1
address=/global.telemetry.insights.video.a2z.com/0.0.0.0
address=/global.telemetry.insights.video.a2z.com/::1
local-ttl=3600
neg-ttl=7200

EDIT:
Also, I have just noticed the cpu is spiking to about 40% on all 4 cores.
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Members online

Back
Top