[SOLVED] DNS query to Barak-Online.net every 5 mins
-
Ok just did a sniff for well over an hour 73 minutes on my wan for dns.. no barak anything..
Arrrgh!!! Thanks for looking.
-
dude this is the strangest thing I have heard of in a long time..
Not sure exactly how you would track it down - with udp being stateless, might be hard to track down the PID via the source port of the traffic. You might get lucking if you can catch it fast enough.. you mention every 5 minutes, is it on the dot every 5.. If so you might be able to time it and catch the pid from the source port of the queries.
In linux something like this would work https://www.rfxn.com/projects/linux-socket-monitor/
But I don't know of how to do this in freebsd currently.
-
Indeed…. one of the oddest things i've seen. The query is "on the button" @ 5 mins.
11:37:49.382567 IP (tos 0x0, ttl 64, id 47829, offset 0, flags [none], proto UDP (17), length 62) 50.150.18.229.64683 > 208.67.222.220.53: 355+ A? barak-online.net. (34) 11:37:49.406707 IP (tos 0x20, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 78) 208.67.222.220.53 > 50.150.18.229.64683: 355 1/0/0 barak-online.net. A 62.0.18.221 (50) 11:37:49.406763 IP (tos 0x0, ttl 64, id 40068, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.42359 > 208.67.222.220.53: 356+ AAAA? barak-online.net. (34) -- 11:42:49.380485 IP (tos 0x0, ttl 64, id 8495, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.28282 > 208.67.222.220.53: 357+ A? barak-online.net. (34) 11:42:49.407708 IP (tos 0x20, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 78) 208.67.222.220.53 ><wan ip="">.28282: 357 1/0/0 barak-online.net. A 62.0.18.221 (50) 11:42:49.407770 IP (tos 0x0, ttl 64, id 46238, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.63695 > 208.67.222.220.53: 358+ AAAA? barak-online.net. (34) -- 11:47:49.379369 IP (tos 0x0, ttl 64, id 4524, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.56574 > 208.67.222.220.53: 359+ A? barak-online.net. (34) 11:47:49.404707 IP (tos 0x20, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 78) 208.67.222.220.53 ><wan ip="">.56574: 359 1/0/0 barak-online.net. A 62.0.18.221 (50) 11:47:49.404765 IP (tos 0x0, ttl 64, id 63486, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.35980 > 208.67.222.220.53: 360+ AAAA? barak-online.net. (34) -- 11:52:49.380716 IP (tos 0x0, ttl 64, id 15559, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.5139 > 208.67.222.220.53: 361+ A? barak-online.net. (34) 11:52:49.410157 IP (tos 0x20, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 78) 208.67.222.220.53 ><wan ip="">.5139: 361 1/0/0 barak-online.net. A 62.0.18.221 (50) 11:52:49.410210 IP (tos 0x0, ttl 64, id 36986, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.35073 > 208.67.222.220.53: 362+ AAAA? barak-online.net. (34) -- 11:57:49.381595 IP (tos 0x0, ttl 64, id 34228, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.29016 > 208.67.222.220.53: 363+ A? barak-online.net. (34) 11:57:49.407406 IP (tos 0x20, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 78) 208.67.222.220.53 ><wan ip="">.29016: 363 1/0/0 barak-online.net. A 62.0.18.221 (50) 11:57:49.407463 IP (tos 0x0, ttl 64, id 8312, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.5555 > 208.67.222.220.53: 364+ AAAA? barak-online.net. (34) -- 12:02:49.379956 IP (tos 0x0, ttl 64, id 38215, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.27535 > 208.67.222.220.53: 365+ A? barak-online.net. (34) 12:02:49.405307 IP (tos 0x20, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 78) 208.67.222.220.53 ><wan ip="">.27535: 365 1/0/0 barak-online.net. A 62.0.18.221 (50) 12:02:49.405369 IP (tos 0x0, ttl 64, id 27631, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.29510 > 208.67.222.220.53: 366+ AAAA? barak-online.net. (34) -- 12:07:49.380314 IP (tos 0x0, ttl 64, id 10174, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.41151 > 208.67.222.220.53: 367+ A? barak-online.net. (34) 12:07:49.406860 IP (tos 0x20, ttl 53, id 0, offset 0, flags [DF], proto UDP (17), length 78) 208.67.222.220.53 ><wan ip="">.41151: 367 1/0/0 barak-online.net. A 62.0.18.221 (50) 12:07:49.406915 IP (tos 0x0, ttl 64, id 62668, offset 0, flags [none], proto UDP (17), length 62) <wan ip="">.39686 > 208.67.222.220.53: 368+ AAAA? barak-online.net. (34)</wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan></wan>
Even when I disconnect the lan port and reconnect, it keeps the same time. That has to be "hardcoded" in the process. I mean if its looking for linkup first, then that should be T0 and start from there. However, that is not the case.
I did catch the source port before my original post. I tracked in diagnostics/states before it cleared. It still pointed to my pfsense box; I also noticed no connection is made to the resolved IP address from the DNS query.
What I am stepping through now?
1. Saving config
2. Removing one package at a time and check
3. Download pfsense 2.1 amd64 from diff mirror (last md5 from BluegrassNet was good)
4. Re-install w/o additional packages and check.
5. Add one package at a time while checking.I don't remember asking Santa for this; maybe I was bad? :)
-
update:
Booted to LiveCD without any packages.
No DNS queries to that site yet [30mins]… also confirms not coming from LAN.
Will install bare install to HD, then install one new package at a time.
-
DOH!!!! It was an alias.
Odds are, I made a bonehead mistake….checking configs now.
Bottom line, when I remove the alias, the queries stop (of course). This would explain the behavior and sourced from pfsense ;)
Odd part is, I put that there to stop the queries from going out in the first place and it's likely I cleaned the host that first sent the request.
(put myself in a loop) :)
I'll report back later - even if I discover it's my blunder. At least I know ext aliases are resolved every 5 mins - LOL
-
Yep. That is what it was.
I set up an alias to block the traffic to that domain and forgot about it. I assume I removed the host which originally sent the request and in the process, exacerbated the problem by building an alias and fw rule to block the traffic to the resolved addy.
Silly me!
-
Well atleast there is an answer ;)
-
Yea man. Thanks for jumping in.
BTW.. Just donated:
Confirmation number: 8RN66929KY7900047Great product - complimented by great folks.
-
Awesome thread, like a textbook exercise in troubleshooting. :)
I wonder what was calling out to the URL originally?Steve
-
Me too! My curiosity has been growing since.
I will restore one of the PC images on a VM this weekend and report back.
Thanks… I hope this helps someone with a similar issue - self inflicted or not LOL