talosintelligence.com domain requests
-
Are you redirecting queries to for other dns to loopback?
-
@johnpoz I am but I don't see this query coming from my LAN when I do packet captures on the LAN interface looking for port 53 activity.
-
Well that only has a ttl of 300 seconds.. So if something it talking to it, that could account for say like 288 queries in a 24 hour period.. But not 16k, unless what is doing the queries has no cache?
-
@johnpoz I even set min ttl to 3600, I know don't shame me :) and it shows the proper ttl count down on the queries but that is the cool thing about dns replies tab is it shows everything even if it is cache hits.
I am just wondering what option that is enabling this and if anyone else is seeing this on their install.
-
Well I am not seeing anything like that at all.
But I don't use pfblocker to look for lists like that. I only use a few lists and all either custom or geo IP lists.
Not going to shame you about the 3600 min ttl, I do the same thing - I hate these 300 second ttls and even worse some that are 60 seconds.
-
@johnpoz Yeah I get a lot of heat online when I tell people I do this, all kinds of lectures about what the DNS owner intended.
I just got tired of all of these cloud services setting 1 minute TTL's and hammering my WAN link with DNS traffic.
Anyways, hopefully someone can chime in on what is causing these DNS requests.
-
Yeah its not really good practice to mess with TTLs.. But then again its not good practice to set ttls to like 60 seconds either ;) Unless you were in the middle of a transition..
Common practice for when moving NS for example, or getting ready to change something for example would be to trim down the ttl to very small number as you get closer and closer to the actual change. So then when the change happens it happens very quickly. Then as it takes effect and all working you would ramp the ttl back up to something sane.
To be honest, many of these dns services site default to very low values - and they charge based upon number of queries. So wouldn't put it past them to try and get number of queries up higher to get more money.
The ones that bug me are the iot devices looking for something.. And they don't have any local cache anyway.. So like everytime they need to check something they have to do another query.. Which might be like every freaking minute anyway. But atleast I can cache is locally vs having to do an external query for it every 5 freaking minutes.
I have yet to find any issue with setting a 1 hour min ttl, other than a drastic reduction in number of external lookups.
edit: But then again I understand how dns works, and if having some sort of problem I would know exactly where to look, and validate it against authoritative NS for whatever, etc. I wouldn't suggest normal users adjust such settings.. So I could see how someone with out actual real world experience in crazy low ttls and how to deal with them might just state best practice.. Which back in the day, no you shouldn't mess with ttls like that.. But then again 10 years ago you wouldn't find services setting 60 second ttls ;) Nor did we have a shit ton of iot devices with no local dns cache trying to ping home to some fqdn every freaking minute ;)
edit2: example just 1 of the fqdn my thermostat looks for every freaking minute
Because it doesn't have a freaking local cache!! And its also just cname that points to place, that has a 60 second TTL..
So this 1 device could create a crazy amount of dns
;; ANSWER SECTION: ic3messaging.cloudapp.net. 60 IN A 13.84.163.27 -
@johnpoz said in talosintelligence.com domain requests:
Yeah its not really good practice to mess with TTLs.. But then again its not good practice to set ttls to like 60 seconds either ;) Unless you were in the middle of a transition..
Common practice for when moving NS for example, or getting ready to change something for example would be to trim down the ttl to very small number as you get closer and closer to the actual change. So then when the change happens it happens very quickly. Then as it takes effect and all working you would ramp the ttl back up to something sane.
To be honest, many of these dns services site default to very low values - and they charge based upon number of queries. So wouldn't put it past them to try and get number of queries up higher to get more money.
The ones that bug me are the iot devices looking for something.. And they don't have any local cache anyway.. So like everytime they need to check something they have to do another query.. Which might be like every freaking minute anyway. But atleast I can cache is locally vs having to do an external query for it every 5 freaking minutes.
I have yet to find any issue with setting a 1 hour min ttl, other than a drastic reduction in number of external lookups.
edit: But then again I understand how dns works, and if having some sort of problem I would know exactly where to look, and validate it against authoritative NS for whatever, etc. I wouldn't suggest normal users adjust such settings.. So I could see how someone with out actual real world experience in crazy low ttls and how to deal with them might just state best practice.. Which back in the day, no you shouldn't mess with ttls like that.. But then again 10 years ago you wouldn't find services setting 60 second ttls ;) Nor did we have a shit ton of iot devices with no local dns cache trying to ping home to some fqdn every freaking minute ;)
edit2: example just 1 of the fqdn my thermostat looks for every freaking minute
Because it doesn't have a freaking local cache!! And its also just cname that points to place, that has a 60 second TTL..
So this 1 device could create a crazy amount of dns
;; ANSWER SECTION: ic3messaging.cloudapp.net. 60 IN A 13.84.163.27Yep, I had a robot vacuum that was doing the same thing, it was so bad someone wrote a firmware for it and provided instructions on how to hack it so it would stop calling home, it didn't respect the TTL at all. BTW I was doing the same thing when I was running PiHole as well.
-
@bigjohns97 said in talosintelligence.com domain requests:
it was so bad someone wrote a firmware for it
Nice!! Yeah some of this iot stuff is just horrible.. I have some smart power switches that use a uk ntp pool to sync time with.. Even though have the US model, and these companies are suppose to get their own vendor fqdn if they want to use the ntp pool.
So I setup host override to just point that to my local ntp server, because they don't honor what you hand out via dhcp, etc..
How much extra ram or coding would it take to just run a local cache.. I mean they are only looking for handful of fqdn.. Not a big issue say if you had 1 or 2 devices doing such nonsense. But when you start having 30 and 40 devices in a home all doing this nonsense - it becomes crazy very quickly. I have like 8 smart bulbs, and 5 or so smart switches, and then stuff like rokus and tvs, and all other kinds of iot stuff.. All doing queries for something every freaking minute.. To be honest I could see how some of these shitty implementations of caching ns on most of your soho routers could have issues with the number of queries that can build up..
-
I ended up resolving this issue by completely deleting the feed that was pointing to this domain, disabling the feed did not help, this is what has caused me so much time as I figured disabling the feed wouldn't query the domain but I guess the cron job still goes through and checks for an update even though it doesn't apply it.
Anyways deleting this list from my ipv4 pri1 lists kept the domain from querying over and over again and now my dns reply report is nice a clean again.
-
@bigjohns97 said in talosintelligence.com domain requests:
deleting this list from my ipv4 pri1
What list specifically - a fqdn is not a list to be downloaded what was the full url?
-
@johnpoz It was the Talos feed
https://www.talosintelligence.com/feeds/ip-filter.blf
I had also found some threads that were pointing to updating that URL to another one that worked better.
https://www.reddit.com/r/pfBlockerNG/comments/ibllbk/talos_ip_list_url/
And BTW I thought I had this fixed by running an out of band CRON as a test but looking at it again this morning I see this in my DNS replies again and don't even have the list defined, so obviously more work to do.
-
that url redirects to here
https://snort-org-site.s3.amazonaws.com/production/document_files/files/000/001/238/original/ip_filter.blf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIXACIED2SPMSC7GA%2F20200930%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20200930T125635Z&X-Amz-Expires=3600&X-Amz-SignedHeaders=host&X-Amz-Signature=ee8d075152fa77b1fbdec3f88502b35c40c9ca02472fb513251307db4dc2c382
I would guess has something to do with how they are doing the redirection?
first it redirects to here
https://snort.org/downloads/ip-block-listand then from there it redirects to that long url posted above... Looks to be a big mess if you ask me.. So yeah sure could see why some automated system could run into issues or a loop. Especially if using something like curl that might not be able to follow redirection.. Depending on how its done, etc.
-
@johnpoz Yeah I just don't get it, I deleted this feed yesterday and ran CRON and no hits in the reply list, and then I check again this morning and it's back, I don't know where it's defined at this point.
I am going to re-add it from the list again and reboot and see if it comes back
reboot is the only thing I know to make the queries stop once they start...
killing my uptime stats :)
Re-adding it under the original URL in the published feeds list doesn't solve the issue either.
I am at a loss of next steps :(
-
Added it and then removed it again and rebooted and something else is calling this domain and it's not through a feed, so I guess I am back where I started.
If anyone has any idea where this is coming from I am willing to disable something to test.
-
I don't know what it was but I ended up blowing everything away and starting over, now running with ESXi underneath and 2.4.5p1 and this issue is no longer happening.
-
Are you seeing "any" of those A queries for what looks to be IP addresses?
-
@johnpoz No I wasn't these were only DNS queries in the DNS reply tab under reports.
-
Oh my bad - I might of confused this thread with a different one, where there was A queries for stuff like 080.010.149.001, etc..
Sorry.. Forget I asked that question ;) hehehe
-
Just wanted to provide an update to this thread as someone helped me find the issue that was causing this.
NtopNG has threat feeds in it now and when it can't get to one of the feeds it just keeps trying and trying.
To disable you have to go into the admin interface go to settings and category lists and then disable the offending list giving you an issue. I went ahead and disabled all of them since this was such a problem to find as well as these lists seem to go up and down and I don't want it to just keep trying (outside of its setting to only pull them down daily).
