Re: Malicious-DNS

Or do the combination, setup the fake server and use tcpdump or wireshark to capture all access. That should catch all ports and protocols. On 18-02-2019 21.05, Kevin Darcy wrote: > Another approach is to define a "fake" vitaminc.pro > domain, point it at an internal webserve

Re: Malicious-DNS

Another approach is to define a "fake" vitaminc.pro domain, point it at an internal webserver (assuming you have a spare, or can spin one up for the purpose), and see what clients are hitting it. Of course, that assumes the communication is web-based. If it's some other protocol(s), you'd need to

Re:

I've already posted a solution for this. Basically, "Define root zone. Delegate teamviewer.com from root zone. Define teamviewer.com as 'type forward'". "Recursion yes" is implied. No views necessary. It doesn't make any sense anyway, to have the same match-clients list for all of one's views, sin

[no subject]

Dear I've implemented two views, one for local resolution and the other for forward a public zone to our resolver. But now I have a problem: If I define the same clients for the local zone view and forward view, depending on the order of the views the client can resolve or not the query. In this

Re: Malicious-DNS

MEjaz wrote: > > If I enabled the system performs will slow down? Depends on how much load your servers are under and what their capacity is. An alternative to query logs, when you are searching for a known query name, is to use tcpdump. It's a tedious and fiddly to convert the name to DNS wire